Architecture has claimed its place in the IT landscape over recent years as the need to understand how increasingly integrated environments, if not entire enterprises, fit together. Unfortunately, rather like standards, we now have a number of options as to which architecture method to follow. Even worse we increasingly find we need a lighter weight solution approach that will span more than one architectural model. This sounds like a cue for making life more difficult and even more complex, but maybe, just maybe, there could be a way of doing this. So please suspend instant judgment and take some time to understand the proposed way you could achieve this in the thoroughly practical approach outlined by my colleagues Theo Elzinga, Joost van der Vlies and Léon Smiers. They call it a Common Reference Architecture, or CORA for short, and this blog post outlines what is in their book ‘The CORA Model’ available from

IT landscapes are becoming more and more complex, containing systems developed for decades with multiple vendor components and technologies. Current and future business needs require flexibility and agility in support of IT. In order to meet the challenge of supporting these new flexible business models and technologies (within compliance boundaries) in a comprehensive and cost-effective way it is necessary to improve the control over the IT landscape:

  • 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) as we described in this book. 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 is defined as an integrated and highly structured instrument to align business& IT. Architecture can be performed on an enterprise level (Enterprise Architecture) and a individual project level (Solution Architecture). In practice we see that a gap exists between the two. 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 Software 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.
In summary, 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.