The CORA Model

Introduction

This is the second blog post about CORA and the Integrated Architecture Framework (IAF) of Capgemini. In the first blog post the Integrated Architecture Framework of Capgemini was mapped onto the CORA model. In this blog post it is described how CORA is used in an engagement at a customer site (public health insurance within the French public sector) to find out design guidelines to implement repositories.

The objective of this engagement was to define recommendations for a future information system architecture dealing with new repositories. These repositories will be put in place in the next 4 years in order to deliver more efficient social security benefits and improve health advices to citizens. Today these repositories are not defined yet; we only had a general vision coming from the government and  administration. Furthermore, this would be changing with time. The architecture should therefore be able to handle and facilitate the future organizational changes that will occur in the next future. The delivery date of this architecture engagement was May 2010.

 

Approach

In order to be sure that the first implementation of the new repositories is aligned with the more long term vision of the organization, we followed a typical architecture approach using the IAF architecture framework :

Figure 1: The IAF-approach

This steps in this approach were:

• architectural context:  the business objectives of the organization for the next 5 years (limited to our scope);
• conceptual business architecture: business services derived from the objectives,
• conceptual information architecture: the information objects (focusing only on mandatory repositories and their relationships);
• logical business & information architecture: components derived from the conceptual layers;

• architectural context: information system architecture: principles, derived from the business objectives;
• conceptual information system architecture: IS services that supports business services.

Based on this design we determined:

• how repositories should be used by Information System services and actors;
• how Information System services should be structured to be aligned with architecture principles and optimize repositories usage.

This resulted in the following logical Information System Architecture:

Figure 2: The Logical Information System architecture

We then used the CORA model at the Technical Infrastructure level in order to map the Information System Services onto the CORA layers. Finally, we mapped the existing application components, related to the Information System Services, onto the CORA model. In IAF-terms this is the logical Technical Infrastructe describing the logical TI components. This is shown in the figure below.

 

Figure 3: The Logical Technical Infrastructure architecture

 

Value of using CORA in this engagement

The CORA model first helped us as a pre-defined logical reference framework to quickly position the IS services in technology layers that made sense in the engagement context. When assessing the result we discovered that repositories and information object rules were shared by a lot of services that are key ones in the future IS architecture of the organization.

Based on this insight, we defined clear rules to define and design the structure of the repositories:

• regarding the handling of rules, we defined two different types of rules: repository building business rules and repository utilization business rules;
• regarding the allocation of IS services that manage repositories, i.e. in which layer they must be implemented (looking back to architecture principles).

Without the CORA-assessment we probably discovered these aspects in a much later stage, resulting a redefinition of the architecture.

 

Next steps

One of the next steps, to follow up on this engagement, could be building an implementation roadmap. During the CORA-assesment we discovered that a lot of existing applications are mapped onto more than one CORA layer. This is particularly true regarding the integration layer, composition layer, data layer (especially services and applications dealing with the repositories – the focus of this study) and the channel access layer. In itself this is not a problem, but it means that in order to implement a consistent set of applications in the future, managing these four aspects will be difficult and cannot be reached in one single phase.

 

About the Author

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