Archive for ‘Oracle’

« Older Entries  |  
May 21, 2013

How to NOT buy enterprise software

by Roman Kharkovski

Recently I had a discussion with a certain retail company in US about their enterprise integration initiative. One of the things that struck me was the way they are comparing costs of potential ESB solutions. Here are some of the assumptions they are making when comparing the costs:

  1. “We asked both vendors for the quote of their ESB product for 24 Intel cores”
  2. “We asked two of our partners for the services quote to implement the solution using ESBs from IBM and Vendor Red”
  3. “We are assuming that license terms and conditions for the ESB software are the same between both vendors”
  4. “We assume that operational costs of IBM and Vendor Red ESB are more or less the same”

I have been in the middleware business for over 18 years now and unfortunately these kinds of assumptions are used over and over again. My discussion yesterday was about ESB, but I have seen these assumptions applied to databases, application servers, messaging, caching, portals and other kinds of enterprise middleware. How unfortunate. Not only this is not fare to vendors, but first and foremost these assumptions are counter productive for the very company that is evaluating the software. Let me consider these one by one and explain why you should NOT be using these in your decision process.

“We asked both vendors for the quote of their ESB product for 24 Intel cores”

What this really means is that the company has sent a request to vendors to quote a certain number of licenses for a fixed hardware configuration. What is wrong with this assumption? Aren’t all ESBs created equal? No, they are not.

If you shop for a car, would you ask for a quote on Ford Focus vs. Ferrari 458? These are both cars, but they have different characteristics and different speeds.

If you shop for a bike to race in triathlon, would you compare price on a bike from WalMart vs. a Felt or Cervelo bike? You can ride any of those bikes, but you sure can’t compare them on price alone.

Same thing with software. You just can not compare the license cost for a single core and assume you get the same performance out of that configuration using arbitrary ESB (or other middleware) product. Lets assume you need to handle 1 million transactions per hour. How many cores of the ESB product do you need to handle the workload?

IBM performance team publishes detailed performance reports for WebSphere MQ and WebSphere Message Broker (all found on Support Packs page). In my earlier article comparing WebSphere Message Broker and Oracle Service Bus, I have used an example of such report for WMB v8 on Linux x86. I have not seen any public performance data for Oracle Service Bus, nor tuning recommendations for specific platforms and protocols. The following table shows the message rates that were obtained for the different use cases when running on a IBM xSeries x3690 X5 with 2 x Deca-Core Intel Xeon E7-2860 2.27GHz processors:

performance

Your company integration logic is likely to be a mix of workloads listed above. For the sake of discussion, let me assume that the average throughput of your application on WebSphere Message Broker is 9,000 transactions per second on the above configuration. This translates to about 450 transactions per second per processor core. 1M transactions per hour is roughly 278 transactions per second. This means you can handle your integration workload with a single core of Message Broker and still have capacity on that core to handle 40% more transactions.

Does this mean you would also need only a single core of the other vendor ESB product? Not necessarily. I have seen many performance POCs at many different customers in US and abroad where performance results of Message Broker were order of magnitude better than that of competition (in particular vendor Red ESB). I also did performance tests of my own where I have seen 2 to 5 times performance advantage of Message Broker over this other ESB product for workloads such as file parsing, database access (read and write), WebSphere MQ interaction and XML payload handling over HTTP and MQ protocols. Unfortunately I can’t publish my performance report since Oracle license agreement requires me to get their written permission to do so. And given the results, I know they wont approve…

You might say that ESB is a very special case and there is no industry standard for ESBs. What about Java EE servers? Those are all standards based and surely are not very different from each other. They all run on Java and all implement similar APIs. Why bother with the sizing? Wrong again. As you can see in this blog article that compares price performance of WebSphere vs. WebLogic – you do get different transactions per core ratio when running different vendor’s application servers. In the case of IBM WebSphere on Power7+ you get twice as many transactions per core compared to WebLogic on SPARC T5. To borrow from that article, here is a comparison of transactions per core for application servers (thank goodness SPEC.org is a public benchmark, so I do not need to get Oracle permission for this comparison):

specj_history

Bottom line – you simply CAN NOT make an assumption that you need the same number of cores for different vendor products to handle the same workload.

“We asked two of our partners for the services quote to implement the solution using ESBs from IBM and Vendor Red”

Implementation costs are very difficult to estimate and comparing bids from different integrators is very hard. There are simply too many variables and risks involved. Never mind the risk of not ever finishing the project, such as this example of a failed multi-billion dollar Oracle implementation.

How do you compare the implementation costs then if you can’t fully trust your integrator bids? This is more art than it is a science, but at the very least, I would highly recommend that you try to implement at least a small pilot project yourself to get a feel for the software. After all it is your business and you need to have at least some first hand experience with the software. You do not need to do a full implementation yourself, it is perfectly fine to hire 3rd party integrator to do the bulk of the work for you, but you are the one ultimately responsible for the implementation.

