Capabilities vs. Business Functions: Same Difference?
Nov 5, 2020
In this recent video, I outlined why enterprise architecture is an essential instrument in improving the capabilities of the functional business units of your organization. The notions of capability and capability-based planning have become quite popular and important in enterprise and business architecture in recent years. But there is also some confusion around this concept, in particular for those who are familiar with the similar concept of business function. In this blog, I want to clarify some of this confusion.
In the world of engineering, the notion of functional decomposition has a long history, dating back to at least the fifties in information systems design and much further in other engineering disciplines, with roots in mathematics and philosophy. Applied to organizations, this has led to the concept of business function in enterprise architecture: a coherent set of activities describing what a business does. Business functions are not like processes, which order activities in sequences; rather, they group those activities based on criteria like the knowledge, expertise, and skills involved.
From a truly functional perspective, business functions should be implementation-independent and only focus on the what, not the how, but in practice there is often a strong overlap with the organization structure of the enterprise: departments are often functionally defined, with e.g. the Finance department performing the business functions related to financial management. Conversely, business functions are often (but not exclusively!) discovered bottom-up by investigating this organization structure.
Like business functions, capabilities describe what an enterprise does, but they can also capture what it is able to do, its abilities. This capability notion has its roots in military planning. That explains why capabilities describe more than just what an organization does day-to-day: they express the potential of the organization: what are you able to do when the need arises?
Potentially, an enterprise can have capabilities that it doesn’t even know it possesses. To quote from the NATO Architecture Framework v4: “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.”
For instance, the highest-level capability the US military wants to possess is to fight and win two major wars at the same time. This dates back to WWII and the European and Pacific theaters. Luckily, this is not a capability that is needed or used all too often… At a detailed level, military capabilities are sometimes defined down to packing lists of the personnel and materiel that need to be shipped overseas for, say, a ‘base defense’ capability for a military base of size x.
This means that the capability concept differs from a business function, which is typically not used to capture such potential abilities. Of course, if an enterprise recognizes a business function, it will also need the ability to perform that function, i.e. a corresponding capability. That explains some of the confusion between the two concepts, since in many (but not all) cases they can match one-to-one.
Defense architecture frameworks like DODAF, MoDAF and NAF have long used this capability concept, and from that domain it has found its way into the business architecture discipline. This established itself as an independent sub-discipline of enterprise architecture over the last years, partially in reaction to the rather IT-focused way in which EA is often practiced. Approaches like the BIZBOK® from the Business Architecture Guild put a strong emphasis on the use of capabilities, and rightly so. Their implementation-independent nature makes them a great instrument in designing and analyzing enterprises from the perspective of what the business needs.
So, my advice to you is to go back to the origins of the capability concept and use it as it was intended: to describe what the enterprise does or is able to do, its potential. That is what gives it strategic relevance. Business functions performed by the various parts of the organization can contribute to the realization of these capabilities, but I would not create both a full-blown and detailed capability map and an equally detailed business function map. Rather, I would combine these in one structure: at the top levels (say the topmost two or three layers), you can use capabilities to express the high-level abilities of the enterprise. At more detailed levels, closer to implementation, you use business functions to express the concrete activities you perform that contribute to these higher-level abilities. This way, different organizations (or e.g. business units) may also have their own distinct business function structure to support the same capabilities.
I hope I have clarified some of the confusion around the two conceptual cousins of capability and business function. If you have any further questions or suggestions, please let me know! And if you want to know more about capabilities and capability-based planning with Horizzon and Enterprise Studio, download or whitepaper.
