iansrobinson.com

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.

I’ve had a few mails over the last few days pointing out that the PDF copy of my QCon presentation was crashing their PDF reader. Oops. I’ve regenerated the PDF and the new version of Steering the Northwest Passage: Beginning an SOA Initiative is now available at the QCon site. Let me know if you’re still having problems.

I also had a couple of requests to make my hand-drawn UML stencil for OmniGraffle available. And so, for your delight: Napkin UML. Be warned: it’s very rough and ready. The font I used in my presentation was FG Jayne Print.

Whilst preparing slides for next week’s QCon London, I remembered that a short article of mine, Representing the Enterprise, had been published sometime last year by Conspectus. I’ve always been sensitive to modes of representation, so I was somewhat disappointed to see that the online version of the article had not only been renamed (to “Do you speak geek?”), but that it had been edited by someone for whom a sentence and a paragraph is one discourse unit too many. Given that the article fills out one of my slides, “Barriers to Communication,” I thought I’d dust it off and put a revised version on this blog for you to read.

I’ll be at QCon London next week - speaking but also attending many of the excellent sessions on offer. On Wednesday I’m presenting Steering the Northwest Passage: Beginning a SOA Initiative as part of Stefan Tilkov’s SOA in the Real World track.

On Friday, I’ll be catching up with Stefan again when he interviews Jim Webber and me on REST for SOA: Using the Web for Integration. I’m currently going through some back issue of Viz so that I can keep up with Jim’s “pattern language.”

At the end of the afternoon I’ll be joining the panel - Martin Fowler, Michael T. Nygard and Steve Vinoski - for Game show: It’s a Bullseye! with Jim Webber. After all, every quiz show needs one fake.

Speaking of all things QCon-wise, InfoQ have recently published Ryan Slobojan’s interview with me from QCon San Francisco last year. I’m surprised that there was so much to show from this. Ryan asked some great questions around REST, WS-* and SOA, but jet-lag had the better of me: thankfully, InfoQ have edited out the parts where I give up on putting one word in front of another.