BPMS Watch

Thoughts on BPMN 2.0

I hate to learn BPM stuff by reading it in the newspaper, but that’s what happened today when my copy of SD Times arrived in the mailbox.  A Page 1 headline blared Could BPMN 2.0 Make BPEL a Moot Point?  Humm, BPMN 2.0… draft reviewed by OMG last June with adoption expected in September.  Wow, I spent 2 full days in May at OMG Think Tank and never heard the words “BPMN 2.0″ once!  In fact, what was presented suggested that just providing BPMN a schema and metamodel, submerged under OMG’s broader BPDM effort, would be bogged down by “choreography” issues for many months at least.  Well, whatever. 

I was quoted in the article as saying that shoring up the BPMN standard would make it the de facto notation for executable process design, and even BPEL design tools would migrate to it.  And I still believe that, but with a big IF…  Which is that providing precise execution semantics is still a goal of BPMN.  That’s always been my assumption.  And not just me.  In fact, everyone who has been pushing the notion of BPMN as the real portability standard far longer than I have - Phil Gilbert, for one - has to be assuming that BPMN is at heart a design language, not just a drawing tool.  In fact, Stephen White, author/editor of BPMN 1.0, says in a presentation from December 2005:

However, BPMN is not “just a notation.” The semantics are defined in the text of the specification. A non-public draft of BPMN 1.1 metamodel exists … [but] moving forward, how are BPMN semantics aligned with other OMG process work? 

That alignment was “supposed” to be what BPMN 2.0 would be about.  But as I noted a couple days back, Frank McCabe of Fujitsu and the BPMN TC in OMG leaked that while the BPMN group thought they were defining precise process semantics, others at OMG (I inferred maybe the BPDM guys?) thought the goal was just a drawing notation for business modeling.  And at that impasse, things, sez Frank, “seem to be a bit stuck right now.”

OK, BPMN 2.0 may or may not exist, may or may not be out in September, and may or may not have anything to do with a notation for portable process design.  But it should.  The interests of the BPMS vendors (and users) may not be the same as modeling vendors.  So if OMG can’t do the right thing, I think the BPMS guys should go off and just do it themselves.  Otherwise the mantra or dream of “BPEL doesn’t matter” can’t come to pass. 

Here’s why.

In my view a key goal of all this has to be portability of the BPMN design.  Model/design in tool A and run on engine B.  I’ve written a lot about how BPEL isn’t portable, because human workflow, subprocess coordination, even data manipulation are vendor-specific.  But it’s still 100 times more portable than non-BPEL execution languages; you don’t have to start over from scratch when you switch BPMS vendors. 

The things that get in the way of unambiguously mapping BPMN to BPEL today are the freeform GOTOs and crazy merge patterns that BPMN allows.  Again, see McCabe on this.  Some of those pathological use cases, I say throw them out, don’t allow them in BPMN 2.0.  If they’re hard for a computer scientist to understand, why do you think business analysts can use them unambiguously?  They’re not even that important to BPMN anyway. 

The important and interesting part of BPMN is stuff like activity groups with intermediate events, transaction compensation, and pools representing collaborating processes (or independent subprocesses) synchronized through messages.  That’s the part that let’s you do cool things like respond to events.  And BPEL has no problem with those, because BPMN was developed with BPEL in mind! (Well, BPML actually, but practically the same thing.)  Most workflow vendors dissed BPEL because their existing process engines couldn’t do those things… they’d have to break their product to implement it.  They don’t diss BPMN, but they just ignore the cool parts.  Again, they’d have to break the product to implement them.  Kudos to Phil, who actually did break his own product to be able to implement the BPMN cool stuff.

So here’s the problem.  A BPMN where products are allowed to omit diagram semantics they don’t like can never be a portable design language.  That’s obvious.  So you need all that MUST-SUPPORT and MAY-SUPPORT kind of thing, where all the important portability considerations are in the MUST-SUPPORT column.  The basic tradeoff is ditch the GOTO and merge semantics that make algorithmic mapping to BPEL and other block languages impossible, and make the cool stuff - events, message flows, compensation and exception handlers - required for BPMN 2.0 compliance.  Nail it down with a formal metamodel and schema. (In fact, if you did the first part, XPDL 2.0 would probably work just fine — the metamodel/schema is already done.  Without the first part, XPDL 2.0 doesn’t give you portability.)

Then you can add on a methodology behind the diagram, and teach business analysts how to map processes to it… including the cool stuff. 

