Today Robert Shapiro of XPDL 2.x fame, also a member of the BPMN 2.0 Finalization Task Force in OMG, delivered an update on progress toward completing both XPDL 2.2 and BPMN 2.0. Here is the link to the unedited replay. Also, Sandy Kemsley does her usual fine job of summarizing the high points here.
I would just add a couple points to the discussion. The first regards an explicit sorting of BPMN 2.0 shapes and symbols into subclasses for the purpose of enabling tool interoperability. I tried hard to get this into the draft last May but IBM, Oracle, and SAP didn’t want to commit to anything specific at that time regarding their initial “BPMN 2.0″-branded offerings. Apparently they are feeling more comfortable about it now, as Robert believes there is a chance this could make the final draft.
Even though BPMN defines only 3 basic flow elements – activity, gateway, and event – counting all the variants defined by border style, icons inside, markers, and diagram placement means there are dozens and dozens of semantically distinct shapes. No tool vendor with an associated BPMN engine, even a simulation engine, is going to support every single one. And that’s just the part of BPMN above the waterline. Beneath each element are countless sub-elements and attributes required to define executable detail.
So if you create a model in tool A and expect to import it to tool B, both of those tools have to support a common subset of elements. That’s what the subclasses are all about. Here is my view of them. The Simple class is setting the bar essentially at floor level. It is meant purely as a lowest common denominator. If a tool cannot support these shapes and serialize to BPMN 2.0 it should not be allowed to call itself a BPMN 2.0 tool, period. The Descriptive class corresponds to the Level 1 palette of my book BPMN Method and Style. It reflects what I believe are the shapes and symbols that should be understood by any business user who wants to read or write BPMN effectively. It is a challenge for tool vendors because it includes collaboration (pools, message flows, message start and end events). I hope those things stay in.
What used to be called the Analytical class, corresponding to my Level 2 “core” palette, got renamed DODAF in Robert’s preso. It is very close to the element set standardized by Michael zur Muehlen in working with the DODAF people. I agree with Sandy that calling this BPMN class DODAF is maybe not the best for an international standard, but realistically it’s all about user buy-in, and DODAF means a lot there. I suspect if OMG goes for it they will change the name. This class includes the most commonly used intermediate events – Message, Timer, Error – plus a few more – Escalation, Signal, Conditional. And additional gateway types, iteration markers, and other things. It sets the bar a bit high for tool vendors, but on the other hand, elements outside of the Analytical/DODAF class are unimportant, almost never used, and stand very little chance of ever being interoperable between tools.
OMG has studiously avoided any actual test of compliance for BPMN 2.0, so getting these subclasses into the final spec would be a major leap. Yes it’s true that most users simply assume that a “standard” implies tool interoperability, but that has been mostly a fake objective in this case. I think there is hope this time. I’ve seen a beta of IBM’s Compass BPMN editor and it is very close to the Descriptive level, maybe a bit more. And I expect Oracle will have something similar.
But you have to understand that these standards are inherently very conservative, and always favor tool vendor “adoption” – even in a proprietary way – over constraints assuring interoperability. That’s why it’s important for OMG to hear from users telling them they demand some level of practical tool interoperability, such as this subclass proposal. If you agree, please email the BPMN group and tell them. The address is bpmn2-ftf@omg.org.
The second point concerns Robert’s comments on the graphics information in BPMN. I wrote about this previously (The DI Mess), and in the end even the BPMN team managers in OMG admitted that what they put forward in the draft spec was unworkable. The new directives were to make the graphics interchange model a real BPMN-specific xsd and eliminate redundancy with the associated semantic model. Scott Schanel and I put forward a BPMNDI.xsd proposal that does this, and Robert’s preso says that the official OMG effort here carries forward our ideas. Having seen a draft of it, I would dispute that — it’s still too much like the old one for my taste — but the good news is that there seems to be forward movement at last on it. More good news is that Denis Gagne is driving the xsd side there (still the tail on the UML dog unfortunately), and since he is launching the Process Incubator tool referenced by Robert – mappings between Visio, BPMN2.0, and XPDL 2.2 representations – he will ultimately force himself to see which parts of BPMNDI are practical in real tools. That’s always helpful.
There is a lot still to do on BPMN 2.0 before the final vote, but all of it “under the covers” so to speak. Nothing significant in the notation or semantics is going to change.
Tags: bpmn 2.0, bpmn interoperability, omg, xpdl
Thanks to all of you who took my BPMN Self-Test. BPMN, today accepted as the universal process modeling standard, is outwardly familiar — it looks like traditional swimlane flowcharts — but few people really know how to use it effectively. That’s what I try to teach in my book and the BPMessentials training. The self-test examines some of those parts of BPMN that are extremely useful in modeling everyday scenarios but which are not part of the traditional flowcharter’s existing knowledge. If you haven’t taken the test yet, why don’t you do it right now? Just click here. Then come back when you’re done and check out the answers. If you have taken it and would like to see my explanation of the answers, read on. Read the rest of this entry »
Tags: BPMN, bpmn 2.0, bpmn method and style, bpmn self-test, bpmn training
There has been a good response to the BPMN self-test. The scores have been lower than I expected, but I have gotten nice feedback from the answer sheet and expanations I send out afterward. It’s fair to say that while the diagram patterns in question describe common business scenarios, they probably represent the part of BPMN that goes beyond traditional flowcharting. BPMN’s appeal is its basic familiarity to flowcharters, but it offers a lot more. This is not technical IT stuff. It’s business-oriented, just unfamiliar to many process modelers, even experienced ones. If you haven’t taken the test yet, check it out.
Tags: BPMN, bpmn 2.0, bpmn self-test, process modeling
[This post describes an approach to integrating the Decsion model of von Halle and Goldberg with process modeling in BPMN. For Part 1, click here.]
Before describing the integration of decision modeling with BPMN, I need to summarize the Decision Model approach described by Barb von Halle and Larry Goldberg in their excellent book. I can’t do it justice in a simple post; if you want to find out more, just get the book.
The Decision Model
Although the book does not use the term, I would call it a metamodel for business decisions, i.e., a description of the relationships between specific decision components and the principles governing how they can be combined. It does not specify a rule language, and is in fact language-independent. Business-oriented decision models, which are the focus of the book, use a structured form of natural language to define business rules. Those are easily mapped to IT-maintained data models and engine-specific rule languages for execution.
Just as the relational model imposes constraints on the organization of datasets, the Decision Model imposes constraints on the organization of rulesets. A business decision is defined as “a conclusion that a business arrives at through business logic and which the business is interested in managing.” The Decision Model provides the framework for structuring that business logic. It makes most sense to use the Decision Model and its associated methodology when the decision has high busness value or the decision logic is subject to change, or is complex, or is reused in multiple business processes. In those situations, the Decision Model’s advantages in management and governance justify the small additional burden its structure imposes. It is most useful for organizations like financial services or insurance, where the number of decisions that must be simultaneously maintained and tweaked can run into the hundreds or thousands. Read the rest of this entry »
Tags: BPMN, bpmn 2.0, business rules, decision model
I am a little surprised at the scores on my BPMN self-test. Ten questions, four diagrams each, one of which is the correct answer. The scenarios are typical from real-world processes, and most of the patterns should be used routinely in process models. A couple of questions are a little hard, but I would have thought that more people understood the basic usage of timer, message, and error events, event gateways, loop vs MI activities, etc. The highest score so far is 80 (out of 100). (You can take the test more than once but I’m only tabulating the first one.) Here is the histogram of scores so far:
[Updated Jan 5, 2010, 8:47am PT]
Oh well… The goal was to get people to think about training. I guess it should. Click here to take the test.
Tags: BPMN, bpmn 2.0, bpmn self-test, bpmn training
I saw a link a couple days ago for a BPMN self-test, and thought I’d try it out. The test, available to anyone, is “part of a research project by Humboldt-Universität zu Berlin and Technische Universiteit Eindhoven on the understanding of BPMN Process Models.” It’s harmless I suppose, but – to my way of thinking, anyway – a bit off target, and in typical academic fashion. It is composed of thirty-odd true-false questions each concerning the behavior described by a particular diagram. I don’t exaggerate by saying the exercise is 50% a test of one’s knowledge of the difference between XOR and AND gateways and 50% a test of one’s ability to follow a maze of twisty-turny criss-crossing sequence flows interconnecting 50 or more nodes in a meaningless diagram. (Although my 4-year old granddaughter Maia is pretty good at mazes, these would be over her head, but I doubt she would find the BPMN semantics challenging.)
I thought I would get them all right, but I missed two (tracing through the maze is not so easy). That put me 99th out of 283 who had taken the test so far, which says a lot by itself.
Anyway, while the test seems totally misdirected as to what is important to know about BPMN, it is a quite clever marketing tool for BPMN training. There are hints in that direction on the self-test site, although, as I say, I don’t think the test itself would motivate the kind of business process analysts and architects I encounter on this side of the Atlantic.
So I decided to create my own BPMN self-test, more reflective of the understanding I think is important. It’s only 10 multiple choice questions, each containing four diagrams, one of which is the correct answer. I would not be embarrassed to call it marketing for my book and training, and it’s helping me get acquainted with the capabilities of the iLinc environment I am using for my virtual classroom offering.
Here’s the link to my BPMN self-test. Unlike the other one, you have to register for mine – basically name, company/title, and email. It sticks to the core Level 1 and Level 2 palette, but it is reasonably challenging if you don’t know BPMN well.
Try them both, and tell me what you think.
Tags: BPMN, bpmn 2.0, bpmn self-test, bpmn training
IBM left a voicemail at 4:58am today about a 6am briefing to announce the acquisition of Lombardi. Thanks for the heads up, guys! Sandy Kemsley does her usual great job with the briefing play-by-play, which I would describe as predictably unrevealing, except for the fact that Lombardi will be brought into WebSphere/AIM instead of being hung out to dry on its own like FileNet. So I guess we’re down to the punditry…
My take is this was bound to happen. I’m sure Lombardi has rebuffed any number of BPM suitors over the years, insisting on an eventual IPO. But in today’s market that exit must have looked farther away than ever, so Phil Gilbert and company could forget all about the past Evil Empire bashing and just take the money (amount undisclosed).
The functional overlap between the Lombardi and IBM BPMSs is obvious. I am not optimistic about the positioning, and I doubt they have even figured it out yet. Who can forget the business about “content-centric” vs “process-centric” BPM at the time of the FileNet acquisition? In the slide deck IBM sent out this morning, a couple graphics seem to be following that same kind of thinking.
Here, for example, IBM is BPM for the Commercial LOB, the Financial Services arm, the Agent network, etc. Lombardi is BPM for one branch of the Commercial LOB, actually for the little circles (departments?) hanging off it. Enterprise vs Departmental. It says it right there on the slide.
The next one is even worse.
BPM involves process (Websphere), information (FileNet), and people (Lombardi). Now we have a separate BPMS for each of those. Isn’t that great? Ummm, no.
OK, to be fair, I’m going to assume the IBM marketing guys found out about this a couple days ago, and this is what they could throw together for the announcement.
Usually IBM is very slow to integrate its BPM-related acquisitions, e.g. FileNet or ILOG. They just add to the list of stuff that the professional services guys can integrate for you. Webify was the counter-example. Renamed WebSphere Business Services Fabric, it was just jammed into the middle of the WebSphere BPMS, even though it retained a completely separate metamodel, vocabulary, and toolset. It confused the heck out of everybody.
I think IBM would be better off adopting a strategy similar to Oracle’s when they bought BEA. Again, two BPMSs, one more human-centric and the other more integration-centric. But instead of just adding to the list of products you could buy, Oracle aggressively went after technical integration, melding BEA’s vastly more business-friendly tooling with Oracle’s strength on the runtime backend.
There is no doubt IBM has been trying to make its own BPMS tooling more like Lombardi for a year now. Business Space and some of the human task features in v6.2 and v7 are a testament to this. But they could never really grab hold of Lombardi’s secret sauce, the “shared model.” What you model is what you execute, instant playback from the design environment, agile iterative design and deploy… WebSphere BPMS just doesn’t work that way.
Positioning that approach as “departmental” is a losing strategy, and I honestly doubt that in the end IBM will do that. The battle for enterprise BPM is about engaging the business at enterprise scale, not just IT. It’s what Phil Gilbert has been preaching for years, and I don’t think IBM would have coughed up the money if they didn’t believe it, too. So the trick is melding Lombardi’s superior business-friendly tooling with IBM’s bulletproof backend and SOA. BPMN 2.0 will provide them a way to do that, so I think today’s positioning slides are just placeholders.
But then again, they didn’t ask me.
No other topic in the BPM arena has suffered from more misinformation, disinformation, and willful ignorance as the relationship between business process and business rules. These two disciplines are most often put forward as alternative approaches, rather than complementary aspects of managing the business. In reality, business process management (BPM) and business decision management (BDM) need to be used together. Unfortunately, each discipline has historically spoken only to its own concerns, with little interest in how it integrates with the other, in fact with little understanding of what the other is trying to do.
Today, both disciplines share the goal of empowering business by allowing models to be created and maintained by business analysts for the purpose of documentation, analysis, and governance. And both allow those business-oriented models – if the organization so chooses – to be transformed into technical models, executable on a runtime engine. In recent years, tremendous progress has been made within each domain toward standards and methodologies that enable a common modeling language to be shared by business and IT, i.e. roundtripping between the business and technical models. In the process domain, such a structured approach is exemplified by my book BPMN Method and Style. In the BDM domain, The Decision Model by Larry Goldberg and Barb von Halle applies a similar structured business-oriented methodology.
Neither book, however, gives sufficient consideration to the fact that in decision-intensive processes like lending or claims, process and decision modeling are separate large-scale activities performed concurrently, usually by independent teams. That can work well, but only if the methodologies on both the process and decision sides explicitly consider how those models will be integrated.
Even though both books are brand new, neither discusses this. That does not mean the books are incorrect. Each just describes a core foundation, a framework for modeling business processes or business decisions so they can be shared, analyzed, and maintained effectively. But creating process models and decision models that fit together – in a way that serves both the analyst/architect concerns of documentation, analysis, and governance, and the developer’s concerns of executable implementation – requires going a step further. Larry, Barb, and I are beginning to do that now.
Both BPMN Method and Style and The Decision Model properly give a lot of attention to the question of cardinality: What is one process, as opposed to multiple related processes? What is one decision, and how does it relate to its constituent business rules? Both frameworks impose some technical constraints on it, but beyond that, the scope of a single process or a single decision is a matter of judgment or art, what I call modeling style. Both a process and a decision, the top-level objects in each domain, are inherently compound entities, composed hierarchically out of reusable building blocks. In BPMN, those building blocks are called subprocesses; in the Decision Model, they are called rule families. A BPMN subprocess can call other subprocesses, and a Decision Model rule family can call other rule families.
Integrating BPMN and decision modeling ultimately comes down to properly representing decisions and their constituent rule families in the context of BPMN subprocesses and tasks. There is a way to do this, and we’ll cover it in Part 2.
Tags: BPMN, business rules, decision model, process modeling
A reader asked me to comment on an interesting paper by the European BPM academics Mendling, Reijers, and van der Aalst entitled Seven Process Modeling Guidelines (7PMG). Like my book BPMN Method and Style, 7PMG is asking the right question: what are the principles of style that improve a model’s chance “(1) to become comprehensible to various stakeholders and (2) to contain few syntactical errors.” I don’t completely agree with their recommendations. See what you think.
They begin with the refreshingly honest statement (with which I concur 100%):
A notorious problem is the low level of modeling competence that many casual modelers in process documentation projects have.
On the other hand, the authors’ assumed tool for these folks is ARIS or Casewise, which are really tools for architects not casual modelers. The diagrams in the paper are all EPC. I wonder why they did not write the paper in context of BPMN. But let’s look at the recommendations. After applying some academic hocus-pocus, they arrive at the following prioritized list:
- Make the model as structured as possible. That’s one of my top ones also, but they mean something completely different than I do. To Mendling et al, “structured” means “block-structured.” That would make Michael Rowley happy, but not mainstream BPMN modelers. No, I think these guys are living in a BPEL yesterworld. Enforcing block struture probably does reduce syntactical errors, but at a heavy price: Only developers are willing to go along with it. In BPMN Method and Style, I emphasize structured models as well, but I mean hierarchical structure, in which a single end-to-end semantic model can be viewed at different levels of detail.
- Decompose a model with more than 50 elements. I’m not sure what constitutes an element, since EPC diagrams include everything but the kitchen sink. In BPMN, my recommended style limits you to 5-10 activities in a process level (subprocess).
- Use as few elements in the model as possible. In other words, if an element is redundant, leave it out. I agree with that. But how did it make the top 3? Kind of a motherhood statement.
- User Verb-Object activity labels. Yes I have that one too.
- Minimize the routing paths per element. I agree that expressing process variation by overuse of gateways and alternative paths makes models harder to read. But minimizing routing paths as a broad guideline seems misguided. The model should reflect how the process works, first and foremost. I think the most likely response to 7PMG’s recommendation would be to omit exception paths from the diagram entirely. Which would be a bad thing.
- Use one start and one end event. I’m on board with one start event, but definitely NOT one end event. Using separate end events to represent distinct end states of a process or subprocess is critical in my method and style. It’s what makes hierarchical diagrams traceable from the top down.
- Avoid OR routing elements. Again the BPEL/block bias. But it would seem to contradict items 3 and 5 above if the process semantics really are conditionally parallel flow.
On the whole, I don’t agree with the conclusions. But at least they are asking the most important question. What do you think?
Tags: BPMN, modeling guidelines, process modeling
Recent Comments