How to Fix Business Capabilities

For many years now, our friends in the business architecture community have rallied around the concept business capabilities and how to model with them. Business capabilities have become the central focus of business architecture efforts and discussions. This is useful. For business architectural discussions with stakeholders, I support these efforts.

As Enterprise Architects, I need to care about business architecture on one hand, and IT architecture on the other. To be business and customer driven, we start with the business architecture and we tie IT architecture to it. This can be a rocky transition, but it doesn't need to be.

As we move from business architecture into the space of IT architecture, we have a problem. I don't want to shy away from it. I think we need to be very realistic about one rather serious limitation when it comes to the use of business capabilities in the IT space: business capabilities represent an artificial consistency that rarely exists in IT architecture. And sometimes, that consistency is actively undesirable.

Bear with me

When we create a capability hierarchy, we nearly always apply a very specific filter that we abbreviate as MECE (Mutually Exclusive and Collectively Exhaustive). What this means: we are not creating a simple taxonomy. We are creating a language, an ontology, and each capability not only has meaning, but it is the only capability that means "that specific thing." In addition, the hierarchy is comprehensive. Nothing the business needs or does is excluded from the capability hierarchy.

For example, if there is a L4 capability labeled "customer bill-to address management", it exists once and only once in the capability hierarchy (even though different units of the business may be involved in actually doing that work). This is a useful feature from a business architecture standpoint. We want the term to have meaning. We want to know what areas of the business are involved and we want to map in the variety of processes that may exist in the organization to that capability.

As a counterpoint, the IT infrastructure does not follow the MECE principle, and in many cases, it actively should not.

In their landmark book "Enterprise Architecture as Strategy", (I'll abbreviate EAaS) Ross, Weill, and Robertson made the case for four different operating model archetypes. They labeled them according to the amount of process consistency and information integration in a simple quadrant diagram. They are: Coordination, Unification, Replication and Diversification. And this is important: these four models represent different ways to run a company. The operating model was strategically chosen by senior executives and reinforced over the life of the company. IT architecture cannot ignore it.

The MECE model of business architecture works very well for Unification model companies. It is also pretty useful for coordination model companies. It is less useful for replication model companies, and nearly useless for diversification model companies (at the enterprise level). In fact, I would suggest that most business architects themselves would agree: when working with a diversification model company, it is reasonable to conduct the business capability analysis independently for each of the diverse companies in the corporate structure. In effect, using a custom tailored subset of the MECE model, multiple times with independent data.

IT architecture needs to use a different paradigm. I learned from a former manager of mine to pay attention to the principle "Commonality at the Core, Diversity at the Edge". (let's abbreviate CCDE). This principle looks to bring capabilities together in a core of systems, in IT architecture, where integration is highly valuable. Each of the four models described by Ross et. al. have core elements and diverse edges. In fact, they may have different notions of "core" vs. "edge" when you consider whether a system is in the value generation, realization, or operational enablement groups of the capability hierarchy (see more on this below).

CCDE is a different perspective on IT architecture and it doesn't fit the MECE model unless you happen to be a unification or coordination company. Unfortunately, most EA tools do a good job of linking applications to the MECE model, but a rather poor job of illustrating CCDE. So we've built ourselves into a corner.

Now, before you argue with me that capabilities are just perfect for IT Architecture, I want you to ask yourself, "Is my experience largely bound to the problems faced by a collaboration or unification company?" Because if it is, you are taking an enterprise view, but not a world view. The world has lots of different styles of companies, and the EAaS book gives us a simply taxonomy to discuss the different types of enterprises.

So if we don't use MECE capability models to organize IT architecture, what is an enterprise architect supposed to do with a capability model? In those companies where the capability model's paradigm doesn't fit, I suggest decorating the business architecture capability hierarchy (adding attributes).

The solution, in my opinion, is to work with your business architects to identify each capability by two additional attributes that you didn't need to consider before:

• Is this capability part of the value generation group, the realization group, or the operational enablement group?
• Is this capability part of the core, the middle or the edge of it's group?

This extra level of effort when applied to a business capability hierarchy is useful because both IT and the business will treat a capability differently depending on the answers to these two criteria. This is not a matter of simple identification. The strategy of the enterprise often involves moving a capability from middle to edge, or middle to core within its group. Additionally, the strategy of the organization is often deeply embedded in the assignment of a capability to value generation, realization, or enablement.

For those of you confused about what I mean by value generation, realization, or enablement, a little detail is useful.

• Value generation capabilities are the capabilities that generate the core differentiation of the enterprise(s). These are the most creative areas of the business and often involve new product development, product improvement, business model development, market strategy, sales strategy and customer service.
• Value realization capabilities are those involved in the transactional processes we typically refer to as "opportunity to order", "order to cash" and "procure to pay". (All of the processes needed to actually deliver the value to the customer exist into this group. Some of marketing and most of sales are in this group as well).
• Operational enablement capabilities refer to what Porter calls "supporting" processes. These are the mission critical processes that provide the underlying support needed to make the organization function. These include finance, information technology, legal services, human resources, and many others. These capabilities are often considered highly valuable for consolidation, even among diversification and replication companies.

I also mentioned that a capability can be core, middle or edge within the group.

• A core capability is one where both the data itself and the processes are common. A good example would be a payroll management capability for a company contained entirely within single country. Literally a single payroll management system is quite useful, even if the company has a dozen different divisions.
• A middle capability is one where the information and processes need to be integrated in order to provide important business value, but the different divisions of the business do things in different ways. The point of a middle capability is that "integration is essential to value". A good example may be for a company that offers both travel agent services and cruise line travel services. Each will have their own customer relationship management processes, but integration between the two is highly valuable to the customer.
• An edge capability is one where the line of business or the business unit gains important business benefits by being independent of other areas of the business. Local processes, or local information, or both, are needed to create a uniquely valuable approach. Of course, we have to carefully examine whether a capability should lie at the edge. Sometimes it is there because "this is how we've always done it", and not because it adds real business value. Sales capabilities involved in meeting directly with customers tend to be edge capabilities for most businesses.

I'm suggesting that EA needs a bit more data for the business architecture to be useful to IT. EA needs us to recognize these different groups, and the different levels of independence within each group, using business capabilities. EA needs to create a notion of "commonality at the core, diversity at the edge" for EACH GROUP in your enterprise, provides a basis that both business architecture and IT architecture can use to deliver value.

This is a compromise on the "pure" answer for business capabilities, but in the end, I guess I'm less interested in what is pure. I care about what is useful. Most of the Business Architects that I know have no problem with this compromise. As both a Business Architect, and an Enterprise Architect, this is useful.