Why did we develop the CORA model
IT landscapes are becoming more and more complex, containing systems developed for decades containing multiple vendor components and technologies. Current and future business needs require flexibility (within compliancy boundaries) and agility in support of IT. In order to challenge this 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).
CORA Model Overview
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 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 Architecture or detailed technology 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.
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.
The elements of the CORA model form the basis for identifying functional needs in a structured way and translating it into IT components and technologies. This is irrespective whether this is custom made, package based or obtained as a service from elsewhere in the Enterprise IT landscape. The result is used by the project teams (including the implementation, infrastructure and governance teams) to enable a predictable implementation of the proposed solution. On project level the CORA model can be used by the software architect of the project team to create an architectural view of the components to be built (e.g. within a RUP or Agile project). Another option to use the CORA model is to map a bought component onto the layered architecture (e.g. a Packaged Based Solution).
- 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