Friday, May 03, 2013

Not your grandpa's functional decomposition

Is there a difference between function and capability? You can find endless debate about this on the Internet (yawn). One of the reasons business architects often prefer the word capability is that the word function can become extremely overloaded - sometimes equivalent to organizational unit, sometimes equivalent to long-running process, sometimes equivalent to purpose. Whereas the word capability seems to focus our attention more clearly on the WHAT rather than the HOW or WHO or WHEN or WHERE or WHY.

But even when people insist that a capability is not the same as a function, they still seem to use the same approach for identifying and modelling capabilities as was once popular for functions. So they draw capability models as simple hierarchies, either as trees or as boxes within boxes. There are many valid uses for these models, including heat-mapping.

One such approach to capability modelling was popularized by Ric Merrifield and others at Microsoft in the mid 2000s. The methodology was originally called Motion, then Motion Lite, and is now known as Microsoft Services Business Architecture. It includes a Business Dependency Network diagram, but this is used to show the dependencies between the business architecture and IT, rather than the dependencies within the business. In fact, it looks remarkably similar to IBM's Business Component Model.

Despite the limitations of a hierarchical methodology, there are some useful guidelines on separating WHAT from HOW, and on the segue from capability to service, as well as a wealth of examples.

In the early 2000s, I started working on an alternative approach to capability modelling in collaboration with the CBDi Forum. This approach, which is loosely aligned with Stafford Beer's Viable Systems Model, concentrates on understanding the dependencies between core capabilities, and the role of key management capabilities such as coordination and intelligence. One of the key drivers for this work was the belief that a network view of capabilities provided a good starting point for developing a shared service architecture (both business and IT). This topic has gone off the radar lately, but I think it remains important. 

Denise Cook, Business-Capability Mapping: Staying Ahead of the Joneses (MSDN March 2007)

Ulrich Homann, Jon Tobey, From Capabilities to Services: Moving from a Business Architecture to an IT Implementation (MSDN April 2006)

Ric Merrifield, Rethink (FT Prentice Hall 2009) (pdf intro)

Ric Merrifield and Jon Tobey, Motion Lite: A Rapid Application of the Business Architecture Techniques Used by Microsoft Motion (MSDN May 2006)

Ric Merrifield, Jack Calhoun and Dennis Stevens, The Next Revolution in Productivity (Harvard Business Review, June 2008) (pdf)

Martin Sykes and Brad Clayton, Surviving Turbulent Times: Prioritizing IT Initiatives Using Business Architecture (Microsoft Architecture Journal, June 2009)

Richard Veryard, Six Viewpoints of Business Architecture (LeanPub 2012)

Updated 31 July 2014


Ivo said...

The good thing about function is that it's both a noun and a verb. When a clock is broken it doesn't function but it still has the capability to show the time with a certain level of useful precision. When the clock is fixed this capability becomes actuality.

(BTW, I'm not sure if the idea of "business capability" appeared first in referred Microsoft works or in DoDAF but that doesn't really matter)

Richard Veryard said...

Thanks Ivo.

There are lots of words that can be used as both noun and verb (architect, book, clock, control, fix, level, matter, object, process, show, use) but I don't know if this is always a good thing. Time flies like an arrow. Fruit flies like a banana.

I don't know who originated the concept of "business capability". I was writing articles for the CBDI Journal about capability before I saw the Microsoft material, but I can't remember where I saw it first. The MODAF/DoDAF approach to capability is significantly different from the Microsoft approach, and does include a capability dependency diagram.