The Common Reference Architecture (CORA) model, Part II

Theo Elzinga, Léon Smiers, dinsdag 05 april 2011

A practical guide on using a common reference architecture to design and deliver integrated IT Solutions successfully.

This is the second blog in a series about the Common Reference Architecture (CORA). In the first blog the CORA model was introduced, being a vendor and architecture style agnostic reference model to support the design of 'predictable, repeatable and risk-aware' IT Solutions on Enterprise as well as Project Implementation level. In this blog post the CORA Model Methodology is explained.

Introduction

The CORA model offers a layered model to determine the impact of a business question on an IT landscape. But how does CORA achieve this in practice? This is described in this blog by discussing the major steps to be taken in order to design an explainable and traceable solution including a list of possible risk areas.

During the many projects in which we used CORA as a starting point for creating IT solutions we discovered that a lot of these solutions are based on the same combination of CORA-elements. We call these combinations "CORA patterns", and because they are re-usable we will introduce the "CORA pattern library", being a major part of the CORA Methodology.

CORA methodology overview

Figure 1 shows the CORA Methodology at a glance.

Input

The input for defining a solution consists of Architecture, Requirements and Landscaperelated materials.

Architecture

  • Principles: A statement of belief, approach or intent which directs the formulation of the architecture, and may refer to the current state or a desired future state. For instance, ‘Buy before make’, ‘Oracle unless’

  • Architecture styles: The way a solution is or must be structured, being the 'N-tier', 'Service Oriented' and/or 'Resource Oriented' architecture style.

Figure 1: Overview of the CORA Methodology

Requirements

  • Use Cases: Decomposition of functionality of the behavior of the system. In order to maximize functionality Use Cases follow the rule OTOPOP (One Time, One Place, One Person).

  • Process Models: Where Use Cases are atomic in nature, Process Models describe the lifeline of a certain object across departments, across applications. For instance the life of a work order and a call center ticket. On Enterprise Level this can be the Value Chain.

  • RDV: Rapid Design Visualization. A term used to design GUI which flows in close cooperation with end-users, an example is the Irise product.

  • Non-functionals: Non-functionals or supplementary specifications concern functionality which cannot be put in Use Cases but applies across all functionality, like reliability, security and maintenance.

Finally the AS-IS Situationdescribes the parts of the landscape that are involved in the scope of the Business Question.

CORA Modeling Activities

The middle part of the CORA methodology contains the main activities, being: decomposing the functionality onto the CORA model, mapping technology components, and looking for repeatable unique interaction patterns.

Assess people, roles. What people (roles) are involved and how (and where) do they interact with the solution.

Develop proposed Solution by mapping requirements onto CORA model elements and define relationship between elements. Map the requirements, both business and architecture, onto the CORA model. Define the relationships between elements in the different layers. An example is given in the blog post on Oracle Fusion, in the section ‘Filling in the blanks using the CORA model’

Check mapping against architecture principles / architecture styles.Investigate the impact of the architecture principles/styles on the already derived mappings. For instance if security principles are defined but no security definition is available in the (non) functionals, security elements are added in the derived CORA model and requirements need to be changed.

Map technology components (CSD/PBS) onto the relevant CORA Interaction Patterns. After the functional and architecture requirements are mapped onto the CORA model and elements and checked for completeness, we know which CORA model layers and elements are used. We also know which elements are not used. First remove these from the model. Now it is time to define with what technology (CSD and/or PBS) is used to implement this functionality.

Identify relevant CORA Interaction Patterns (using the ‘CORA Interaction Pattern Library’): "Playing with LEGO". This is an interesting part of the CORA modeling. Look at all the defined functionality and identify reusable and unique patterns in the mappings. For instance the requirements describes interactions with three systems, of which two are completely based upon file exchanges picked up by one SAP system, which processes the data using a BAPI (see Figure 2). An Interaction Pattern is a combination of CORA elements across layers connected via relationships. It is like building with LEGO. Identified Interaction patterns are stored in the CORA Interaction Pattern Library. This library defines all patterns that are used in the solution. Every functional description can be linked to one or more interaction patterns. Repeatable use of these library patterns improves the quality of the solution and gives a higher quality of estimations.

Figure 2: Example interactions between three systems

Assess the results by identifying Risk Areas and resolving them.This is an activity that does not stand on its own, but is executed in parallel with all other activities. An uncertainty in a requirement, an unstable or unknown technical component poses a risk to the solution and increases the amount of time (money) that is needed to implement the solution.

Derive guidelines for implementing the mapped technology components. As a first step towards implementation, decide how the CORA interaction patterns will be implemented. As always, there are multiple ways to implement a certain pattern.

Output

Thoroughly evaluated Solution Architecture. After finishing the CORA modeling exercise we have translated our Business and Architecture requirements, related to the current landscape, into a solution. At this point in time we are aware of the risks and where they exist in the landscape.

Implementation guidelines (based on CORA Interaction Patterns). The CORA Interaction pattern Library shows us the different patterns as defined in the solution, and guidelines on how to implement these patterns are defined.

Relevant CORA Interaction Patterns for planning and QA purposes. The identified CORA Interaction Patterns help in planning and are a good reference for Quality purposes.

In the last part of this series several real-life examples will be presented to show how CORA has been used.

[PDF]

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

15-02: GIA sessie over digitale transformatiespel meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden