Services, meet process

The current focus of most SOA development is the creation of more flexible systems. That's a fine objective, but it's only a staging post. It falls short because at heart it still regards a system as an inherently fixed structure, with some flexibility built in (or, in some even more unfortunate examples, merely bolted on). The problem with this approach is that it regards flexibility as the addition of a finite set of options, whereas the ultimate objective has to be a continuously flexible set of system resources that remains free to adapt and evolve within an ever-changing environment.

Without this ultimate objective in mind, any services architecture is bound to disappoint, as Howard Smith and Peter Fingar point out in a new ebizQ article, Love Affair With Web Services Waning? (requires free registration to view). They point out that there's an often-overlooked difference between services and process, and cite Services Blueprint: Roadmap for Execution, a book by Dr Ravi Kalakota and Marcia Robinson, to illustrate their point:

"But perhaps the most obvious element missing in Kalakota and Robinson’s otherwise excellent book is the process lifecycle itself. For while attributing to services (and service thinking) many wonderful attributes, the book omits to say how services, or for that matter processes, are actually improved in line with business objectives ... [H]ow are they taken through the lifecycle of process improvement, from discovery, to design, to deployment, to execution, to operations, to analysis and optimization? In short, where is business process improvement in Kalakota and Robinson’s service model?"

Unfortunately, Smith and Fingar then go on to overstate their case, arguing that instead of calling everything a 'service', the word should be expurgated and everything should be called a 'process'.

I would argue that the important thing is to put both these concepts in their proper place. We should be celebrating services as a potent reconfiguration of today's inflexible business automation systems, exposing those systems' resources as reusable services. And having done so, the next step is to assemble those services to automate processes within the organization. The distinction is clear: services are the capabilities delivered by the technology infrastructure, and processes are what happens in the business infrastructure.

But I do sympathize with Howard Smith and his co-author. Howard and I first started following each others' work five years ago, when I set up ASPnews.com, a website covering the then emerging phenomenon of application service provision. Although I didn't realize it at the time, my perception of ASPs was not the same as the mainstream view. I saw ASPs as delivering something a lot more akin to web services rather than traditional applications, whereas the rest of the world saw them as online application outsourcers. It took me several years to accept that my interpretation of the ASP concept hadn't prevailed, and that the mainstream definition was the one everyone had in mind when talking and reading about ASPs. Nowadays, of course, the likes of salesforce.com and Amazon and Google are belatedly bringing the concept back round to my original idea, but too late to correct all those earlier misunderstandings.

I mention this history because I suspect that Howard's definition of business process management (BPM) is in a similar limbo. He knows what he means by it — and he'll probably be proved right in the long term. But right now, the mainstream perception of BPM is very different, one that's little more than a sad parody of Howard's vision, perceiving BPM as a slightly more business-aware version of EAI, and just as beholden to static process models as today's inflexible enterprise business systems. That's not at all what Howard has in mind when he says that we should think in terms of BPM rather than SOA. But unfortunately his readers understand a different interpretation.

The simple moral of this story is to always beware of popular expressions and acronyms when talking about emerging technologies, because people may be using them with meanings you're not aware of. Consider where they're coming from before you evaluate what they're saying. The culture gap is particularly wide between systems people and business people. Here are some simple rules of thumb to be going along with:

• Automation is what technology does. Technology operates to precise metrics.
• Process is what people do. People operate in an uncertain world.
• Services are a bridge between people and technology. They make automation available within processes.

When the sort of people who work with technology talk about services, they have a different concept in mind than the sort of people who direct and maintain processes. When these two sorts of people get together, they can have entire conversations with each other and take away completely different understandings of what they just agreed.

posted by Phil Wainewright 3:45 PM (GMT) | comments | link