Author Archive

  |  
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 »

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: , , ,
November 29, 2011

Why Java CAPS customers are choosing WebSphere over Oracle

by Eric Berg

Following Oracle’s acquisition of Sun it was determined, to no one’s surprise, that the Java CAPS middleware suite was not a strategic middleware platform and would be eventually moved to a “sustain” mode for support (in the interim support costs are likely to rise).  What this means to Java CAPS customers is that they would see little or no new investment in the platform.  This raises questions of what they should do about new IT projects (e.g., do you continue to invest development effort in an effectively defunct SOA infrastructure?) as well as the value of the subscription and support dollars currently being spent on the Java CAPS platform.

Oracle would of course prefer to see these customers move to SOA Suite, but despite many promises to deliver migration tooling has done little to bridge the gap from Java CAPS (and especially e-Gate).  Java CAPS customers are essentially left with the choice to throw out their code investments by starting over with a new platform, which brings with it a host of new challenges (new skills to develop, business risk and potential interruptions, etc.).

What many Java CAPS clients are now discovering is that IBM not only offers a robust SOA platform alternative, but they have now delivered a migration toolset that is capable of preserving their investments in Java CAPS Collaboration and ETD/OTD assets by parsing and recreating that same code into the WebSphere target environment.  Combine this toolkit with other assets such as WebSphere Support Pac IAM6, and you can see that IBM is willing to make investments to help customers running Java CAPS where Oracle has not.

With new version 8 capabilities, industry specific accelerators, and WebSphere Message Broker’s new packaging options that provide low cost entry points with the same reliability and robust scalability, it is not surprising that more Java CAPS customers are stepping back to consider their options.

Posted in Oracle | 2 Comments »

Tags: , , , , , , , ,
  |  
Follow

Get every new post delivered to your Inbox.

Join 407 other followers

%d bloggers like this: