I know, I can hear the question now… “How can he be posting about meta-models when the whole reason for the blog is about delivering real-world, gritty value from EBA? How abstract can you get?” Well, I could say “There are such things as meta-meta-models, you know, just ask the people who designed UML!” but that would just be getting picky.
There are two real reasons I’m posting this technique:
- I find that capability models underpin so may other things I want to do with my business architecture that they’re important enough to put some focus on; and
- While there is a lot of buzz (quite rightly in my opinion) about capability models there’s not a lot of information out there about what they actually look like.
These posts aims to set out how you can build a business capability model that can be used to deliver real business value without the cost of consultants, excessive time or expensive tooling. Building the capability model will be the subject of another post but I will show you how to build a capability model yourself, in under two weeks and using free software!
Enough hype, on with the meta-model…
A basic capability model need only consist of 4 first class entities (3 if you choose to differentiate between primary and supporting capabilities in another way, see later):
- Primary Capability – The end-to-end, logical (mostly) response to an actor’s trigger that delivers the value the actor is looking for e.g. Handle Customer Enquiry, Fulfill Customer Order, Provide Regulator Filing etc.
- Actor – The person or entity to which the value is delivered e.g. Customer, Distributor, Regulator etc.
- Supporting Capability – A logical (mostly) capability that participates in one or more primary capabilities but does not deliver value in and of itself e.g. Take Order, Render Communication, Route Call etc.
- Category – A hierarchical “folder” structure for organising capabilities e.g. Sales Capabilities, Customer Capabilities etc.
I’ve also included a second class entity (Focus) that indicates whether the primary capability delivers value internally or externally. This could be inferred from the actor but I would recommend being definitive – external value delivery is far more likely to be a source of competitive differentiation than internal value delivery.
OK, time for a couple of notes…
- You may well find that some primary capabilities “consume” other primary capabilities e.g. while handling a customer enquiry they may also place an order. This is allowed for via the “pig’s ear” recursive association on primary capability.
- Based on the above and depending on your circumstances, you may choose to consider abandoning the differentiation between primary and supporting capabilities. My advice would be to think very carefully before doing so – the key differentiation between primary and supporting capabilities is a question of value-delivery not re-use.
- Aren’t primary capabilities just value-streams by another name? – Absolutely, business capability theory builds on Whittle and Myrick’s work; it doesn’t replace it.
- Logical (mostly) – Don’t get hung up on whether this is a logical or physical model. Keeping it logical means that you don’t need to differentiate, for example, between customer authentication over the phone, via web, or via post. However, keeping it totally logical could mean you miss, for example, a capability to bespoke content in the web-space via CMS. Mix and match logicality and physicality to meet your business’ needs not the models needs.
- Use different category hierarchies for primary and supporting capabilities. Your primary capabilities are much closer to the business and it’s worth considering a business focused categorisation. Microsoft (yes, Microsoft!) have a good starting point with their Motion categorisation of level 1 capabilities. Your supporting capabilities are much closer to the IT realisation of capabilities and it may be worth considering a more functional or entity based categorisation of capabilities.
- Granularity/physicality – Any model is a trade-off between accuracy and maintainability. Physicality and increased granularity increase the costs of maintaining the model but may provide additional insight. Logicality and reduced granularity reduce the costs of maintaining the model at the risk of loss of insight. I can’t give you the answer to this one, but my advice is to keep maintenance costs as low as you can and only increase granularity/physicality when you need to.
So, that’s pretty much it for my meta-model and it boils down to a few simple rules:
- Do differentiate between value-add and supporting capabilities;
- Do focus on the customer to whom the value is delivered;
- Do worry about the costs of maintenance vs. value of insight;
- Don’t fret about whether it’s a logical or physical model or whether it’s a value stream or capability model; and finally
- Do worry about how you are going to use it to deliver results.