I have been interviewed a couple of months back with a digital transformation officer at a relatively large company, and it seems that this office was just established to synergize all the initiatives across that company.
Anyhow, as part of the talk we had, I briefly talked about business capabilities as an essential assessment tool for addressing any transformation activity. To that, he responded asking me what’s a business capability. Yap, I know this is a question to see my knowledge in the domain which is fine by all means. To that I answered: “It an ability or capacity that a business possesses which helps it in achieving a value” or on other words “what the business does and how well can it do it?”, Yap that is what at least I know from the definition of business capabilities according to the Business Architecture Guild. Ok, so he contained asking me if the agility is an enterprise capability? Well, that is for sure not a capability but rather a corporate value rather than a capability!
Something similar has happened with a friend of mine when discussed capabilities where he started arguing that Enterprise Architecture is a capability of an enterprise; that line ignited at least 30 minutes discussion on what defines a capability.
As far as I know, the first who introduced the concept of business capabilities was Ulrich Homann in his article A Business-Oriented Foundation for Service Orientation in 2006 (I am not doing literature here). That article was mainly focused on business capabilities within SOA-enabled enterprises, which makes it much easier to define and orchestrate business services across the enterprise spectrum. Just before moving forward, a critical distinction is a difference between the capability word and the capability within a business; the earlier is just the ability to do something regardless while the latter is the ability of the business to do something to create value for its stakeholders. This is why when my friend said EA is a capability I immediately objected on the premise that it is just a function rather than a capability (huh I will talk about functions to solidify the concept in my thick brain).
Now it is essential to have one and only one list of capabilities for an enterprise. The reason is that the business capabilities can be later become the reference that crosses all business units and stakeholders that defines what the enterprise does. I hate having multiple capabilities and different categories of capabilities within the enterprise, like the ones mentioned in Marc Gewertz book, unless it is from an enterprise and system engineering perspective cause the capabilities is a glossary of what the enterprise does. Thus socializing it will give a better understanding for everyone of what the enterprise cumulatively does to produce value. Moreover, hence, communication can be much more straightforward and concise across business units.
So what a typical capability map looks like? Well here is a one I sketched:
This sample is very small and reaches up to level 2 of capabilities leveling. A Typical enterprise might have from 20 to 25 level one business capabilities and reaches up to levels 5 or 6. Heck, even level 7 is not unheard-of. For this diagram, I am following the CBA guides for both the leveling and stratification. I saw way different business capabilities representations ranging from a simple listing of the capabilities like the ones in Archimate (I am using the strategy view in the diagram) to very elaborated one like the one demonstrated by Tom Graves. My issue with having a simple listing is that it doesn’t put empathies on the criticality of the capabilities for the business.
Moreover, for much-elaborated ones like, Tom’s work, it digs deep into the value stream which should be abstracted in other architecture views. So, I follow the CBA’s convention for its simplicity and the comprehensive view it presents. Even the Open Group is following CBA for their TOGAF 9.2 update or what they now call TOGAF® Series Guide: Business Capabilities.
So yea, you can name anything a capability, but without centralizing it around the business context then it is all messy with less tangibility.