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

Comments

• Anonymous
  April 24, 2008
  PingBack from http://microsoftnews.askpcdoc.com/soa/merging-capability-modeling-with-process-modeling

• Anonymous
  April 24, 2008
  Opinion A: I don't like the idea that capabilities are performed by a process. Opinion B: Does the hierarchy of capabilities have to look like the organization itself? I do not think so, but if you think so isn't this the case for Opinion A too? My vote goes to Opinion B. Relating capabilities and processes gets easy and natural when you think along these lines.

• Anonymous
  April 25, 2008
  +1 for Option B.  My concern with the process-oriented approach is that processes that may span multiple capabilities and organizational units are too difficult to manage or govern?  Who "owns" the process?  Who funds it?  I think option B, whereby capabilities (exposed via services) are orchestrated to form processes is the most flexible and ultimately useful of the two. Thanks for insightful post.  Out of curiosity, do you ever read Steve Jones' stuff?  He often talks about similar topics.

• Anonymous
  April 26, 2008
  The comment has been removed

• Anonymous
  April 26, 2008
  Hi Craig, I like the way you think.  There may, in fact, be more than one "right" answer.  It could depend on the size and complexity of the company, as you suggest, or the maturity of the process-orientation efforts.   Assuming that there is a model you would use for the most complex of situations, and we simplified from there depending on the situation, would you use "a" or "b" to model that "most complex" scenario?  It sounds like you would vote for "b" in that case.   --- N

• Anonymous
  April 26, 2008
  Doesn't this depend on which operating model your organisation pursues?  If it is operating under the Replication or Unification model, then would you not define a single capability map, but under the Coordination or Diversification model would you not define a different capability map for each division? This then defines the extent to which your organisational structure influences your capability map. Once you then had your capability maps, would you not then just define the business processes that support each capability independently?  These business processes would of course interact, but would do so through an event-driven model.   One business process in one capability would raise business event, which would then trigger other business processes within other capabilities.

• Anonymous
  April 28, 2008
  The comment has been removed

• Anonymous
  April 29, 2008
  The comment has been removed

• Anonymous
  April 29, 2008
  Hi Brian, Sounds like a vote for Option A.   Do you see processes like "Order to Cash" in your environment?  How would you handle that if the capabilities like "Sell Product" are at the top level?  Perhaps "Order to Cash" isn't really a process? Not trying to put you on the spot.  I'm honestly asking.   --- Nick

• Anonymous
  May 01, 2008
  Enjoying the discussion, We have a capability object that I believe fits the above description but we are looking at this a bit differently and I would like to get some feedback.  We have it placed capability as a logical part of our application architecture.  It is tied to our application (again logical) and also to an object to represent the physical software.  The intersection of this defines a usage scenario or specific implementation of the capability using specific software.  Since the capability is at a logical level we tie it to the process model at a lower level but not at the activity level.  The usage scenario would tie more closely to the activity level. Our thinking is we needed capability in this place to answer questions like how many processes are supported by the same capability, how many software solutions support the same capability, what applications use what capabilities, and what capabilities do we have that we are not using (software capability not deployed).  We see this as a key part to understand how to consolidate, harmonize and enhance our business by understanding capabilities from an application (logical) perspective and then tying it to the business processes that use them. I understand that some of you may be thinking not all capabilities have software supporting them.  We do accept that and would have capabilities within an application, tied to a business process but there is not any software.  Essentially this is a non-system supported capability.  This may represent an opportunity going forward as technology or the business process changes to automate that capability.  This is another perspective we are expecting the placement of capability to help us identify. So we are not option A, closer to option B and could easily add in the second hierarchy shown in B, but not sure what it would add. We are very early in our modeling and would encourage feedback on this, especially gotchas that we may need to watch out for or concerns you may have around this approach being successful. Thanks, Andy

• Anonymous
  May 01, 2008
  Hi Andy, I'll confess.  When I presented this discussion, I took a very small portion of our metamodel and exposed two opinions about that portion.  The metamodel that we use certainly extends to the same places that your model does. I'm glad to hear that you have modeled logical capabilities into logical applications.  We have done the same, but we used different words (of course).  The concepts are identical.  The fact that two people come to the same conclusion, independently, means a great deal to me. So I like your concepts.  We use different words, partly, because the word capability is used in SO many ways already.  Early on, there was a proposal to model 'application capabilities' just as we are modeling 'business capabilities' and 'technical capabilities.'  The odd thing is that the business and technical architects both wanted to use the same word.   We backed out of using the term 'application capabilities' to avoid confusion. So we model logical applications (we call them solution domains).  And those logical applications have 'features' (our word that maps to your definition).  It is not a perfect word.  There are no perfect words, but it works for us. One thing that I like to keep seperate is the notion of 'requirement' from 'feature.'  We want the business processes to dictate a desire, and from those desires come requirements.  Have you ever noticed that processes are rarely performed exactly as described?  Life is messy.  Processes are neat.  They are a mere shadow of reality.  On the other hand, they reflect a desire for orderliness, for a lack of variation, and a consistency that delivers efficiency... and those desires are the requirements that we are trying to live up to. So we don't use 'application capabilities.' Our terminology is not consistent yet, but we are getting closer.  For us, the business needs capabilities.  Processes interweave those business capabilities together.  Business systems provide features that support those business capabilities.   That much we all agree on.  The rest... well, that's what this post is for, now isn't it?

• Anonymous
  May 10, 2008
  Nick Yes I imagine Microsoft businesses would be best addressed by B. I also think B sets you up for beter flexibility and leveraging opportunities for the future, so there is another dimension; Are you trying to stabilise the business or disrupt it for innovation opportunities?

• Anonymous
  May 16, 2008
  A bit late to weigh in, but I believe BPM as a management discipline/theory is all about B, and typically poses A as the "old" stovepiped way.  In reality, most organizations getting started in BPM implementations (i.e. automated solutions) do not tackle cross-functional processes right away... too hard.  But B is the goal.

• Anonymous
  May 16, 2008
  Thanks, Bruce.  

• Anonymous
  May 19, 2008
  A few weeks ago, in a blog post , I asked about the relationship between business process modeling and

• Anonymous
  May 24, 2008
  The comment has been removed

• Anonymous
  May 24, 2008
  Hi Antony, Perhaps your situation is different than mine.  When I describe this reference architecture, some people understand it, and some do not.  The capabilities view appeals to people whose frame of reference is organizational or functional.  They sign up. But for people who need to see cross-functional processes, who want to optimize along the lines of a process, or want to examine the customer's experience across an entire process, they need a 'front door' to not only find the processes, but to MEASURE the processes.   Without a process heirarchy, there is no way to create a roll-up measurement framework that ignores the organizational boundaries and focuses on the customer experience and operational excellence. So while I agree with the idea of placing 'activity' at the center, I would find a reference model that lacked a process heirarchy insufficient.

• Anonymous
  May 24, 2008
  Nick, A very good discussion. I agree that a process view is essential as the activities have to be put into a number of named processes. By not being keen on a process hierarchy I really mean describing processes within processes within processes. In my experience this has lead to inconsistencies in representation. Activities for examples found sometimes at level 2 in other places at level 4. I've also found many different views about where a process starts and ends and this to me depends on the audience. End to end to me is made up by connecting together many smaller processes but all at the same level i.e. the level that contains activities. I read this as been consistent with option B ... " connects many ".   My front door would be a grouping of processes into a process area. This to me this is for navigation and the criteria for grouping. So in my approach I cover cross functional but have measure at various point horizontally rather than rolled up.