Which comes first: process or service? Part 2
The question of how to combine BPM and SOA came up a lot here at TIBCO's TUCON user event - and, a little disappointingly, the standard response seems to typically revolve around reinventing the three-tier architecture of the 1990s, just with more scope and scale.
I pointed out in
the previous part of this post a few ways in which that perspective is too short-sighted. It's OK to view BPM and SOA as both essentially technology approaches to building and integrating applications, but this is a perspective that misses a big part of the potential business value of the combination.
What we're starting to see, though, in a few advanced organisations, is how top-down, business-driven approaches to service orientation and business process thinking can combine with bottom-up, technology-driven approaches. The model that we see links an approach to business architecture that leans on the concepts of process and service to describe business fundamentals, with an approach to technology architecture that uses the same concept to describe the operation of automated systems. The same concepts are used at multiple levels of abstraction and composition/decomposition, so the link is seamless.
To make this link, the concepts of process and service are united through a third concept: outcome. The middle section of the diagram below, which outlines a process- and service-oriented view of business architecture, calls this out.
This is how it lays out:
- Outcomes are desired results. An outcome at the highest level is likely to be something concerned with the core value of the organisation, financial performance, etc. At this level, outcomes might link very straightforwardly to mission statements. At lower levels outcomes are going to be concerned with operational results - for example "product is delivered".
- Services are commitments to achieve outcomes.
- Processes are the methods through which outcomes are achieved.
One of the realisations that should come when you think about this approach is that service-oriented thinking can "drive" process thinking - but not only because technical process implementations can be wrapped with technical service interfaces, as I mentioned in the last post. More importantly, service-oriented thinking should drive process work because when you define business services (commitments to achieve outcomes) you're actually providing business context that shapes the KPIs and goals that you need to set for processes in BPM initiatives.
Another way to explain this aspect of service orientation is like this: when you model a process, and define a KPI and a target for that KPI, you're actually modelling aspects of a service "wrapper" for the process, as well as the process. You're defining what the commitment to achieve the outcome looks like, as well as the method you'll use to achieve the outcome. It's only when you start to think in terms of outcomes (and then services and processes) that this becomes clear, though.
There are other ways in which SOA and BPM can be intelligently combined to add value to both that aren't just about simplistic views of integration (and I'll try and get to some of those in future posts, watch this space) - but I think this is one of the most important. It's important because it helps people get their heads around a way of linking business architecture work with technical architecture work - with one consistent set of concepts. To date, there haven't been many ways to do this, and our research suggests that few organisations manage to make the link effectively today.
To come back to the post title: when you start to think about outcomes as a core concept in business and technology architecture, it becomes clear that it's not accurate to say either that services come first, or processes come first: the truth is that *outcomes* come first, and services and processes are two sides of the same coin in achieving the right results.
Labels: BPM, EA, SOA
