Using Capability Mapping to Inform the Target-State Systems Landscape

One of the most important jobs of an Enterprise Architect is to map out the target state for the organisation. Capability mapping is an effective way to drive target-state decisions using objective, clearly-presented information captured from key stakeholders.

Business Capabilities

A capability is something an organisation does which helps to achieve its business goals. Capabilities are generic, meaningful to the business and focussed on specific outcomes. A capability model captures, classifies and presents the capabilities of an organisation in a structured, hierarchical way.

Let’s take the example of an online jewellery store. Business capabilities would include things like “Product Catalogue Management” or “Payment Processing.” (Capabilities are often written in the form “thing-action,” but use whatever form works best with your stakeholders.)

The “Payment Processing” capability might further be broken down into second-level capabilities like “Payment Card Validation,” “Payment Authorisation,” “Payment Routing,” “Funds Transfer” and so forth. Some of these capabilities might be broken down into yet further levels of detail. (A big challenge in capability modelling is deciding how detail to go into. A very high-level model is easy to understand, but probably not of much use. A very detailed breakdown is much more informative, but can take a long time to prepare, analyse and validate. Getting the right level of detail for your particular situation is one of the big challenges of this sort of modelling activity.)

Capability models do not attempt to show organisational structure, roles and responsibilities or process flow. This keeps them simple and quick to develop, but still allows a lot of useful information to be captured and used as in input to decision-making.

Business Systems

A business system is a system which supports the business activities of the organisation. This would include systems for things like customer and account management, product management, billing and so forth. (I use the prefix “business” to distinguish them from systems which only indirectly support the business, such as HR or facilities management systems, and technology platforms such as servers, databases, and end-user computing.)

Of course many business activities are only partially automated, or not automated at all. So an analysis like this almost always includes things like “manual process,” “email/phone call” and “spreadsheet.” The model should also include outsourced business systems and externally-provided business services.

One of the most important attributes of a system is its future state. A common way of classifying future state for systems is is known as “Buy/Sell/Hold”:

  • Buy systems are ones that the organisation plans to grow and invest money in;
  • Sell systems are ones that the organisation has already decided to decommission or migrate;
  • Hold systems are those whose future is not yet certain. (A capability map is a great way to assign a target state to systems categorised as “Hold.”)

Mapping Capabilities to Systems

The final piece of the jigsaw is a mapping from each capability to the system(s) that implement that capability. Conceptually this takes the form of a two-dimensional grid, with capabilities down the left-hand side and systems across the top. At the intersection of each capability and system, a check-mark indicates that that system implements all or some of that capability. Here’s a very simple example:

The mapping shows four systems, two of which are a “Buy”, one a “Hold” and one a “Sell,” and five capabilities of importance to the organisation.  System A (a “Buy”) provides Capability 1, System B (a “Sell”) provides Capabilities 2, 3 and 5, and so forth.

In practice a map like this will contain much richer information. The same capability may be implemented in different systems for different products, customers, locations, or sales channels. A capability may be well-implemented by a system, or the implementation may be a poor fit to requirements, difficult to use, poorly secured or slow. It is important to capture this additional information in the model, since it will inform decision-making.

Insights, Options and Recommendations for Future State

A capability map can provide many insights and recommendations for the future state. The diagram below shows some examples.

We can see from the model that:

  • Capability 1 seems to be implemented in one place only, by a “Buy” application, so is probably not a particular cause for concern.
  • Capability 2 is implemented in multiple systems, so is a candidate for consolidation. System C, a “Buy,” would seem a good candidate for this.
  • Capability 4 does not seem to be implemented anywhere . This may or may not be problem.
  • If we sunset System B, any activity requiring Capability 5 will fail!


The hardest part of capability mapping is getting the right information from the right stakeholders. Draw up a stakeholder map before starting the analysis, to identify who the sources of information are and who should be involved in reviewing and ratifying the model. It is important to get feedback from your stakeholders: it usually takes several iterations to get the model right.  I don’t usually try and populate the model on the fly while I am interviewing someone, but prefer to take notes and feed them into a model afterwards.

Of course the insights you gain from a capability map are only a starting point for further analysis. Life is rarely simple, and it may be that what appear to be multiple implementations of the same capability are actually different in ways that only become clear after further investigation. There may be technical reasons why a capability can’t be moved onto another system, especially for legacy systems or external services. Finally, real-world constraints around cost, effort and the organisation’s capacity for change must be always taken into consideration when making recommendations.


Mapping out the target state of an organisation is a difficult and often contentious activity. It can be hard to remain objective in the face of differing priorities, time and budget constraints and – sometimes – a poor understanding of what the business actually does.

Done well, capability mapping is an effective way to drive target-state decisions using objective, clearly-presented information. It helps take the heat out of the debate, and can quickly bring about a consensus on the best way forward.

Published in Insight / Research, Opinions
Connect with Nick Rozanski

Tags: , ,


  1. Dave MacFadyen

    Hi Nick,
    Nice post!
    I’ve used Capability Models very successfully on past EA engagements. As you say, getting the stakeholders on board is crucial for adoption. Getting the language (ie. terminology) right is key to success as well. For example in the past I’ve used Run/Transform/Grow/Retire to categorise business systems (Rather than Buy/Sell/Hold) in order to align with clients existing Portfolio Management and Budget Planning.

  2. Nick Rozanski Post author

    Good to meet you! Yes, in fact at my last engagement they wanted me to use a model from Gartner called TIME (Tolerate/Innovate/Migrate/Eliminate) – same idea but different names.

  3. Pingback: Using Capability Modelling to Inform the Target-State Systems Landscape – Vitruvius Consulting