The terminology used is my own, and although it bears similarity to concepts conveyed in other architecture frameworks there are differences (there are, after all, only so many words in the English language that are suitable for certain concepts). For those readers already familiar with established architecture frameworks, it is therefore worth approaching this material with an open mind in order to avoid attaching existing preconceptions to the content.
Please keep in mind at all times that in my architecture approach, the model you are creating first and foremost is the future model (often referred to as the “to-be” architecture). Starting with the “as-is” model, in an attempt to record the status-quo is, in my opinion, unproductive in the absence of the “to-be” model. (See my previous article http://theenterprisingarchitect.blogspot.com/2009/08/to-be-or-not-to-be.html for a more detailed explanation of this position).
The EA Grid
Essential to an architecture is a “big picture” that brings together all the concepts into a single easy to understand starting point. An Enterprise Architecture is made up of several self-contained, but inter-dependent architectures, and thus the EA is made up of several “big pictures”, as shown in the following diagram:
The EA Layers
The EA is first divided into three layers (down the left hand side of the diagram) defined as follows:
- Business Layer
Focuses on the future needs of the business by describing what the business intends to provide to fulfil the needs of its external and internal customers.
- Application Layer
Describes the high level solutions that need to be provided to support the future intent described in the Business Layer.
- Infrastructure Layer
Describes the raw infrastructure elements that will need to be provided to support the solutions described in the Application Layer.
The EA Models
The layers of the EA are then divided into three model types (across the top of the diagram), defined as follows:
- Behaviour Model
Describes how each element of the architecture will behave in isolation and how they will expose this behaviour.
- Structure Model
Describes how the elements of the architecture will all fit together to form a coherent whole.
- Knowledge Model
Describes what will need to be known, and how this knowledge will be grouped and categorised.
Inevitably this grid results in nine “big pictures”. Nine big pictures might sounds like a lot, but considering that this presents the model for an entire enterprise this is a relatively small number of pictures. Also, each performs a specific job, and many people will be interested in only one or two of these pictures. The intent of a big picture is to convey the overall concepts in one single place that can be easily understood and digested before the reader dives into the underlying detail. For this reason, the techniques used to draw these pictures may be different dependent on the environment, but as a starting point the following descriptions should work in most circumstances:
- Services (Business Behaviour)
Shows the business services to be provided to the internal and external customers to fulfil the business vision and objectives, and models these services as well defined and self-contained processes.
- Organisation (Business Structure)
Shows how the proposed business services fit within the target organisation model, and how these services interact with one another to create the desired customer experience.
- Information (Business Knowledge)
Shows the information as understood by the business as a set of entities and includes the relationships between these entities. This information model needs to be supportive of the business services described in the Services model (and vice versa).
- Capabilities (Application Behaviour)
Shows the internal application services needed by the business (including IT) to allow it to undertake the processes described in the Services layer.
- Solutions (Application Structure)
Shows how the application services interact with one another to fulfil the needs of the Organisation model and thus provide the desired customer experience.
- Data (Application Information)
Shows the detailed data elements and relationships required to support the Information model. This data model is derived from the Information model, but at the same time, needs to be supportive of the application services described in the Capabilities model (and vice versa).
- Components (Infrastructure Behaviour)
Shows the individual infrastructure components available to the business to perform its daily activities. In a COTS (Custom Off The Shelf) environment which adopts a “buy not build” strategy, there may well be a great deal of similarity between this model and the Capabilities model.
- Systems (Infrastructure Structure)
Shows how the infrastructure components interact with one another to fulfil the needs of the Solution model.
- Sources (Infrastructure Knowledge)
Shows the sources of the raw data described in the Data model. In an ideal world, these sources will be derived directly from the Data model, but in reality sources may duplicate data, or separate related data as a result of the choices made in the Component model. This model should therefore identify how the duplication and re-combination of data will be handled.
But that is a lot of pictures to consider, and we have to start somewhere. The majority of “traditional” organisations start in the centre by developing the Solution model. This task often falls to IT alone, acting on a variety of unaligned instructions from many interested parties. In my opinion, this is where many of the problems associated with “Big IT” originate.
It is far better to treat the EA Grid as a jigsaw. Start with the corners, then fill in the edges, and finally complete the centre. The corners allow us to better understand how the edges fit, and the edges give us a better understanding of how the middle needs to look. However, as for a jigsaw, if you find a piece that you know fits an area you are not yet working on, don’t just ignore it; put it where you think it belongs.
It is also best to start with the top left corner (the Services model) in keeping with the service oriented approaches that many architects adopt, and then work left to right and top to bottom (still focusing on the corners first and foremost).
Joining the Dots
The full Enterprise Architecture only makes sense if each of the models links to its neighbours to form an overall joined up picture. It is therefore important to ensure that for each type of model (Behaviour, Structure and Knowledge) there is clear traceability from the Business Layer to the Application Layer and from the Application Layer to the Infrastructure Layer to demonstrate how the needs of the business are being fulfilled, and by what.
This concludes the second part of the Quick Start Guide. The overall Enterprise Architecture has been described as a set of interlinked and mutually supportive big pictures, and an initial indication of the purpose and content of each model has been given.
Further articles will follow describing each of the models in more detail, but from this overview a strong architect should be capable of developing models of whatever flavour they choose that fit into, and fulfil the intent of this approach.
And remember... One of the problems with architecture is that when you describe it in words, it always sounds more complex than it actually is in practice. This article simply applies one of the core concepts of enterprise architecture to itself:
Divide and conquerRegards
The Enterprising Architect