Download the software, install it and try to build something with it. Spend no less than one week with one vendor product and one week with another – just to get a feel for those products. You might be surprised. Personally I find WebSphere Message Broker very easy to use. Sure, there is a learning curve, but once you get a feel for the product, it becomes very productive. I recorded several demos with Message Broker and Oracle Service Bus – implementing the same integration logic in both products. What takes me 6 minutes and 50 mouse clicks in Message broker, takes over 1 hour and 1,000+ mouse clicks in Oracle Service Bus. Unfortunately I can’t post my demos in the public domain because Oracle license agreement is very restrictive. But you can get a feel for the Oracle Service Bus productivity from this article (not sponsored, nor affiliated with IBM in any way).

“We are assuming that license terms and conditions for the ESB software are the same between both vendors”

I have covered this topic in my other posts and will simply refer you to these articles:

“We assume that operational costs of IBM and Vendor Red ESB are more or less the same”

Operational costs include installation, monitoring, deployment, configuration and many other factors. I will cover these in my future posts in more details, but for now let me make few quick notes on this subject:

  • Installation time of Message Broker is only about 3 minutes as I have documented in this demonstration video. Try installing Oracle Service Bus with all of its prerequisites and compare that to Message Broker. (Tip: You may be able to get around some of the complexity of Oracle install by using shared files system with binaries.)
  • Another consideration is the number of cores and number of machines machines you need to manage. Performance differences require configurations of different sizes and the number of machines in a cluster has direct impact on the difficulty of administration.
  • Performance tuning of Message Broker is well documented in IBM performance reports and public best practices documents. Tuning Oracle Service Bus involves tuning of the JVM, WebLogic Server and Oracle Service Bus itself. Outside of the basic Oracle documentation, there is not much information available to the public on best practices and performance of Oracle Service Bus, nor can you find a single performance or sizing guide report from Oracle on the Oracle Service Bus.

Conclusion

There are many considerations that need to be evaluated when selecting your integration bus and the cost is very important, however one needs to be thoughtful on how to compare costs between different vendors and products. In any case it is a lot more than just comparing a cost for a single core license. You may want to consider experience of companies who decided to move from Oracle to IBM middleware to reduce their costs.

Posted in Oracle | Leave a Comment »

Tags: , , , , , ,
April 29, 2013

WebLogic 12c on Oracle SPARC T5-8 delivers half the transactions per core at double the cost of the WebSphere on IBM Power7

by Roman Kharkovski

Last few weeks brought us two new SPECjEnterprise2010 results – one from Oracle and one from IBM. Both were done using very latest software and hardware. Oracle announced their new SPARC T5 processor with much fanfare and claiming it to be the “fastest processor in the world”. Well, perhaps it is the fastest processor that Oracle has produced, but certainly not the fastest in the world. You see, when you publish industry benchmarks, people may actually compare your results to other vendor’s results. This is exactly what I would like to do in this article.

specj_apr_2013

Full results can be found here:
Oracle total EjOPS: 57,422.17 http://www.spec.org/jEnterprise2010/results/res2013q1/jEnterprise2010-20130305-00041.html
IBM total EjOPS: 13,161.07 http://www.spec.org/jEnterprise2010/results/res2013q2/jEnterprise2010-20130402-00042.html

Being “fastest processor in the world” means that such processor must be able to handle the most transactions per second per processor core, which is how software pricing works and how people size their workloads and control their costs. This is not the proof Oracle delivered with their latest result (see full details on Spec website). To give Oracle credit, their result is the biggest overall 57,422.17 EjOPS (transactions per second). But that is a Total number of transactions, not a measure of the processor speed. To achieve that result, Oracle had to use 128 SPARC T5 cores for the WebLogic 12c and additional 128 cores for the Oracle database! The total cost of the hardware to achieve such high number of Total EjOPS is $1.1 Million. Even more sobering is the list price for the software, which is $5.2 Million (including 3 years of support and using lower priced WebLogic Standard – not even clustered!). If you price Oracle configuration with the WebLogic Enterprise (which does support clustering), your software cost will be $7.7 Million. Overall this latest Oracle result produced 449 EjOPS/core at the cost of $109.45 per EjOPS.

Now look at the IBM result published recently using WebSphere 8.5.5 on Power7+ hardware with DB2 database. IBM did not go after the biggest number of EjOPS (which is just the matter of throwing bunch of hardware together). However IBM produced the world record result in terms of EjOPS per processor core – truly a measure of the fastest processor known to men (for Java EE workloads that is). The total hardware cost of IBM result is $74,000 and the software cost is $766,000 (of which WebSphere is only $72,000 and the rest is DB2). This IBM result delivered world record 823 EjOPS per core with the cost of $63.79 per EjOPS. Now this is almost twice as many transactions per second at almost half of the Oracle cost. Truly remarkable.

