It would be easy to come away from a BPM conference thinking the primary objective of business process management is improving human work – making it faster and more productive, less error-prone, more compliant, more flexible and adaptive to changing business needs, and more measurable in support of performance targets. And for many business processes, those are indeed BPM’s goals, both as a management discipline and as a software technology. But for many of the operational processes that drive company’s bottom line, these are not the primary goals, because those processes are not human-centric. They’re what we call integration-centric processes, and their demands on the BPMS are different.
BPM suites optimized for integration-centric processes often don’t show up in the Gartner magic quadrant for BPM, even though they represent the Billion-dollar software giants – IBM, Microsoft, Oracle, SAP – in contrast to the $50 Million private BPM pureplays that dominate the Leader quadrant. Moreover, there is a frequent tendency among analysts to dismiss these offerings as warmed-over EAI tools. And, to be fair, many of these vendors do themselves no favors with slogans like “BPM is the business face of SOA.” What the heck does that mean, anyhow?
If you can even get them to admit that integration-centric processes are important to a customer’s enterprise BPM strategy, most BPMS vendors with a human-centric offering will tell you their tools can handle them perfectly well, while those from the “warmed-over-EAI” camp will fail utterly with the human-centric processes. But today at least, that’s just not true.
So what are the kinds of things needed in a BPMS for integration-centric processes that are often missing from the pureplays? Another way of saying it is what are the identifying features of an integration-centric BPMS?
Let’s start with integration itself, meaning how the process queries or updates external databases and applications. All BPMSs – human- or integration-centric – provide native support for integrating web services and databases through self-generating “introspecting” adapters. That means through the BPMS design tool you can connect to the external system, graphically select a web service operation or database table, and instantly generate a component you can attach to a process activity to execute that integration. Most BPMSs can also do the same with any external application that exposes a Java API.
Why isn’t that good enough for integration-centric processes? The problem is this method of integration is synchronous, low-level, and tightly coupled. Synchronous integration, also known as remote procedure call, is like a telephone call. You dial, and either someone answers and you talk and then hang up, or it’s busy, or it rings and no one answers. In the latter two cases, the process has to wait and try again later, or else give up and do something else. In all three cases it’s slow. The target system may be unavailable or the connection lost, and the process is blocked until the call is complete (or abandoned). Slow is a relative term, but when you’re processing the main stream of orders or claims or other transaction requests that drive your business, every ounce of speed counts.
Integration-centric processes support asynchronous integration over a message bus. Async is like email. You send it and can do other things while you’re waiting, so it’s fast. Moreover, the bus itself handles the queuing, the errors, timeouts, and retries, so the process logic doesn’t have to deal with such “plumbing” issues. Also, message-based integration is less dependent on details of the target system platform or programming language; it is often the only way to integrate legacy systems, for example. Asynchronous integration over a message bus is the part of integration-centric BPM that is indeed warmed-over EAI, but unlike EAI, BPM embeds this technology in an end-to-end process modeling and management context – a big difference.
A second identifying feature of integration-centric BPMS is how events and exceptions are handled without programming. You don’t just fire-and-forget the service request. You expect a response sometime later in the form of a message. Also, other message events may arrive unsolicited – the customer changes or cancels the order, for instance. The process needs to be able to pause at some point and wait for such messages, or be interrupted and rerouted by such messages. Activities defining such event waiting and interruption are fundamental to integration-centric process language standards like BPEL, and through that connection found their way into modeling standards like BPMN that are now used by human-centric and integration-centric tools alike. The difference is that integration-centric BPMSs support BPMN’s event and exception handling features, while human-centric BPMSs tend to conveniently ignore them (and then solve the problem in custom Java code).
A third identifying feature of integration-centric BPMS is support for complex data objects and transformation mappings. If you’re doing order management or supply chain or claims, the process has to manipulate complex business objects like Order or Customer or Claim, and map the individual elements of those objects to the various data models of disparate backend systems. In contrast, human-centric BPMSs think of process data in terms of simple fields that you can attach to forms – not Customer but CustomerName, CustomerStreet, etc., and each element has to be individually mapped for integration. Try integrating the process with a few ERP and supply chain systems this way and you’ll quickly appreciate the difference. Human-centric vendors will counter that they do support complex data objects; it just requires Java programming. But integration-centric vendors can respond, “Isn’t this the kind of programming BPM was supposed to eliminate?” Yes it is.
Related to this is a fourth identifying feature, prebuilt industry solution frameworks in the BPM Suite – not free, but engineered and QA’ed, documented, and supported – that provide out of the box industry-specific business objects and their transformation mappings to backend systems. In addition, integration-centric BPMSs are more likely to rely on a separate third-party tool like IDS Scheer ARIS for process modeling, rather than merge modeling and design in a common BPMS tool shared by business and IT, as favored by human-centric. One reason is the BPA tools’ built-in support for industry frameworks like SCOR, which tends to be more important in this segment than business-IT “collaboration.”
Finally, the key feature that sums up the difference – at least today – is true support for SOA. This means integration-centric BPMS offers asynchronous integration via an enterprise service bus, SOA’s standards-based update of the EAI message bus, and links to an enterprise registry/repository of business services. SOA not only addresses the asynchronous integration requirement, but simplifies process design by integrating at the business service level – the level of reuse – rather than at the individual API level. It also adds “loose coupling”, the ability to change backend systems transparently to the process design.
While some SOA stack vendors falsely claim to provide BPM, true integration-centric BPMSs have begun to clarify the relationship of BPM and SOA: Design and implementation of reusable business services belongs on the SOA side of the dividing line, and orchestration of those services in business processes belongs – along with modeling and performance management – belongs on the BPM side.
In this early stage of SOA evolution, most integration-centric BPMS vendors offer their own SOA stack, but down the road there is no reason why BPMS vendor A should not be able to fully leverage SOA stack vendor B. When that day comes, and companies have built out their key business functions as reusable business services, we should see less of a distinction between human-centric and integration-centric BPMSs. But that’s still a couple years away.
