CORA Requirements

• Principle 1: CORA is vendor agnostic
• Principle 2: CORA is a layered architecture
• Principle 3: CORA describes elements that comprise an IT landscape
• Principle 4: CORA uses a ‘relaxed’ layering scheme
• Principle 5: CORA can be used at different architecture levels
• Principle 6: CORA is easy to understand

Principle 1: CORA is vendor agnostic
The reference architecture needs to be vendor agnostic in order to overcome the issues with the use of vendor architectures as many vendors deliver reference architectures crafted to their own solutions and/or platforms. This counts even more when a mixture of Package Based and non-Package Based Solutions is used to deliver a solution.This implies that the CORA needs to be an architecture described in logical terms.

Principle 2: CORA is a layered architecture
A layered architecture is one of the most common techniques to break down complexity. It enables the separation of responsibilities, decoupling, re-usability, portability and substitutability of elements. When an IT landscape consists of multi-vendor and multi-technology elements a layered architecture makes comparisons and integrations of these elements much easier. A distinction needs to be made between horizontal and vertical layers, where elements within the vertical layers have impact on all horizontal layers.

Principle 3: CORA describes elements that comprise an IT landscape
The CORA needs to have the ability to be used as a component model in order to allow the choice of an element according to the situation and architecture style. The emphasis needs to be on determining the consequences when adding or removing elements and layers. The process of determining and documenting the consequences and decisions is an essential part of the job of an architect.

Principle 4: CORA uses a ‘relaxed’ layering scheme
Regardless of the architecture style all logical elements need to be clustered according to their role in one common ‘relaxed’ layer-scheme. In a pure layered hierarchy, each layer only provides services to the adjacent upper layer directly and only request services from the adjacent layer directly below. To be able to support different distributed architecture styles (N-tier, SOA and ROA) the CORA must be ‘relaxed-layered’, because the layers to be used depend on the architecture style.

Principle 5: CORA can be used to describe different architecture levels
The CORA needs to be able to be used in describing the Information Systems & Technical Infrastructure at logical level (Enterprise Architecture), describing the Information Systems and Technical Infrastructure at physical level (Enterprise Architecture), describing the Software Architecture at enterprise level and describing the Software Architecture at project level.

Principle 6: CORA is easy to understand
Each layer, and the elements within a layer, needs to be described and be easy understood. therefor grouping- and splitting criteria need to be explained.

Guiding principles
Besides these basic principles, a number of guiding principles are identified and summed up in underlying  table.