This article first appeared on the HiveMind Network here.
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 organization does which helps to achieve its business goals. Capabilities are generic, meaningful to the business and focussed on specific outcomes. A capability modelcaptures, 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, 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 organization. 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 databases, operating systems, end-user computing and so forth.)
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.
Where the future state of a system is known, this should also be recorded. A common way of classifying systems is “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;
- Holdsystems 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 capabilities to the system or systems 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. A simple example is given in Figure 1.
In practice a map like this can contain much richer information. A capability may be implemented in different systems for different products, customers, locations, or sales channels. A capability may or may not 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 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. Figure 2 shows some examples.
- Capability 1 seems to be implemented in one place only, by a “Buy” system, so is probably not a 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.
- 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.
Pitfalls
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 taken into consideration.
Conclusions
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.