Since Oracle knew they can not produce the most efficient result in terms of cost or transactions per second, the only way for them to claim world record was to throw large hardware at it and produce the biggest total number of EjOPS. Not a very useful metric I must admit. Much more interesting is the efficiency – measured in EjOPS per core and most importantly cost of EjOPS.

The story does not end here. Why not take a look at the history of performance results on similar and dissimilar hardware? Why not compare these platforms:

  • IBM WebSphere on Power7+ vs. Oracle WebLogic on SPARC T5 (latest generation hardware – shown above, but just to rub it in)
  • IBM WebSphere on Power7 vs. Oracle WebLogic on SPARC T4 (previous generation hardware for both vendors)
  • IBM WebSphere vs. Oracle WebLogic on Intel Sandy Bridge Xeon E5-2690 (almost identical hardware setup using latest Intel hardware)
  • IBM WebSphere vs. Oracle WebLogic on Intel Westmere Xeon X5690 (almost identical hardware setup using older Intel hardware)

Here is a summary of these results listed above:

specj_history

Here is a brief summary of the IBM WebSphere performance track record since year 2000:

  • Held the most records in ECPerf (pre-2001)
  • FIRST to publish SPECj2001
  • FIRST to publish SPECj2002
  • FIRST and ONLY company to publish SPECj2002 Distributed
  • FIRST to publish SPECj2004 and the only vendor to publish for over 13 months, held #1 spot for most of the time
  • FIRST to publish SPECjEnterprise2010
    • LOWEST cost per transaction as of today
    • BEST performance per core as of today

For additional information, please refer to these performance related articles: http://whywebsphere.com/?s=specj

******************* Notes:

(1) SPEC and SPECjEnterprise2010 are registered trademarks of the Standard Performance Evaluation Corporation. Results from http://www.spec.org as of 04/04/2013 Oracle SUN SPARC T5-8 449 EjOPS/core SPECjEnterprise2010 (Oracle’s WLS best SPECjEnterprise2010 EjOPS/core result on SPARC). IBM Power730 823 EjOPS/core (World Record SPECjEnterprise2010 EJOPS/core result), (2) Results from http://www.spec.org as of 04/29/2012 Oracle SUN SPARC T4-4 313 EjOPS/core SPECjEnterprise2010 (Oracle’s WLS best SPECjEnterprise2010 EjOPS/core result on SPARC). IBM Power780 681 EjOPS/core (World Record SPECjEnterprise2010 EJOPS/core result), (3) Results from http://www.spec.org as of 11/14/2012 Oracle SUN Fire X4170M3 519.39 EjOPS/core SPECjEnterprise2010 (Oracle’s WLS best SPECjEnterprise2010 EjOPS/core result on Sandy Bridge). IBM WAS 8.5 System x3650 M4 Intel Sandy Bridge EjOPS/core (World Record SPECjEnterprise2010 EJOPS/core result) (4) Results from http://www.spec.org as of 04/29/2012 Oracle SUN Blade Server X6270 M2 452.285 EjOPS/core SPECjEnterprise2010). IBM Websphere HS 22 Blade 524.621 EjOPS/core.

Posted in Oracle | 1 Comment »

Tags: , , , , , , , ,
April 24, 2013

Reduce cost and move to a standards based platform by migrating off your Oracle Tuxedo applications

by Roman Kharkovski

This article was written by Hariharan Venkitachalam (IBM).

In this article we want to illustrate the options and the benefits of moving off from the Oracle Tuxedo platform on to a IBM solution. Having talked to several customers we want to highlight and provide insights on the migration process. IBM provides different solutions catering to needs of the clients migrating from Oracle Tuxedo. In brief below are the available solutions:

  1. IBM TXSeries for Multiplatforms and IBM Migration Assistant Tooling for Oracle Tuxedo – helps clients to reuse existing applications.
  2. IBM WebSphere eXtended Transaction Runtime and IBM Migration Assistant Tooling for Oracle Tuxedo – helps clients to modernize their existing COBOL / C / C++ applications and get new features in porting them to the new IBM platform.
  3. IBM Mixed Language Application Modernization Pattern – helps clients to deploy in a cloud ready environment such as IBM PureApplication System or through IBM Workload Deployer.

What values does the IBM solution bring to me? As said there are different solutions from IBM and so it would be best to talk the value add on the context of each solution:

IBM TXSeries for Multiplatforms and IBM Migration Assistant Tooling for Oracle Tuxedo.

IBM TXSeries has been in the market for well over decade and is a mature product; having a wide spread deployment world-wide running across various industries like Banking, Healthcare, Insurance, Retail, Manufacturing, Transportation, and so on.

TXSeries adopts a robust framework of CICS – a famous OLTP platform in the industry. The simplicity of the CICS architecture provides various benefits to that of a Oracle Tuxedo. Firstly, it is proven that TXSeries consumes less CPU power and memory usage to that of Oracle Tuxedo for the same throughput (or a TPS factor). This means you can do more with less. In terms of large deployments, TXSeries scales across different hardware platforms, provides an intuitive work load management, flexibility in deploying applications and refreshing them later with an updated version without requiring to stop your business. Multiple instances of TXSeries systems running on different hardware can talk 2PC (global transaction), provides monitoring through Web based administration tool, Tivoli agents, Web Services SupportPac, WebSphere Business Events SupportPac, IMAT SupportPac…. and all this at no additional cost!

