Archive for May, 2006
For me, the most troubling part of the BPM Think Tank event was my roundtable on The Business Value of BPMS. The roundtable format was an open-ended discussion with 10-12 attendees on a specific topic, formulating a problem statement and then a proposed ideal future state. I expected a discussion about which of BPMS’s putative benefits — business/IT alignment, process efficiency, compliance, agility, and performance visibility — was most valuable to the business or had some issue blocking full realization. Instead, to my surprise, I found that most “practitioners” at the table — business architects, IT analysts, and BPM consultants — didn’t get BPMS at all. They got BPM, and were “doing” BPM, but it was just modeling, i.e. cross-functional “process thinking,” documenting how it’s done now and how it could be done better. Executing the process? Huh? Why would anyone want to do that?
I expect that reaction from business folks, but these were IT. The good news? They get BPM, how it can improve business-IT alignment and performance optimization. The bad news is that they equate BPM to modeling (plus perhaps BI/BAM). The idea of building process implementations without programming and executing them on a process engine (which also monitors process performance, enforces business rules, etc) still draws blank stares.
BPMS vendors — not modeling tool vendors, not implementation consultants — are the primary funding source for the conferences, web portal sites, and other channels of BPM market education. They’re evangelizing the benefits of BPM, and it’s working… But the market is attaching those benefits just to the modeling piece. The vendors as a group haven’t yet closed the sale on the incremental business value of BPMS, i.e executable design, process automation, and process performance monitoring.
BPMS vendors need to take some time out from bashing each other and join in common cause to educate the market — both business and IT — about BPMS as a different style of process implementation, what it gives you beyond what you get with modeling alone. And provide proof points, case studies of customers who have done it and achieved the benefits.
May 26th, 2006
My previous post just hit the low points. Sandy has a more complete writeup of the day’s activities, which is mostly accurate. Kinda long, though, Sandy. Didn’t have time to fin
May 24th, 2006
- BPM is about empowering people. It was co-opted by integration vendors, who took it down an IT-centric path. – Connie Moore, Forrester. [Note: Forrester has separate analysts and “waves” for human-centric and integration-centric BPM. Guess which is Connie’s…]
- The ultimate goal of BPM is self-aware processes that can recommend changes to process owners. – Connie again. [Yeah, I hear businesses asking for that all the time.]
- Portability of process templates was never a goal of BPEL, just interoperability [i.e., abstract process definition]. – John Evdemon, Microsoft, BPEL TC co-chair. [You mean I’ve been defending BPEL against the haters all this time for nothing??]
- BPEL is not ready for production. – Evdemon [Because the 2.0 spec could still change in the next 30 days? At least I hope that’s it…]
- BPEL probably got more press than it deserved when it came out because of the vendors supporting it. I probably should be covering up my badge. – Evdemon again [At least the guy’s honest! Note: BizTalk 06 still doesn't support it except as an import/export format.]
- OMG can’t finalize the metamodel (BPDM) and schema for BPMN until it works out the complete semantics of choreography (message exchange patterns between multiple collaborating processes). – Fred Cummins, EDS, OMG BPDM TC. [Translation: don’t hold your breath…]
- The BPDM metamodel and BPMN schema are available today. It’s called XPDL. – Keith Swenson, WfMC XPDL TC. [That’s basically true. OMG has effectively given XPDL a two-year window to establish itself as the de facto BPMN schema, and make the official OMG epic irrelevant.]
- An easier way to do BPM is to just use modeling and BAM, and forget the process engine and BPMS. That would make it easier to “sell” internally. - Consensus of BPM practitioners at my roundtable. [D'oh!]
- My blog posts are too long. Who has time to read 500 words? - Sandy Kemsley, BPM blogger. [I have no comeback to that one.]
May 24th, 2006
[my latest BPMS Watch column on BPMInstitute.org]
The annual BPM Think Tank, now in its second iteration, is an event I’ve been looking forward to all year. Unlike most BPM conferences, which are generally aimed at helping newbies get started, Think Tank is a forum where experienced BPM vendors, analysts, academics, and user organizations come to discuss what needs to come next in terms of technical standards, software capabilities, and overall business value from business process technology. The event is hosted by OMG, the standards organization that last year absorbed BPMI.org, the original creator of the Business Process Modeling Notation — the emerging standard for process modeling and, increasingly, for business-driven process design.
This evening, before the event got underway, a number of Think Tank leaders gathered in an informal dinner meeting to discuss a new proposal not even on the official agenda: a way to query running BPM systems about process performance, from the state of an individual process instance to aggregated metrics displayable in a management dashboard. The idea, variously called the Business Process Performance Management Interface or the Business Process Runtime Interface, would complement BPMN’s focus on process modeling and design.
Even if the entire BPM world suddenly standardized modeling and design on BPMN, today there would still be no standard for the runtime artifacts of executing processes, i.e. the data used to measure process performance. Each BPMS defines and stores those artifacts in its own way, from how it logs process state information and related business data to how it propagates that information in the form of events, to how it correlates and aggregates those events in KPIs and other performance metrics, and displays the aggregated data in management dashboards and alerts.
The proposed new standard would do for process performance data what BPMN is doing for front-end process modeling: allow process information to be understood in a common way across vendor offerings and become accessible to third party tools. If such a standard became widely adopted, process performance data would not be the proprietary domain of BPMS vendor-specific performance management engines and dashboards, but could be incorporated, for example, in the performance management dashboards created by leading business intelligence software vendors.
Wouldn’t it bother you, I asked the CTO of one BPMS vendor advocating for the new standard, if your customers didn’t use the performance dashboards of your own BPMS but funneled all their process performance data to Cognos or Business Objects? Not at all, he replied. We don’t want to be in the dashboard business. As long as our BPMS owns the data, we’re fine. In fact, a number of our customers have more than one BPMS vendor installed and are looking for ways to tie together management data from all of them. Today there’s no way to do that.
My gut reaction is I see the need, but BPMS as a technology has more immediate concerns, such as really standardizing BPMN, for instance, with an official metamodel that nails down the precise meaning of all the graphical constructs, and a standard XML schema to store and exchange process models. At last year’s Think Tank OMG was supposed to be working on that, and it still isn’t done. That’s coming soon, however, according to OMG sources. A new draft of the Business Process Definition Metamodel (BPDM) covering BPMN and process orchestration is due in June. The final BPDM draft needs to tackle the harder problem of message exchanges between the processes of two trading partners, called choreography.
Standardizing the precise semantics of BPMN could have a profound effect on BPMS. A number of vendors are already using it as a common modeling and executable design tool shared by business and IT. Others are using it for modeling and simulation analysis, followed by automated mapping to BPEL, creating a skeleton implementation completed by IT in a technical design tool. Vendors are beginning to automate the mapping of BPMN to BPEL and back again, allowing the model and executable design to stay in sync even after IT has fleshed out the implementation. If BPMN became a portable standard for modeling and business-oriented process design, it could make the underlying execution language, whether BPEL or vendor-proprietary workflow language, almost irrelevant.
If OMG can make BPMN a success, BPPMI (or whatever it winds up being called) is a logical next step. The reason BPM is becoming the “business face of SOA” is its emphasis on performance management. With BPM you can model process performance, analyze it through simulation, instrument it in execution, and continuously monitor it in dashboards and alerts. Standardizing access to process performance data brings BPM into the broader realm of corporate performance management, which is a true CEO concern.
Success with both BPMN and the performance management interface would firmly establish OMG and its BP-* standards as the business-oriented management layer for SOA surrounding the WS-* technical standards stack managed by OASIS and W3C, and would likely lead to well-defined mappings between the two. That would mark BPMS as truly mainstream IT. When it happens, I can say I remember when that started at the BPM Think Tank.
May 23rd, 2006
Virtually all the modeling notations and tools I know, including BPMN, as well as executable process design tools (both workflow-style and BPEL-based) follow the activity flow paradigm, i.e. like a flowchart or UML activity diagram, in which the flow is generally in one direction. Moreover, to create a valid executable process diagram, many (including the BPEL language itself) exclude arbitrarily looping back to previous steps in the diagram.
But for many real-world processes, particularly those characterized as “event-driven”, that no-loopback rule doesn’t work. They are better modeled as “business state machines,” similar to a UML statechart diagram. Nodes in the diagram are not process activities but states of the process instance. In each state, the process listens for various events, which trigger a specified action (process activity) and transition to a new state (or back to the same state). The triggering can also be conditioned by a rule. This event-condition-action (ECA) paradigm is the hallmark of event-driven processes. UML provides a diagram to let system architects model them, but I don’t know of any tools for process analysts to model them. Maybe the concept is too “complicated”?
Very few BPMSs support business state machines natively in their design tools. In Vitria BusinessWare, it’s actually the default. In IBM WebSphere BPM Suite, it’s provided as an alternative design tool in addition to their conventional BPEL editor, although it has no corresponding modeling tool in WebSphere Business Modeler. The interesting thing about the IBM implementation is that the business state machine is expressed as BPEL. I always wondered how that was done, but an article on DeveloperWorks provides the clue, which was subsequently verified to me by Matthias Kloppmann, one of the architects of WebSphere BPMS.
States are represented in BPEL as variables. Each state can have predefined exit and entry actions. Between the start state and the end state the BPEL is a While loop containing a giant Pick, with a separate Pick branch for each event in the state diagram. Each branch performs the following sequence of steps:
- Validate the event for the current state
- Evaluate the condition if any
- If transition to a new state, perform the exit action of the old state
- Perform the transition action specified in the state diagram
- Perform the entry action of the new state
- Update the state variable
For any arbitrary state diagram this works in BPEL without violating the rules. If you viewed the BPEL in a normal BPEL editor it would be much less clear what is going on in the process. It’s much clearer in the state diagram.
It seems to me event-driven processes are not too complicated for process analysts, and would benefit from a business-oriented modeling tool. (Actually IBM’s business state machine editor doesn’t seem too complicated, but it’s buried inside a tool that probably is.) BSMs and conventional activity flows can even be combined in an overall process description. Screenflows defining a single “user task” come to mind, for example. For now the BPMN world probably has higher priorities than this, but extending modeling to event-driven processes or process fragments seems like a good idea.
May 22nd, 2006
Nothing pegs my BS meter like a BPM keynoter waxing poetic about pi-calculus, especially to an auditorium full of business analysts. But now it looks like the pi guys have the last laugh. I noticed Technorati’s #2 hottest new book on Amazon is, you got it, “The Pi Calculus,” with 386 new links in the last 48 hours. Wow. And at 75 bucks its a steal! What are the rest of the top 5? That would be, let’s see, The Da Vinci Code, another The Da Vinci Code, Dan Brown’s Angels and Demons Special Illustrated Edition, and Harry Potter 6. Yeah that makes total sense.
So what do these new linkers say? Here’s the Technorati abstract of the first one:
f.Send(new Channel(”hello!”)); Channel r = new Channel(”r”); f.Send(r); System.Console.WriteLine(r.Receive().Name); } } Special! Congratulations, you read this far! Thank you. Now…
Umm. What’s the frequency, Kenneth?
May 19th, 2006
Can anyone help me understand how (or if) ESB fits in a BPMS? In the mountains of blather you can Google on either topic I can’t find anything that makes sense about how the work together! In fact, the more I try to understand ESB the confuseder I get. For clarity, let’s just consider BPEL-based BPMSs like IBM, Oracle, Intalio… Is ESB an inherent/invisible capability of these offerings (I think not) or something that can be added on in some implementations (I think so, but not sure)? What do you get with the ESB version that you don’t with the non-ESB version?
There seems to be redundancy between what the BPMS provides and what the ESB provides, including integration adapters, data transformation tools and engines, and of course a BPEL tool and engine. So are they sort of the same thing (except for BPMS’s “business-oriented” things like process modeling, performance management, and business rules that no self-respecting SOA Architect would be caught dead worrying about)? I don’t think so.
A few things come to mind. One is synchronous vs messaging-based connection to services. Is it correct to say that BPMS integration adapters without an ESB just provide synchronous connections? (Except for JMS or MQ adapters, I suppose). To connect asynchronously over the network you need either an old-school message bus or an ESB. Is that right?
Another is centralized vs distributed intelligence. In BPMS the process engine is the centralized brain of the process. That’s fundamental. In the ESB literature they talk about distributing intelligence to nodes in the bus (”content-based routing”) or even to the service endpoints. Anything else, we’re told, is “hub-and-spoke”/”can’t scale” architecture. I.e. without an ESB, BPMS can’t scale. Can that be right? It makes ESB sound like those 1990s-era message brokers that BPMS was supposed to be a step up from!
And then there is the business services/loose coupling thing. This at least makes sense conceptually (sort of), although I don’t know if people are actually doing it. Network Computing’s review of ESB Suites in March talks about the 3 layers of SOA, the lowest being coding of services or “service-enablement” of existing systems, the middle being “service orchestration” to create coarse-grained “business services”, and the highest being “process orchestration” to create business processes. Network Computing assigns ESB to the middle layer — orchestrating low-level services into larger service units which will be exposed to the business for use in processes — and BPMS to the top layer. At least that idea computes in my brain, but it’s not obvious why the technical features ESB provides, like message transformation and queuing, are more relevant in the middle layer than in the top layer.
Others have described ESB in a loose coupling context. In BPMS, the argument goes, services are not really pluggable since each has a distinct signature or request/response schema. In BPEL terms, that means you have to change the Assign activity before the Invoke — big deal. The better way that ESB supposedly allows is that BPMS can invoke the service through a generic interface (maybe using some industry-standardized vocabulary) and entrust the mapping to the endpoint-specific interface to the ESB. Kind of like Crossworlds or Vitria used to do, or some EAI. Is that what ESB is about?
I’m looking for feedback here. Anyone?
May 19th, 2006
It’s good to see Workflow Management Coalition’s Keith Swenson blogging now. Keith, whose actual livelihood is as chief architect of Fujitsu’s BPMS, has done heroic service over the years in advancing BPM standards consistent with the WfMC reference model, such as XPDL, ASAP, and others. His recent post “Workflow is Back” reflects the irritation of many who are continually forced to watch BPM startups tout their “invention” of functionality that has existed in workflow products for over a decade, followed by lavish praise from industry analysts too young to know better. He also notes that all major workflow offerings have long provided application integration in addition to human tasks — how could they solve real problems if they didn’t? His major beef, though, is over vendors’ wholesale abandonment of the term workflow in favor of BPM, when there is in fact little or no distinction between them — implicitly validating the contention that “workflow failed” as a software technology. Being an engineer, naturally he blames it on “marketing fluff.”
Forrester’s Connie Moore validates Keith’s position, which isn’t far from my own. Connie tells Doug Henschen in an interview last fall:
There’s lots of confusion about the term [BPM]. When we do surveys about BPM and we define it as software that supports cross-functional processes that involve people and systems, the top buyers are oil and gas, utility, chemical, retail and consumer packaged goods companies. Yet when I look at the base of clients placing inquiries about BPM, it’s from government, banks, insurance and financial services. The latter have been doing process automation since the early ’90s and still use the term “workflow.” The former are newer to the concept [and know it as] BPM, but both groups are talking about the same thing.
But in fairness to the workflow-is-dead-long-live-BPM crowd, BPM did significantly enlarge the scope of the process management solution over the vision of traditional workflow vendors. Business-oriented modeling and simulation analysis, for example. Integration adapters and middleware. Business rules. KPIs and BAM. None of that was ever part of workflow. When workflow vendors added it — as many did — they called it BPM. I think that’s fair, and not really marketing fluff.
I use the term workflow today in two different contexts: One is as a feature of BPM, meaning human task management, which is probably how most people talking about BPM today mean the term workflow. The other is as one architectural style of BPMS offerings, in contrast to the service orchestration style based on BPEL. I don’t know of others using the term workflow in that context, but I think it fits.
In workflow architecture, process activities are divided into distinct types - a human task, a subprocess, an integration step, a script or business rule, etc. Each type has its own icon in the diagram and its own configuration dialog, all of which generally simplifies process design. BPMS tools based on workflow architecture typically use XPDL to serialize the process definition, but the underlying execution language is actually proprietary to each offering.
Those offerings stand in contrast to the service orchestration style, what Keith calls EAI-oriented, in which there is basically just one activity type that “does” anything — in BPEL it’s called Invoke — meaning all process activities need to expose the same interface, such as WSDL. Stateful activities where a simple WSDL doesn’t work too well — such as human tasks — don’t fit the model, so service orchestration BPMS’s either ignore human tasks altogether or define some kind of task management service to manage the interaction. The fact that BPEL makes human tasks a second-class citizen in the process is what is motivating the BPEL4People proposal from IBM and SAP. See this for a deeper discussion of that. There are numerous other differences between workflow-style and orchestration-style offerings that have a lot more to do with their currently distinct target markets than with the fundamentals of their architecture. I might blog about that later, but not now.
Most BPMS pureplays are in the workflow-style camp, but would come out swinging if you called them that out loud. Most large middleware and enterprise app vendors are in the orchestration-style camp, although Fujitsu is not, and BEA, with the Fuego acquistion, is not any more. In general, workflow-style vendors are bitterly dismissive of BPEL, and vice versa, although most of that discussion is, in my view, ill-informed on both sides.
So… is workflow “back”? In one way I think it is, with the growing recognition among the orchestration-style vendors that the action today in the BPM market is focused around human work, not application integration. I think that’s what motivated BEA-Fuego, why IBM and SAP are now behind BPEL4People (when they could have done human tasks in BPEL from the start), and why Oracle is putting so much into its human workflow capabilities. So, yeah, workflow is back. But just don’t call it that.
May 18th, 2006
If it were anyone else but Ismael Ghalimi, I would have simply muttered “idiotic” and moved on without a second thought. But when a guy at the top of my BPM hero list declares that “nobody cares about BPM” any more, my actual reaction was dismay and mild depression. The apparent basis for Ismael’s loss of faith: the fact that Google Trends shows searches on “bpm” have declined since 2004, while searches on “soa” have gone up!
OK, to me that reasoning does seem idiotic, while to those who have moved to a more Googlicious orbit it probably carries the aura of Delphic certainty. And, to be honest, I’d probably be heartened myself if searches on “bpm” were on the upswing, even though, as Lombardi’s Jim Rudden points out, to most of the world bpm still means “beats per minute” - I searched just now and the number one listing is about “DJ culture and the electronic music lifestyle.”
In a followup piece, Ismael tries to put on a happier face by saying BPM is probably still tainted by 1980s Hammer-Champy baggage, but could be made “cooler” if, following the suggestions of Dion Hinchcliffe and Sandy Kemsley, it took on the personality of an “enterprise mashup.” Dion’s article is kind of interesting, but it’s not about processes I recognize from today’s BPM mainstream. If I were an entrepreneur or VC looking at new opportunities, I’m sure I’d see mashup-style BPM as a more attractive idea than conventional BPMS today, but not because nobody cares about BPM. (Actually, if you’re reading this and have no idea what an enterprise mashup is, you’re far more likely to be a potential BPM buyer than someone who does!)
My own experience as a regular speaker at BPM conferences and as a BPM industry analyst leads me to a different conclusion: Interest in BPM is on the rise, both among users - who still aren’t quite sure what it is - and larger middleware vendors like IBM, BEA, Oracle, and webMethods, who are now looking to BPM to serve as the business face of SOA. The smaller BPMS pureplays, generally not BPEL-based and whose technology Ismael unfairly characterizes as 1990s architecture, have I think done reasonably well in the past year. That’s not to say things couldn’t be better, but I have a different assessment and prescription for the industry.
First of all, let’s look at the technology maturity. We’re just on the threshold of doing it right! How can you be bailing now? We’ve been going for a year now on beta software and standards. BPEL 2.0? Due this summer. BPEL4People and BPEL-SPE (subprocess extension)? Probably Q4. The BPMN metamodel (BPDM from OMG) and schema? Not out yet — hopefully soon. Integrated modeling and simulation in BPMS from BEA, Oracle, and others? Still 6-12 months away. BPMN as a front end to BPEL? Just coming out now - Intalio (beta), Cordys (beta), eClarus (GA this month), IDS Scheer, Telelogic…. BPMN-BPEL roundtripping? Just beginning, about a year away.
Second, completeness of the BPMS offering. It’s a lot to put together: modeling and simulation, rich human workflow, integration middleware, business rules, BAM and process analytics… but that’s what the BPMS vendors have been doing for the last year. The platform offerings are just beginning to match the vision, and we have another year or so to go before the tools are really integrated and process analyst-friendly.
Third, marketing. As an industry, an unmitigated disaster. BPMS vendors fund conferences where the overwhelming message is that BPM is really a management discipline, has nothing to do with technology, you should be suspicious of vendors, etc. Unbelievable! I was at one such event a couple years ago, where after one such bloviating keynote by the conference chairman, Howard Smith stood up from the audience and said “if you’re not using a BPMS you’re not really doing BPM.” Brass balls! I love it — if only the industry as a whole would latch on to this message. Vendors, however, spend more energy bashing each other than speaking with one voice to educate the market about the value of BPMS.
In my experience at Brainstorm, attendees have a big interest in “how to do BPM,” documenting current processes, modeling process improvement, and cataloguing business rules, but relatively low interest in the technology of BPMS. I admit I don’t completely understand why that is. Part of it, I think, is that BPMS technology acquisition has been delegated by the business to IT, and BPMS is at heart threatening to IT. Unlike the composite app style of SOA, BPM is top-down, business-driven. Letting business analysts anywhere close to executable design? Surely you jest. BPM vendors haven’t addressed this issue at all.
Another thing they haven’t addressed: the enterprise architect problem. EA thinks in terms of stacks interconnected through open standards. A BPMS is not a stack, but an integrated suite of tools and runtime engines that only works if it all comes from one vendor. Playing well with others? It’s hard enough for BPMS to play with itself.
In spite of these woes, I’m optimistic. What Ismael and I have both described as BPM 2.0 is just being released. The marketing thing is fixable, and it costs a lot less than product development. A trade association might not be a bad idea. I’ve talked to John Mancini of AIIM about it. (Vendors - if you have any interest in this, please contact me.) Except for Gartner, there really are no major vendor-neutral IT-oriented BPM events.
Keep the faith. A lot of people still care about BPM.
May 16th, 2006
If you’re new to BPM and want to better understand the technology, I’m doing an all-day training session in San Francisco on June 28, in parallel with the Brainstorm BPM/SOA Conference. The training is sponsored by BPM Institute and counts toward their BPM certification credential. Click here for more information.
May 12th, 2006
Previous Posts
