There are actually two pieces to the capability puzzle. The first is your capability model. Once you understand your capability model, you can begin to create a capability map that will help manage alignment with the capability model throughout the company.
A capability model is a taxonomy of capabilities. In my experience, there are normally at least three levels of decomposition, with the final level being the most granular. That doesn't mean the final level represents an individual capability, rather, it means that capabilities at that level are at the finest level of granularity necessary for your decisions.
For the purposes of this discussion, a capability is one or more functions required for the operation of the business. You may find that other sources define capability as a grouping concept, with the term "functionality" used for the most granular item; however, I feel functionality is too much of an application specific term.
Capability models can be tricky to develop. As with any categorization, there are multiple ways that things can be organized, so how you choose to do so will depend on your method of organization. Strive for an organizational method that matches the way your company makes decisions around key capabilities.
These capabilities should make sense to your business leaders, at least at the higher levels in your model. If your enterprise architecture team is like most, and has grown from the IT department, be sure to include your business stakeholders in the discussions. The capability model is a representation of your business, so it needs to make sense to everyone in the business, not just IT.
A capability map, as the name implies, maps the capabilities defined in your capability model to the applications, systems, and components in your technology portfolio. This is where we get into the alignment between technology and the business. In the simplest sense, an application provides a capability. Here's where capability mapping gets very useful.
First, if your map reveals that you have more than one application that provides a capability, it may be an opportunity for consolidation. There may be perfectly good reasons for having multiple applications providing the same capability, and if there are, those should be documented and consistently applied.
For example, your organization may have a diversified operating model with no overlap in customer base across the different operating units. If this is the case, having multiple applications that provide customer management capabilities may be perfectly alright, as long as those applications are aligned to the operating units. But, if there are multiple applications providing that capability within an operating unit, it may be something worth looking at more closely.
Besides finding redundancy in the portfolio, capability mapping shows you how applications span the capability model. As mentioned earlier, you will likely have at least a three level categorization of capabilities. It is not uncommon for a single application to provide more than one capability. Preferably, those capabilities would also be grouped into a single category at a higher conceptual level. If they aren't, then you are at risk of having applications that are out of alignment with the way your company thinks about its business capabilities.
There are many reasons why misalignment can occur, but the important thing is that you have a way of quantifying how closely solutions align with business defined capabilities, and can make a decision on whether it needs to be addressed. The capability model can represent an optimal way of organizing and providing like capabilities for your business.
Not only is this a useful tool for internal business and IT alignment, but it is also a useful tool for third-party acquisitions, whether a simple technology purchase or a merger or acquisition. If the third party has a different capability model than you, or if mapping it to your capability model uncovers systems that span across your capability domains, it helps identify alignment decisions your organization may need to address.
This was first published in June 2011