The CORA Model

Introduction

Doing audits as a Solution Architect is very instructive for the daily routine of solution crafting. It boils down to the same question over and over again: why did you make this choice? What is the reasoning behind the solution? Too often we realize that there is a gap between Architecture and the Software solution. Grasping the rationale behind a proposed solution is essential because it ensures traceability all the way from achitecture down to the implementation details. It also helps to identify the risk areas which can help improve the predictability of the implementation project and/or program we are working in. Finally it helps to check whether the proposed solution is complete, if we made the right choices regarding possible reuse and if the functionality is available 'out-of-the-box' or do we have to build it from scratch.

CORA is extensively used in the Solution crafting phase at the start of projects. The actual functional and non functional needs have to be translated into a solution which aligns with the Architectural principles and the Reference Software Architecture while simultaneously looking at reuse across the Enterprise.

The 'Why' process touches the same parts as the solution crafting process and is a repeatable and predictable process.

Examples of aspects in The Why process are: 

• How is the functionality split up over the CORA layers, what is the relations between these layers and what is the rationale behind it?
• Make a counter check from the CORA layer perspective. For instance if the Integration layer is hardly used but application logic from legacy systems is needed, an omission in the Integration is spotted.
• Check the risk areas decide in what CORA layer these are situated. Validate that no other functionality can be identified as risk areas. How is this risk mitigated and what are the investigated alternatives?
• How are the architectural principles related to proposed solution, where in the solution crafting process are these principles used, in what parts of the solution and what are the effects on the implementation?
• What CORA layer elements are used by what functionality and why?
• How are the CORA elements implemented, what technology is used, and (again...) why?
• The choices need to be made in the right order. When the technical solution is choosen before the functionality is investigated thoroughly, you know questions need to be raised.
• How are the vertical CORA layers, Security and Governance used in the solution?

Just like Test driven development, the repeatable and predictable process of the CORA modeling leads to a 'Why' driven solution crafting.