Requirements for CORA
The CORA is based upon the following basic principles:
- 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.
Besides these basic principles, a number of guiding principles are identified and summed up in underlying table.
- Assessing IT solutions with CORA
- CORA and Archimate
- Architecture Styles and CORA
- ERP and PaaS
- CORA and Application Lifecycles
- CORA Methodology (Project level)
- The roadmap for Fusion Applications, CORA is there to help
- Technovisions "Sector-as-a-Service" mapped
- Business Logic and the CORA Model, Part II
- CORA and Cloud Computing: Static versus Dynamic View
- Technovisions "Thriving on Data" mapped
- CORA Foundation
- Business Logic and the CORA Model, Part I
- CORA and IBM
- CORA and Microsoft
- CORA and Cloud Computing: Overview
- Technovisions "Process-on-the-Fly" mapped onto CORA
- Risk aware design: using CORA to investigate an IT solution
- A ROA based iPhone App for SAP: Part II
- A ROA based iPhone App for SAP: Part I
- Technovisions "We Collaborate" mapped onto CORA
- SAP platform decomposition with CORA: SOA/ROA style
- 'Why' Driven Solution crafting
- CORA and TOGAF
- SAP platform decomposition with CORA: N-tier style
- Requirements for CORA
- CORA and Oracle
- Technovisions "You Experience" mapped onto CORA
- CORA and SAP
- CORA in action: design guidelines to implement repositories
- The basis of all, your data
- CORA and IAF
- Technovision and CORA - Overview
- The importance of an Integration layer