Service models: Building services that add value, not follies

Blogger: Richard Watson

Should I use WS-* or REST? Should a service provide access over HTTP, MOM, or XMPP? These are the wrong questions for architects to ask when first conceiving a service. By concentrating on how to build, we lose focus on what to build.

Debates about whether to use REST or WS-* interface styles are seductive. But, these are the wrong questions to ask first. Interface style and middleware decisions should be based on consumer requirements. The primary service design principle emphasized in a service model is maintaining a clean separation of capability ('what') from interface concerns ('how'). If we are arguing at all we should be arguing about what services to build, and why.

What is a service? This question cannot be answered in the abstract. Service modeling is an entirely contextual activity. 

Despite their rich history, service design practices remain nascent. The identification and definition of sharable and reusable services is still more art than science. In this paper (Burton Group subscribers only) published today, I examine the neglected art of service modeling. When people hear "model" they immediately think of formalism, notation, and tools. My definition of service modeling is not a formal model or modeling notation. It's thinking about the answers to these questions in a repeatable way.

Can you answer these questions? Do you have places in your service development process where these questions are answered in a consistent way? Service modeling is a set of software architecture practices for providing us with a way to get at answers to these questions and document them in a way that's valuable for everyone who has a stake.

Near where I live, in Dublin, is an extensive park called St. Anne's Park. It's part of what was the Guinness estate (yes, that Guinness!). This is a Greek Temple, built in the park as tea house by the Guinness family. It’s has very ornate mosaics on the floor, and is almost perfect classical design.

But, it's a Folly. Follies are buildings, or parts of buildings that have no purpose other than as an ornament; they are purpose-built as ornaments; they are often eccentric in design or construction; there is often an element of fakery in their construction.

The Guinness family built this because they were wealthy, just because they could. We can't afford to do that in our organizations any more. What we build must be relevant, driven by the right business context, and play its part in a portfolio. As you can see from its state of repair, there's no great motivation to maintain the tea house. It’s not valuable any more, if it ever was...

Put simply, if you create services without a service model, then you are creating bespoke application integration interfaces and not doing service oriented architecture. If context is not driving you to create the right services, then they are most likely not adding value to your applications architecture, they are making it worse.

Let me know what service modeling means to you. If you’re going to the Burton Group Catalyst conference next week in San Diego, I'll be giving a session on service modeling on Wednesday afternoon in the "Whither SOA: What’s next?" topic.

Comments

[Richard]

Well written and thought out paper. Liked the short and long term service model roadmap as well as the service identification and classification advice.

FYI, a couple headings in the article get cut off after the word "the" (e.g. "Forces Dragging the Organization Back to the").

Thanks for contributing this valuable paper.