iansrobinson.com

I’d long been interested in capability mapping, but was always looking for an in, a way of communicating the purpose of the exercise and eliciting useful descriptions from participants. Goals and capabilities seemed an easy pairing, but in practice it proved a little too formal. I needed something more expansive, something loose and conversational that would nonetheless help stakeholders frame concise descriptions of the capabilities that were important to them.

The answer was close to hand: user stories. The added depth that the story format brought to the table really invigorated the capability mapping process – not only does a story describe a goal, it also describes a user (or organisational) role and the value attached to realising a goal. Used judiciously – after all, it’s not always wise to insist that every utterance use the story format – story writing can greatly help in discovering and mapping capabilities.

And in pairing user stories and capabilities, I learnt something interesting about stories.

Goals or Features?

I’ve written briefly in the past about using stories and capabilities to create a business-meaningful model of an organisation. When I pair stories and capabilities, I say that stories describe strategic organisational goals; capabilities describe what an organisation must provide to satisfy those goals. How an organisation meets its strategic goals is another matter: capabilities can be implemented in many different ways, and the how varies over time. The capability to source replacement parts for used cars, for example, might today be implemented by harried customer service staff leafing through papers in a filing cabinet; tomorrow it might be implemented using an online application backed by a relational database.

If you’re familiar with any kind of agile requirements analysis process, whether based on Mike Cohn’s “user stories”, or Behaviour-Driven Development’s example-based specifications, you might think it a little odd when I say that stories describe goals. User stories and BDD exemplars typically describe features. Moreover, they do so in way that is estimable and testable. The purpose of stories is to guide software development in a way that is meaningful to end-users and stakeholders. In the course of describing features they might allude to or otherwise encode user goals, but the goals would not appear to be ends in themselves: they simply motivate the features that drive specific instances of software development.

So in saying that stories describe goals we appear to have reduced the usefulness of the story format. Without features, user stories feel a little too sparse, and of insufficient value to feature-focussed software development.

Nonetheless, when I use stories to drive out capabilities, I use a weak form of the story format – one that aims at describing only goals not features. In effect, I unpack a feature into its constituent parts: on the one hand a goal (or need), on the other, a capability.

Why would I do that? Because goals can be satisfied in many different ways. Just as capabilities are amenable to multiple implementations, so high-level goals can be satisfied through a range of possible capabilities.

This isn’t really news to the agile community, of course. Both Dan North and Martin Fowler have discussed the double-edged power of the user story, the benefits and dangers that come from baking features into user stories. The only novelty here concerns the degree to which I make explicit and control the split between goals and capabilities. By distinguishing between the two, I can “slow down” the analysis process and tease goals from capabilities so as to focus on the capabilities, or I can speed things up and get at the features.

When the purpose of the exercise is to identify and map capabilities, I enforce this split quite rigorously. The fine-grained control over the analysis process this gives me helps emphasize the distinctive nature of the capability concept, differentiating it from goals on the one hand, processes on the other. The power of variability comes into play here, helping us progress the conversation and get value from the workshop. In practical terms, this means we can anchor a goal and then iterate capabilities until we’re happy we’ve found the right set of capabilities and an appropriate language to describe them.

When gunning for development, however, I’m often quite happy to roll goals and capabilities back up into features, though always with the acknowledgement that I’m assuming a more one-to-one relationship between a goal and a capability.

In both situations, I’ll stress the need to specify a meaningful value for the story. I’ll also be on the lookout for inadvertent lapses into specifying solutions rather than goals, and I’ll quite happily employ the shift left approach to highlight poorly constructed stories.

From Operating Model to Business Architecture

A little more context may be useful here. I use the story and capability pairing when running high-level capability discovery workshops with business unit heads or their delegates, heads of the lines of business, strategy makers, etc. These people are typically responsible for specifying what their part of the organisation must achieve, what capabilities it must possess; they have little direct responsibility for determining how those capabilities are implemented on a day-by-day basis. (For insight into the lower-level capabilities and the how of execution, I speak to operational staff.)

Used in this way, the stories are not necessarily estimable or testable. But because they’re not being used to guide software development, that’s not an issue. The stories are vehicles to get to capabilities.

The purpose of these capability discovery workshops is to create a network map of an organisation’s high-level capabilities. These maps link an organisation’s operating model to its business architecture. Subsequent iterations of the capability map lay the groundwork for service discovery. The workshops themselves help establish context and create consensus amongst stakeholders; at the same time, they serve as a platform for interrogating and challenging an organisation’s goals and benefits. In this way they provide for early course corrections towards the beginning of an IT or business initiative.

JAOO Aarhus 2008

I’ve just come back from JAOO Aarhus 2008, where I was presenting on “RESTful Enterprise Development” in Stefan Tilkov’s REST track. An anodyne title, I know, but in reality a straightforward case study illustrating how Atom and AtomPub are being used to implement an event-driven, business-service-oriented solution for a large entertainment and communications company. You can catch the talk again at the London Enterprise Web Conference in October and at QCon in San Francisco in November.

The other two speakers in the track, Stefan Tilkov and Arjen Poutsma, nicely advanced the conversation beyond the usual REST 101: Stefan with a concise, highly illustrative set of REST patterns and anti-patterns; Arjen with a preview of the forthcoming REST features in Spring 3.0, including first-class support for ETag filters and an API for the much-neglected REST client. Elsewhere the conversation touched on using the links embedded in representations to advance an application protocol: again, a welcome step forward from the naive misrepresentation of REST as a chatty, CRUDish interface on top of a data store.

