Business Capability Modeling

March 25th, 2009  |  Published in SOA by Ian Robinson  |  2 Comments

Some commentary from Richard Veryard on a conversation between Udi Dahan and Colin Jack over business capability modeling caught my eye yesterday. I wanted to write something in support of Richard’s comments, and at the same time illustrate a practical approach that helps “identify capabilities with … high cohesion and low coupling” and “draw a matrix of the interactions between entities and processes”.

Over the course of a piece of analysis some things, some entities, will emerge as being of particular significance to the business. Customer and order, for example. Don’t refuse to acknowledge or model these things, but don’t get hung up on them either: they’re just a part of a whole that includes not only concept models, but lifecycle models and capability maps.

Take customer for example. We can, very quickly, create a high-level picture of what a customer might look like – an overarching, company-wide view of all the parts of a customer that are of interest to the business, or the several parts of the business. But this isn’t the domain model: rather it’s an approximation, a temporary stabilizing of multiple shifting perspectives, a flawed starting point – just good enough – for further investigation.

Side-by-side with this high-level conceptual view of a customer, we can also model the customer lifecycle; that is, the story of a customer’s relationship with our company. I’ll often model this in the form of a state machine. We then see that our interest in a customer can be expressed in terms of our transitioning the customer through several different states.

For each transition in this state machine, we can now ask: what business capabilities do we need in order to transition the customer from, eg. lead to applicant? How well do we implement these capabilities today? And so on.

Capabilities operate on the customer in order to transition it through different states, in so doing releasing value both to the customer and the business.

What likely starts to emerge are business-meaningful bounded contexts, each context encapsulating part of the high-level picture, plus one or more state transitions, plus the capabilities necessary to effect those transitions. Each bounded context projects a different view of the customer onto the business landscape – suggesting there’s not necessarily an organization-wide canonical model of a customer, just many “interested” views. That’s why I say our original high-level picture isn’t the domain model: it’s simply a starting point for identifying the bounded contexts – and the processes – that transition the overarching concept “customer” through states in the customer lifecycle.

What we end up with is a high-level model/picture divided by bounded contexts, a customer lifecycle model, and a capability map. Together these comprise part of an operating model – a useful representation of the organization that we can use to identify desirable business outcomes and guide the identification, planning and prioritization of projects.

2 Comments  |  Atom   RSS 2.0   Email

Responses

  1. Colin Jack says:

    March 25th, 2009 at 4:20 pm (#)

    Agree with you/Richard/Udi, just on the discussion though I think it was also informed by my comments on DDD forum about bounded contexts.

    My company didn’t really take advantage of capability modelling, we tried to use Steve Jones’ approach but didn’t really take any of the advice he gave and it hasn’t really worked (surprise surprise). Bit of a disaster really, and a disaster we should have avoided, but I definitely love the idea.

    I totally saw it fitting in with the bounded context approach, I see Evans was talking about the link between SOA/DDD at QCon (along with your talk the main reasons I regret missing QCon) and context maps seem very valuable in this context (titter).

    I’m very interested in reading more about your approach, one thing that worries me with it is if you start with the entities are you ever at risk of getting into granular capabilities too soon? Also how do you avoid entity-think, because your bounded contexts (and capabilities) will be very much cross-entity? I think you’ve pretty much answered my questions here but I’d be interested in reading more anyway.

    I also got some great feedback from Steve Jones when I described the problems we were having over e-mail and he gave me some great advice including asking the Prince Charles question of entity-oriented capabilities, “and what do you do?”. The royal family having a use, who would have thought.

    You probably already know of him but Bill Poole (http://bill-poole.blogspot.com/) has also blogged about this a lot, and explained it beautifully.

    Oh and our head of development actually saw your talk and said it was great, looking forward to it appearing on InfoQ in 2012…patience is a virtue.

  2. iansrobinson says:

    March 26th, 2009 at 9:42 am (#)

    Hi Colin

    Thank you very much for your comments. I’ll try and pick up on a few of your points.

    I wouldn’t say I “start” with entities. In the initial stages of an engagement, when we’re seeking to clarify objectives, scope and the business case for proceeding, I’ll try and frame the discussion around high-level capabilities. But entities, or coarse-grained business concepts, such as customer, will inevitably emerge, and I’ll note and develop these, and their lifecycle models as appropriate. Analysis then proceeds by “keeping the plates spinning”, touching on capabilities, entities and entity lifecycles. But I’ll usually try and subordinate entity and lifecycle modeling to capability modeling, at least initially.

    It’s difficult to escape the entity trap and focus instead on high-level capabilities. It’s partly about getting the right people around at the right time. I prefer to target some initial analysis activities at strategic decision makers, at the people who set big goals and targets, but who don’t involve themselves with the day-to-day how of execution. Follow-up sessions can then better frame the conversation for those responsible for execution – you’re already furnished with descriptions of some significant goals and outcomes, and you can use these to test and challenge the results of the ongoing analysis.

    More often than not, however, we do end up in the weeds, focussed on low-level, contingent capabilities – process atoms. As a facilitator or guide, I’ll try then to look up and out to the high-level capabilities. Keep asking Steve’s question, “And what do you do?” (“And why?”), until you feel you’re getting the “big” answer.

    And of course, it’s not always possible to start in the ideal position of engaging with strategic business stakeholders. How many times have I been engaged by an IT function that wants to “get its ducks in a row” before speaking to the business? In the QCon presentation I discuss briefly how you can still get started even in such non-ideal situations. This sometimes requires you to rehearse “one more time” the Folk IT and business process disorder representations of the problems at hand until, exasperated, someone cries: “Surely it’s simpler than this? There must be a better way!” More to write about there sometime.

    Bill Poole, I agree, is terrific. I’d recommend his and Udi’s – and for the broad-minded, Jim’s – writings any day to someone wanting to orient themselves in a world of hyperbole. I’d also recommend Jack Calhoun’s talk The Progress you Make Depends on Where you Start, from the Microsoft SOA and BP Conference in January. I saw Jack speak there when I was giving the first version of Steering the Northwest Passage, and it was worth the trip over the Atlantic. Jack contributed to Microsoft’s Microsoft Business Architecture (MSBA) efforts, where a lot of the capability modeling approach was developed, and co-authored the Harvard Business Review article, the Next Revolution in Productivity.

    A last note:

    High-level capabilities; process-centric services: there’s obviously a great deal of overlap here. On my understanding, this specific use of the term “capability” grew out of business process reengineering, insofar as it was an absent concept, but everywhere implied. The business process reengineering literature gives us plenty of examples of how people (organizational structure), process and technology can all – individually and together – change completely, and yet something, some stable thing, continues to happen. Capability is the name we now attach to that stable element in the operating model. But the high-level capabilities we favour today are still, to my mind, process-centric, where process refers to some highly cohesive (logical) composite of people, specific this-then-that processes and technology. What business process reengineering discovered was that these logical composites were in fact split into functional silos, with terribly inefficient handoffs between them, lots of reconciliation, and no explicit coordination and monitoring of the whole from end to end.

    The “process” in business process reengineering is a somewhat overloaded term. It refers both to the big, abstract process – what today we call capability – and the this-then-that particular implementation of a capability. I’m actually quite down on the term “business process” when it’s used in a this-then-that sort of way: when we use it to describe nothing more than the particular, contingent sequence of steps that we execute today in order to achieve (or defer achieving…) some goal. But process as an abstracted encapsulation of an outcome and the things need to deliver that outcome fits nicely with our articulating a useful representation of an organisation’s operating model.

    Best wishes

    ian