Another really old paper (2006) but one that I still get asked about. I wrote this whilst under contract to Cornwell Management Consulting (later became Serco Consulting) for one of their clients who wanted to use the Zachman Framework, but didn’t know where to start. Looking back on this now (2019) it all looks rather naïve.

What is Enterprise Architecture ?

Organisations develop an enterprise architecture (EA) to inform the decision making process. By understanding how complex organisations are structured, how they function, and what technology supports those functions, the decision maker is better informed about the impact of change – how changes to technology affect the business and how changes in process drive new requirements into the IT. One of the main uses of EA is in supporting change programmes – it acts as a common guide for all participants in the programme, and ensures that they understand how their work fits in with, and impacts on, the work of others. The key benefit of Enterprise Architecture is that it allows early identification of clashes and incompatibilities and so helps to prevent duplication and re-work. The other benefit is that the tight coupling of the IT architecture to the business helps ensure that solutions actually mean the requirements.

It would be wrong to think of EA as an IT discipline, as it is far broader than that. However it must be recognised that, in most cases, increasing complexity in IT has been the driver for EA adoption – the sudden increase in IT portfolio size that results from a merger or acquisition has often been identified as a justification for EA projects.

What EA seeks to do is model the relationships between the business and technology in such a way that key dependencies are exposed from the underlying complexity and so can be used to support decisions. This could be seen as a critical path of dependencies between the operational domain and the technology. For example, by ascertaining which business processes are supported by a given software application, and then which platform the application runs on, it is possible to calculate the impact on the business of hardware obsolescence. From the same model, it would also be possible to examine, the cost of replacing the application, or which processes could be best re-designed to reduce the IT portfolio. When other dimensions are introduced such as data models, organisational structure and standards, questions which initially appear impossibly convoluted can be answered, provided the dependencies between domains are all known.

The information that is used to inform an EA can often be obtained from the appropriate departments of the organisation (though the information can vary in quality). The job of the Enterprise Architect is to put this information together, and establish the key dependencies. The first stage in any “green field” EA project is to establish what models and architectural information already exist in the organisation, how complete the coverage is, and at what level of maturity. This paper outlines Cornwell’s approach to establishing the coverage and maturity of an Enterprise Architecture.

Architecture Frameworks

An architecture framework is used to categorise models of the enterprise. The categories are usually called “views”, because they define how a certain aspect of the enterprise is to be represented. The models that conform to these views are called architectural products, or usually just “products”.

The best known of the architecture frameworks is the Zachman Framework™ which categorises models in terms of their audience – e.g. business models, technical models, etc. – and in terms of their purpose – data, function, network, etc.:

There are many other architecture frameworks, including TOGAF (which is more of a methodology than a framework), and MODAF (the MOD Architecture Framework, based on the US DoD Architecture Framework).

Frameworks are key to Cornwell’s approach to EA, and in particular they form the basis of the EA Maturity Dashboard. For each view in the framework, the dashboard summarises the status of the existing EA models in terms of the completeness of their coverage and the quality/maturity of those models.

The EA Maturity Dashboard

In any new EA project, one of the most important things to do early on is establish what already exists in terms of architectural products. In other words, there is a requirement for an audit of the organisation’s business and technical models. From working on a number of EA projects, Cornwell recognised the need for a packaged EA audit service, using the skills of our consultants to analyse existing architectural products and provide guidance to the customer on what is needed to complete the architecture. A key part of this service is presenting the findings of the audit in such a way that the customer quickly understands where the strengths and gaps in the architecture exist.

Put simply, the Cornwell EA audit service provides experienced EA consultants who collate, analyse and report on the state of the customer’s enterprise architecture. The first stage is to ascertain an appropriate architectural framework to scope the audit. This is a crucial aspect of the audit as it defines what types of product are in scope and which are not, and also defines how the results are to be presented – the EA Maturity Dashboard.

Once the framework has been established (we usually recommend you use an existing framework, or a derivative of it) we produce a survey based on the framework and begin the process of collating and auditing the architectural products. The audit results in two measures for each of the model categories (views):

• Completeness against the View– is there sufficient breadth and depth of models to cover the scope of the view ?
• Maturity of Models – this is measured against discrete levels of maturity, with the lowest level being “dumb diagrams” through to the highest level which are models that are fully integrated with other models as part of a common repository

The default presentation is to use colour coding for the maturity and a bar-graph for the completeness:

In the example above, there is good coverage of existing products conforming to View 1, but their level of maturity is low. The products conforming to View 2 do not conform the complete scope of the view, but are at an advanced level of maturity. The products which conform to View 3 are reasonably mature, but do not conform well to the view.

The example below shows a typical dashboard based on the Zachman™ framework:

This simple view is often sufficient for smaller projects, but needs some enhancements for larger change programmes. In particular, when the programme has a certain degree of complexity, such as when there are discrete organisations responsible for delivery of different parts of the architecture, the maturity levels will differ across the programme. The Cornwell EA Maturity Dashboard provides two approaches for dealing with this. Dashboards can be generated for each aspect (e.g. workstream or deliverable) of the programme, as well as compound dashboards for the whole programme:

In the example above, there were only four workstreams, but it is not unusual for there to be many more workstreams in a large programme. Cornwell recommend that for the purposes of the maturity audit, the number of workstreams represented in the dashboard are kept to no more than ten. In many ways, this is a choice about how you analyse the project.

The EA Maturity Dashboard need not be based on Zachman™ – though if a customer does not already have a framework in mind, we usually recommend it as a starting point. The example below shows a Dashboard based on MODAF:

Benefits

The main benefit of the dashboard approach is that it provides CTOs and CIOs with a immediate impression of where their knowledge of the enterprise is strong and where it is weak. It tells them which parts of the enterprise have particular architectural strengths, and most importantly of all, it tells them where to concentrate their EA efforts.

The dashboard is the final product of the Cornwell EA Maturity audit. The audit itself will also expose specific issues and provide detailed recommendations and a way-forward guide for the Enterprise Architecture. The audit is usually carried out at the beginning of an EA project, but it is important to ensure that an existing architecture is kept up to date, so a smaller-scale periodic audit service is also available should customers require.

Cornwell believe that the best Enterprise Architects come from within the organisation. Our service offerings are all about knowledge-transfer and preparing the customer to build and maintain their own EA. The audit and dashboard are key enablers in this, revealing the true state of the enterprise architect to the customer.

Acknowledgements

The ideas underpinning the dashboard developed from conversations with Mike Duffy, Teresa Fox and John Kendall of Cornwell. John and Teresa further developed the audit technique, and were the first to test the dashboard approach, providing invaluable feedback and refinements to the dashboard.