IBM WebSphere eXtended Transaction Runtime and IBM Migration Assistant Tooling for Oracle Tuxedo.

IBM WebSphere eXtended Transaction Runtime offers a first class integration between traditional applications written in C, C++, or COBOL and Java EE applications running on WebSphere environment. This is the best available solution in the market place today to modernize your existing Oracle Tuxedo applications and manage them on the WebSphere environment. The management, deployment and development processes for applications are all integrated with the features provided by IBM WebSphere eXtended Transaction Runtime technology, and couple this with the feature pack that provides the IBM Migration Assistant Tooling for Oracle Tuxedo that helps you to migrate off your existing Oracle Tuxedo applications.

This solution helps in standardizing your entire application environment including Oracle Tuxedo applications based on the WebSphere infrastructure with proven high availability, scalability, work load balancing, security contexts, etc. With this you do not have to maintain or buy additional components for managing Oracle Tuxedo applications compared to your Java EE applications.

IBM Mixed Language Application Modernization Pattern

IBM Mixed Language Application Modernization Pattern helps clients to deploy in a cloud ready environment such as IBM PureApplication System or through IBM Workload Deployer. This solution leverages the capability of the IBM WebSphere eXtended Transaction Runtime technology as described above. In addition this solution provides a cloud-ready solution to run your existing Oracle Tuxedo application on to a IBM Cloud platform. IBM Mixed Language Application Modernization Pattern is a virtual application pattern that allows you to run COBOL, C and C++ applications on a modern cloud ready environment.

Migration Assessment

The migration assessment starts with a discovery process. IBM has developed a migration questionnaire that we send to our clients in advance of a discovery call. The questionnaire enables us to get a basic understanding of the existing application environment so that we can ask more appropriate questions, dig deeper in to their application environment and estimate more accurately the potential problems and issues facing the migration on to a IBM technology.

One of the must to understand in terms of Oracle Tuxedo migration is the services used within their existing Oracle Tuxedo applications such as the ATMI API. This can be done either by scanning the source of the application code and looking for ATMI API or to make it even easier we provide a analyzer tool that generates a summary report on the usage of Tuxedo services within the application and if they would be supported with IBM solutions.

We then usually proceed for a proof of concept to migrate a subset of TUXEDO application to the target IBM solution. It helps to validate the target solution that is being offered and can offer further guidance on how the rest of the application migrations could be migrated.

Our initial focus is to retain the existing application in an as-is form as much as possible. However as we work through the migrations we further add value and benefits in terms of providing a better unified management environment for the applications, better tools, other non functional aspects such as scalability, high availability and a future-proof compatible applications that can be run on CICS Transaction Server for z/OS.

How does IBM Migration Assistant Tooling for Oracle Tuxedo (IMAT) can help?

IMAT tool provides you the necessary tools that lets you to migrate your existing Oracle Tuxedo based application on a IBM Solution seamlessly, without requiring considerable effort…During the migration process, your application remains as-is – this is a key benefit in the migration projects which are quite sensitive to any changes done in the application business logic. Also you might think that being new to a IBM environment, it would require a larger learning curve – but this is not the case with IMAT… it is equipped will all the tools required with which you continue to develop and deploy your application as you were doing in the Oracle Tuxedo environment! Isn’t this a great boon for such migration? Less learning and quick deployments of your existing applications! This is why we call IMAT an S.M.A.R.T migration offering. You can continue to maintain your existing applications and new application can be written to take advantage of the CICS Application Programming sets.

Does IMAT change my application code?

Not really. We have had proof of concepts where we have done the migration of applications without modifying a single line of code in the existing applications… Even the Makefile or the build scripts used to build the application remain unchanged except for the libraries that needs to be link-edited to the one provided by IMAT tool.

Bullet proof investment for the future

One unique advantage moving to an IBM solution is that your applications become compatible with the best quality of service platforms such as CICS Transaction Server for z/OS if you wish to scale over the roof… With the z Enterprise one can consolidate all the heterogeneous hardware in to one single box with the reliability that you can only get from IBM mainframe.

More Information

 

Posted in Oracle | 1 Comment »

Tags: , , , , , , ,
April 11, 2013

WebSphere Message Broker vs. Oracle Service Bus: comparison of adapters and protocols support

by Roman Kharkovski

Enterprise Service Bus (ESB) is by definition required to provide universal connectivity to many different systems that the enterprise needs to connect together. Therefore many ESB vendors provide extensive library of connectors for their products. In this article I will compare adapters and protocols supported by latest versions (as of this writing) of ESB products sold by IBM and Oracle:

  • IBM WebSphere Message Broker v8.0.0.2
    and
  • Oracle Service Bus 11g (11.1.1.7)

