After the BP Trends newsletter this month on Business Capabilities and the ensuring linkedin debate, Adrian Grigoriu in his column on ebizq has done a great job (as usual) of taking the whole concept back to first principles and putting it perspective.
I would describe first an entity that ties a functional process group to the people and technology that execute them. This functional process grouping consists of related processes (such as recruiting, for instance). The associated people would have the skills to execute the processes (to recruit). A (recruitment) application would perform the automated part of the process.
The entity would consist of the process, the skilled people and the application performing the activity. A process alone is an abstract concept; it cannot deliver without the people and systems.
Let’s call this entity a Capability.
The capability can be performed repeatedly or on demand and it can provide services to the enterprise or to other parties. It can be roadmapped and strategies would cascade to capabilities for implementation.
As much as I like the definition, it also kind of worries me in the same way that BPM COE initiative sometimes worry me.
Implicit is a significant effort in mapping and creating the AS-IS and a roadmap to improve it. It’s a great set of tools if you have the right kind of problem and a lot of effort to make pretty diagrams if you don’t.
In my experience the model is only useful if all the stakeholders see it as relevant and, usually, the quickest path to relevancy is to find a problem and solve it, quickly and publicly. Nothing creates engagement like success.
My advice to the champions of the Capabilities in the Enterprise Architecture world is find a business sponsor with a problem and see if a capability map helps solve his problem. Now, that’s a case study or blog article I’d love to read.
Theory will only take us so far.