Styles in Architecture

Introduction
One of the primary inputs of the CORA approach are the ‘allowed architecture styles’. In this blog post I will explain what is meant by this and why these architecture styles are so important when using the CORA methodology.

Architecture styles
I differentiate between three major distributed computing architecture styles as distributed business functionality in heterogeneous IT landscapes is what CORA focusses on: the n-tier (“client-server”) architecture style, the SOA (Service Oriented) architecture style and the ROA (Resource Oriented) architecture style (see also Tau et al. Software Architecture Design – Methodology and Styles. Stipes Publishing L.L.C., 2006).

1 See Ross et al. Enterprise Architecture as Strategys, 2006

Note that the CORA model was developed to support all three architecture styles. This is a good thing as all three architecture styles have merit and are often used simultaneously.

Architecture styles within the CORA model
When using the CORA methodology, one of the first steps is to determine the capabilities that are required (before actual technologies can be mapped to them). The capabilities you require depend on the chosen architecture style. This CORA model shows the capabilities that each architecture style requires.

Findings from the CORA mapping
This CORA mapping shows us that all architecture styles require most of the capabilities from the Security & Compliance layer and the IT Governance layer. This should not come as a surprise, but do note that for the N-tier architecture style these capabilities are typically contained within the application, whereas for the ROA and SOA architecture styles additional components/products/applications might be required.

Also can be seen that, compared to the other styles, the SOA architecture style requires a lot of capabilities. This is an indication of the complexity and investments needed when applying this architecture style. The least amount of different capabilities is required when the N-tier architecture style is used. This is because the intent of the N-tier architecture style is to provide as much functionality from ‘a single box’, whereas many of the capabilities in the CORA model focus on integration aspects.

Looking at the way styles are used the mapping shows that solutions based on the SOA architecture style are typically provided through a webbrowser. It also shows that the ROA architecture style is typically used on mobile devices but also requires some form of software development to provide a consumer for RESTful services, either by reusing and extending functionality that already exists (Business Component and Business Entity) or through traditional software development (Make: Application Logic and Application Entity).

These findings provide a first step deriving the risks typically associated with each architecture style. For instance, n-tier architecture style provides many security and governance capabilities ‘out of the box’, but only ‘within the box’: these capabilities can typically not be reused in application integration scenario’s. The SOA architecture style on the other hand provides a lot of flexibility but at the cost of additional complexity in the IT landscape. There are many more risks, which will be the topic for future blogs.