Such comparison needs to be done at the technical level (i.e. what? and how?) and also at the financial level (how much?). I researched public information for both vendors using their websites, documentation and google (duh) and came up with a list of adapters and protocols as well as the cost of those connectors. Before I show you the actual comparison, let me make general observations and conclusions from my comparison:

  • IBM provides more diverse set of adapters and protocols compared to Oracle offering.
  • IBM tends to include adapters for free, while Oracle charges for adapters based on per core basis.
  • Both IBM and Oracle provide additional for a fee industry specific protocols to extend their ESB offerings.
  • Both IBM and Oracle provide toolkit so that users can build custom adapters.
  • The list below only represents adapters and connectors officially supported by IBM or Oracle respectively, but you can find additional implementations on the internet (supported by community).
  • In this article I do not have time nor space to evaluate the quality of each adapter and connector, but I think the quality trumps quantity. For some adapters that I have evaluated in the lab environment I found quality of IBM adapters to be significantly higher than Oracle’s (for example File adapter, Database Adapter, FTP, WebSphere MQ – more on this later in the article).

Once again, I think quality is a major consideration and I can’t say that enough. Before you make a decision one way or the other, I highly recommend that you actually test the product in the lab environment and validate ease of use, security, performance and other characteristics. For example, I have seen dramatic performance differences between WMB and OSB in the order of magnitude with file and database adapters (WMB being faster, of course). I believe part of the WMB performance advantage comes from the fact that unlike OSB, it does not force payloads to be converted into XML on the input and then back from XML to whatever format on the output from the message flow (proxy in OSB terms). Buyer beware!

table1

table2

Notes:
* – included free of charge with WMB Advanced v8
** – these are JCA adapters and can be used in WAS

In addition to the adapters and protocols mentioned above, there are additional industry specific pre-built flows, message formats and specialized adapters that are provided with WMB and OSB (not all of them are included above). These pre-built components are designed to simplify development and thus shorten implementation time:

table3

Ease of use and small footprint are important considerations. Especially if you are building integration layer as part of your private or public cloud environment or doing multi tenancy and need to be able to add and remove instances of ESB quickly. I have measured the speed of installation for WMQ and WMB and as you can see from this video even  using interactive method on my laptop I was able to fully install WMQ in 43 seconds and WMB in 1min 44 seconds. Using silent script to install these products and removing local install of MQ Explorer will reduce this time down to under 2 minutes total. Startup times for WMQ and WMB on my laptop are under 10 seconds. How long do you think it takes to install Oracle Service Bus and all of its prerequisites? (hint – hours). How long does it take to start and stop? (hint – minutes). Oracle license agreement does not allow me to publish these numbers in the public domain without Oracle’s written permission, but you can try installing OSB yourself and will probably see orders of magnitude difference:

video

I mentioned above that the quality of adapters and provided features provided by IBM and Oracle is not the same. Lets consider WebSphere MQ adapter as an example. As you can see from the table below IBM WMB provides much stronger integration with WMQ (as expected) by providing support for latest versions of WMQ, better performance, management and lower cost as WMQ is included with WMB at no extra charge (so long as messages are consumed or produced via Broker):

integration-w-WMQ

Lets take a look at other adapters and consider transaction control capabilities of those adapters. While both WMB and OSB allow one to connect to remote systems, there is a difference between the two products in their ability to coordinate distributed transactions. This is a very common pattern for ESB – get message from the queue, update certain database, perhaps update another database and send message via another queue, perhaps even update CICS or IMS too. Ability to coordinate distributed 2 phase commit (2PC or XA) transactions is key for ESB product. WebSphere Message Broker shines in this area as you can see from the table  below:

transactions

Performance is another critical consideration for an ESB. IBM performance team publishes detailed performance reports for WebSphere MQ and WebSphere Message Broker (all found on Support Packs page).

Here is an example of such report for WMB v8 on Linux x86. I have not seen any public performance data for Oracle Service Bus, nor tuning recommendations for specific platforms and protocols. The following table shows the message rates that were obtained for the different use cases when running on a IBM xSeries x3690 X5 with 2 x Deca-Core Intel Xeon E7-2860 2.27GHz processors:

performance

I would love to share with you performance of Oracle Service Bus for the above workloads, but Oracle license agreement requires me to get their written permission to publish OSB results and given the performance difference between WMB and OSB, I do not think I will get such permission any time soon :-) .

See related articles:

Posted in Oracle | 1 Comment »

Tags: , , , , , , , , , ,
April 2, 2013

Migrate Off Java CAPS With Less Risk And Cost

by Eric Berg

I’ve spoken to many companies about moving from Java CAPS (or the predecessor SeeBeyond platform) to WebSphere. I thought I would share with you a little insight into how we approach these migrations in order to help organizations reduce the costs and risks associated with the replacement.

Why choose IBM connectivity solutions over Oracle?  Go here to learn why WebSphere is the smarter choice.

