Archive for March, 2006
If BPM is going to be widely accepted as an instrument of business-IT alignment, it has some work to do. IBM developerWorks has an interesting monthly series in the context of SOA. In Part 2: How do I translate business needs into IT requirements?, IBM’s panel of “visionaries” mainly seems to agree that the right starting point is a tool called Rational RequisitePro, which IT uses to gather business requirements that can later be fed into BPM modeling tools like WebSphere Business Modeler and IT modeling tools like Rational Software Architect. Oops. Turns out RequisitePro doesn’t integrate with Modeler, but you can open Modeler in Rational Software Architect. Kind of an odd way to do business-IT collaboration.
A common refrain in the piece is that business and IT lack a common language for describing the problem, leading to all those bad things that can happen. One of the panelists, Kerrie Holley — CTO of IBM’s SOA and Web Services Center of Excellence — offers a magic quadrant segmentation of the possible outcomes based on effective business-IT communication, or lack of it. 
Interesting to compare this to another quadrant posted by Sandy Kemsley, taken from Simon Hayward’s keynote at the Gartner BPM conference.
Let’s make the BPM leap and equate Holley’s Know What and Don’t Know What categories with Gartner’s Strong and Weak Process-Centric Business Culture categories, respectively. And equate Know How and Don’t Know How with High and Low Process Capability of IT. Sandy likes the “Reflect” quadrant, where business is ready (for BPM) and IT isn’t. Holley calls this segment the “Quest.” Unfortunately, I think that’s where BPM is today.
March 30th, 2006
[reprinted from BPMS Watch on bpminstitute.org]
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. In BPM 2.0 you do not write 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.
March 30th, 2006
Doug Henschen, my editor at Intelligent Enterprise, already has posted an interview with Gartner’s BPM guru Jim Sinur, live from their shindig in Opryland. Jim makes some interesting points about the market, but the BPM bloggers on site (e.g. Kemsley, Taylor) seem to be most taken by Gartner’s new BPM “maturity model.” I’m sure it makes a great Powerpoint slide, but not sure I’m buyin’ it.
It starts off on the safe side: Most companies, he says, are at stage 1(modeling and measuring) or 2(tweaking and optimizing, using business rules). OK, I believe that. So what comes next? Stage 3 is an enterprise-wide process architecture with processes extended to trading partners. Stage 4 is instrumenting a framework of performance management goals against the actual process implementation.
The order seems funny to me. If that’s the way BPM is going to be adopted, it’s not how BPMS vendors have oriented their tools. Later in the interview, Jim talks about the business-driven iterative improvement strategy that is really driving BPM. But his maturity model is not iterative, it’s waterfall. A more logical progression would seem to be:
- Model and measure (as-is and simulated to-be), and establish performance targets.
- Implement one app, and measure performance achieved.
- Tweak and optimize, add business rules.
- Iterate that for a few more apps.
- Develop the enterprise process architecture.
The essence of modeling is performance prediction. When the modeling and simulation tool is part of a BPMS, there is an implicit assumption that the KPIs that were modeled will be monitored at runtime. That’s why the BPMS vendor has taken the trouble to include BAM in the offering. Maybe Jim is saying that’s what the vendors are selling but companies aren’t ready for it yet? I don’t know, but the thought of rolling out an enterprise process architecture before I had closed the loop on process performance doesn’t really make sense.
March 28th, 2006
[Originally posted on IT|Redux]
Edwin Khodabakchian, the brains behind Oracle BPEL Process Manager, posts on a set of possible “BPEL enhancements” suggested to him by Oracle’s application groups — eBusiness Suite, PeopleSoft, Siebel… They include:
1. Business Process Outline — “Enable business analysts to build the skeleton of a business process, skeleton which can be then implemented by an application composer. The outline view also offers a foundation for self-documenting business process and audit trails.” Imagine that!
2. Business Events — Allow the process to raise events processed by external apps and to subscribe to events raised by apps, providing “the glue between business activities and the foundation for realtime analytics.” He proposes a new event language standard, not mentioning the fact that IBM has proposed one already (apparently without unanimous support) and uses it in its own BPM/BAM integration.
3. Variable Entity Binding — When BPEL is used not in an integration context but within an enterprise app, persist BPEL variables automatically in that application.
To my mind, those innovations sound suspiciously like what BPM calls process modeling, BAM, and embedded application workflow — assumed “must-haves” in the BPM world but exotic enhancements to the BPEL mainstream. But unlike IBM (and now BEA), Oracle is not trying to appeal to BPM buyers or industry analysts, just better support Oracle’s own apps. They’ll figure it out eventually.
March 17th, 2006
[Originally posted on IT|Redux]
In his new blog on ebizq, David Ogren of Fuego offers a spirited rebuttal to my charge (and that of others, like Sandy Kemsley) that, whatever its merits in filling out the BPMS magic quadrant checklist, acquiring Fuego was a strange way for BEA — one of BPEL’s initial sponsors — to go about it. While admitting that he (like the rest of the Fuego guys I’ve met) probably falls into the category of “BPEL-haters,” he says that the Fuego engine in fact executes BPEL in addition to its native XPDL-based language. My impression had been that FuegoBPM could import BPEL but immediately converted it for editing into Fuego-native, i.e., a one-way trip… once out of the tube that toothpaste was never going back in. But I could be wrong.
Still, I find it odd that the core of Aqualogic — as I understand it, BEA’s strategic standards-based SOA platform — should be XPDL, or workflow-based, rather than BPEL, supposedly the SOA orchestration standard. And not only that, BEA already has a BPEL engine in WebLogic Integration.
David makes another interesting point in his post, that BPEL vendors like IBM and Oracle are not considered by Forrester to be “strong players in human focused BPM.” Probably Forrester puts them in another bucket entirely, but let’s just stipulate that those companies’ major interest in BPEL is business integration not workflow. So with AquaLogic, is BEA trying to compete with IBM, Microsoft, Oracle, and SAP, or with Savvion, Lombardi, and FileNet?
As I’ve said before, BPEL has serious “issues” with trying to make human tasks portable across engines, and most BPEL vendors are still figuring out stuff workflow vendors have known since 1990. So if human-centric processes are your organization’s immediate focus, workflow-style BPMSs may be a better way to go. But I would not have thought an organization like that to be in BEA’s SOA crosshairs.
Now that he’s been at BEA for a few days now, I’m hoping that David will chime in with his version of the AquaLogic BPM story — not so much why BEA bought Fuego, that’s water under the bridge — but how BEA views BPM within its overall SOA context and how AquaLogic BPM relates to other BEA components.
March 15th, 2006
[Originally posted on IT|Redux]
BEA’s acquisition of Fuego this week is a welcome validation of the BPMS market, but what a surprising way to go about it! Probably the strangest BPM acquisition since TIBCO spent big bucks on a workflow engine that couldn’t even receive a JMS message.
FuegoBPM appears to have already morphed lock, stock, and barrel into BEA’s AquaLogic BPMS. Not that FuegoBPM isn’t a fine BPMS, but it’s not based on BPEL — wasn’t BEA a “founder” of that standard? – and you could argue it’s not even service orchestration, at least in the way most in the BPMS community understand it. For example, process activities in Fuego are not SOAP calls to remote services, but user-defined “methods” of the activity implementation written using Fuego’s VB-like FBL script. Architecturally, that puts it closer to a workflow engine than to a BPEL engine. What’s even stranger is that BEA already has what looks to be a fine BPEL engine and tool in WebLogic Integration 8.1. OK, that’s strictly J2EE, and AquaLogic is supposedly “platform-independent” (can that be right?), but still… I’ve heard (but don’t actually know) that the AquaLogic ESB is really WLI.
If BEA was anxious for a quick entry into the BPMS magic quadrant, this was probably a cheaper and faster way to check off all the features than building out WLI. Companies like IBM, Oracle, and Intalio have shown that you can build a complete BPMS – with human workflow, business rules, BAM, and the rest – on top of a unified service orchestration stack, so why would BEA want to go back to the old dual architecture approach — workflow for the end-to-end process and BPEL just for system-to-system integration? That makes sense for a pureplay like Fuego, but not for a core platform provider like BEA.
March 1st, 2006
