Two or three years ago, when I began speaking at BrainStorm BPM conferences, I coined the term “BPM 2.0” to refer to new tools that allowed “process without programming.” That technology, featuring integration adapters that could introspect enterprise information systems and turn them magically into “services” ready for orchestration in a business process, was the beginning of the convergence of SOA and BPM. Looking back now, however, I think a better term might have been BPM 1.1, or “integration without programming.” Today it’s safe to say that not everyone interested in service orchestration is trying to do business process management, and that BPMS should signify more than simply agile integration infrastructure.
A couple months ago, Ismael Ghalimi – founder of Intalio and the original brains behind BPML, BPMN, and standards-based BPM in general – revived the term BPM 2.0 on his blog IT|Redux. His piece, posed as a manifesto of sorts, drew a long list of distinctions between the second generation and BPM 1.0. I agree with most of Ismael’s formulation, and also with the idea that BPM should be based on a set of principles, not just a collection of technical features and functions.
Here, then, is my own BPM 2.0 manifesto.
1. BPM 2.0 is top-down and business-driven. BPM begins with business objectives, and aligns them with the operation of end-to-end processes. That alignment is achieved through process modeling, performed by business analysts. Models are not simply documentation or “business requirements” shelfware, but the skeleton source of executable process implementations that will actually manage those processes in operation. This top-down design contrasts starkly with current SOA initiatives, which are bottom-up and IT-driven, and where the services exposed for composition are determined by IT’s notion of enterprise architecture, not by process-centric analysis.
2. BPM 2.0 quantifies, predicts, monitors, and optimizes process performance. Success in BPM is measured by quantitative performance metrics and targets – whether based on cost, time, profit, efficiency, or compliance. Without specifying technical implementation details, modeling allows processes to be parameterized sufficiently to predict these metrics through simulation analysis, and optimize the design accordingly. The same metrics and KPIs defined in the model are then used to monitor actual performance in the process implementation, displaying results in management dashboards and executing rule-triggered notification and remediation (BAM) automatically via the process engine. That implies, for example, consistency of the data model, event model, and aggregation model across historically separate tools for process modeling, executable design, and performance management.
3. BPM 2.0 requires a BPMS. Modeling by itself is not BPM. BPM 2.0 requires an integrated design and runtime environment – a BPM suite – that automates, integrates, and monitors process execution end-to-end. A BPMS is not a collection of best-of-breed components occupying colored squares in an enterprise architecture diagram; it is a unified platform, usually from a single vendor, architected to work as an integrated system, increasingly within a standard environment such as Eclipse. The list of features and functions within the BPMS continues to grow. At a minimum, it includes human workflow, an integration framework (including introspecting adapters), data transformation, a business rule engine, BAM and process analytics, event and exception handling – and, of course, modeling and simulation.
4. BPM 2.0 does not require code. Process design is graphical, with configuration via wizards and point-click dialogs. The users of these tools are generally IT, not business analysts, but they are not hard-core programmers – Ismael calls them “process analysts.” Implementation artifacts are generated automatically under the covers. Process designers don’t interact with them directly. Extending autogenerated BPEL with inline Java, for example, is not in the spirit of BPM 2.0. But BPM 2.0 sets the bar higher than this. In most BPEL-based design tools, the graphical notation corresponds one-to-one with the execution language, unlike a modeling notation like BPMN, where the shapes map more naturally to business process constructs. BPM 2.0 implies using BPMN or a similar notation, in conjunction with wizards and dialogs, to build robust executable designs.
5. BPM 2.0 is standards-based. This is a tricky one. Everyone is officially for standards: We use J2EE, we use XML… OK, let’s get real. When users want their IT to be “standards-based,” they are really saying they don’t want to be held hostage by their vendor. That translates to some combination of interoperability with other systems (plays well with others) and portability to alternate BPMSs (in case things don’t work out). Support for BPMN is a step in the right direction, and will be a likely “requirement” once OMG finishes the metamodel. Support for BPEL as an execution language helps on the portability side, but most BPEL-based offerings are still stuck in the bottom-up programmer-centric world of BPMS 1.0. Standards for integrating process with business events, business rules, and other critical components are barely off the ground. So we have a way to go on this one.
6. BPM 2.0 eliminates barriers to get started. As in price. Savvion has made modeling and simulation a free download. Oracle has made BPEL design and development runtime (including adapters) a free download. Microsoft will be doing the same. Intalio and ActiveBPEL provide free open source BPEL engines, and Intalio’s Community Edition (available soon) will provide a complete production BPMS, including workflow, rules, BAM, and the rest, for free.
If you like BPM, you’re going to love BPM 2.0.
