Open Group on business-capabilities – a quick review

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.

Posted in Business, Complexity / Structure, Enterprise architecture Tagged with: , , , , , ,
9 comments on “Open Group on business-capabilities – a quick review
  1. Bruce Kay says:

    A good tip Tom. I downloaded the paper and I’m reading it today. I have agreed with your comments in the past about The Open Group and TOGAF. Whilst I’m TOGAF certified, The Open Group’s humongous documents and it’s methods have always proved too slow and cumbersome to utilise with clients. My colleague Laurence Biglia and I concentrated on capability modelling when we worked with ACT Government Shared Services. It was the only way to get some traction. But our ICT-fixated work mates always tried to block this approach. Plus our ‘business’ (i.e. Non-ICT) work mates were always sceptical about EAs discussing Non-ICT topics. We needed a lot of patience and strong determination to eventually deliver valuable contributions. Nowadays we’ve left behind a legacy of important information to aid decision making.
    What pleases me most about this TOGAF publication on Business Capabilities is that the language just might become part of the vocabularies of the ICT folks and ‘business’ folks who were previously so resistant.
    Cheers
    Bruce

    • Tom G says:

      Glad it’s useful, Bruce. (And why am I not surprised that you’re referring to an Australian context? Yes, you still have some intransigence and clinging-to-IT-centrism from colleagues there, but in general it’s way, way more advanced in understanding than over here in the UK: I’d say that here it’s still barely catching up with where we were in EA when I left Australia nigh on a full decade ago – and the US is probably a full decade behind even the UK. Bah…)

    • Igor says:

      Hi Bruce,

      I would be keen to discuss further with you the challenges you faced and the approach you took since i’m facing similar dilemmas. What would be the best way to reach out to you?

      • Tom G says:

        Hi Igor – Bruce may have had an auto-notification from this website, but in case not, I’ve sent him a contact-email on your behalf. Hope it’s useful to you both. Best regards etc – tom g.

  2. David Eddy says:

    Tom –

    >
    > 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
    >

    I would argue that embracing this “use the same terminology” indicates how totally removed from the real world Open Group/EA is.

    Long story short… this opens the door to “My words are right & yours are wrong” mindset. Not a strong selling point.

    Since this is a TOGAF forum, evoking the Zachman Framework is a bit out of bounds, but much easier to grok.

    “Embracing the same terminology” means that in Zachman Cell 1,1, the CEO will use the same terminology as the programmer in Cell 1,6? I don’t think so. Even if they did by remote chance use the same terminology, in all likelihood, the meanings would be different.

    • Tom G says:

      Oops… – my apologies, David, looks like I’ve set you up for a misunderstanding there.

      a) This isn’t a TOGAF forum here, it’s just me commenting on something that some of the Open Group crew have put out – and that’s not necessarily a ‘TOGAF Forum’ document either.

      b) Yes, of course the CEO in referencing Z1.1 is going to be using very different terminology from a deployment-person in Z1.6. (Programmer would be more at Z1.4 or .5 than .6, I’d suggest?) But in talking about consistent terminology, I’m not talking about the CEO, the programmer or the deployer – I’m talking about the architects who have to do the translations between those (very!) disparate worldviews and domains. We need a consistent terminology – or meta-terminology, rather. That’s the point I was making there.

      So in that sense it’s unfair to Open Group to use what I’d said in the article above to assert that it “indicates how totally removed from the real world Open Group/EA is” – not least because it wasn’t their words, they were mine. (I’d agree that Open Group are totally removed from reality in other ways, but not in this one.) And the key point of architects using a consistent terminology is precisely to avoid (defuse?) the ‘”My words are right and yours are wrong” mindset’. We choose consistent-metaterminology as a conscious choice, aware of the risks and limitations of doing so – not because we’re deluding ourselves that our choice of terminology is somehow ‘The Truth’, but because we’re well aware of how much it isn’t. Consistent-metaterminology gives us a means to manage cross-domain translations, in a way that’s difficult (if not impossible?) to do without that metaterminology – that’s all that’s implied in the section you’ve quoted above.

  3. Tom – thanks for the pointer. I agree that this document provides a better articulation of business capabilities, and that it will advance the understanding and practices associated with architecture development and realisation.

    There have been longstanding issues around the identification and documenting of business capabilities, with many examples being quite poor quality, leading to significant criticism from various quarters (eg BPM advocates). I think this document helps in this area, but there is still a little way to go.

    I will come back with a separate comment on the document content itself.

  4. Two particular areas of interest – partly based on comparing my own approach to defining business capabilities and operating models.

    a) I note that TOG describes a business capability as being composed of four components – roles, processes, information and tools – and collapses technology, machinery, finance and IP into this last category. My personal preference is to identify each as gaps are often caused by particular components and there are significantly different responses to be made, depending on whether a gap is due to financial constraints vs technology constraints (for example)

    b) I was interested to see the material on stratification and levelling – this will help with modeling quality. I note, though, that three Level 1 domains are identified – strategic, core and supporting. I have been adding “development” as a fourth domain. This covers the entire change / transformation lifecycle. Given that enterprises often fail in implementing change, it seems important that we assess their change / transformation capabilities as gaps in these areas may be more critical than some of the other gaps!

  5. Alec Blair says:

    Tom – I am happy to get the praise – faint or not. It seemed that every time I read the document I found that there was something more we could add. As I am sure you can imagine, we had to say, “It’s good enough.” and get it out for people to use.

    I ground myself in the reality that, “All models are wrong, some are useful.” If we go in recognizing the limitations of our models, but can make them useful, then we can be successful.

    We are planning additional guides to help us build on the Business Capability Guide to show the power of this abstraction in different scenarios. I hope you will continue to see that we make practical sense.

Leave a Reply

Your email address will not be published. Required fields are marked *

*