The CORA Model

Introduction

This blog is the second in a series about the CORA model and Cloud Computing. In the first blog the viewpoint of the CORA model was described shortly (being to enforce predictable, repeatable and risk-aware application design on different architecture levels, being  Enterprise level and Implementation Level). After that the Cloud definition of the NIST-institute was used to connect CORA with Cloud Computing.

The CORA model delivers a 'common' stack of IT landscape elements and their interaction to support the decision making process regarding architecture style to be used, elements needed, their interaction etc. Besides this a 'dynamic' view is needed showing how a (hybrid) cloud should work in the end with the actual interaction between services presented, derived from the CORA elements and based on the concept of information hiding. This is described in this blog using TOGAF as a reference.

Views on cloud computing

Today many standards exist with regard to Cloud Computing, predominantly from a provider perspective regarding the delivery of cloud services and the deployment strategies for cloud computing (i.e. NIST, The Open Cloud Manifesto, The Cloud Computing Use Cases Group). Also recently a framework and notation is being developed, called the "Integrated Cloud Framework" with a focus on the user perspective regarding the experience or use of cloud services. And then there is the CORA model perspective... How do these three perspectives fit together?

Dynamic view

The distinction can be made clear when the three perspectives are mapped onto the TOGAF ADM.

This figure show that different (enterprise) architectures can be designed, depending on its goals and purposes. Because of its specific dynamics (determine Cloud Services to be used and deployed within end-to-end processes spanning multiple domains), Cloud Architectures will be different from purely "On Premise" architectures. This means that these type of architectures (deployment strategies and the abovementioned framework) are dynamic in nature, based on specific circumstances and organization is faced with. It is also shown that regardless of the architecture to be designed the same steps within the ADM need to be taken.

Static View

Where CORA comes into place is that any dynamic architecture will make use of (a subset) of elements described in the model, where elements can be module, subsystem, object, software component or a whole system (depending on the level of needed detail). This rather static 'common' set of elements is needed to make the proper design decisions regarding elements needed, their interaction and architecture style to be used. This will be especially important in a hybrid cloud environment where elements within the Enterprise IT landscape and interact with (the same) elements within the IT landscape of Cloud Providers!

In the next blog CORA elements which are used "on premise" and "off premise" simultaneously are mapped and assessed.