I know many of you are planning to put learning BPMN at the top of your 2010 resolutions list. Well, if you’re not, you should be! Travel is hard these days, but you’re in luck. I’m going to be offering my BPMN training in a virtual classroom format – live, interactive, delivered over the Internet, starting in January. The first public class will be January 25-28, 2010. That’s Monday through Thursday, 4 hours a day. Right now I’m planning 8am-noon Pacific time (11am-3pm ET), but that’s not final.
It’s going to have everything you get in the live BPMessentials classroom version, same course content, including hands-on in-class exercises using Process Modeler for Visio from itp commerce and post-class certification exercises with individualized feedback. It is based on the Level 1 and Level 2 methodology from my book BPMN Method and Style and the new BPMN 2.0 standard.
The delivery platform is iLinc, which is similar to Acrobat Connect but I think with some better e-learning features. Students will be able to ask questions via audio or chat. I can “glimpse” at student desktops to help out with the in-class exercises, or even share student desktops with the whole class. And the whole session can be recorded for later playback. I’m really excited about it.
You can sign up by credit card or PO — I’m still working to set up the payment processor account. If you’re interested, contact me to discuss pricing and other details. I’ll be doing private classes (best for 10 or more from one company) as well as the public.
Tags: BPMN, bpmn 2.0, bpmn training
I should have known that disputing Michael Rowley’s contention that mapping BPMN to BPEL was “simpler” than a straight BPMN 2.0 solution would invite a further response. Two, actually, one from Michael and another from Frank Leymann. Hmmm. In a room with those two, I’m at best the third smartest guy. But unlike the “stacker-bashing” flame wars of 2008, their points are well stated and sort of illuminating. Anyway I can’t resist taking another shot.
I tried to let Michael off the hook the first time by suggesting maybe he meant a hybrid BPMN-BPEL solution was simpler for engine vendors. But no, he says he means simpler for process modelers! OK, I’m thinking of three products: Oracle’s BPA Suite (BPMN) mapped to BPEL Designer through their Blueprint intermediary notation. No way that’s simpler. I think Oracle would be the first to admit it, and Oracle BPM 11gR1 will put the nail in that one. How about IBM’s WebSphere Modeler’s quasi-BPMN mode with “direct deploy”, i.e. avoiding a stop in WID’s BPEL editor? Closer to “simple” I guess, but the direct deploy is just to a test environment that outputs design bugs to be fixed in WID. I can hear the stacker-bashing competitors snickering from here: that’s simple? OK how about Michael’s own ActiveVOS? I just saw a beta demo a couple months back — maybe it’s changed — but that was a BPMN 2.0 diagram with the node names changed to BPEL. Now why would you want to do that? His argument would have a lot more power if he just kept the BPMN names and hid the BPEL execution language under the covers. You only keep the BPEL nomenclature if the diagram is secondary to the XML, the BPEL language. So I guess he means this is “simpler” to BPEL developers, not mainstream process modelers. OK, I’ll concede that point.
Both Michael and Frank take me to task for saying that BPEL is block oriented while BPMN is graph oriented. Yes we know BPEL does support the flow/link construct in addition to the more frequently used sequence block construct, but it still has those restrictions – no freeform loopbacks, no “interleaving.” Try explaining what interleaved topologies means to a typical BPMN modeler. He presents a BPMN diagram that would probably give interleaving errors in my BPMN tool if I tried to export to BPEL, but it works in ActiveVOS because they use eClarus’s more-intelligent-than-the-others’ BPEL mapping algorithms. But even there Michael admits that some diagrams still require a workaround. Again, I think it fails the “simplicity” test.
Frank Leymann’s post is more interesting, I think. Frank was one of IBM’s original BPM gurus. He jumps in to defend BPEL as today’s BPM runtime standard, says I’m flat wrong to deny that. I guess among all the BPM runtime standards BPEL is the most widely adopted, I’ll agree with that. But among all BPMS platforms? BPEL is the runtime of just a few. Most BPMSs today have proprietary runtimes. That’s a plain fact.
But here is where Frank gets to the heart of the BPMN-BPEL issue:
We are faced with the following problem: How can we bridge the gap between BPEL (an execution language with rigor operational semantics) and BPMN (a visual language with informal semantics)…. One possible way to solve this problem is to standardize a visual representation for BPEL… But the problem is that BPMN contains quite a number of constructs that… have no direct correspondence in BPEL. Thus, BPEL extensions would be needed to support [them]… but extending BPEL is time consuming (see the recent BPEL4People extensions) while BPMN users want to see a solution “soon”.
The other way to solve the problem – the way that has been taken – is to move BPMN forward… to make transforming BPMN process models to BPEL much easier. The fundamental enhancements of BPMN 2.0 [now] enable this….
From a BPEL perspective the current situation is as follows: A subset of BPMN 2.0 is “isomorphic” to BPEL. As a consequence, BPMN 2.0 encompasses a visual modeling language for BPEL – this subset can be naturally transformed to BPEL and executed in a BPEL engine. From an architectural point of view, a tool supporting this BPMN subset is a layer on top of BPEL engines…. From a BPMN 2.0 perspective,… BPMN 2.0 is a process modeling language with an operational semantics [influenced] by BPEL… Thus, it is now possible to build an engine that directly supports BPMN 2.0 – without the intermediate step of generating BPEL.
What he fails to explain is that the subset of BPMN that is isomorphic to BPEL is not a subset of BPMN elements or shapes in the diagram palette. It’s a subset of BPMN diagram topologies. We’re back to that same problem of explaining interleaved loops to a business process analyst. A tool that prevents modelers from drawing the problem patterns is probably going to enforce some kind of block structure, like the BPEL drawing tools do today. Alternatively, they can let the modeler have at it and then give the BPEL validation errors at the end.
The answer is just so obvious to me… and I think to Frank as well. He even says it right there: “It is possible to build an engine that directly supports BPMN 2.0 without the intermediate step of generating BPEL.” Duh. Oracle and IBM, two of the biggest BPEL vendors, essentially designed BPMN 2.0 with that specific intention. I’ll grant the obvious: Neither Oracle BPM 11g or IBM BPM v7 are shipping yet. But when they are, it’s hard to see BPEL as the simpler path forward.
Active Endpoints’ Alex Neihaus points me to a post by his CTO Michael Rowley entitled “Which is simpler: BPMN or BPEL?” I’m groaning before I even read it, because I know where Michael is headed. Right off a cliff, in my view.
Their product ActiveVOS is one of the first to support BPMN 2.0 diagrams, but they use it to create BPEL. Such a use was actually anticipated by the developers of BPMN 2.0 – IBM, Oracle, and SAP – all of which have been shipping BPEL engines for some time. So that’s not such a big deal, and Michael doesn’t really need to defend doing it. Saying it’s a “simpler” way to go than executable BPMN 2.0, however, is a stretch.
Simpler for whom? When you sort it all out, he’s actually saying BPEL is simpler for an engine vendor because it doesn’t have overlapping or alternative constructs like BPMN does. No one would argue with that, but who cares? No engine vendor is going to support every possible BPMN 2.0 element and attribute called out in the metamodel. And I’m not saying just in the first release. Not ever. In that sense, BPMN 2.0 is not a self-contained execution language like BPEL is.
However, for process modelers, and even for executable process designers, there’s no way BPEL execution makes BPMN modeling “simpler.” That’s because the subset of BPMN supported with BPEL execution excludes the very features that make BPMN attractive to business-oriented modelers in the first place: things like freeform looping back to a previous step in the flow. BPEL is inherently block oriented, like a computer program, while BPMN is inherently graph oriented, like a flowchart.
In the BPEL mapping section of BPMN 2.0, the spec describes “basic mapping” of block-oriented BPMN. Then follows a section on “extended mapping” where the BPMN does not conform to BPEL’s natural block structure. The spec essentially says here engine vendors are on their own, noting “in many cases there is no preferred single mapping of a particular block, but rather, multiple WS-BPEL patterns are possible to map that block to.”
Freeform loopbacks are a prime example. They typically describe what BPEL calls “interleaved loop” structures. To map these to BPEL, the BPMN spec says the following:
The looping section of the Process, where the loops first merge back (upstream) into the flow until all paths have merged back to Normal Flow, shall be separated from the main WSBPEL process into a set of derived processes that will spawn each other until all the looping conditions are satisfied.The section of the process that is removed will be replaced by a (one-way) invoke to spawn the process, followed by a receive to accept the message that the looping sections have completed and the main process can continue.
In other words, just to support freeform routing in the diagram, a single BPMN process must be split into multiple BPEL processes that signal to each other through messages. Is this simpler? No I don’t think so.
Over the past year, engineers at Oracle and IBM have been making changes to their process engines precisely to break out of the BPEL box, not just to better handle BPMN constructs like OR gateways, boundary events, and sequence flow loopbacks, but ad-hoc behavior as well. If BPEL were adequate to execute processes the way business wants to model them, it would have become the BPM runtime standard. It hasn’t.
Lombardi’s Teamworks 7 adds a wealth of features tosupport massive reuse of process artifacts across multiple projects in various stages of development and maintenance. My latest BPMS Report takes a close look at Lombardi’s brand new offering.
Two weeks ago Appian launched version 6 of its BPMS, along with a rebooted online collaboration network called Appian FORUM and a suite of professional services offerings. Appian plays in the human-centric business-empowered end of the BPMS vendor landscape along with Lombardi and Savvion. With all the vendors now claiming ease of use, Appian’s new claim is “fastest,” meaning shortest cycle time from concept to production. It’s a distinction without much of a difference, but Appian believes that its tools require less scripting and technical futzing than its natural competitors. I think it would be fair to say that Appian provides more of the solution building blocks already preconfigured, so in that sense it could be faster to deploy.
Like Lombardi in Teamworks 7, Appian 6 is emphasizing new capabilities that enable “massive reuse”, design team collaboration, and one-click deployment. This is natural as the human-centric end of the BPMS market evolves from isolated projects to “enterprise” BPM programs. Of all the human-centric vendors, Appian seems most at ease with complete business empowerment.
All of Appian’s design and runtime administration tools are browser-based, and Appian 6 now supports import, export, and publishing of all application components – flows, forms, rules, etc. – in one click. In order to support today’s multi-application BPM environments, Appian 6 has also adapted the portal to provide tab-selectable application-specific views.
Appian FORUM appears to be the successor to the promised online “marketplace” for Appian Anywhere, the company’s cloud-based offering. Available to customers of both Appian Enterprise and Appian Anywhere, the new FORUM provides a library of downloadable application templates, process templates, and reusable tasks called Smart Services, developed by customers, partners, and Appian itself. Templates include Employee Onboarding, Spend Request, and IT Service Management. Appian-developed templates are free, while partner-developed are fee-based.
Appian’s new professional services framework is built around a its own BPM maturity model that aims to move customer self-sufficiency from the isolated project level to the enterprise program level. Like Lombardi’s similar offering, it takes a fairly narrow product-centric approach to “BPM in the large.” At the same time, Appian appears to be expanding its relationship with Mega, a major player in the BPA space. That could help to enlarge Appian’s view of the BPM market to include the majority of “BPM” users that are still at the modeling and analysis stage and not ready to automate anything just yet.
[My August column on BPMInstitute.org]
BPMS Watch readers know I am a big fan of OMG’s Business Process Modeling Notation (BPMN) 2.0, which has passed its first approval hurdle and is now in the Finalization Task Force stage. A major reason is that for the first time, BPMN has standardized the schema for XML interchange of process models. That means you will be able to create a BPMN model in one tool with confidence you can open it in a different tool. I think that’s what every user expects from a “standard,” but BPMN never had it until v2.0. But there is one part of the standard that the team messed up big time: Diagram Interchange (DI), meaning the graphical layout of the shapes and symbols.
Prior to BPMN 2.0, the de facto interchange format for BPMN models has been XPDL, an existing standard from the Workflow Management Coalition (WfMC) modified to handle BPMN. Each node in XPDL represents both an element in the BPMN semantic model and its corresponding visual element – including position, size, and other graphical details – in the diagram. But BPMN 2.0 separates the semantic model from its diagrammatic representation. That’s in a separate model – the DI model – that sits alongside the semantic model in the XML interchange document.
That’s actually a good thing. It allows multiple diagrams (views, pages, etc.) to represent the same semantic element in different ways, such as different levels of detail. For example, if you have a hierarchical diagram of a complex process model, with a top-level view showing the entire process at very coarse-grained detail and many child-level views showing increasing levels of detail, BPMN 2.0 maintains a single consistent semantic model for the process, referenced by all the various views. That is good for maintaining the integrity of the model. In contrast, with XPDL each view of a particular model element represents a different XML element in the export, so if a subprocess or pool appears on multiple pages of the model, it is up to the tool – or the modeler – to maintain consistency between their definitions.
But OMG did not want to make DI, the graphical model, BPMN-specific. They wanted it to support other types of diagrams as well, particularly UML, something completely different but also owned by OMG. And they didn’t want to define the format in an XML schema document (XSD), the universal standard used by XML tools, SOA, and BPM. They wanted to define it in XMI (XML Model Interchange), OMG’s own standard for interchanging UML models. The problem with DI as specified in the BPMN 2.0 draft is that BPMN-specific diagram structure is not defined in a format usable by XML tools. Instead, it is defined in a separate “library,” which you could think of as a cheat sheet off to the side to remind you of the particular attributes allowed or required for BPMN-specific shapes.
If you think that is a strange way to define what is still nominally a notation (i.e. graphics) standard, you are not alone.
The problem is not that it is impossible to define a BPMN 2.0 model using the graphics as specified by DI, just that it will be too difficult to do so in practice. Unless you can represent DI as a true BPMN-specific schema, tool implementers cannot use the rich array of XML tools available to validate, transform, and test their XML exports. Graphical model interchange is difficult enough in XPDL, where the graphics come pre-attached to their semantic elements. A few BPMN 1.x tool vendors – ITP Commerce, Fujitsu, Global360, eClarus, TIBCO, BizAGI, and Lombardi – have achieved some level of BPMN interoperability using XPDL 2.1, but it requires tweaks to the XPDL using XSLT, the standard language for XML transformation. It would be extremely difficult to create those tweaks with DI – and they no doubt will still be needed with BPMN 2.0 – since tools that create, execute, and debug XSLT all need a proper schema. OMG needs to try again on the DI part.
It is no great feat to turn DI into a proper BPMN-specific schema. I did it myself (BpmnDi.xsd) in a few hours. I also created an XSLT that maps XPDL 2.1 to BPMN 2.0, using BpmnDi as the graphics model. If you are interested in such things, you can download from http://www.bpmnstyle.com on the Tools menu page. If your BPMN tool outputs XPDL 2.1, you can try it out on your own models. [So far only the XPDL "standard"-level conformance is supported.] If you are interested in interoperability between BPMN tools, please make your sentiments known to OMG. These implementation “details” are what the FTF phase is all about.
Tags: BPMN, bpmn 2.0, diagram interchange
I just finished a white paper on case management for Global 360, whose Case360 product comes the closest to my own view of what case management is all about. Click here to download the report. If you are interested in that topic, you might want to subscribe to my BPMN Case Management site, www.bpmncase.com.
Tags: case management
I wrote previously about Lombardi’s efforts to open up Blueprint using XPDL 2.1. A BPMN diagram created in Blueprint can be exported as XPDL and imported into itp commerce Process Modeler for Visio, the tool I use in my BPMessentials training. This is great! Even though it is a standard, BPMN is rarely portable between tools, something that baffles users. But I noticed the lanes did not import properly. My investigation into why has increased my understanding of the portability problem.
A long time ago, when we wasted time talking about the relative merits of BPEL vs XPDL, Keith Swenson used to go on and on about the need to port the diagram graphics in addition to the semantic model. (BPEL has no graphics model, but today that seems almost besides the point.) I argued at the time that graphics portability was hopeless anyway, since each tool uses different graphics libraries, fonts, connection points, etc. You could never get the graphics to port exactly and remain editable.
The truth, as it turns out, is something in between. Portable BPMN graphics is really an approximation of the layout, capturing the arrangement of nodes in swimlanes and connector bendpoints, but not necessarily fonts, precise connection points, etc. Those are still determined by each tool. This is more or less in line with user expectations, and XPDL can deliver on this… in principle.
Upon further investigation of the Blueprint-ITP issue, I found out that ITP ignores the graphics info in the Blueprint XPDL and reconstructs the diagram from the semantic model (sans lanes). The engineer said it was too complicated to explain, as he headed off for vacation. So I had to figure it out on my own.
Turns out there are several related issues. One is coordinate systems. “Standard” XPDL measures node xy coordinates as position of the top left corner relative to the top left corner of the page. Yes, XPDL expects diagrams to have pages, but they are not required. Blueprint has no pages.
Second is scale. There is a PixelsPerMillimeter scale attribute in XPDL, but tools can omit or ignore it. Scale turns out to be important because most of the graphics in the diagram are fixed in size.
Third is standardization in XPDL. The spec says, per Robert Shapiro, my XPDL guru:
X and Y coordinates of node’s upper left corner (bounding box). Tool specific and depends on ToolId. Usual implementation based on upper left corner of page being (0, 0) and all coordinates >= 0.
The operative words here are tool-specific and depends on ToolId. You can’t have real portability when key elements are tool-specific. It’s more like EDI: you can integrate, but it takes side agreements to do so.
In the end, it seems that ITP only imports the graphics when it recognizes its own ToolId. OK, I can forge that. And it measures coordinates of node centers relative to bottom left corner of page. OK, I can do the math. And it uses the PageId attribute. That’s a bit harder, since Blueprint is pageless. When it constructs the graphics from the imported Blueprint XPDL, ITP creates pages for the expanded subprocesses. This is the hierarchical style I teach in BPMessentials. I’ll figure that out somehow…
I set about writing an XSLT transform that would map the Blueprint export XPDL into something ITP can import, including graphics. I played around to arrive at a scale factor that made the imports look OK. If I had more time, maybe I could figure out how to create multi-page hierarchical models in the XSLT, but to start I just put everything in one page — which is what the Blueprint export actually provides.
Here are the results. This is a fragment of the sample Hiring process on the Blueprint site:
Here is how it looks imported from the raw XPDL. Note the lanes have been lost and pages for the subprocesses have been added.
Here is the import after my XSLT transformation:
The lanes are back! Actually, I had to do two things first in Visio. Send the expanded subprocess shapes to the back layer in order to see the connectors, and change the page size (fixed at A4 in the XSLT) to fit the drawing. Note the connectors do not touch the activities in exactly the same place as in the Blueprint original, but the general layout is preserved.
And here’s a cool thing you can do in the ITP tool: convert the expanded-inline subprocesses into collapsed subprocesses with the expansion on another page of the diagram, as in the hierarchical style. Here is what that looks like:
I’m not much of a programmer, but it seems to work. If you are interested in the xslt, you can download it here. I used the xsl:function tag, so it requires an XSLT 2.0 engine, such as XMLSpy (the engine is free from Altova). It probably could be rewritten in XSLT 1.0 without that.
Tags: BPMN, diagram portability, xpdl
Well, sort of… By that I mean you can export a BPMN diagram from your Blueprint account to your desktop and import it into another BPMN tool, like Process Modeler for Visio, the tool I use in my BPMessentials training, or BizAGI (see screenshot).
After months of my nagging Lombardi about the need for this, it popped up like a surprise gift in the July Blueprint release. You might think they always had this. Not really. Notwithstanding Forrester’s swooning over Blueprint’s BPDM export feature, that never really worked. The one that does work is based on XPDL 2.1, which has emerged as the interchange format of choice for BPMN 1.x. Robert Shapiro and I are working on the portability conformance levels in XPDL 2.2, which supports BPMN 2.0, and we welcome Lombardi’s commitment to BPMN model portability between tools.
There is a small problem getting lanes to interchange properly with Process Modeler for Visio. I am trying to get ITP to debug that for me and then I will post the minor xslt tweak needed to go between Blueprint and Process Modeler for Visio. This is key for me as I am committed to BPMN training on both tool platforms. Kudos to Lombardi for making it happen.
I have taken Phil Gilbert’s suggestion to heart and stood up a new website BPMN Case Management where we can explore the possibilities for a case management modeling notation closely tied to BPMN… without re-fighting the whole BPMN war from the very beginning, as OMG seems inclined to do. Once the DNS sets up, it will be www.bpmncase.com, but for now you can reach it at www.brsilver.com/bpmncase. I’ve invited a bunch of people that I know, and who have expressed an interest in the topic, to be “authors” – allowed to post – and I expect to hear from a lot more people that I don’t know requesting same. There’s not much there yet… I just registered the name a couple hours ago… but if you’re interested, maybe subscribe to the feed and something good will come out of it.
Tags: BPMN, case management
Recent Comments