Modernization and Migration Strategies for Oracle Forms

Oracle Forms is one of the oldest (if not the oldest) toolsets for client/server application development (AD) on the market. Oracle Forms is a venerable technology, and is still widely deployed and commands respect. Nonetheless, Gartner believes it is not best positioned for many next-generation AD challenges. Here, we address best practices for managing Oracle Forms applications and migration strategies for future investments.

Key Findings

• Oracle Forms remains a viable and valuable technology asset for mainstream IT strategies, but has limited scope in next-generation AD efforts.
• Most, if not all, innovation in future versions of Oracle Forms will focus on integration into modern service-oriented architecture (SOA) and middleware technologies, while maintaining strong backward-compatibility with a stable core.

Recommendations

• AD organizations should:
  • Update to a supported version to gain advantages in centralized management and deployment.
  • Modernize and integrate SOA and other middleware best practices and infrastructures (specifically Oracle's Fusion Middleware stack and Java development tools).
  • Migrate next-generation development projects to industry-dominant technologies (for example, Java, Microsoft .NET and open-source software) to align with industry best practices in the future.

The Past: An Entrenched Technology Base

Because of Oracle Forms' tenure in the market, there are thousands of Oracle Forms customers collectively, with tens of thousands of applications in production today. Compounding this issue is that significant percentages of these deployments are built on older, outdated and unsupported versions of the toolset. As an even-greater challenge, many older deployments are accompanied by wholly insufficient documentation, and, to keep them running day to day, developers try not to disturb the systems lest they collapse under their own weight.

Moreover, the combination of Oracle Designer and Oracle Forms has created a powerful platform for model-driven AD when the term "enterprise client/server" remained an oxymoron (for many years, client/server applications didn't scale well beyond workgroup-size deployments). Consequently, many Oracle Forms applications are larger and more complex than typical client/server solutions, for example, deployed on products such as PowerBuilder or Visual Basic, which were deployed during the same time period.

The combination of older code, lack of documentation, and application size and complexity all contribute to very high barriers to migration for many Oracle Forms deployments. For these reasons and others, many Oracle Forms developers have avoided upgrading to newer versions of the toolset, never mind the larger challenge of migrating from Oracle Forms altogether.

The Present: Fitness of Purpose and Proprietary Lock-In

Most AD organizations with investments in Oracle Forms are longtime customers. Few (if any) AD organizations are considering Oracle Forms for new investments, but there are exceptions, such as the acquisition of third-party applications that are built on Oracle Forms technology (for example, Oracle's own pre-Fusion business applications). Consequently, investments in Forms are long-term commitments, and most users are steadily upgrading to the current version (11g) over time. These updates are driven by a number of factors, with version obsolescence and OS compatibility/certification (e.g., Windows 7 and 64-bit support), database support (for example, Oracle 11gR2 requires a newer version of Forms) most widely reported as key incentives; most are tied to a broader application portfolio risk management strategy.

There remains a solidly entrenched community of several hundred system integrators (SIs) and independent software vendors (ISVs) committed to Forms as well; while most are smaller "mom and pop" vendors, they represent hundreds of applications upon which thousands of IT organizations continue to depend. As a result, Forms remains a longstanding and well-entrenched toolset within Oracle's customer base. Gartner estimates that at least 30% of Oracle Database customers are currently Oracle Forms users, and 80% of Fortune 100 enterprises continue to invest in Oracle Forms.

Although Oracle Forms remains a solid fourth-generation language (4GL) development toolset for two-tier client/server-architected solutions, the industry's state of the art has long since moved forward to embrace Web-centric application designs and SOAs. Oracle has focused its next-generation software solutions on an SOA supported by its Fusion Middleware stack, with Java technology as the foundational core of this strategy. To be accurate, Oracle Forms can play a role in these efforts, but it's outclassed by more modern, next-generation toolsets (for example, integrated development environments [IDEs] and languages built on Java and Microsoft .NET). At best, Oracle Forms should be considered for a supporting role in next-generation SOA and middleware efforts, not as the focal point of application design. For example, Gartner sees mobile and context-aware application initiatives playing an increased role in day-to-day IT challenges in the coming years. Oracle Forms can play a part in these initiatives, but not serve as the technology "anchor."

It's also clear that Oracle's long-term AD strategy is squarely based on the Java platform. It is moving its business applications away from Oracle Forms, and is focusing on next-generation SOA and middleware deployments. This effort began with a gradual move from Forms to Java for Oracle's E-Business Suite, and concluded with the eventual delivery of Oracle Fusion Applications. Nevertheless, Oracle remains committed to the Oracle Forms toolset, and will continue to support and enhance it for the foreseeable future (see Figure 1).

Source: Oracle (November 2011)

The Future: Upgrade, Modernization, Integration and Migration

Gartner's research regarding application portfolio management (APM) provides key planning and management details for IT application overhaul programs. Progressive refinement from a high-level assessment leads to focused decisions that can improve application portfolio value and total costs. We strongly recommend that organizations consider the role of Oracle Forms applications in a broader APM strategy (see "Planning for Application Overhauls: Start From the Top With APM").

While Oracle will continue to support Forms in the future, we do not believe Oracle will attempt to position Forms as a preferred technology for next-generation (e.g., SOA and mobile) IT efforts; instead, it will focus on a three-tiered strategy:

• Modernize Oracle Forms continuously, and as best as possible provide:
  • Existing customers with a simple, highly compatible and low-risk path to upgrades.
  • A range of high-priority, "good enough" pragmatic features for longstanding and entrenched legacy Oracle Forms code bases that do not require leading-edge technology investments.
• Provide features and support that allow Oracle Forms applications to take part in hybrid application deployments that utilize well-worn legacy Oracle Forms code, combined with newer technologies, such as its Oracle Application Development Framework (ADF) Java framework.
• Provide a path of least resistance and lowest barrier to entry for Oracle Forms code bases with high-priority migration requirements (e.g., skills consolidation) to Oracle's own next-generation Java technology — Oracle JDeveloper and the Oracle ADF framework.

Upgrade and, Potentially, Modernize

In general, Oracle Forms deployments should be upgraded to the current versions whenever practical. In addition, applications should be modernized (refactored to embrace current application design and architectural best practices) whenever practical. This provides several advantages, the most important of which is establishing a foundation to leverage the integration features of current and future toolset versions with Oracle Fusion Middleware and Java tools (see the Staged Migration Over Time Via Hybrid Approach section). Second, Oracle Forms can provide a compelling, centralized deployment, monitoring and management hub for Forms-based solutions. This centralized control will offset the costs of upgrading efforts in many ROI scenarios.

Of course, modernization can also come at considerable expense, especially for older solutions. However, we should emphasize that movement from an older code base isn't an issue of if, but when. Ultimately, this is a risk management.

Reasons to Upgrade

Here are reasons when upgrading is important:

• If the intention is to extend the life cycle of an Oracle Forms application for as long as it's practical.
• If the intention is to integrate Oracle Forms functionality with Oracle's Java AD technology (see the Staged Migration Over Time Via Hybrid Approach section).
• To gain centralized deployment, management and monitoring of Oracle Forms applications. This can extend the life of these applications, and optimize total cost of ownership.
• To bring Oracle Forms applications up to date in service and support. Gartner doesn't generally recommend that IT organizations leverage unsupported technologies. Exceptions are cases in which the strategy may be to aggressively migrate Oracle Forms applications to another platform (for example, Microsoft .NET), or to another vendor's Java technology (for example, IBM WebSphere). In scenarios where complete migration is scheduled within 24 months, it may be sufficient to document the code base, and to contain an established deployment as-is.
• To access features in newer Oracle Forms releases that may provide significant technical value to the application. For example, the newest release of Oracle Forms version 11.1.2 includes a number of significant new and expanded features:
  • Oracle Access Manager support
  • A smaller install footprint for design time
  • Support for 64-bit Windows design time
  • Administrative improvements
  • Prestart scheduling of servers
  • New metrics-gathering agent
  • Improved integration with Oracle Real User Experience Insight (RUEI)
  • Improved network stats
  • Operational improvements
  • Support for database NCHAR
  • IDE Editor improvements
  • Runtime font improvements
  • Native multiple document interface (MDI) maximize option
  • Support for 64-bit for WebUtil
  • Additional support for mixed-page embedding
  • Configurable menu bar
  • Use of external resources for images, etc.

Bottom Line

We must emphasize, however, that unforeseen issues can arise anytime and may affect the stability of older, unsupported Oracle Forms deployments (for example, OS patch and so on). IT organizations assume considerable risk with unsupported deployments of Oracle Forms solutions, and this risk grows as the technology ages.

Integration

The current version of Oracle Forms (11gR1) provides several integration points that may provide considerable value for established Oracle Forms code. Oracle Forms and Java applications are now deployed to one unified application server (Oracle's WebLogic Server), which provides common administration features and security contexts. Moreover, it's now more practical to share common business and user interface logic between Oracle Forms and Java. Oracle Forms developers can consume and expose services within an SOA as well. For example, Oracle Forms may be a good choice for user interface development within a composite application that leverages existing Oracle Forms apps and apps that expose Web services APIs. These integration strategies can significantly extend the role of Oracle Forms within SOA efforts. We expect that virtually all new features in future Oracle Forms versions will focus on integration with Oracle Fusion Middleware (for example, Oracle WebCenter) infrastructures.

Migration

Migration to Oracle JDeveloper and Oracle ADF

Select a migration target platform carefully. We believe the least risky (and often the least costly) migration path forward from Oracle Forms is Oracle's JDeveloper IDE and ADF — especially for application leaders who plan to retain their existing programming staff. Oracle is addressing Oracle Forms to Oracle JDeveloper and Oracle ADF migration not only by creating specific integration points between the technologies, but also by focusing on training, seminars and tutorials that aim to minimize the learning curve for Oracle Forms developers. Although the transition from Oracle Forms to Java will be challenging for some Oracle Forms programmers, Oracle JDeveloper and Oracle ADF represent the lowest barriers to entry, insofar as Oracle Fusion Middleware and tools can be most directly integrated with established Oracle Forms code. Moreover, both JDeveloper and ADF share similar look-and-feel features with Oracle Forms, and concepts familiar in one can be mapped to the other. Finally, ADF offers sophisticated and rich support of the Oracle Database features that are similar to Oracle Forms.

Migration to Other Java Toolsets

It's also possible to migrate from Oracle Forms to non-Oracle Java technologies (for example, IBM, JBoss, SAP, open source and so on); however, we believe that, for most Oracle Forms developers, this will represent a significant learning curve that's beyond an acceptable level of risk and cost. However, application leaders should at least consider this strategy when outsourcing their migration efforts (see the Outsource/Offshore Migration section).

When Oracle Fusion Middleware and Java technology aren't selected, we recommend that IT organizations consider migrating to the Microsoft .NET platform instead. This will provide a lighter learning curve for programmers and a toolset that's more akin to the 4GL features of Oracle Forms. There are many circumstances in which developers may be compelled to select Java over .NET (for example, OS compatibility). Alternatively, open-source dynamic languages, such as PHP: Hypertext Preprocessor (PHP), have emerged as viable options.

Migration to Oracle Application Express

The Oracle Application Express (Oracle APEX) toolset is a Web-based rapid Web AD tool for the Oracle Database. Since it is built on the same foundation of Procedural Language/Structured Query Language (PL/SQL) as Oracle Forms, many developers are now considering it as a migration point from Forms code bases.

Oracle APEX is targeted at power users (citizen developers), and has very limited support for advanced software development life cycle (SDLC) and application life cycle management (ALM) feature and best practices (e.g., no team support and no direct source code versioning). Gartner does not consider Oracle APEX a practical replacement for the full breadth and depth of the Oracle Forms toolset, although it more than fits the needs for basic Web-based "maintenance forms" (i.e., simple create/read/update/delete centric forms) interfaces. However, Oracle APEX is less suited for elements of Oracle Forms applications with more complex business logic requirements.

Rather than a direct migration target for existing Oracle Forms code bases, we believe Oracle APEX may be a good choice for some Oracle-centric AD organizations for new, simple applications that might have otherwise been written in Oracle Forms instead. This is particularly true for applications where Java is technical overkill.

Complete Wholesale Migration (Forklift Migration)

Automated Migration Tools

We have found the success of automated migration tools to be hit or miss (at best), given the architecture of Oracle Forms and the way many Oracle Forms applications are structured. Most automated migration efforts simply result in an older Oracle Forms-centric application architecture on a modern platform (e.g., Java), rather than a modern application architecture. Instead, we believe that modernization and migration efforts that embrace differences, and rearchitect and build to the "sweet spots" of their target technology are most successful. For this reason, developers should not expect Oracle to provide automated tools to directly migrate Oracle Forms code to Java or .NET. Instead, Oracle will focus its investments on integration and unified management.

Gartner is aware of several third-party companies that provide automated migration tools (for example, CipherSoft and PITSS) from Oracle Forms to Java. Based on Gartner client feedback, the resulting code is, in many cases, good enough, but generally less than optimal, compared with manual recoding efforts. However, good enough may be sufficient for many needs.

Advantages

The advantages are as follows:

• It's least intrusive to the established code base.
• There are fast automated results.
• It may allow the retirement of older versions of the stack.

Disadvantages

The disadvantages are as follows:

• It can be difficult to maintain the generated code after the migration process.
• The results are often good enough, but not optimal. Moreover, results tend to vary significantly from one application to another. Some migrate easily, while others don't.
• Difficult to incorporate new design elements in the migration effort; instead, most projects focus on as-is migrations.
• Architecture is not well-formed for the target platform.
• Source code can be difficult to read for Java and Oracle Forms developers because they try to maintain Oracle Forms constructs/coding/methods as much as possible, but these are at odds with how users would develop in Java.

Outsource/Offshore Migration

In many cases, outsourcing a migration project is a suitable alternative to automated code migration. The principle difference is that the addition of human touchpoints provides more flexibility over the final product. This process takes longer, but the end result can be more polished and a better fit with specific design goals — particularly when the effort incorporates new application features and design elements.

Advantages

The advantages are as follows:

• No internal skills are needed for the initial migration effort.
• There is the ability to incorporate more aggressive design changes above and beyond mechanical translations.
• There is the ability to bring resources with experience in both platforms, thereby meeting an aggressive delivery time frame and quality expectations.

Disadvantages

The disadvantages are as follows:

• It can be difficult to maintain the code after the migration process is complete and the project is turned over.
• The system must be extremely well-documented.
• Some new application scope can be introduced, but limited hands-on owner involvement confines many aspects.
• It doesn't achieve the same level of results as when done in-house and there's time to rethink the approach, given modern technology.

In-House Migration

Instead of outsourcing a migration effort, many IT organizations choose to leverage internal resources for the effort. It is critical, however, to consider this option only if internal resources have both an intimate knowledge of the business processes and the technical skills related to Oracle Forms development.

Advantages

The advantages are as follows:

• In many cases (but certainly not all), developers may have a much more intimate knowledge of the business processes and technical nuances of the older system.
• If time is available, developers can often rethink the problem and come up with a better approach, given more modern processes and technologies.
• Developers are completely familiar with the final product, thus minimizing any maintenance risks going forward.

Disadvantages

The disadvantages are as follows:

• Splitting developers between maintaining an old system and new development efforts can stretch resources thinly.
• Lack of technical expertise with new technologies can create severe risks related to the time frame for delivery and quality of the new system.

Staged Migration via the Hybrid Approach

In reality, it's rare to find a case where an enterprise is overwhelmingly compelled to migrate an entire Oracle Forms code base at once. For example, an enterprise may simply need to make Oracle Forms-based business functionality available to a wider audience (e.g., mobile or B2B channels), or to more deeply integrate Oracle Forms code in a real-time SOA. In this case, some functionality can remain in Oracle Forms screens and business objects, while others are rendered as HTML pages using a different technology (e.g., Java, PHP, .NET, etc.). As mentioned, when Oracle Fusion Middleware and toolsets are selected as the target platform, migration efforts can much more aggressively take advantage of integration points between Oracle Forms and Java code. Specifically, business and user interface logic can be composited into a unified experience. Oracle Forms technology can be integrated into Oracle WebCenter and composite SOA efforts.

A staged (that is, phased) migration effort enables Oracle Forms applications to be migrated over time. This lengthens the period during which Oracle Forms remains an architectural element, but reduces the overall migration risk during that time period. It's an excellent strategy when the goal is to maximize current Oracle Forms code investments over a period of years. However, it isn't appropriate when there are more urgent requirements to quickly and entirely deinvest in Oracle Forms technology.

Bottom Line

Oracle will continue to focus on Java for next-generation IT challenges (e.g., SOA, context-aware computing, social, mobile, etc.). Oracle Forms can play a supporting role in this road map insofar as most, if not all, innovation in future versions of Oracle Forms will be enhanced to leverage the Oracle platform, which spans hardware (e.g., Exalogic), RDBMS and Oracle Fusion Middleware. However, the future of Oracle Forms as an element of Oracle's broader technology road map is clearly as a supporting player, bridging the gap between older deployed systems that need to integrate and interoperate with newer platforms and application architectures.