Archive for July, 2006
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.
July 6th, 2006
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…
July 6th, 2006
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.
July 6th, 2006
I think I know quite a bit about BPM, and while I can’t say the same about SOA yet, I’m trying hard to learn. Still, I already know enough to say that when a BPMS vendor talks about how his product is based on SOA, he’s not talking about the same SOA that the real SOA guys are selling. Including things like loose coupling, supposedly a foundational SOA concept. Nobody talks about it, it blows my mind! And 99.9% of what is written about the intersection of BPM and SOA is either irrelevant or plain incorrect.
So out of the blue I stumble on a new blog from Jesper Joergensen, whom I know as the BEA Aqualogic BPM marketing guy, that just nails it… in a way that all those so-called SOA thought leaders have never been able to do. Here it is:
BPM suites (like BEA’s AquaLogic BPM Suite) can enable easy access to applications and databases using various techniques, service-oriented or not. The implementation … is derived from and dependent on the underlying system interfaces and thus, any change to underlying databases and applications will require changes to the business process.
This is fine if the organization and IT environment are reasonable small and the same group of people control all systems including the BPM suite. It also works well if the underlying systems do not change at all. But if the BPM suite is deployed by one group and it consumes services from systems in another group, then it can quickly become hard to coordinate and manage change within each group. This is the classical problem that SOA was meant to address and thus, it applies to the deployment of a BPM suite as it does to everything else.
If BPM is deployed as part of SOA, it means that when a business process connects to underlying systems, it connects to proxy services provided by an enterprise service bus that hides the complexity of the underlying applications and databases.
At last! A concrete statement on the subject that makes sense! It’s even the way I thought it was supposed to work. He goes on to list the benefits of this approach:
- Easier for IT to expose coarse-grained services this way, and easier for business people to understand and orchestrate them.
- Process “more robust” because decoupled from changes in the backend systems.
- Allows service governance/maintenance outside of the BPMS. He implies (but doesn’t outright say) that IT owns the services, and business owns the processes.
- Better discovery through enterprise registry.
He’s very careful to say BPM doesn’t need this until it reaches a certain level of “maturity” (i.e. widescale adoption) within the enterprise. Jesper, thanks for a great post on a subject nobody else seems to understand! Dude, you’re on my blogroll.
But taking it another step… What would a BPMS design tool that worked this way look like? Seems to me that the orchestration should reference those implementation-independent service interfaces using some canonical data model, leaving all those messy service endpoint mappings to the ESB and service architects, instead of introspecting the endpoints directly the way all BPMS’s (including Fuego 5.5, I mean Aqualogic BPM) do today. Jesper, does that make sense to you?
July 5th, 2006
As if we needed more evidence that BPM and SOA are uneasy allies, one of Steve Jones’s SOA Anti-Patterns, widely praised in the blogs for their hilarious wit and insight, seems to me a perfect example of how some architects still view BPM’s top-down approach as worst practice, not best. The “percolating process” anti-pattern is described this way:
An organisation’s “Services” come in two basic types, firstly end-to-end processes that co-ordinate lots of individual steps, and secondly a large set of fine grained services that represent individual steps. Any hierarchy or structure is solely from the basis of process. The fine grained services proliferate and become difficult to manage while the large business process elements become difficult or impossible to change.
The cause of this sad situation? Steve explains it this way:
The organisation has decided to map the processes and end to end and in detail; the work has created a series of grand “end to end” process models that are categorised by their large number of steps and the lack of sub-processes that they use… The problem is that the valid business services have not been identified and thus the process maps have been created without a proper service structure…
The challenge here is that the organisation has not started with clarity on its services and hence has created a Process Oriented Architecture. Retrofitting services into such an environment creates a sub-optimal system that is liable to have all the issues of other process based systems, such as COBOL.
I’ve never heard the BPMS approach described in quite this way before. The beef seems to be that integrating systems top-down from the process perspective, using BPMS’s point-click introspect-and-catalog paradigm, leads to unwieldy COBOL-like monstrosities. If the business would just wait until the architects properly factored the universe into right-sized reusable chunks, life would be much better. I think Steve has unwittingly discovered the business-IT non-alignment anti-pattern.
Update: Phil Ayres, whose blog Improving New Account Opening suggests he is a serious been-there-done-that guy in BPM, presents a positive take on the BPM anti-pattern. He maps it to his own real or imagined past experience in a way that I can best sum up in one sentence: The business guys doing the process modeling were idiots (led by the infamous ‘consultant’). OK, I’m sure that’s not such a rare occurrence, but what I still don’t get is Steve Jones’s anti-anti-pattern, which is to have IT figure out the “services architecture” before you put the idiots in the room. I’d like to offer a different anti-anti-pattern, coming from a BPM perspective, which is to provide a methodology behind the modeling - and train the business guys how to use it - that helps define “coarse-grained units of reuse” as determined by the business. Hey Steve, how’d you like to become a “consultant”?
July 4th, 2006
David Chappell, who long ago took the position that BPEL isn’t portable so it doesn’t matter, now amplifies it with the conclusion that portability should be at the design language level, not the execution language, and the best candidate for that is BPMN. I’ve come to the same conclusion myself, on both points. John Evdemon, BPEL TC co-chair, sealed point #1for me at Think Tank when he said portability is not, and never was, a goal of BPEL. A look at Cordys, Lombardi, and Intalio offerings — all of which use BPMN as a notation for executable design — convinced me of point #2.But the goals of a pure modeling notation and an executable design notation are not one and the same. So what is BPMN anyway? And can it simultaneously serve two masters?
I believe in its earliest beginnings, BPMN was conceived as a Third-Wavish business-oriented executable design notation upon which additional implementation detail could be layered - the design surface for BPM based on service orchestration. But after BPEL left BPMI in ruins, the BPMN banner was picked up by the analytical modeling vendors, who actually got the spec out the door. It was around that time that Gartner blessed us with the BPM Suite concept, in which modeling and simulation analysis were seen as distinct from, but exporting directly into, executable process design.
This odd history probably provides much of the reason behind both BPMN’s quirky gaps — no properties to hold the simulation parameters used by virtually all business process analysis tools, no XML schema to store the diagram, and most crippling of all, no methodology behind the diagram – and its sophisticated design features, like intermediate events, transaction compensation, and collaborating processes synchronized through messages — features often viewed as “too technical” to be understood by the folks actually drawing the process models, and which most simulation engines have no idea how to handle.
I convinced myself, and tried to convince BPMS Watch readers, that BPMN would eventually outgrow its personality disorder as soon as it got a schema and precise semantics - a metamodel! - either from OMG’s BPDM (the “official” one) or WfMC’s XPDL 2.0 (the “pirate” one). But now I see a post from Francis McCabe of Fujitsu Labs and the “BPMN team” at OMG that sounds like bad news.
There is something of a fracas about the relationship between BPMN and BPDM: is BPMN ‘only’ a notation or does it have some semantics. This whole thing was news to the BPMN team as they (including me) were blithely assuming that we were trying to define a language. For us, the major issues seem to revolve around the execution semantics of a BPMN diagram; for others, it is only a diagram notation and we needn’t worry our little heads about execution.
Hmmm. Sounds familiar. He concludes:
The BPMN effort does seem to be a bit stuck right now. Personally, I think that the issue is that we are trying to have it both ways: have an easily understood execution semantics and allow the business modeler to do whatever …
OMG’s natural constituency is enterprise architects and business analysts, i.e. the modeling side of the equation, but BPMS vendors have more to gain by making BPMN a standard notation - with rich and precise semantics - for executable process design. We’ll see who carries the day. More thoughts on this later…
July 3rd, 2006
Next Posts