That said, I don’t think any of us really nailed the “hypermedia and application state” subject; which is a shame, given that the day before, Gregor Hohpe had reintroduced his “Your Coffee Shop Doesn’t Use Two-Phase Commit” article to illustrate how simple business protocols – retry, compensate, throw away – are used in real-world business activities to advance the participants towards a successful outcome. A nicely self-contained, quirky example of application state: ripe, you might think, for casting in a RESTful light.

Which is exactly what Jim Webber, Savas Parastatidis and I have done…

How to GET a Cup of Coffee

Available now on InfoQ, “How to GET a Cup of Coffee” takes Gregor’s Starbucks example and runs it through a Web-friendly (that is, RESTish) state machine. Along the way, we take a potted look at using response codes for coordination, ETags for consistency, and caching for scalability and resiliency.

I’m really proud of the article: I don’t think there’s anything else out there that really deals with the topic in this way. Take a look and let us know what you think.

The RESTful/AtomPub talks are advertised as covering “Atom, AtomPub, caching, URI templates and microformats.” Well, either I’ll have to talk very fast or skip lots of detail to get through such a range of topics: more likely, I’ll be covering off just Atom and AtomPub. “Testable Foundations for Service-Oriented Development” takes as its starting point some of the material I’ve covered in a recent InfoQ article, and goes from there.

I’d also been hoping to speak on SOA and testing at Øredev, but a number of factors have worked against this and taken me across the pond. Happily, my friend Ian Cartwright is taking over speaking duties. Ian is one of the most successful and experienced delivery practitioners at ThoughtWorks, and I’m confident he’ll have a lot of great stuff of his own to say on SOA and testing.

Add to your calendar

A few months ago Stefan Tilkov very kindly offered me the opportunity to write about consumer-driven contracts for InfoQ. The resulting article, “Service-Oriented Development with Consumer-Driven Contracts” is now available online.

Special thanks to Stefan for thoroughly reviewing a draft of the article, Dan North for helping shape an even earlier version, and Jim Webber and Ian Cartwright for lots of conversation and encouragement.

I’ve still not written much on how to implement consumer-driven contracts, but I’ve something special cooking (slowly) in that area: expect some illustrative material to emerge over the next few months.

Jay Fields has written a nice post about “The Simplest Thing That Could Possibly Work.”

I worked very briefly with Ward Cunningham a few years ago. After hearing Ward use a curiously inflected version of this phrase, I asked him about it. We discussed “the simplest thing that could possible work,” what it meant to us, and how we might use it to guide our day-to-day development activities:

“The simplest thing that could possibly work”

This is the prescriptive approach. It passes an almost aesthetic judgment on the desired “final” state of an application: whatever will, in retrospect, prove to have been the simplest way of solving the problem at hand - do that now!

There’s something overly thrifty about this use of the phrase. It ignores the fact that noise, waste and redundancy form an ineluctable condition of possibility for producing something meaningful and useful – no matter how much we might want to trim all excess from what we do. Too often, it’s an appeal to no authority whatsoever; an attempt to bring an abrupt end to the conversation; the agilista’s last resort.

“The simplest thing that could possibly work”

This says more about the process than the final result. It’s an investigative tactic, an exploratory strategy, a way to get you somewhere:

“We don’t know enough about this yet to propose a great solution, so what’s the very next little thing, the simplest thing, that we could do that might just move us forward, or might just give us enough information to work out how to move forward again. Let’s do it. If it doesn’t give us any more information, or leads us down a blind alley - well, what have we lost? Not much, an hour at most.”

Said against a background of asserted behaviour, a safety net of unit tests and continuous integration, this is the pragmatist’s “just enough” (but the politician’s death knell; U-turn as a failure of leadership).

A Duty of Care

The conscientious developer is always working out what’s important today, what to do now, next. But it’s not all for the now; there’s a counter-force, another imperative, which we must reconcile with the demand for “the simplest thing.” We might call this force our duty of care to the overall lifetime of a system.

“The simplest thing that could possible work” has nothing useful to say about our duty of care to the overall lifetime of system. The “simplest” variant is too simplistic, too absolute: it determines our duty purely in terms of a rigid adherence to the simplest thing we might do now. The “possibly” variant has no pretensions to determining our duty: it’s a key to the immediate future only.

Martin Fowler’s “Who Needs an Architect?” does have something to say about our duty of care, however. Casting that article in the terms I’ve established here, I’d say that “architecture” is the term we might apply to those collaborative activities that seek to balance our desire to do “the simplest thing that could possibly work” with our duty of care to the overall lifetime of a system. We do architecture when take up the challenge of mediating these two forces.

My duty of care has been pricked recently by such things as auto generated proxies, naive point-to-point connections, implementations that allow schemas and technology choices to bleed across the application landscape, dogmatic adherence to architectural purity, insufficient separation of message representations from internal domain representations – the list goes on. These things aren’t wrong in and of themselves, but set in a particular context, evaluated against possible lifetime of a particular system, they beg to be interrogated. I suspect the signatories to the “ADO .NET Entity Framework Vote of No Confidence” have been similarly provoked by their duty of care.

Jay’s anecdote quite nicely stages the tensions between our need to do the next important thing now and our duty of care to the overall lifetime of a system. Both the full-blown pattern implementation of the feature being discussed and the more minimal solution Jay’s team have currently settled on exhibit a desire to do “just enough” for the now - but in a way that doesn’t foreclose the future. Resolution here was achieved not by pre-emptively invoking the prescriptive “simplest,” but by collaboration, pairing, discussion; by attending to the process, exercising group judgement, working up insight and feedback; by trusting in a cautious thread of discovery. Architecture, as Martin says, as social construct.