The CORA Model

Introduction

This blog is the first in a series around on the comparion between the CORA model and Oracle. In this first part, after introducing Oracle, the different architectural views Oracle uses are described, concluding with the added value of CORA within the Oracle field.

The history of Oracle

Oracle started 30 years ago into the Database world, which still is one of the cornerstones of Oracle. Oracle has a focus on two main areas, Applications and Technology. Some ten years ago Oracle decided to be bigger then SAP, and created a blueprint of functionality needed for that purpose. On the other hand Oracle realized that it needed a sound technology platform to support all that functionality. Since then Oracle has been filling in the blanks in both areas by creating new software (mainly by means of acquisition) in the area of Applications (i.e. Peoplesoft, Siebel, JD Edwards), Middleware (BEA the largest) and lately with Hardware (Sun). With every acquisition Oracle needs to consider, what part of the acquired product will be included in the product stack and what component will be reused from the already existing stack. This calls for continuous architectural thinking and consideration.

The Vision of Oracle

The credo of Oracle is Complete, Engineered and Integrated systems.

• Complete meaning: 'We've got it all'. Oracle owns a (complete) stack containing applications, middleware, databases and hardware which rivals the stacks of SAP, IBM and Microsoft.
• Engineered means that Oracle is now selling complete stacks aimed at a typical target market. A first example is a solution for the Healthcare market. Oracle delivers this as an 'appliance': a preconfigured Sun machine containing OS, Database, Middleware and Applications aimed at the this market.
• Integrated systems: the Oracle stack is able to integrate complete (both internally as well as externally) based upon open standards.

The technology part of Oracle is there to support the functionality available in the Applications part. In other words when it comes to Technology, Oracle eats its own dog food.

Architectural views of Oracle
Oracle has different views to look at their architecture.

• A 'High Level View'. This is used as a comparison between the Oracle stack with their main competitors, being SAP, Microsoft and IBM.
• 'Applications and Technology'. Each has their own viewpoint where Technology is aimed to support the Applications part.
• The 'Fridge'. This is aimed at Technology and shows a product mapping stacked on top of one another. (This view is shown in the CORA book).
• 'Industry Reference maps' aimed at Applications.

In upcoming blogs we’ll cover these topics.

What is the added value of CORA in the Oracle field

In an effort to fulfill their vision Oracle has shifted gears in terms of development to the maximum. Even though Oracle has given the assurance that versions will be supported lifetime, customers need to know what the impact of changes in the Oracle stack will have on their existing landscape.

CORA will help showing the impact of these shifts onto an existing IT landscape in two ways:

• Applications: Oracle is about to present to market the 'Fusion Application'. In time this will contain all applications functionality, making Siebel, JD Edwards, eBusiness Suite (partly) obsolete.
• Technology: Because of acquisitions in the past one logical CORA element (for example 'Integration Core Functionality' within the Integration Layer) can by mapped onto multiple software components (i.e. Siebel and BEA). Oracle decided that in the long run the 'Oracle Service Bus' will the standard supporting this CORA element. By mapping these different components onto the CORA an indication of changes to be expected as a result of the standardization process can be derived.
• Applications and Technology. Some (acquired) applications also comprise technology components supporting different CORA layers/elements, such as BEA, eBusiness Suite and Siebel. By decomposing these applications (i.e. mapping onto the CORA model) the separation of responsibilities, decoupling, re-usability, portability and substitutability of elements can be assessed.