The blog

The CORA approach (project level)

Introduction
What is the impact of a business question on an IT landscape? The CORA model offers a layering model to help answering this question. But how does CORA determine this in practice? In this blog this is described in the situation CORA is used on project level by discussing the major steps to be taken in order to design an explainable and traceable solution in which we’re able to point out the risk areas.

Within the many projects I used CORA as a starting point for creating IT solutions I discovered that a lot of these solutions are based on the same combination of CORA-elements. I call these combinations “CORA patterns”, and because they are re-usable I’ll introduce  the “CORA pattern library”, being a major part of the CORA Methodology.

The following figure shows the project level CORA method.

cora_methodology0001

Input
The input for defining a solution is contained of Architecture, Requirements and Landscape related material.

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.

Requirements

  • Use Cases: Decomposition of functionality of the systems behavior. 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 cross departments, cross 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 Capgemini term used to design GUI design and flows in close cooperation with end-users, an example is the Irise product.
  • Non-functionals: Non-functionals or supplementary specifications concerns functionality which is cannot be put in Use Cases but applies across all functionality, like reliability, security and maintenance.

Finally the AS-IS Situation decribe the landscape parts 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.

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. Remove these first from the model. Now it is time to define with what technology (CSD and/or PBS) is used to implement these 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 3 systems, of which two are completely based upon file exchanges picked up by one SAP system, which processes the data using a BAPI. An Interaction Pattern is a combination of CORA elements across layers connected via relationships, it’s 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 and gives a higher quality of estimations.

Assess the results through identifying Risk Area’s and resolving them. This is an activity that does not stand on it’s own, but is executed in parallel with all other activities. An uncertainty in a requirement, an unstable or unknown technical component poses a risk on 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 are 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 out 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 how to implement these patterns are defined.

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