SOA

QCon Presentation and UML Stencil

March 18th, 2009  |  Published in Events, SOA by Ian Robinson

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.

Atom   RSS 2.0   Email

Representing the Enterprise

March 3rd, 2009  |  Published in SOA by Ian Robinson

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.

Atom   RSS 2.0   Email

QCon London

March 3rd, 2009  |  Published in Events, REST, SOA by Ian Robinson

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.

Atom   RSS 2.0   Email

Stories and Capabilities

October 28th, 2008  |  Published in Agile, Behaviour-Driven Development, SOA by Ian Robinson

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.

Atom   RSS 2.0   Email

Stories, Capabilities, Services and Contracts

June 25th, 2008  |  Published in Agile, Behaviour-Driven Development, Consumer-Driven Contracts, SOA by Ian Robinson

Today I want to introduce a bare-bones model to help guide the creation of business, architectural and technology artefacts in an agile and iterative manner over the course of an SOA initiative:

  • Stories – in the form of Behaviour-Driven Development exemplars – describe goals and desired outcomes;
  • Capabilities encapsulate the resources and abilities an organisation needs to satisfy those goals;
  • Services host capabilities;
  • Contracts – particularly consumer-driven contracts – assert the interactions between services.

We iterate over this model many times in the course of an engagement, emphasising different parts as we go. We concentrate on organisation-level stories and capabilities when establishing an organisation-wide context, then project-level stories, capabilities and services whilst planning projects and delivery streams, and then release- and iteration-level artefacts during specific instances of delivery.

Such an approach represents a “thin-slice” way to:

  • establish context, business goals and consensus amongst stakeholders;
  • create a long-term vision that joins up the business, architectural and technology views of an SOA initiative;
  • describe and challenge an organisation’s goals and the benefits attached to those goals;
  • describe the capabilities needed to meet those goals;
  • identify the quality-of-service expectations the business has of those capabilities;
  • identify services and assign capabilities to services;
  • describe and test the externally visible interactions between services;
  • identify, plan and develop slices of service functionality that deliver business benefits early and often.

Atom   RSS 2.0   Email