Which comes first: process or service? Part 1
Over the years I've been helping to run MWD I've been to quite a few events, talked to many enterprise IT folks and talked to many tech vendors, too - and one of the topics that comes up most often is the relationship between BPM and SOA. There's been a bit of a run on the topic in the blogosphere lately. First, I was alerted to
this post on CIO.com via the EDS fellows' blog in a post called
SOA is a Business Process Architecture. At around the same time, I read
The Problem with Process by Nick Malik (always good to read).
Too often, in presentations and papers, I see diagrams that replicate the old three-tier architecture of the '90s, but with a twist: instead of user interface, business logic and data access layers, now I keep seeing portal, BPM and SOA layers. Portals provide user interaction, and invoke processes; processes invoke services. Job done.
Looking at BPM and SOA purely in this way is short-sighted, disingenuous and dangerous. It looks at both initiatives through a very focused lens, and essentially says "BPM and SOA are about building and integrating applications". Not your father's applications I'll grant, but applications nonetheless - things with hard boundaries that have little awareness of other systems or resources that might exist, and little conceptual relationship to broader architectural or business considerations.
The first, and most obvious, point to make that blows this kind of picture apart is that it's mind-numbingly straightforward to wrap a process (or at least the initial invocation of a process) as a service. So *now* what's "on top" - process or service? This realisation has led to more enlightened commentators advocating that organisations consider processes and services more like a lasagne, with alternating layers of the two concepts. Services expose processes, processes call services, etc etc ad infinitum.
However even here we're only part way to the real answer, because this view also stems from seeing both BPM and SOA primarily from a "bottom up", software development- and integration-centric perspective. Of course, many people refute a view like this, and point out that "BPM is a business management approach, and SOA is a technology architecture approach - you can't lump them together so easily". In other (very simplistic) words BPM is a top-down, business-driven initiative, whereas SOA is a bottom-up, technology-driven initiative.
The two articles I've linked to above are great because they start to take a deeper look at the architectural and conceptual relationship between service and process. Both EDS Fellow Fred Cummins and Nick Malik start to pick away at the simplistic views that seem to hold sway in the minds of many at the moment.
Neither quite take the argument as far as they might, though. Through our industry research (for
our book as well as our various
free reports and consulting gigs), we've come to see that the value of both BPM and SOA comes from considering them neither purely as bottom-up initiatives focused on improving the development / integration of applications and resources, nor as top-down initiatives focused on exploring and elaborating business architecture. We already have a champion in the case of "top-down SOA" - the
OASIS SOA Adoption Blueprints team. The real insights come, I think, when you see how top-down *and* bottom-up perspectives of service-orientation *and* process-orientation can all come together in a more holistic view of business and technology architecture.
I'll expand on what such a view entails in a Part 2 of this post, in the next few days.
Labels: BPM, EA, SOA
