The CORA Model

Introduction

Architecture defines an integrated and highly structured instrument to align Business & IT (and keep them being aligned). This helps organizations to make decisions based on requirements, and translate them into a coherent style or structure. Architecture can be separated into enterprise level (‘Enterprise Architecture ‘) and individual project level architecture (‘Solution Architecture ’ or ‘Software Architecture’). Both architectures reduce complexity, improve the ability to manage IT, to respond to business needs and improve the predictability of implementing a solution.

Frameworks help in describing and structuring the Enterprise Architecture. These can be used as a reference in discussions with the Project Architects, Software Architects, Business Analysts and last but not least the client. TOGAF is a framework for developing an enterprise architecture, and consists of a detailed method and a set of supporting tools. It is developed by members of  The Open Group Architecture Forum. The core of TOGAF is the 'Architecture Development Method'. The scope of CORA in relationship with the ADM is depicted in the following figure.

CORA and Phase D: Technology Architecture.

In this phase the logical software and hardware capabilities that are required to support the deployment of business, data and application services are designed .This will form the basis for the following implementation work (Phase E and further). Architecture reference models are used as a resource for the design. TOGAF delivers a selection of architectural reference models which include the 'Integrated Information Infrastructure Reference Model' (III-RM).The TOGAF III-RM is a model of the major application components and services essential for an integrated information infrastructure.

Like stated in the TOGAF document, one of the greatest challenges in designing an architecture is in choosing the proper reference model. Looking from a hybrid IT landscape point of view where different architecture styles are used it is difficult to use the III-RM as a quality instrument. Main reason for this is the impossibility of relating different services (called 'elements' within CORA) with each other which is needed to assess the architecture.

When using CORA as the reference architecture in this phase the model can be of great help because the logical elements within the model can be related to each other, depending on de architecture styles (to be) used. 

CORA and Phase E: Opportunities and Solutions

In this phase the physical software and hardware capabilities that are required to support the deployment of business, data and application services are designed. Basis for this design is the Technology Architecture in relation to Vendor Solutions .

Various vendors have created a reference architecture. These architectures are usually aimed at the product stack of the vendor. Therefore they cannot be used solely at an Enterprise Level where a variety of technologies and vendors may exist. The risk of vendor locking will be inevitable. The CORA model is vendor agnostic. Mapping a vendor architecture to the CORA helps to better understand the vendor architecture itself. If no vendor architecture is present one can be designed by using the CORA. Five vendor architectures have been mapped against the CORA so far.

Using CORA is especially important when software from more than one vendor is being used as many vendors deliver reference architectures crafted to their own solutions and/or platforms. This counts even more when a mixture of Package Based and non-Package Based Solutions is used to deliver a solution.

So when when designing solutions within Phase E of TOGAF the CORA model can be of great help because the logical elements within the model can be related directly with vendor specific solutions and/or platforms.