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 SOA governance
Related Q&A from Todd Biske
Whether you view microservices architecture as merely a change in emphasis or a change in approach, its principles have the potential to improve ...continue reading
While some of the hype around SOA architecture may have died down, the importance of API management remains.continue reading
There isn't a shortage of success and failure stories with any integration method. Here's a look at when REST integration with SOA may be best.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.