Skip to Content
Author's profile photo Former Member

The COmmon Reference Architecture (CORA), Part I


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

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/Solution Architecture or detailed technology architecture can be created from a total IT landscape point of view. This forms the basis from which software/solution architectures 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 (like SAP) 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, inclusing the ‘SAP SOA Reference Architecture’ 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.

In the next blog I will map the CORA-model onto the SAP SOA Reference Architecture and assess the results.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Arundeep Singh
      Arundeep Singh
      Hi Theo,

      Thanks for introducing to another reference architecture.

      Seems like what happened at technology and language levels is happening at architecture levels. Many languages and then many middlewares. And now may architectures and then many refrence architectures to communicate.

      Look forward to your next entries to learn more about it.

      Arundeep Singh

      Author's profile photo Former Member
      Former Member
      Blog Post Author
      Hi Arundeep,

      Thanks for you nice comment. I hope you enjoy the other blog posts!