BPMS vendors love to throw a bone to SOA, and if you weren’t paying attention you might even think that BPM on SOA was real. I’ve written at length about how BPM and SOA aren’t enemies but natural allies, but they are allies with distinctly different goals and aspirations and mental models of the world. Kind of like America and France.
Following his post on the subject, I’ve been having a side conversation with Jesper Joergensen of BEA about what real BPM on SOA would look like. I admit I’m still trying to figure it out. Here’s where I am so far.
Let’s start by acknowledging the inherent Mars/Venus-ness of BPM and SOA. For example:
- BPM is top-down. It starts with the end-to-end process in mind. SOA is bottom-up. It starts by factoring the world into atoms and molecules of reuse — business services — that can be consumed by any number of processes or applications.
- BPM is business-driven. A “model” created by the business drives the implementation. SOA is IT-driven. Technical architects define the scope of business services based on their own notions of “abstraction” rather than business need.
- In BPM, success is measured by business metrics and KPIs at the end-to-end process level. In SOA, success is measured by architecture, logical consistency, ease of integration. Performance goals do not extend beyond the individual service level.
- BPM is project-oriented. The goal is solving a real business problem today. SOA is enterprise infrastructure-oriented. The goal is creating a foundation for solving many business problems a few years down the road.
- In BPM, what is reused is the process model, i.e. the “abstract” design of a process fragment. It is inherently transparent — you see its steps and their individual performance parameters. In SOA, what is reused is the service implementation. It is inherently opaque, defined simply by its interface. Its internal steps and performance parameters are invisible, except for an overall SLA for the service as a whole.
- In BPM, a business process is inherently hierarchical, composed of nested and chained orchestrations. In SOA, services are inherently independent. An end-to-end process is more likely to be implemented as a spaghetti-like SCA assembly than a nested hierarchy of BPEL orchestrations.
- In BPM suites based on service orchestration, process activities are bound to service endpoints. In SOA (supposedly), orchestrated services are supposed to be abstract, with connection and mapping to endpoints mediated by an ESB. The ability to swap out endpoints performing the same abstract service is the effective definition of loose coupling. I don’t know of any BPMS offerings oriented to this mode of orchestration.
If you accept most of the above, you might ask why try to save this marriage anyway? But the goals of BPM and SOA are not opposed, just different. Bringing them together is mostly a question of timing. BPM, trying to solve real business problems today, starts by acknowledging that the refactoring of the enterprise into “business services” — macro-scale units of reuse — doesn’t yet exist, so the best approach for now is simply to incorporate service-oriented middleware here and there — mostly in application integration — in the BPMS.
In SOA, BPEL orchestration in reality is mostly used to assemble business services out of low-level APIs. They call that “BPM,” even though it’s not what the business means by that term. Eventually, there will be enough of those business services in the registry that BPM can orchestrate them in end-to-end business processes. That’s the end state that makes bringing BPM and SOA together worthwhile. We’re just not quite there yet.
So let’s wind the clock forward a bit to a time when, in some organizations at least, the set of defined, built, deployed, registered, and governed business services is significant enough to form the basis of key business processes. What would a BPMS layered on that infrastructure look like?
First, it seems that in such a world, BPM and SOA likely each have their own enterprise repository/registry. The SOA one would hold opaque service implementations – IT assets – bound to physical endpoints, SLAs, and perhaps other “contractual” aspects of the provided service. These services are not “abstract,” but real services offered by real service providers. The BPM one would hold transparent process models – specifications of business services – in which activities can be mapped to services in the SOA repository to create an executable instance of process model. Processes (including process fragments, or abstract business services) in the BPM repository could be reused throughout the enterprise to provide standardization and consistency with best practices, mapping model activities to different service providers in each instance.
Second, I believe that services in the SOA repository will generally not include human tasks, even though business services that include human tasks (payInvoice and things of that nature) are frequently described within the SOA vision. Unless the human interaction component is very simple and a minor fraction of the functionality, services that include human tasks should be represented within the BPM repository instead. One reason is you want to retain the transparency, i.e visibility of internal state, as well as ability to configure and analyze human resources to optimize performance. Conceivably one could add such attributes to the SOA repository, but they would no longer describe “services” as meant by SOA. Another reason is that the individuals and groups mapped to task performer roles are going to be different in each reuse of the model. This notion of reuse is fundamentally different from that of a single web service being consumed by multiple applications or processes across the enterprise. The latter is more about outsourcing than reuse.
In my mind’s eye, the distinguishing characteristic of a BPMS layered on SOA would be a design environment that can:
- retrieve and copy process fragments from the BPM repository, and assemble them within larger end-to-end processes
- search the SOA repository for available business services as a guide to scoping activities in the process model
- bind process activities to services in the SOA repository, via proxies defined by SOA infrastructure (e.g. ESB). Any mapping from the service interface to backend systems providing the service is handled by the ESB and mappings within the SOA domain; BPM doesn’t have to think about it.
- turn newly created processes and process fragments into “abstract business services” and store them as models in the BPM repository.
- leverage SLA, cost, and other service properties from the SOA registry in BPM performance analysis (simulation, BAM, etc.)
In Part 2 we’ll talk about how this differs from the way current “SOA-based” BPMSs work, and how it might evolve.
Top-down BPMSs suitable for Straight-Through Processing?…
In his post, Bruce specifically talks at a level that really makes sense, rather than the usual “we need BPEL/BPMN/WS/SOAP/I’m smarter than you by being able to use technical acronymns in seamingly meaningful ways that are completely unrelated to the…
I believe that SOA and BPM is the perfect match, but let’s focus on what’s missing instead of how they intersect.
How do you envision Reporting to work in such an architecture, where each “Service” has its own state/data, and the BPMS is also collecting/showing data. How can this whole system operate without a fully integrated reporting solution? and where would such a solution fit in and what would it look like?
Great question, aa. In standard SOA, such services would be opaque and stateless, so BPM’s reporting/monitoring would know when they were invoked and when/how they completed, but the internal state of in-process instances would be invisible. Jesper suggested that the new Business Process Runtime Interface in OMG would be the way to get that internal state info back into BPM. I’m not sure if that’s the BPRI group’s idea of how it would work or just Jesper’s fantasy. OMG people, if you’re lurking, please chime in with the answer!
Business Architecture is not for Dummies…
SOA is a means to make sense of the complex IT assets – a way to manage them and package them – so that “the business” can more easily consume them…. The IT assets that will be maintained by IT (or, more and more, that will be available as a host…
[…] Normally when the Ayn Rand references start flying, I head for cover. But since Phil Gilbert’s rant on the futility of foisting an SOA primer on naive business managers tracked back to my post on what BPM on SOA would look like, I guess I’m obligated to say something. Phil’s nominal beef is with the mere idea of a book called SOA for Dummies, which commits the sin (in his eyes) of equating SOA with web services and ESBs. The deeper issue, however, seems to be misappropriation by the SOA community of a value proposition that really belongs to something called Business Architecture, things like business-IT alignment, agility, reuse, etc. Business architecture, from his description of it, looks at business and IT together as an “organic” whole (with a slight top-down business-oriented perspective), rather than starting with IT infrastructure and then seeing what you can build on it. […]
[…] But in my view, the basic fallacy of Dave’s argument relates to the difference between SOA and BPM. Yes, orchestration is important to SOA — to create coarse-grained business services out of fine-grained services distributed over the ESB. And orchestration is also important to BPM — to create end-to-end business processes by orchestrating business services and human tasks. But BPM is not SOA, and business services are not what BPM means by business processes. […]
[…] Bruce Silver has an interesting post named BPM on SOA: What would it look like? – Part 1. Here he talks about whats the differences between BPM and SOA, I will here repeat these points and add my own comments: Where BPM is topdown, SOA is more bottom-up, utilizing and exposing the already existing infrastructure, hiding the complecity and details of technology from the business layers of the enterprise architecture BPM is businessdriven, a model created by the business drives the implementation, SOA is IT-driven and there are technical architects that defines the scope -A BPM project success is measured by business metrics and KPIs. A SOA is measured by architectural metrics, ease of integration, cost of change, etc BPM is more projectoriented, where SOA is more enterprise wide infrastructure-oriented In BPM, what is reused in the processmodel, in SOA, services are reused -In BPM business processes are more hierachical, chained and nested In BPM suites concrete endpoints are used, in SOA and ESBs, abstract endpoints are used for utilizing effective protocolswitching […]
I also believe SOA and BPM is the perfect match. I only think plays a vital role in achieving added value. What is your opion about this?
[…] BPM on SOA: What Would It Look Like? – Part 1 […]
[…] Bruce Silver wrote a nice post on BPM and SOA. I agree on his analysis that these 2 worlds are slowly merging. An Service Oriented Architecture will only be efficient when the business processes on top of it are efficient. It is good to see that the Oracle SOA Suite gets more and more tooling for Business Process Analysis (BPA), simulation and Business Activitity Monitoring (BAM). The tools you need for process improvement or BPM. […]
Haifa Wahbi…
I Googled for something completely different, but found your page…and have to say thanks. nice read….