Merging Capability Modeling with Process Modeling

Gentle reader: can you help me to solve a debate?

Introduction

Many companies have adopted the practice of capability modeling in the past few years.  Often, this is done to align the portfolio of business initiatives (and often, IT projects) with corporate strategy.  Many folks, including our own Microsoft Services Business Architecture (MSBA) consultants, view capability modeling as both a great business architecture practice (it is) and a great way to align SOA to your portfolio (it is that too).  Internally, Microsoft IT has adopted capability modeling with a great deal of success. 

Unfortunately, the way that capability modeling is described today, there is an element of business architecture that is "outside" the capability mindset: business process.  Capabilities are often defined as a 'mapping' to business processes, but there is little or no attempt to include process modeling in the capability modeling approach. 

This could cause some confusion if you are not careful.  Many companies have long-standing efforts to describe, optimize, and reuse their business processes.  These efforts are led and guided by various methodologies including six sigma and lean engineering.

So if your company is a process oriented one (or becoming a process oriented one), how do you fit in capability modeling?  Do these two methods conflict? 

I do not believe that the do.  In fact, I believe that they are quite complimentary... but you have to take a moment to see how they relate.  The debate that is going on at the moment: how do they relate?   That's where I'd like your opinion.

Perspectives

In process modeling, you divide up the things your company does into high level cross functional processes (like selling, marketing, fulfillment, etc).  Breaking down processes into sub-processes, and sub-sub-processes, you eventually get down to activities.  (I use the same definition as the Workflow Management Coalition: an activity is a unit of work.  Think of it as the leaves of the process tree.)  Process modeling is essentially concerned with how these activities are done.

These activities are interesting from a SOA standpoint, because the activities are where you actually perform automation.  You connect services to these activities.  This is where work is done.

Unlike process modeling, capability modeling attempts to separate the "what" from the "how."  The capability view is quite understandable for the business, and unlike process modeling, doesn't require considerable training in order for the business to describe itself.  I've seen a group of four business architects analyze a business, and adapt an existing capability taxonomy to it, as a PART TIME EFFORT, in a couple of months.  All this while holding down their other responsibilities.  If you don't have a group of architects to call upon, like we do, tailoring such a hierarchy can be done in a matter of weeks using a full-time Microsoft consultant.  Maintaining the hierarchy is fairly simple.  Using it is quite valuable for project portfolio alignment, both in the business and in IT. 

With capability modeling, you create a hierarchy of the company's capabilities.  You then identify the capabilities that best align to corporate strategy, and which one of them need the most work.  Focus your work there, and you get a big payoff through focused investment.

Microsoft is an interesting bird, but I don't think we are unusual.  We want to do both.  Which unfortunately means that, unless we are careful, we end up with two hierarchies.  No one wants to maintain that, and we don't get consistent benefits if process modeling and capability modeling don't work together.  But how to combine them?

There are two opinions within this company. 

Opinion A

In this understanding, the notion of "Capability" is a good way to create the top levels of a hierarchy, while process creates the lower levels.  This requires discipline because you have to limit the hierarchy of capabilities to one or two levels.  On the other hand, it is not possible, after just a few levels, to describe "what" a company does without making assumptions about "how" the company does it.  This view is illustrated with the diagram below.

Opinion B

In this understanding, the notion of Capability is related to the objectives of specific organizational units within a company.  This is a totally different perspective, in that we are intentionally saying that capabilities should look like the organization itself, an the business should "see itself" in the capability hierarchy.  There is little or no attempt for capabilities to be mutually exclusive from one another, and they can go down to five or more levels of depth.   Therefore, the fact that the support division sells support contracts, while the retail division signs up retailers using retail contracts, both of which 'sell stuff' is not a problem, because we are less concerned with redundancy in the capabilities themselves.  Where we find uniqueness is in the activities.

In this view, activities are a shared and linked resource, managed in a database of activities.  A functional view would assign particular activities to a particular business unit or department, which reports in an organizational chart up to a senior leader and eventually the CEO. 

Business processes are ways to thread those activities together, respecting the fact that sometimes different departments MUST perform the same activities, but that they don't have to use the same processes to do it. 

What do you think?

These two opinions are quite different.  Perhaps they are both quite useful, and the choice of which to use depends on your company.  Perhaps, one is optimal and the other is suboptimal, and you should avoid one and use the other.

I'd love to hear your opinion.  Personally, I like "Opinion B." But I reserve the right to be wrong on this.

Your turn to vote.  I'd love to hear your thoughts.

Technorati Tags: SOA,Business Process,BPM,EA,Enterprise Architecture,Capability