BPM stands for Business Process Management and is a discipline that aims to model, realize, manage, and even simulate business processes that involve both human and system tasks. These system steps might be automated via batch processes, on demand services, asynchronous processes. One key aspect of BPM is the focus on business metrics. Improving revenue, saving costs, improving customer experience, increasing productivity are what it aspires to achieve. Whether or not you explicitly model and manage business processes, they exist in your organization. BPM provides the technology infrastructure to better capture, streamline, and manage the realizations of business processes.
Typically, a visual tool is used to capture process flows which are decoupled from technology constraints and limitations. this rough technology-agnostic business flow can then be translated into an execution flow that will need to take technology choices, scalability, user preferences, integration with front end and back end services. BPM process flows can invoke data services, business services, perform human workflow tasks – delegation, escalation, routing – all within a stateful container.
Where does SOA fit into this picture?
Services ideally should be devoid of process-specific couplings – meaning they should be able to execute a series of steps based on a set of inputs and provide a set of outputs. Service capabilities need to be built for reuse across multiple business processes. BPM processes should avoid directly invoking service providers from legacy systems, packaged applications, etc. – although technically feasible it isn’t a wise move for the long term.
Why? Because without a mediation layer you lose significant benefits:
- abstraction (legacy system might go away, r u going to force all ur consumers to be impacted?)
- alignment with enterprise data models (minimize data transformations across calls, reuse schema types both at the business entity level and the individual types)
- database changes- structure, data typing, etc.
- freedom to switch service providers (example: moving to a cloud based infrastructure for saving costs)
- scalability (independently scale the service layer by deploying redudnant listeners or physical nodes etc.)
SOA can manage the messiness of enterprise integration (protocol bridging, data translations, transaction management). Most SOA capabilities tend to be stateless while BPM processes persists process state for several business processes. SOA can focus on building strategic services while BPM leverages them as much as possible to build new business capabilities. In other words, SOA and BPM can feed off each other – it is a symbiotic relationship wherein there is both a need for reusable service capabilities and well managed business processes.