Those who have been following this blog will know that I have devoted four or five entries to the issue of capability maps. Mainly because I have not seen the need for them and because they can obscure the core operating processes and give too much prominence to the support processes.
So I thought I would share an excellent comment on this topic from David Winders. In 2009, he wrote an article “Capability Frameworks” from which I have stolen some choice paragraphs and added some of my own text and edits. In other words the text in inverted commas is 85% David and 15% me. Apologies David, if I have inadvertently subverted your meaning, but I thought you were making some great points with two excellent examples (one of course is now no longer topical!)
“In nearly every encounter with fellow business architects the subject of capability frameworks seems to come up in discussion. In nearly every case, people are trying to establish their understanding of this approach and seeking to get further information or comfort from discussion with an outsider who might have the answer.
I have concluded that we need to recognise the differences between capability frameworks and process architectures and understand where they add value and where they don’t. We need to perhaps use more concise language that is business-focused and be aware that different disciplines use conflicting terms like “business services” creating unnecessary confusion. I would suggest that “business building block” is better than the ambiguous term “capability” to describe a portion of the business that delivers something, but with reference to the capability in the name of the building block.
Capabilities focus on outputs whilst processes are concerned with actions. In financial services a high-level process architecture often looks nigh on identical to a high-level capability model. Hence, in a process dominant sector like financial services, people look at capability models and say “what is the point?” Apart from a slightly different naming convention – process is verb-followed-by-noun (Make Payments) whilst capability is often noun-followed-by-verb, (Payment Making) – there is little difference between the two.
A possible reason for the convergence of process and capability models maybe due to reluctance to define capabilities. If you ask people in an organisation steeped in delivery, particularly in a high volume processing area, they are often more focused on what their department does day to day than what the department delivers to a customer. If you ask what the capabilities are, you universally will get a list of processes. It is quite difficult to ask people to forget how they do things, and think about what the deliverables are instead, and what the outputs mean to customers or the rest of the organisation’s value chain.
Military enterprise architectures MODAF/DODAF do give special focus to capability frameworks, as the military is more interested in what it can achieve than in designing repeatable activities in the form of processes; from an architecture perspective the capability of a platoon or a gun is more important than how it is deployed in the process of executing a particular battle (the process view).
A topical subject at the moment (2009) is the 65th anniversary of the allied DDay landings in Normandy, where the capabilities of “Fuel Supply” and “Stores and Provisions Supply” were provided through the technologies of pipeline under the ocean (PLUTO) and floating harbours (Mulberry Harbour). There was a process content in these “Overlord” capabilities: they were part of the DDay process. But military people doing architecture work are interested in their capabilities to support and maintain mechanized divisions in the field of combat (for example gallons per day or tons per hour).
Like so many things, there is a danger that we get too intellectual about the techniques, tools and language we use. There are situations where the capability language and focus will be most helpful, and others where the process language is likely to be more useful. The only real guide is that it must be appropriate for the audience that receives it. It may well be academically interesting for us in business architecture to have these debates but what value does this add to the business that pays the bills?”
So maybe I should stop my agonising about capability maps? But, there is some value in discussing tools. If we use the best tools, we are likely to do good work. David’s point is that it is horses for courses. Tools should be chosen to suit the situation.