The CORA model

An IT Application Reference Architecture

What you will learn

Why do we need the CORA model?

Explanation of the rationale behind this model and its added value with regards to risks-aware IT landscape and solution design.

What is the CORA model?

Give insight how CORA as a reference architecture can be used to design comprehensive application/technology architectures for all relevant stakeholders.

What is the relationship between the CORA model and TOGAF?

The logical positioning of the CORA model within the TOGAF-ADM cycle and explanation where the CORA model adds value.

What is the method of practice when starting with CORA?

Explanation of a proven step-by-step approach, in which principles as well as the quality of proces- and data models are key input.

How did the CORA model come about?

Description of the way existing vendor architecture-, maturity- and governance models were used to develop the CORA model.

In which situations can the CORA model be applied?

Description of different use cases in which the CORA model can be used, ranging from enterprise to individual project level.

Chapter overviews

1. Introduction

Information technology has had a profound influence on business and society. Decades of software implementation have created complex IT landscapes which are less flexible than current business needs require. New technologies and the increased use of technology in social traffic both add possibilities and create challenges to the evolvement and governance of IT.

The field of architecture provides a way to manage complexity and risk and presents views of the problem and solution that can be understood by various parties. This book describes an architectural approach and a reference architecture to address these possibilities and challenges.

2. Creating a stable Innovation Platform

Organizations who want to introduce new business models and technologies (i.e. create a stable innovation platform) need an IT landscape supporting both flexibility as well as regulatory demands. In this chapter this is explained in more detail based upon two existing models, the Architectural maturity by means of the Ross model and Governance by means of the Crown model. Both models provide the foundation for the layering of the CORA model.


3. An architectural approach

In a lot of cases the IT landscape is very rigid and strictly based upon (locally implemented) business processes and organizational structures. Changing both to support new business models and technology is not easily met and has major impact on the organization as well as in the IT landscape and accordingly on IT budgets.

Architecture defines an integrated and highly structured instrument to align Business & IT and keep them aligned. This helps organizations to make decisions based on requirements, through visioning them into a coherent style or structure.



4. Common Reference Architecture

The CORA model is needed to adapt new technologies and concepts in a controlled way because it guides the necessary connections between an Enterprise Architecture, a Software Architecture at Enterprise level and Software Architecture(s) at project level.

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

5. Using CORA on Enterprise Level

The CORA model delivers a reference model for grouping application capabilities on Enterprise level and a detailed description of each capability on Software Architecture level. When designing a specific organizational Enterprise Architecture the CORA model can be used as a basis for selecting the relevant logical capabilities and translating them into needed physical capabilities.
The CORA model can be used for an IT landscape consisting of both Package Based solutions (PBS) as well as non PBS components. Special care must be taken when a PBS needs to be integrated in a multi-vendor and multi-component solution because a PBS can be implemented using a mixture of capabilities which might support varying architecture styles (Client-Server, SOA and/or ROA).


6. Using CORA on Project level

One of the main aspects of the CORA model is the vendor agnostic approach that is needed to design and deliver integrated IT solutions successfully. This approach does not only apply to enterprise architecture but also to the level of projects. The software engineering process needs to take into account the fact that components from different vendors and technologies can/must be used to implement the requested functionality.

The start of a new IT project is the result of the need for changed or new functionality. Different roles in the project team interact to make a feasible solution, which aligns with the needs as required by the business. Within this context it is shown how the CORA can be used within an IT project.


7. Governance aspects

In the previous chapters it is explained how the CORA model can be used as an instrument describing architecture assets on Enterprise Architecture level which are input for the Software Architecture on Enterprise level as well as on project level. These assets needs to be governed in a proper way.

After introducing different types of governance is it described how architecture design, project implementation and governance are connected. Next some additional governance and project management aspects with regard to the SOA/ROA architecture styles are briefly mentioned including the way the CORA can be extended to support these.


load more

The Authors

Theo Elzinga (@telzinga,

theo_elzinga1After graduation in Business Administration at the Groningen University in 1994, Theo started his career in Information Technology. Throughout his career his focus has been on shaping IT solutions on Enterprise as well as on project-level, based on the Packaged Based Solution SAP. Theo is working at Capgemini Netherlands, where he is one of the leading SAP-Solution architects. He’s currently involved as lead Architect in several global IT projects within Unilever.

Léon Smiers (@leonsmiers,

leonLéon Smiers works as a Software Architect/Engineer for Capgemini Netherlands in the area of Oracle Technology and Architecture, where he is one of the leading Oracle specialists. He has done a lot of work and research in the field of Integration and new technologies, like RFID, Process and GUI integration, on which he wrote articles and presented on international conferences. Currently Léon is setting up Solution Architectures for large Oracle based projects. Prior to Capgemini Léon worked for Ernst & Young Consulting, USoft, the City of Rotterdam and has 20 years of experience in IT. Léon obtained his Master of Science in Astronomy at the Leiden University. Léon maintains a blog around software architecture.

Joost van der Vlies (

joostFor over 15 years Joost is working in the field of Information Technology. He is working as a Solution and Enterprise Architect on the level of a total information system landscape, where multiple vendors and technologies need to work together. Specialized in Service Oriented Architecture (SOA) and Cloud Computing he is also knowledgeable on the transformation of architecture towards projects which realize the IT systems. He is graduated in Software Engineering (Polytechnic school) and Social Sciences and IT (University). He has worked for Capgemini the Netherlands for more than nine years till moving to China in 2008. He did a few projects for Capgemini China and stopped working for the company in Q1 2009, and joined Hewlett Packard. Since July 2012 he is back in the Netherlands.