The CORA Model

Introduction

This is the first blog post about CORA and the Integrated Architecture Framework (IAF) of Capgemini. IAF is an architecture framework that contains processes, products, tools and techniques to create all types of architectures which are intended to shape businesses and the technology that supports it. The core mechanisms that form IAF’s basis are:

• traceability of decisions (from business to IT);
• basing decisions on principles;
• reducing complexity by separating concerns.

IAF has also proven to be flexible, because it can be adopted by all the different types of projects in which architecture is required (from Enterprise architecture to Solution architecture levels). It has been used standalone and in combination with other methods and approaches. This works so well because IAF is not a rigid cookbook.

As a result IAF is extremely elegant in supporting discussions with stakeholders in terms that they actually understand (e.g. business or IT, or high-level concepts). It supports the separation of Business and Information Systems, Information Systems and Technical Infrastructure, the separation of the Logical and Physical architecture and traceability between all these elements (including Security and Governance aspects) as described in the following picture.

From an IAF perspective, with regard to Enterprise Architecture and Solution Architecture, CORA scope is about the Technical Infrastructure layer in logical and physical terms and the Information Systems layer, only in physical terms as depicted in the following picture.

Mapping IAF onto CORA

CORA delivers a reference model for describing the Logical and Physical IS/TI architecture. Therefore, it is a good starting point to define Logical/Physical TI architecture components and map physical IS components on that model.

However, IAF structuring (i.e. Component definition) is based on applying architectural principles, derived from many sources (business and IT strategies, regulations and policies, standards and guidelines, etc…). CORA model is also based on guiding principles, described in this blog post. These principles are based on best-practices and designed to support very different types of business and IT situations. Some other principles exists, only based on the client context (specific business and IT environments) which could be conflicting with the CORA ones.

The architect must recognize these differences in mapping and making decisions based on principles defined and validated client-specific environment. As CORA's guiding principles are extracted from IT best-practices, a mismatch could lead to difficulties when implementing the architecture. Detecting these differences at an early stage helps in taking the right decisions and mitigating risks before implementation decisions are done. It will finally lead to define guidelines for implementation (i.e. software design phases).

When a packaged based solution (PBS) is part of the IT landscape (i.e. described at the IS/TI physical level), a mapping of IS physical components onto CORA/IAF is crucial to decide what pre-delivered components to use. CORA helps to clearly position IS software components on the Technical Infrastructure layers that always come with any PBS (again, pre-delivered). One example is decisions that must be taken regarding the pre-delivered integration and composition layers of a PBS, especially when an integration/composition  solution is already implemented within the organization.

In the next blog post it is described how CORA is used at a customer site (public health insurance within the French public sector).

About the Author

Philippe André is working at Capgemini as a Certified Global Architect.