How you draw a capability model and map is really up to you. You can actually define the taxonomy in an Excel spreadsheet...
or in any number of EA tools on the market. When creating a visualization of the model, you must be conscious of your audience. Technical people tend to see things near the top of a diagram as things closer to the user and things on the bottom of the diagram as closer to the infrastructure. They may also begin thinking about the capability map and inferring that applications providing the capability near the top of the model can only call applications providing capabilities in subsequent layers of the diagram and so on.
When visualizing a capability map, there are additional risks. When trying to show redundancy, things are actually pretty straightforward. The more boxes there are for a particular capability, the more redundancy there may be. Be careful when using higher levels in the model, however. A broad capability area like "Marketing" can have multiple applications that support the finer grained capabilities without having any overlap whatsoever.
Trying to show problems with application-capability alignment visually can be a trickier exercise, because you're limited by the spatial layout of your capability groups. Rather than trying to overlap an application across your capability groups, a better approach is to use a simple tabular format. On one axis, list out the capability groups of interest, on the other axis, list out your systems. Then place a checkmark in each cell where the application provides that capability. By color coding your higher level grouping of capabilities from your model, you can see where an application provides capabilities that span more than one grouping. Those cases can then be discussed and planned for re-architecture, if the organization deems it necessary.
I've found capabilities to be a very powerful tool that help make discussions around application optimization very objective and quantifiable, rather than subjective and opinion-based. In the simplest sense, capabilities represent the problem that we're trying to solve, while the applications represent the solution. If we can't describe our problems in a consistent manner, then we can't hope to optimize our portfolio.
Dig Deeper on Holistic governance, risk and compliance (GRC)
Related Q&A from Todd Biske
The emergence of the stack brings up an important question: Are app servers dead? Contributor Todd Biske examines the future of the app server in a ...continue reading
Everyone has a different viewpoint on SOA, but three key differences between SOA and microservices architectures can help you determine which is best...continue reading
Why do we need mircoservices architecture? How can we benefit from it?continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.