I have a feeling this is not the BPM 2.0 that SD Times is promising for September.  But if BPMS vendors want a standard that provides portability without commoditizing the runtime, this is the way to go, OMG or not.

3 comments July 6th, 2006

Claiming the Dinner Bet

You may recall my dinner bet with Ismael last month.  He bet I couldn’t find 3 BPM implementations that met the following criteria:

• Complex process (e.g., “more than 100 steps”)
• Integration with transactional systems through WSDL
• Human workflow through web-based interfaces
• Modeling and skeleton design done by process analysts using BPMN
• Implementation done by IT people without writing code
• No vendor support through executable design and deployment.  [He doesn’t say into production, just deployment.]

The BPMN part kind of narrows down the field, but I was pretty sure Lombardi, Cordys, BEA, and Savvion would be able to provide me 3 at least!  I haven’t heard back yet from BEA and Savvion, but Lombardi and Cordys have provided 4, which I present below.  Let’s see Ismael try to wriggle out of this one!!

From Lombardi (thank you Wayne Snell!):

• Allianz Life of Minneapolis, 2800 employees, $14B in premiums, part of the Allianz Group HQ’ed in Germany.  At Brainstorm SF, Kim Kostelecky presented on their initial foray into BPMS with Lombardi TeamWorks.  The first project was new account opening in their securities business.  Project began November 2005 and went into production March 2006.   Five additional projects are in development, with others planned.  The process is complex process is complex, meaningful, has many subprocesses, BPMN-based, and even incorporates web services for integration.  They mostly model and modify their processes without any vendor help, according to Wayne, ”unless they are resource constrained, at which we do help them occasionally.”
  
• Hasbro, Inc., $3 Billion leader in toy manufacturing.  TeamWorks is managing the B2B RFQ process for more than 100 suppliers building out Hasbro’s toys, mostly out of the Far East. This is a very large process that they totally created and manage by themselves. it has been in production for more than 4 years now. It does not use web services, but does directly connect to SAP and other transaction systems.  With BPM, Hasbro increased volume 250% with no increase in staff, and reduced cycle time from 12 days to under 2.

From Cordys (thank you Erwin Nooteboom!!):

• Bouwfonds (currently owned by ABN-AMRO bank), an international property company located in Europe.  The application is a complex business process with human workflow to support the financial consolidation, Basel II and Economic Capital reporting.  Cordys is completely SOA, service orchestration, ESB, the whole works, using BPMN for modeling and design.  The nice thing in this case is that the business not only understands process modeling but actually runs, demos, and tests the implementation!  To date there have been around 10 iterations where change requests were implemented within less than a week.
• De Amersfoortse (owned by Fortis bank), an insurance company located in Europe, uses Cordys Composite Application Framework (BPMS) in a complex solution to register new pension plan participants and adapt the plans of existing participants to conform to regulatory changes.  The system also supports a new system of internal benchmarking, taking advantage of
  Cordys BAM features to monitor business activity across the various divisions. The solution also supports management of third-party organizations such as employers through the seamless integration of business processes with web services and standards-based web portals.  Cycle time for new pension enrollment has dropped from 13 minutes to 2 minutes.

According to Cordys, both of these implementations are in production, based on top-down (business model-driven) design, and meet the other criteria in the bullets above.

Ismael, let’s talk about dinner!  I know a great place in Los Gatos…

3 comments July 6th, 2006

Does SOA Require an ESB?

Forrester’s Ken Vollmer takes issue with my inference that a BPMS truly layered on SOA must include an ESB in order to achieve the “loose coupling” promise.  He writes:

I guess the one point I would argue with you is that you seem to equate SOA with ESB’s and that is not a good way to think about it.  SOA existed way before ESB’s in the form of CORBA and DCOM technology.  So ESB’s are a newcomer to the SOA world. 

Also, ESB’s are just one alternative for achieving SOA.  The other major options are application servers and BPM Suite products.  Both of these have ESB features and much more baked into their solutions.

Just so you know that I know what I’m talking about, I cover ESB’s, BPM and SOA at Forrester.

CORBA? DCOM?  Loose coupling?  I guess I don’t know what I’m talking about!  Whatever, Jesper’s post I referenced yesterday still computes better for me.  By Ken’s definition, BEA already has all 3 ways to do SOA - an app server, BPMS, and ESB - without even putting them together! 

But I don’t think I’m the only one confused on this issue.  There is a long thread on Yahoo Groups in which some heavy hitters weigh in on the relationship of SOA to ESB, and come to no recognizable conclusion.

2 comments July 6th, 2006