The project, announced at Oracle’s Collaborate user forum in Las Vegas, could reduce the complexity of integration, but could also detract from its forthcoming Fusion applications because it provides a way of streamlining interactions and process flows across heterogeneous apps.

At the heart of the new architecture is a translation layer that sits between the applications and Fusion Middleware and is accessed via the middleware, and an emerging set of common definitions and objects that applications can conform to. The approach caters for the different ways applications define objects such as a sales order.

With no standard definition, each application needs to know how the other applications it integrates with defines an order so it can expose it in a meaningful way, explained Paco Aubrejuan, vice president of application strategy at Oracle. This means that, even in a service-oriented environment, if an application integrated with multiple applications it would have to expose multiple versions of the same service.

The Oracle approach is to have applications conform to a common set of object definitions. An application could expose an order based around a common definition, making it available to others through an intermediary framework. Consuming applications should be able to pick up the common definition and transform it into the format they need.

Using this approach, Aubrejuan said, some of the cost and complexity of application integration can be reduced because each application only has to expose one standard version of a service that conforms to common definitions rather than having to expose a different version for each application.

Oracle is working with bodies like the OAG to help define application and vendor independent objects, as well as basing work on customer requirements.

One of the advantages of this service-based framework-style is that it allows disparate applications to work together without demanding changes to the application architecture, making it attractive to Oracle with its portfolio of acquired and in-house developed applications. It should also make upgrades easier according to Aubrejuan.

Instead of changing the data models, which is not feasible, we are creating a single logical representation of an order that all systems adhere to when taking an order, he said. It reduces the complexity of integrations and the cost of maintaining integrations.

Aubrejuan said it that Oracle was using this approach internally to enable integration across its disparate applications, and was making it available to customers. Business application consolidator Infor has also adopted a framework type of approach to deal with its disparate applications.

As well as providing an integration platform, Project X should also provide a way of developing composite applications based around business processes. In fact Oracle is releasing two pre-packaged process-based applications – pre-packaged order to cash and opportunity to quote – that will work across Siebel and E-Business Suite. Further horizontal and vertical composite process applications are planned.

Oracle is behind SAP on delivering a composite application strategy but naturally believes it has more to offer. We think we are different because we are standards-based, because [the work] is independent from the application design, and external to the applications. Processes can cut across application solutions….and with the number of best of breed applications [we have] we can leverage the breadth of that footprint, he said. Using banking as an example he cited the ability to automate account origination across front and back office using Siebel and i-flex as an example of the breadth Oracle can deliver.

Our View

Oracle’s new integration and composite application strategy is great news for the thousands of users who are quite happy with their existing applications because it brings a new level of flexibility to their business application infrastructure and an opportunity to take advantage of new technologies without having to undergo an expensive and risky upgrade (in the sense that all application upgrades carry inherent risks) to Fusion applications.

It could draw attention away from the planned Fusion applications and delay adoption as users may see Project X as a reason not to upgrade, which may not be so good from Oracle’s perspective.

However, Oracle’s application strategy has undergone a quiet transformation over the last year or so, whereby it appears to have prioritized customer retention and related maintenance revenue over cajoling the customer base to move to its next generation technology.

Purely in terms of revenue, it needs to keep its expensively acquired customer base and the best way to do that is to keep it happy with new versions – new versions of all five core products have been released over the last few months – and new options around the existing products such as Project X.

One of the drivers is that we think Oracle is unlikely to see much revenue from Fusion applications until 2010 at least because if they launch in 2008, cautious customers are likely to wait until the second release before starting to adopt in large numbers and based on typical release schedules, that could be 2010.

In the meantime, Oracle has to keep its revenues up, and future proofing existing applications to retain customers and increase the number of seats or functionality used, which in turn maintain or increases maintenance revenue, is one way to do it. Producing initiatives like Project X that help wean customers onto Fusion Middleware are also part of a long-term plan.