I won’t spend time discussing why there is a need to replace Java CAPS infrastructure (you can find a quick summary here).  Safe to say that anyone running this platform is likely to understand that it is imperative they develop and execute a roadmap to a new integration platform.  The problem most organizations face is that they have a significant investment in the existing platform in the form of code artifacts, the details of which are not necessarily well documented, that they are reluctant to lose.  Additionally, there is a concern with both costs and risks in order to replace the “plumbing” between  applications, a project that might at first glance be perceived as not delivering an immediate business benefit.  Our focus is primarily placed on helping customers make the move to WebSphere Message Broker, though there have been some cases where other WebSphere target platforms may make more sense depending on what version and parts of the Java CAPS software stack were in use (e.g., BPEL processes).  Here’s a video that outlines some of the key capabilities of WebSphere Message Broker:

We’ve understood these concerns and have developed both an approach to the migration as well as a set of tools that helps to preserve current investments.  The approach we take to migrating off Java CAPS (a no charge service offering – based on the WebLogic to WebSphere migration discussed here) consists of three basic steps – a Discovery, followed by a Migration Assessment, and then finally providing guidance, best practices, and support around the Full Migration.

Discovery

Our team has developed a migration questionnaire we send to our client in advance of a scheduled Discovery call.  The questionnaire helps us gain a basic understanding of the existing environment, the scope of the integration applications that need to be migrated, a review of testing practices, as well as giving us a chance to review any documentation that exists for the implementation.  Next we meet with the client, typically via conference call, to review the responses and dig deeper into any areas where we need more information.  Use of the questionnaire helps make the Discovery call an efficient use of everyone’s time, and allows us to be very focused when the team arrives for the onsite Migration Assessment.  The output of this step is a basic understanding of the current infrastructure, an understanding of what a future state infrastructure needs to deliver, as well as identifying candidate areas for detailed investigation.

Migration Assessment

This step is where we dig into the details of the Java CAPS implementation.  Through the Discovery step we’ve typically identified some example code artifacts, such as OTD’s / ETD’s and Java Collaborations, that we can examine in detail. This step allows us to assess the applicability of our migration tools as well as identify any areas where manual effort needs to augment or replace what we can deliver through automated conversion.  The team will also conduct architectural and functional reviews of the system.  The output for this step is a full migration plan that includes a timeline with migration steps, level of effort, and a risk mitigation plan.  The team follows up the onsite portion of this work with a presentation of the findings and recommendations that include the migration plan deliverables outlined.

This step may be augmented with a proof of concept to migrate an example integration program to the target WebSphere environment.  This work helps to build confidence in your team around how the migration can take place, serving as an example for which to build your “migration factory”.  It also helps us to identify any specific issues with your artifacts, allowing us to further refine your migration plan.

Full Migration

Once the migration plan has been delivered, you are free to engage whatever resources you would like to use to conduct the full migration.  Some of our clients have chosen to use their own IT staff for the migration, others have engaged service delivery partners, and IBM has consulting services (IBM GBS or IBM Software Services for WebSphere) that can be used as needed.  In many cases our clients choose to use a blended approach in order to ensure they have the most efficient use of resources while also having the right expertise at the right time.

In any case, our Migration Team will stay engaged to relay their experience and answer questions as they arise.

In a future post I’ll provide some more information on the investment IBM has made developing tools to help automate the conversion of Java CAPS / SeeBeyond environments to WebSphere.  One of the recent developments we’ve had in this area is to add support for the conversion of Monk code, so anyone with an older e*Gate implementation can benefit from our tools investment as well.

Interested in learning more about how to migrate your Java CAPS environment to WebSphere?  Contact us at whywebsphere@gmail.com.

Posted in Oracle | 1 Comment »

March 25, 2013

How does IBM connectivity and integration portfolio compare to Oracle?

by Roman Kharkovski

Back in 2007 Kevin Kelly in his TED talk has made predictions about the future of the Internet. It turns out he was right. Applications talking directly to each other are a norm today. Of course, those of us who were in what was called at the time EAI (Enterprise Application Integration) knew that already, but the general public did not appreciate the value of universal connectivity. Until now. These days everyone talks about APIs, standard formats for data, etc. However the truth is, while social networks and public web is built on standards, the vast majority of enterprise data is still locked in proprietary systems, accessed by proprietary APIs, or worse, via file exchanges or direct access to the database (yeah, its you, pre-internet Oracle eBusiness Suite).

The ability of enterprises to create new applications is limited by the ways those applications can reuse existing business logic and data. This explains huge interest in messaging and connectivity products. Some call them ESBs, others call them SOA products, but no matter what you call it, this kind of specialized middleware must provide a set of capabilities that make it easier to connect to many different types of old and new applications, data formats, protocols and be able to perform transformation of the above mentioned things. Synchronous, asynchronous, transactional, reliable and high performance capabilities are a big plus (as they say in job postings).

