In 2006, Andrews Consulting Group released a white paper entitled The Transformation of JD Edwards Applications that you can download from our white papers section. This year, we are revisiting the subject of how Oracle is transforming our applications with a new series of articles. We welcome your comments and questions as the series evolves.

As I explained in our first article in this series, Oracle has set an ambitious goal for itself. That goal is to make it easy for all of its Applications Unlimited (AU) offerings—including JD Edwards—to invoke functions from the rest of Oracle’s vast application portfolio. This would make each AU product significantly more complete than it is today.

If Oracle realizes its vision, it could make life dramatically different for JD Edwards customers. A company might, for instance, integrate functions from Oracle’s Agile, Demantra, G-Log, and Siebel products under the covers of EnterpriseOne or World. Indeed, it might even integrate some of the latest Fusion Applications in the same way. In some cases, these integrations would require the deployment of selected components of the integrated applications. In other cases, the customer would invoke the functions from an Oracle-hosted site. Either way, the resulting integrations would be virtually seamless, with data flowing almost effortlessly between the new functions and the underlying JD Edwards applications.

How could Oracle make it so easy for JD Edwards and other AU customers to close the functionality gaps in their existing applications? The answer lies in two strategic initiatives that the software giant has been pursuing for more than two years. The first initiative is to repackage much of the “best of breed” functionality in its applications as composite business processes. These processes will integrate with AU applications and each other via a service-oriented architecture (SOA). The second initiative is to create an “integration platform” that governs how composite business processes are created and defines how they interoperate with AU applications over SOAs.

Since the second initiative lays the foundation for the first one, let’s take a closer look at it. Fortunately for us, Oracle has given this initiative—and the integration platform it is creating—a name. That name is Application Integration Architecture, or AIA.

Application Integration Architecture 101

Imagine for a moment that your current applications are your house. You want to remodel your house to give it that modern, SOA look…you know, where it’s easy to add or reconfigure rooms and other amenities because everything is modular and based on standards. Now, think of AIA as Oracle’s instruction manual for how to remodel your applications and, in fact, all of its applications. This instruction manual includes:

  1. A body of reference models and procedures for transforming the “best of breed” functions in Oracle’s applications into composite business processes
  2. Technologies that enable AIA-compliant applications to invoke and integrate with these composite business processes
  3. Packaged offerings that utilize AIA standards and technologies to integrate specific composite business processes with specific Oracle applications (such as product lifecycle management functions from Agile with EnterpriseOne Manufacturing)

As the following Oracle diagram illustrates, AIA contains three major components.

  • Best practice industry processes. Oracle has created an extensive list of horizontal and vertical industry business processes that companies must implement. Some of these processes are high-level in nature, such as “order to cash” or “hire to exit”. Others are subsets of these processes, such as “verify the tax and citizenship documents of a new employee.”
    With this list of processes in hand, Oracle’s development teams are determining which of their applications do the best job of supporting each process. This effort will achieve two things. First, it will establish “industry reference models” for how business processes should be executed. These models will be embedded in Oracle’s middleware and provide guidance to Oracle’s customers on business process design. Second, Oracle’s effort will determine which components of its current applications are repackaged as composite business processes. Naturally, these repackaged components will abide by and support the industry reference models.
  • Common objects and services. To turn its existing “best of breed” code into composite business processes that all AU applications can invoke, Oracle must repackage that code with standard definitions and access methods. The standard definitions are known within Oracle as Enterprise Business Objects, or EBOs. Each EBO defines an object, such as Customer or Item, in accordance with widely used XML protocols and other industry standards. The EBOs are then implemented as web services known as an Enterprise Business Services (EBS). Each EBS provides an object-oriented “container” for a composite business process that includes standard means for discovering and invoking it.
    All Enterprise Business Objects and Services reside in an Enterprise Service Repository that is common to all of Oracle’s AU applications, including JD Edwards EnterpriseOne and World. Access to these objects and services is provided via Oracle Fusion Middleware and the tool sets of the AU applications themselves.
  • Process Integration Packs (PIPs). If your current applications are your house, think of Process Integration Packs as AIA-compliant blueprints and tools for adding that extra study or bedroom you always wanted. PIPs are packaged offerings that use AIA standards to integrate AU applications with other Oracle applications or specific application components. For instance, Oracle just announced a PIP that integrates EnterpriseOne with Oracle Transportation Management (formerly known as G-Log). Another PIP adds trade promotion management to EnterpriseOne by integrating it with software that Oracle acquired from Demantra.
    In a real sense, PIPs are Oracle’s way of packaging AIA to make it easier for customers to use. Many JD Edwards customers may implement AIA in their organizations via PIPs without fully understanding the sophisticated integration platform.

While the diagram above does not make it clear, AIA is heavily based on open, widely accepted industry standards. This will make it easier for companies to use AIA to integrate their Oracle applications with non-Oracle software. It should also make it easier for Oracle to convince its business partners and other software vendors to support AIA in their products.

In short, AIA is Oracle’s blueprint for SOA-enabling its Applications Unlimited products so they can consume the “best of breed” composite business processes that the vendor is creating. At the same time, AIA provides many of the procedures, standards, and tools for deploying an SOA. Through PIPs, AIA even offers “pre-built SOAs” to integrate specific applications with each other.

At this moment, Oracle’s application development teams are working to ensure that their products support AIA. By 2009, we believe that the integration platform will be fully embedded in the current releases of most applications. Indeed, the latest JD Edwards EnterpriseOne and World releases already support much of AIA. In our next article in this series, we’ll discuss the impact of AIA on JD Edwards applications and consider its implications for our community, so stay tuned.

Related Articles

The Transformation of JD Edwards Applications II: Part One
The Transformation of JD Edwards Applications II: Part Three