An interesting post from Nick Malik recently about how process architectures and capability architectures are different – picking up on an article from Paul Harmon. I’ll be very interested to see the promised “later blog posts”. In the meantime, though, I’m dealing with something at work that really emphasised some of the differences between the two so I thought I’d share it here.
We provide services to distinct groups of individual customers and those services commonly need to be tailored to those distinct groups. We currently have a project underway to extend that tailoring to our web presence. The first capability increment we are developing is the ability to deliver bespoke web content based on the group the customer belongs to.
In capability terms this can be encapsulated quite neatly into the ability to “Deliver bespoke web content based on customer groups”. This is something that is meaningful to any member of the top table and can equally be used as a scoping statement for the delivery teams – be that business analysts, project managers, test managers, solution architects or whoever.
When we get into the detail of the delivery then, absolutely, things become more complex. We’ve identified that we will need, at a minimum, the following supporting processes:
- A process to develop, test and deploy new content;
- A process to understand what content is currently deployed and, periodically, to get it reapproved;
- A process to understand what content was used for a particular user at a particular point in time (non-repudiation);
- A process to retire content that is no longer used.
In addition, the bespoke web content capability will be used in multiple, customer facing (primary) processes and capabilities – so each of those processes will need to be updated as and when they take advantage of the new capability. Now all of this has to be worked through in the detail of the implementation of the particular project. But how relevant is the detail from an architectural point of view?
My top table doesn’t care what processes we will have to put in place to deliver this capability – all they want to know is can we do it, yes or no? The processes that will use this capability, similarly, don’t care about how the content is managed. All they want to know is what can be done with the capability and how do I access that functionality? Neither of them care what is inside the “black box” only that the black box is there and what it is capable of.
So, to me, some of the fundamental differences between process and capability architectures are:
- Capabilities allow me to talk to any stakeholder at any level (business or IT) about what is to be delivered without having to delve into the detail of the how;
- Capabilities allow me to “architect by black box” creating reusable components of business capability where the implementation details are irrelevant to the capability consumer – this should be a principle that resonates with anybody who has been exposed to SOA;
- Capabilities are a layer in the enterprise architecture that sits above process or IT system architectures – capabilities don’t care how they are realised and you can, for example, automate processes within the capability to improve its efficiency without changing the fundamental building block; and
- As a result of that last point, capability architectures are much more stable than business process architectures, because they are insulated from the “how”, and so require less maintenance.
Now, where I agree with Paul Harmon’s point is that the concept of a capability has yet to achieve a fully agreed definition. I’m not sure that we will ever see that ultimate truth agreed, though. Is there a universally agreed definition of a process map, for example? One question that has parallels with capabilities is “How physical vs. logical should the process map be?”
What I do know is that capabilities have significant real-life benefits for me as a business architect and, quite frankly, I’ll take any edge I can get! Definitions will evolve over time as and when they get tested (and fail) against real world usage. I’m happy and grateful to be part of that real world testing.