Where there is demand, there is usually supply. In case of IBM and Oracle, both vendors provide a set of offerings that claim to solve the problem of connectivity. Both vendors claim that they have the “most complete integration solution on the planet”. I decided to take a look and compare. In this first article of the series I will simply look at the products at a high level and in subsequent articles will look into specifics and more in-depth technical and financial TCO comparisons between products. Here is how offerings from these two vendors stack up to each other. Please note that color coding on this comparison is meant to reflect the strength of the product based on (a) Technical capabilities (performance, feature richness, security, scalability, etc.) and (b) Market position (number of users, market share, history, release schedules, analysts’ feedback, etc.)

product_map_1

* – IBM MobileFirst MessageSight messaging appliance is scheduled for general availability in second quarter of this year.

From the table above you can see that Oracle does provide several important connectivity products, but is missing a number of important components from the platform and is far from being “complete”. In future posts I will compare individual products at a much deeper level, but in the meantime, you can learn more about IBM and Oracle offerings here:

Posted in Oracle | 2 Comments »

Tags: , , , , , , , , ,
February 25, 2013

The Oracle Forms Dilemma – part 1

by Eric Berg
A common challenge that organizations have is determining what they should do about legacy applications built on older technology platforms.  These apps often don’t fit well with their plans to implement a modern, scalable, and secure services-based infrastructure but the path to replacing those apps is not necessarily clear.  A prime example of this dilemma is addressing the considerable investments they have tied up in Oracle Forms applications. Oracle Forms has been around for a very long time, so organizations that have been using it for any period of time will probably have lots of Forms applications, most having outdated user interfaces with hard coded business logic that is not well understood.  Although the latest version of Oracle Forms (11g) has the ability to interact with elements of Fusion Middleware 11g, that interaction is very limited.Oracle considers Forms to be a “mature” technology so not much has actually changed with Forms or is likely to change any time soon.  Although Oracle has stated that Forms is not going away, Oracle Application Development Framework (ADF) is firmly established as their strategic platform for application development going forward, with no plans to provide a migration path for existing Forms customers.In this post I wanted to discuss some of the business drivers for replacing Forms applications as well as some considerations for identifying which Forms applications to replace or modernize. In a future post I’ll discuss some of the options you should be considering to support your modernization and replacement plans.Why you should replace your Oracle Forms applicationsThere are several obvious reasons for replacing Oracle Forms applications.First, customers who have been using Forms for a significant period of time probably have applications built by developers who left the organization and have left behind little or no documentation.  These apps are unlikely to be understood all that well by your current team of developers so time must be spent investigating the app whenever there is an issue or a new requirement to be implemented, increasing support, development, and testing costs.  Further, the Forms specific skill sets for maintaining these applications have over time become harder to find and retain – after all, who wants to work on 1980’s technology?  These factors all contribute to rising support costs that are adversely impacting total cost of ownership.A common complaint with Forms applications is that they are using old, outdated user interfaces, resulting in low user adoption and poor user satisfaction.  The workforce of today is used to modern web interfaces with usability paradigms that are inconsistent with the way these older Forms applications were designed to work.  Further, the Forms UI’s miss out on the move towards incorporating new capabilities such as social business features or supporting new channels like mobile, which most organizations realize is becoming an imperative.

Another pressing issue is that the business logic contained within these apps has been hard coded, which makes them difficult to update as market conditions change and processes are updated.  This can impact your organization’s business agility, leaving you exposed to competitor threats and potentially missing important market opportunities. Certainly there is a risk that users – both internal and external to your organization – are left dissatisfied when changes cannot be made or delivered on time.

So, our next question is “why shouldn’t I adopt Oracle ADF as a replacement for Forms?”  Certainly there are plenty of organizations that have gone that route.  ADF is a platform for developing applications that use several standards based technologies (e.g. Java skills, web development skills, etc.).  However, there are several reasons why you might not want to go down this path:

  • ADF is a heavyweight proprietary development framework, effectively locking you into the Oracle stack of software
  • ADF has a significant learning curve, so don’t expect that just because a your staff has some familiarity with Oracle’s SOA stack that picking up and running with ADF is a given – it will require some significant investments in skills development
  • Some have complained about the slow page performance of ADF applications due to the complex generated javascript and html
  • ADF uses its own javascript libraries, which are large and difficult to modify with no real option to use Eclipse, which many developers are more accustomed to using

So for many organizations it makes far more sense to consider standards based alternatives to ADF that make use of lightweight frameworks that provide more flexibility and choice.

Considerations for modernizing and replacing Forms applications

So assuming you have a wide range of Forms apps, your first task is to build an inventory of all Forms apps and then examine how these apps are maintained and what changes are actually required.  Some have probably been in use for years doing their job, with few new requirements and no significant usability issues, no need to support new channels like mobile, no new integrations needed, or any of the other typical drivers for application change.  These are obviously the cases where it makes the most sense to just leave the app alone. Start with the assumption that not all Forms apps will need to be replaced and stay focused on those apps where there is a solid business case to replace.

