Open Group on business-capabilities – a quick review
Blog: Tom Graves / Tetradian
You might perhaps describe this piece as “praising with faint damns” – but oh, it’s so nice to be able to say something nice for once about The Open Group!
Okay, yeah, maybe a bit unkind to start this that way: but Open Group have so consistently made such an utter hash of so much of enterprise-architecture – with both TOGAF and Archimate still fundamentally unfit for almost any viable purpose in present-day EA – that it’s a real pleasure to come across a document from them that actually does make real practical sense.
In this case, it’s a recent white-paper on business-capabilities: catalogue-number G161, ‘Open Group Guide: Business Capabilities‘ (free download, but registration required).
The really good news: it doesn’t have any of the endemic IT-centrism that’s otherwise crippled just about everything else they’ve produced in the past decade and more. Instead, it’s just solid business-architecture, properly done – and that is so, so good to see! It is, at last, something from them that I can genuinely recommend to other enterprise-architects – including those of us who work at the whole-of-enterprise level.
Here’s the one-paragraph summary, from the Introduction section:
Business capabilities provide an abstraction of the business reality in a way that helps to simplify conversations between interested stakeholders. Defining a business capability’s supporting components (roles, processes, information, and tools) provides a business context for those supporting components. Creating a business capability model for the enterprise promotes more of a common understanding of the business.
What’s interesting, to me at least, is to note some of the routine traps for capability-modelling that they haven’t led others into here:
- Definition: ‘Capability’ is defined as ‘the ability to do something’, with the ‘Business’ merely as an indicator of scope – and not as something fundamentally-different from other types of capability.
- Consistency of terminology: The document correctly notes that we need to be able to use the same terminology for capabilities and suchlike in every context and at every level – hence why ‘Business’ is merely an indicator of scope, not of qualitative difference.
- Naming: The document recommends that capabilities should be named as nouns, as non-active ‘ability to…’ – not as active verbs, which always creates confusion with services, functions and processes.
- Naming: The document correctly warns that “appending ‘Management’ to the end of a term does not suddenly make it a capability”.
- Relationship to organisational-structure: The document correctly warns that the capability-model must not be linked directly to the current organisational-structure – the latter may change almost from day to day, whereas the capability-model would or should remain much the same for as long as the organisations operates within that overall type of business.
- Role of IT: The document correctly notes that capabilities (especially at a ‘Business’ scope) may be implemented in many different ways, including human and machine – not solely via IT-based means and ignoring everything else, as is too common in other descriptions.
- Recursion: Although it does struggle a bit in places, the document correctly notes that nominally-static capabilities are composed not solely of other capabilities, but also of other resources and nominally-active services and processes – which can otherwise lead people into misinterpreting capabilities themselves as ‘active’.
The only significant omission from the document that I’d noted so far was the absence of any description of the role of skill-level and/or decision-level in capability-descriptions – in other words the decision-making ability and operational-competence embedded within the capability’s ‘ability to do something’. To be fair, it’s a common enough mistake for IT-folks to make, because within IT-systems, competence and decision-making capabilities are implicit, embedded within every instance of the software itself. But in anything involving humans (which includes development and operation of software-applications), skills and competences may be highly variable from person to person – and hence usually do need to be specified explicitly for the respective capabilities.
And yes, it’s fair to say that none of what’s in this document is actually ‘new’ as such. In essence, it’s the same as what we were doing in Australia a full decade and more ago, with recursions of capabilities that provided multi-tier Functional Business Models such as this:
…to this, and beyond:
This kind of mapping was also at the core of what I described in my 2009 book ‘Doing Enterprise Architecture‘, and in my first Open Group conference presentation, ‘Unpacking TOGAF’s Phase B: Business Transformation, Business Architecture and Business Buy-in‘, way back in early 2007.
(In my more recent work, there’s more on these themes in posts such as ‘Service, function and capability (again)‘, ‘Fractals, naming and enterprise-architecture‘, ‘Why service, function and capability‘, and the series of posts on service and Enterprise Canvas, starting with ‘Services and Enterprise Canvas review – 1: Core‘.)
But whether it’s new or not, what’s described in this Open Group white-paper is what works – and that’s what matters, after all.
Again, a strong recommend: if you’re doing business-architecture, this is one Open Group document that you do definitely need.
Leave a Comment
You must be logged in to post a comment.
