The CORA Model

• on both enterprise as well as project implementation level;
• with the focus on a heterogeneous IT landscape (e.g. Packaged Based Solutions, Custom Software Development, different technologies and software architecture styles);
• for the complete lifecycle of IT solutions (i.e. design-, run- and change time);
• between enterprises & social networks.

Today architecture based approaches, including reference models, exist to enable this improvement. Because they all have difficulties to take these demands into account simultaneously we've developed the COmmon Reference Architecture (CORA).

A stable innovation platform is an essential part of the IT landscape, as shown in the Ross and the Capgemini Crown model. Both models provide the foundation for the “COmmon Reference Architecture” (CORA). Besides the CORA model, for an implementation of both models to be effective they need to be supported by an approach for delivering IT solutions that fits within the architecture maturity and governance perspectives.

Architecture defines an integrated and highly structured instrument to align Business & IT. Architecture can be performed on an enterprise level (Enterprise Architecture) and a individual project or program level (Solution Architecture). In practice we see that a gap exists between the two. Often Solution/Software Architects perform their work with no relationship to an already existing Enterprise Architecture. The reason is that Enterprise Architecture generally is too abstract to be used on a Solution Architecture level.

The CORA model describes elements with their interactions and principles at an Enterprise Architecture level in such a way that the different architecture styles, such as N-tier, Service Oriented and Resource Oriented, can be fitted in. With the help of the CORA model a reference Software Architecture or detailed technology architecture can be created from a total IT landscape point of view. This forms the basis from which Solution Architects of individual projects within the portfolio can be derived and detailed.

Using CORA is especially important when software from more than one vendor is being used. The reason is that many vendors deliver their own reference architecture which is aimed at their own product stack. This leaves little room for including other vendor products or even their own 'legacy' stack and applies even more when dealing with an environment containing a mixture of Package Based and Custom Software Solutions. The CORA is a vendor agnostic model. Mapping a vendor architecture to the CORA helps to better understand the vendor architecture itself. Five vendor architectures have been mapped against the CORA so far.

Summarizing, the CORA mode divides an IT landscape into different (blue) layers and (green) elements and:

• provides insight in the way an IT landscape can support both business flexibility and compliancy boundaries by using several distributed ‘architecture styles’ (N-Tier, Service Oriented, Resource Oriented) simultaneously;
• can be used at different levels (Enterprise level, project implementation level) and to design and implement functions with a mixture of ‘architecture styles’ on the best fitted platform available (or planned);
• have a relationship with vendor specific reference architectures so that different technologies can be fitted in and vendor-specific functions can be properly allocated across a hybrid IT-landscape.

This way the CORA introduces a quality instrument to be used at different levels, regardless of architecture style and vendor-specific implementations and effectively enable transformation.

The elements of the CORA model form the basis for identifying functional needs in a structured way and translating it into IT components and technologies. This is irrespective whether this is custom made, package based or obtained as a service from elsewhere in the Enterprise IT landscape. The result is used by the project teams (including the implementation, infrastructure and governance teams) to enable a predictable implementation of the proposed solution. On project level the CORA model can be used by the software architect of the project team to create an architectural view of the components to be built (e.g. within a RUP or Agile project). Another option to use the CORA model is to map a bought component onto the layered architecture (e.g. a Packaged Based Solution).