Merging Capability Modeling with Process Modeling

Nick Malik asks about the relationship between capability model and process modelling. "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?"

Nick suggests two answers. In this post I want to offer a third answer. But first we have to understand the purpose of each type of modelling.

Nick mentions two purposes for capability modelling - project planning and service design.

• Project Portfolio Alignment - "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."

• Service Design - "The activities are where you actually perform automation. You connect services to these activities. This is where work is done."

Nick's first answer is that a capability is a top-level chunk of business, while processes are at a lower level. In a later post, Nick says this is how FEA handles capability and process modelling. As Nick acknowledges, FEA actually calls them business areas (or Lines of Business) rather than capabilities. In my 2001 book on the Component-Based Business, I called these things Business Components, and this terminology is still used by IBM in its Component Business Model. I think this is a useful construct, but that's not exactly what I call capability.

Nick's second answer is that a capability corresponds to the objectives of a specific organizational unit. Capabilities are not directly linked to processes; both capabilities and processes use and share atomic-level activities. This is better, but I am uncomfortable with the organizational tie-up.

Meanwhile, the latest version of MODAF does explicitly include "capability" as a first class construct. MODAF includes a hierarchical decomposition of capabilities, and a many-to-many mapping between capabilities and processes (which it calls "operational activities"). This is a lot closer to my notion of capability.

Another way of getting to my notion of capability is to take Nick's second answer and remove all mention of organization units. While the organization structure may give us some important clues about what an organization does and how it does it, I am careful to avoid hard-coding the organization structure into my business models.

So what is the point of modelling capabilities as well as processes? To justify capability modelling, I want to articulate two additional purposes.

• Management of Variation - Capabilities can often be decomposed into highly generic elements and asset-specific elements. (See my example of Green Coffee Beans.) Decoupling these capabilities helps to drive higher levels of cross-process and cross-organizational sharing.

• Viable System Design - A complete system needs to include management capabilities such as planning and coordination as well as operational capabilities. With a capability model, I find it much easier to check for completeness than with a process model.

So I end up with a notion of business capability which maps easily onto business services, supported by information capabilities which may be implemented as software services. This notion allows for a much finer level of granularity than Nick's first answer, but I think it is much more flexible and powerful than Nick's second answer.

The capability defines WHAT the business does; the process defines HOW the business does it (and the organization structure defines WHERE the business does it). So we expect the capability to be more stable than the process; many capabilities should be shareable not only between different processes within a single enterprise, but between multiple enterprises.

This then raises the question of capability modelling techniques - how do we analyse capabilities? We certainly need to map capabilities onto outcomes (as in Nick's second answer) , but we also need to analyse commonalities and variations within and between capabilities, as well as other dependencies between capabilities. In fact the diagram I find most useful, both for planning and for service design, is the capability dependency diagram. MODAF V 1.1 includes a suggested notation for capability dependency diagrams, but I use a slightly different notation.

Sources

• MODAF Version 1.1 (April 2007)
• L. Cherbakov et al, Impact of service orientation at the business level (IBM Systems Journal, 44/4, 2005)
• M. Dodani, The Architecture of Business (JOT 17/4, 2008)
• R. Veryard, Component-Based Business: Plug and Play (Springer, 2001)
• R. Veryard, Capability Dependency (CBDI Journal, May 2007)