The Oracle Forms Dilemma

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, scale-able, 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 will probably have a wide variety 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 the current releases of Fusion Middleware, 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 applications

There 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 thereby 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 have the potential to adversely impact 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 a stategic 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, business strategies evolve, and processes need to be 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 uses 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 as 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 need to integrate with other systems, 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 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 run on a new platform or technology framework.  Unless you have 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.

Categories: Migration


Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: