Capability-based Planning is very helpful in defining a good business architecture. It’s being used more widely, and rightly so. The concept is rooted in the defense domain, and from there, it permeated various other domains.
According to 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.”
Business 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 describes what the business does on a day-to-day basis, like a business function and its potential, is very valuable from a strategic perspective because it provides management with insights into 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 capabilities are often used in business architecture has lost some of the benefits of the original notion by solely focusing on 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 capabilities according to BIZBOK are rather constricting. In their approach, all capabilities must be based on a specific business object and named after that, in a business object + action naming convention. 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’ 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 are relatively independent and can function as true business components.
ALSO READ: Capabilities vs. Business Functions: Same Difference?
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 escape these IS/IT connotations of (enterprise) architecture. This focus is also apparent from its four central notions: 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. This was probably done to avoid promoting an implementation-specific view of the business too strongly, but why include the organization’s 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 details 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. In contrast, 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.
For assistance with your Business Architecture or Capability-based Planning, please contact us.
Managing Consultant & Chief Technology Evangelist at Bizzdesign
Marc contributes to Bizzdesign’s vision, market development, consulting, and coaching on digital business design and enterprise architecture. He also spreads the word on the Open Group’s ArchiMate® standard for enterprise architecture modeling, of which he has been managing the development. His expertise and interests range from enterprise and IT architecture to business process management.
