Business capabilities vs. business functions: Same difference?

The origins of the business function concept

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 a business function in enterprise architecture: a coherent set of activities that describe 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.

The roots of the capability concept

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 can you do when the need arises? 
 

High-level capability map of an insurance company. Source: Bizzdesign 
 

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 specifying 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 of capability the US military aims to possess is the ability to fight and win two major wars simultaneously. 

This dates back to WWII and the European and Pacific theaters. Luckily, this capability is not 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 they can match one-to-one in many (but not all) cases. 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 strongly emphasize 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. 

How to use capabilities and business functions together?

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. 

Instead, 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, you use business functions closer to implementation 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.

To learn how to effectively model and manage your business capabilities, explore our Business Architecture Management (BAM) solution