Theo Elzinga en Léon Smiers, maandag, 07 maart 2011
A practical guide on using a common reference architecture to design and deliver integrated IT Solutions successfully.
Architecture has claimed its place in the IT landscape over recent years as there is a growing need to understand how increasingly integrated environments fit together. Unfortunately 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 may seem like a way of making life more difficult and even more complex, but maybe there could be a way of doing this in a straightforward manner. So please suspend instant judgment and take some time to understand the proposed way this could be achieved in the thoroughly practical approach, called the Common Reference Architecture (CORA) which we will show you in three parts, of which this is the first.
Today’s changing business needs affect the way how organizations and their IT landscape are and should be organized: Globalization, Enron-downfall etc. The IT landscape within organizations (“On Premise”) which supports these changing business needs has evolved into a myriad of legacy systems, custom made systems, and Packaged Based Solutions (PBS) from a cocktail of vendors. All these different applications are required to primarily support local changing business needs and are almost always implemented using vendor-specific reference architectures.
At the same time organizations add complexity to their IT Landscape by incorporating loose coupled services from other parties into the enterprise architecture of tight coupled applications and provide services to external consumers to be processed on any device.
Last but not least, with the advent of Cloud Computing, organizations not only have the opportunity to outsource (parts of) their “On Premise” IT but also provide this outsourced IT “On Demand”.
All this has a profound effect on the internal enterprise IT landscape because the architecture and the governance of the IT landscape needs to deal with this cross-boundary traffic that requires a completely different way of capturing and implementing requirements. Excellent architecture and implementation models/methodologies are available to deploy/use within organizations. However, the result is often a false feeling of safety and control that vaporizes with the next overrun of project and IT budgets. This is mainly due to the fact that:
a gap exists between architecture and implementation (=Solution Design);
current architecture models are aimed at one vendor architecture and/or architecture style;
new demand and different methods for requirements gathering and implementation are often overlooked or ignored.
To address these issues the COmmon Reference Architecture (CORA) model has been developed.
The CORA model is a library of all possible, vendor agnostic, elements within an IT landscape. How elements relate to each other and which actually are or will be used depends on the current (and to-be) IT landscape, the solution proposed and architecture style(s) applied - such as N-tier, Service Oriented and/or Resource Oriented.
This way the IT Landscape itself as well as proposed solutions can be mapped onto the model and assessed (are elements ‘forgotten’? are there overlapping vendor-solutions? etc.).
The CORA Model has a robust and diverse foundation, based on existing theoretical models (Ross, Crown), standards (TOGAF III-RM, IAF), methodologies (RUP/Agile) and Vendor Reference Architectures. Five vendor architectures have been mapped against the CORA so far.
Figure 2 CORA model requirements based on six basic principles
Principle 1: CORA is vendor agnostic, described in logical terms
CORA needs to be vendor agnostic in order to overcome the issues concerning the use of vendor architectures as many vendors deliver reference architectures crafted to their own solutions and/or platforms. This implies that the CORA needs to be an architecture described in logical terms. Mapping a vendor architecture onto the CORA model helps to better understand the vendor architecture itself.
Principle 2: CORA is a layered architecture
A layered architecture is one of the most common techniques for breaking 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.
Principle 3: CORA describes elements that an IT landscape is comprised of
The CORA needs to have the ability to be used as a component model in order to allow for 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 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 layer directly above and only requests services from the adjacent layer directly below. To be able to support different distributed architecture styles 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
Architecture can be performed on Enterprise level (Enterprise Architecture) as well as 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. Therefore CORA needs to be able to be used on Enterprise Architecture level as well as project level to make traceability possible between both.
Principle 6: CORA is easy to understand
Each layer and the elements within a layer need to be described and easily understood.
The CORA model can be used in different ways, for instance:
To derive the impact from new IT-developments such as cloud computing;
To optimize Solution shaping because CORA is aimed at hybrid and cross technology environments;
For platform decomposition: mapping Package Based Solutions onto CORA to assess the bought functionality;
For landscape harmonization: mapping functionality onto logical elements to depict and assess overlap.
In Part II of this series we will introduce the CORA Model Methodology. In Part III several real-life examples will show how CORA has been used in practice.