There are different reasons for using the CORA model to define the current and future state of an IT landscape, the most important one being able to identify risk areas which help to:
- define a solid solution for a program or project;
- discover sweet spots for improvement & innovation areas;
- determine the impact of security regulations on a solution;
- perform an audit on a solution.
No matter what the objective, using the CORA model helps in clarifying the solution related to the Software Architecture and spot the risk areas. In order to get a quick understanding of the area under investigation, workshops facilitated with the CORA model are very usefull.
Within Capgemini we’ve got a group called ‘Flying Squad’. Whenever there’s external knowledge needed at a project (support needed at start-up of work, an audit needed for solution shaping, solving a problem etc. ) the Flying Squad team is flown in. Typical characteristic of a Flying squad project is the lack of preparation time; there are only two to three days to come up with a solution and a report-out. I’ve been so lucky to be involved in such exercises. The CORA model helped me getting a quick overview of the situation and help identify the improvement points and/or problem areas.
Preparing the ‘Flying Squad’ workshop
In Flying Squads you’ve got to be up-and-running with the situation in half a day. So you have to be able to digest all the information and bring it down to a simple and understandable overview. For this I always use a workshop which starts with meeting up with the main key stakeholders explaining the playing ground and purpose. Then I introduce the CORA model as a means to speed up the process. Due to its simplicity in no time the CORA model and working method are explained. For this all I need is a beamer to project the CORA model onto the wall. Then I give room to the key-holders to explain the situation, the problem(s), the location of the problem(s) and the systems involved (i.e. positioning within the CORA model). The trick now is to write down on post-its the key features, key components and integration between these parts. Red dots can be used to denote the risk areas in the solution.
In one of my ‘Flying Squad’ workshops, the following question needed to be answered: ‘We need to support integration between local branch offices and communicate this using a central location. We created a solution which needs be verified’.
At this point I knew at least two CORA layers were touched so started asking questions regarding these layers:
- Are the branch offices and central office application all the same?
- Are these applications Legacy, Custom build or Package based?
- What integration functionality is needed, real time, messaging based, file based?
- Is already some existing integration between the branch offices and central office?
- What type of integration do you have in mind?
Then I started questions regarding the other layers, for instance regarding non-functionals like performance:
- What do you know about the current situation regarding network capacity and how does it relate to performance?
- What are expected growing fugures about the needed integration
- What type of security is needed between the branch offices and central office
After getting an idea about the needed functionality, positioned within the CORA model, the proposed solution was assessed being a Service Broker, which could be be mapped perfectly on the needed (non) functionality. So no harm done there.
However the technology vendor proposed a portal for delivering insight for both the branches and the central office, offering a file-upload type of paging, typicially being used by a functional administrator. Because the functional needs within the Channel Access and Presentation Layer were very meager at this point, choosing the portal in this phase of the project would introduce a large risk in terms of costs (i.e. licenses and development work).
Because the CORA model helps identifying risks when designing the solution, it is a risk-aware model. Every mapping onto the model should be explainable and traceable. Every part where the solution is still not clear, both the functionality and technical aspect, is a risk area. By putting a red dot on the model where the risks are you easily get an overview of the overall risk of the solution.
The report out is often done to a group of people who are not always involved in the nitty gritty of the project. Again the simplicity of the CORA model with the investigation area plotted onto it, gives direct insight in risk areas and consequences for the business and technology, which makes decision making a lot easier.