How are BPM and SOA different and why does it matter?
It is a well-known fact in the industry that "processes run on services," so it's obvious that business process management (BPM) and service-oriented architecture (SOA) belong together. The good design principles of SOA are the difference between processes that are fragmented and inefficiently connected to the transactional backbone of the enterprise and processes that are an integral part of transforming a business. So why do we even ask where BPM ends and SOA begins?
One reason is that the two acronyms represent different types of concepts. BPM is a business discipline, aimed at operational improvement. SOA is an architectural style, aimed at engineering the systems (business and IT) of the enterprise. Specifically, BPM is a way of building operational solutions and SOA is a thought model that helps decompose complex problems into well-defined and reusable components.
Another reason is that BPM and SOA are important to (and done by) different kinds of people. BPM is important to business and process analysts. SOA is important to architects and engineers. Both may, when left in isolation, produce the same types of artifacts, namely process and service definitions, but they will do so with different motives and applying different skill sets. Architects and engineers are generally not equipped for defining how the business wants to run itself. Conversely, business and process analysts are not equipped for engineering complex systems of systems, instead they will inevitably focus on solving the problem currently at hand.
Finally, the lifecycles of the respective outputs from BPM and SOA are different. Not only can and will processes change independently of services, they do so much more frequently than a well-designed service should do. In fact, if a reusable service changes in as volatile a fashion as many business processes, that service would incur unacceptable cost on its consumers, forcing them to continuously adjust and regression test against ever newer versions.
With this observation we get to the heart of why understanding where BPM ends and SOA begins is so important. Processes and services, while dependent upon each other, do not follow the same lifecycle, yet they still need to holistically, together, support changing business objectives. If processes drive services unchecked, service proliferation will occur and ultimately the SOA fabric will be no better than an entangled set of legacy applications. If services drive processes unchecked, then change and innovation will suffer because any change will be measured in terms of whether the end result is reusable, regardless of the fact that many business processes have no need to be reusable at all. The proper balance between BPM and SOA is based on negotiation between what is desired from a single process solution perspective and what is manageable from an enterprise service portfolio perspective.
BPM ends with a statement of the desired level of automation
At the heart of good business process design is the distinction between a human task and a service (automated) task. For a modern enterprise, transacting with integrity means carefully designing and managing the integrity of end-to-end business processes, and optimizing those business processes from an operational perspective. It is simply assumed that the automated parts of those optimized processes can be connected to the relevant IT capabilities that support them.
SOA begins with the set of services that are available to support the desired automation
The notion of mediation between consumer and provider is fundamental to SOA. Historically, mediation has been thought of in terms of IT systems' interaction with each other. With the advent of BPM, the notion of mediation must now include connecting processes (as consumers of automation capabilities) and services (as providers of automation capabilities). This is not to say that the implementation of some business services cannot include people and processes, simply that to a consuming process the service is a black box that automates a particular part of that process.
It's important to remember that service orientation doesn't begin with technology; it begins with the mind-set of thinking about your business and the world around you in terms of functional components. Thinking in terms of services (and the processes that consume them) provides a uniform mediated architecture that can connect the key stakeholders inside and outside the enterprise.
Vendor products often blur the lines between BPM and SOA
Many vendor products, in particular BPM products, blur the lines between BPM and SOA in that the BPM offering ships with an embedded enterprise service bus (ESB). An enterprise service Bus is the pattern that embodies and formalizes the notion of consumers, mediations and providers; hence from a technology perspective is a core SOA technology. The reason an embedded ESB often ships with a BPM product is simply, as discussed above, that BPM assumes that the automated part of processes can be connected to underlying IT, so connectivity and mediation capabilities must be available or the BPM solution will be human-centric only.
Nevertheless, even when using a BPM suite that embeds an ESB, you should still keep in mind that BPM and SOA are done by different people with different skills. In fact, a reasonable requirement of a combined BPM and SOA offering is that there are dedicated tools for each group: the process specialists as well as the integration specialists. Furthermore, if SOA is part of the enterprise strategy, care must be taken that there is an on-ramp to having the SOA capabilities externalized from the BPM platform – after all, BPM is not the only consumer of services, just think mobile, cloud and big data!
Adopting BPM and SOA together remains common sense, yet care must be taken to effectively address the differences in skills and thought models between process specialists, integration specialists and service architects. All three are key to business transformation and must work together against common objectives. If the boundaries between BPM practitioners and SOA practitioners are not well defined, each constituency will make its own assumption about what they are and are not responsible for, and rarely will that match the assumptions of the other groups. The remedy, of course, is to crisply define and communicate where BPM ends and SOA begins.
- Managing your SOA portfolio for long-term success
- Service-oriented design principles: The foundation of new business engagements
- IBM Software for SOA and Business Flexibility series (registration page)
- BPM and SOA: Better together (Video)
- developerWorks BPM zone: Get the latest technical resources on IBM BPM solutions, including downloads, demos, articles, tutorials, events, webcasts, and more.
- IBM BPM Journal: Get the latest articles and columns on BPM solutions in this quarterly journal, also available in both Kindle and PDF versions.
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.