Improving the Use of Capabilities in Business Architecture
Nov 12, 2020
As I discussed in my previous blog and earlier, the capability concept is a great help in defining a good business architecture. It is used ever more widely and rightly so. As I mentioned in that blog, the concept itself is rooted in the defense domain, and from there it permeated various other domains. To quote again from the NATO Architecture Framework: “A capability is the ability to achieve a desired effect under specified standards and conditions. […] In NAF, the term is reserved for the specification of an ability to achieve an outcome. In that sense, it is dispositional – i.e. resources may possess a Capability even if they have never manifested that capability.”
So capabilities are focused on the ability to achieve certain results rather than on how those results are achieved. In particular the idea that a capability not only describes what the business does on a day-to-day basis, like a business function, but also its potential, is very valuable from a strategic perspective, because it provides management with insights in future options. Describing this potential is highly valuable when you want to explore e.g. new business models or other innovations that deviate from the current functioning of the enterprise but for which you do have the ability. This is what makes capabilities such a strategically relevant concept.
Unfortunately though, the way in which capabilities are often used in business architecture has lost some of the benefits of the original notion, by solely focusing on the day-to-day operations. This has increased the confusion among architects who were used to creating business function maps and are now confronted with identical-looking capability maps.
In addition, the rules on discovery and naming of capabilities according to BIZBOK are rather constricting. In their approach, all capabilities must be based on a specific business object and be named after that, in a business object + action naming convention, and this action must not be expressed with a verb; even gerunds like Engineering, Marketing and Accounting are explicitly forbidden…
This leads to rather contrived results. For instance, each of the BIZBOK’s example high-level capability maps for financial services, the healthcare industry, and manufacturing has over 40 capabilities that are all called ‘X Management’ for some object X: Asset Management, Patient Management, Order Management, Work Management, Content Management, and so on. For any regular stakeholder this ‘X Management’ just means the same as ‘Doing something with X’ but doesn’t give any actual meaning to the work involved. So these capability maps have in effect turned into business object maps.
Rather than permitting only business objects as a criterion to decompose and discriminate between capabilities, I favor using the classical notions of coupling and cohesion. Pick those criteria that create the highest internal cohesion and the lowest external coupling. This gives you self-contained capabilities that have a relatively independent existence and can function as true business components.
High-level capability map of an insurance company
This focus on business objects in defining capabilities betrays that BIZBOK is still rooted in an information system-centric way of thinking, even though it explicitly wants to get away from these IS/IT connotations of (enterprise) architecture. This focus is also apparent from its four central notions being Capability, Value Stream, Organization, and Information. Information is just one type of resource of the business – and an important one, of course – but putting it at the center in this way while omitting a more generic Resource perspective, to capture for instance physical resources or capital, leaves a major gap at the junction of business strategy and architecture. Probably this was done to avoid promoting too strong an implementation-specific view of the business, but why then include the Organization perspective?
This is where business architects can again learn from the defense domain. Physical resources (in the ‘tangible’ sense, not in the way IT people use ‘physical’ as opposed to ‘logical’) are essential for the capabilities of many organizations. Whether you work in manufacturing, logistics, retail, utilities, oil & gas, or any other domain outside the ‘information factories’ in finance and government, a solid resource view is key for a useful business architecture.
Of course you shouldn’t focus on implementation detail too early in the design process. This is why the ArchiMate language for enterprise architecture positions generic Capability and Resource concepts in its Strategy layer, whereas the realization of these by more concrete and detailed elements like business functions and processes, people and organization, systems, information, and physical resources, is positioned in its core layers. Typically, in designing something new you would start from the Strategy layer and add its implementation in the Business, Application and Technology layers later; conversely, when describing an existing part of an enterprise, you can start from this core and generalize towards capabilities and resources. The addition in ArchiMate 3.0 in 2016 of these capability and resource concepts, and of concepts for modeling the physical world, was important in NATO’s decision to make ArchiMate one of two allowed metamodels in NAF v4 (see also https://bizzdesign.com/blog/nato-architecture-framework-and-archimate-how-archimate-adresses-defence-needs/).
I would be interested to hear your opinion on capabilities and how you use them. And if you want to know more about capabilities and capability-based planning, download our whitepaper.