Your next set of Forms apps are those where usability might be an issue, but for the most part the app does its job and could use just a bit of modernizing.  Solutions such as exposing the app through a portal, treating them as back office apps that are called through a workflow, or wrapping the Forms app as a web service and calling on them to deliver a business function as needed are all reasonable ways to deal with this group of apps.  This type of modernizing is again going to be the hallmark of apps that are undergoing very little change so these approaches help avoid unnecessary migration costs and risks.

The key is to identify the apps in the inventory that have been costly to maintain, or cases where new requirements are being raised.  Look for cases where the business logic must be updated regularly, where the app needs to be delivered through new channels such as mobile, or cases where there the Forms app must be integrated with several other applications.

Once you’ve identified this group, focus on building the business case for moving the app to a new platform.  Unless you’ve got a clear and compelling business case it is unlikely you will ever see the funding for the replacement. There are a lot of different ways to go through the decision process to determine which apps to leave alone, which to modernize, and which to replace.  There will certainly be many borderline cases as well.  The key is to identify the costs associated with the apps – licensing, subscription & support, maintenance, development, testing, etc. as well as costs that may be harder to measure, such as productivity and usability. Ask the business users of these apps about their pain points and the opportunity costs of continuing to use these applications.  Pulling together this focused inventory of Forms apps along with the hard and soft costs will go a long ways towards moving down the path to replacement.

Posted in Oracle | Leave a Comment »

Tags: , , ,
February 6, 2013

SPECjEnterprise2010 benchmark – IBM beats Oracle on performance and cost

by Roman Kharkovski

It has been quite some time since I wrote about the SPECj battles between IBM and Oracle. Today I would like to discuss the rare case of an “apples to apples” comparison between IBM and Oracle on almost identical hardware. It is not often that we get to see results published by different vendors on the identical processor types on servers with very similar configurations. Such rare comparison point became possible thanks to IBM publishing a result in late 2012.

Read full article here: SPECjEnterprise2010 benchmark – IBM beats Oracle on performance and cost.

Posted in Oracle | Leave a Comment »

Tags: , , , , , , , ,
January 8, 2013

Why Canadian D+H has moved from Oracle Fusion Middleware to IBM?

by Roman Kharkovski

“So, while it took us a year to do the development on Oracle Fusion, we were up and running both development and a production service on the DataPower appliance within four months, shockingly fast.” – Paul Lewis, Vice President of Technology, Architecture and Security, D+H.

Davis + Henderson Corporation (D+H) has been a trusted partner to the financial services industry for over 130 years. Today, D+H offers a broad range of technology and technology-based solutions to financial institutions across North America, including commercial and mortgage lending technology, student lending services, collateral registration and recovery services, and payments solutions. Headquartered in Toronto, D+H employs approximately 4,500 people.

In 2010 and 2011 D+H was trying to build a new SOA platform using Oracle Fusion Middleware and Sun GlassFish, but it proved to be exceedingly difficult and after performing several POCs, D+H decided to switch to IBM WebSphere Application Server, IBM DataPower appliances and the IBM DB2 database.

In addition to reducing their costs, D+H has seen 20 to 40 percent performance increases and can now deploy new workloads in hours versus the five days required in the past.

pdf_icon

Read complete case study:

“D+H consolidates its IT environment for improved growth and efficiency”.

Posted in Oracle | Leave a Comment »

Tags: , , , , , , , , , , ,
December 10, 2012

Billion-Dollar Flop

by Roman Kharkovski

Interesting article in NY Times today: “Billion-Dollar Flop: Air Force Stumbles on Software Plan”:

QUOTE: “For the United States Air Force, installing a new software system has certainly proved to be a wicked problem. Last month, it canceled a six-year-old modernization effort that had eaten up more than $1 billion. When the Air Force realized that it would cost another $1 billion just to achieve one-quarter of the capabilities originally planned — and that even then the system would not be fully ready before 2020 — it decided to decamp… The software initiative, called the Expeditionary Combat Support System, was supposed to manage logistics using software from Oracle. In 2006, the Air Force announced that it had awarded a $628 million contract to the Computer Sciences Corporation to serve as lead system integrator…” END QUOTE

Unfortunately the article is not answering some of the key questions one might have after reading it:

  1. As a taxpayer I want to know whether US government will have its money back?
  2. Why exactly the program failed? Was it software’s fault, or vendor incompetence,  or all of the above? (one of the suggested reasons is the desire to do too much at once and lack of central leadership in the project)
  3. How can the Air Force to go forward with the software systems built in 70s?
  4. What disciplinary actions are taken against those who was in charge of spending this much taxpayers money?
  5. What actions are taken against Oracle and CSC? Where there any SLAs set for the project?
    etc.

Posted in Oracle | Leave a Comment »

Tags:
« Older Entries  |  
Follow

Get every new post delivered to your Inbox.

Join 407 other followers

%d bloggers like this: