The CORA Model

Introduction

Oracle Fusion Applications came to birth last september at Oracle Open World. After five years of development the first Fusion functionalities have been released. What does this mean for the customers using eBusiness Suite, Siebel, JD Edwards and/or Peoplesoft? What steps do they need to take? Oracle realizes that pushing customers towards Fusion Applications will chase them away although Oracle keeps on repeating the message that it will not harm their existing investments. To avoid this Oracle announced (yet again) a three-word acronym for the strategy for customers with respect to their existing (legacy) landscape and integration towards Fusion Applications:

• Continue: on your current path, stay with your current portfolio and upgrade.
• Adopt: a co-existence strategy, add Fusion Apps to the landscape while at the same time continue with your current stack.
• Embrace: the complete suite, start from scratch with Fusion Apps.

It is clear that the last strategy option will not be the most likely choice. Oracle aims for the second one where clients use Fusion Apps in co-existence with their current stack. But how will this impact your landscape? In order to move (in your pace) towards the future Fusion Apps stack a roadmap needs to be created with intermediate “islands of stability”, safe heavens based upon product versions with known and proven functionality/technology.

The CORA model is highly suitable for creating these type of roadmaps with regard to:

• Combining Oracle Fusion Applications components with existing Oracle Applications,
• Combining Oracle and non- Oracle applications,
• Providing orchestration of processes and workflow,
• Enabling real time insight in processes.

Moving onwards through the roadmap the CORA Model can be applied perfectly to incorporate new possibilities like new Fusion Apps components.

Based upon a case around the co-existence ("adopt") strategy the impact on your landscape will be shown, including the involved risk areas.

Case description

The case handles Order Orchestration, which is one of the new Fusion Application components.

Current situation

In the current situation we have a landscape built of several order capture and inventory management applications, a typical traditionally  grown environment where at one point we are loosing insight and cohesion. A sum-up of what you might encounter in such an environment:

• Many systems doing Order Capture,
• No central control and insight in global position of orders,
• Scattered landscape of inventory management,
• Does not allow for growth by acquisition,
• Homegrown (old) application(s), which are costly to maintain & operate.

The wish list for the near future

In order to improve margins and avoid loosing customers we need a centralized Order Capture process and improved Insight into inventory and flight orders being processed across the organization. The solution should be derived from this business need instead of available functionalities within (existing) applications. 

Filling in the blanks using the CORA model

The context of the Business Question is around the Order Capture and creating the visibility of the order processing. We start off with a new (light blue) system overarching the Order Capture Composition component which is the base part of the proposed solution ("Order Capture" and "Insight"). This component abstracts the Order Entry from the involved systems, and is exposed to users via a Worklist in a Portal (available in the Presentation respectively the Channel layer). 

Next the (dark blue) systems in scope are put into the Applications Layer, which are SAP SCM, Oracle ERP and two Order Capture applications, one by Siebel and one Custom made.

A huge Data & Process integration component is needed to tie up the Order Capture process and the systems. This integration is done asynchronous or synchronous, depending where in the process we are. In order to get Insight we need to have access to both the Order (capture) Data as well as the Process (insight) data. Oracle Fusion Applications SCM helps to accommodate this needed functionality, the red box denotes the master component, the blue boxes shows the functionality as part of the master component.

Assessment regarding risk areas

When looking at the risks involved in this solution we can pick out a few based on different viewpoints:

• Functional viewpoint: every system has their own methodology for creating an Order. How well can this be orchestrated by one central component and how well is the needed data aligned?
• Organizational viewpoint: who is going to be responsible for the overarching Order Capture functionality?
• Technology viewpoint: how well can we communicate with the Custom Order capture? And looking from a the run time perspective of this solution, are all systems equipped to pass data and execute process parts in order to fulfill the Insight demands?
• Software delivery viewpoint: the Oracle Fusion Applications has just been released, the fearful 1.0 version (although this will be dampened by the fact that starting customers get full support from product management because of the huge investment Oracle placed in the Fusion Applications project)

Conclusion

Looking at this example it is clear that moving into the co-existence ("adopt") scenario is not going to be an easy exercise. However, looking at this scenario from a Business perspective is necessary in order to fulfill the demands of being able to get insight in in-flight processes at a more rapid pace then we’re used to. The CORA model is there helping investigate the impact on your landscape!