I tuned in to Sandy Kemsley’s webcast for Active Endpoints on How to Explain BPMN to Business Users today to see how this pet topic of mine is filtering out to the world. Longtime BPMS Watch readers will recall the spirited discussion I had with Michael zur Muehlen a couple years back, when he did some academic “research” that demonstrated that the BPMN elements most used were the ones carried over from traditional flowcharting. No kidding… Unfortunately that was marketed as defining “all the BPMN you need.” In the end we agreed to blame the headline-writers on that. Anyway, Michael has come around, through his work with WfMC and the DODAF community, and today we are in basic agreement.
Sandy didn’t really tackle the question of how much BPMN business users need. She gave a serviceable presentation on what is in the BPMN 2.0 conformance classes, subsets of BPMN elements generally aligned to descriptive modeling, analytical modeling, and executable modeling. I recommend the replay. But she missed the real motivation for these subsets in the standard, which is portability of models between tools. BPMN tools rarely support all of the shapes and symbols, and never support all of the technical detail allowed for the XML underneath each shape in the diagram. The purpose of the conformance classes was to define specific palettes that tool vendors could assert support for. Modelers could then assume a model confined to such a palette would be portable between conforming tools.
Anyway, getting back to the question of how much BPMN do you need… The composition of the Descriptive and Analytical classes in the BPMN 2.0 spec originated as aligning with the Level 1 and Level 2 core palettes of my BPMN Method and Style book and training. I tried hard to get this into the BPMN 2.0 draft, but at the time, Oracle, IBM, and SAP did not want to be in a position where their first BPMN 2.0 offering would not meet all the conformance classes, even though they all agreed that a levels-based approach made good sense for maximizing BPMN adoption. (IBM’s WebSphere Business Compass, for instance, implements the Level 1/Descriptive palette.) In the Finalization Task Force phase, Robert Shapiro ultimately succeeded in getting conformance classes into the final BPMN 2.0 draft, so we all owe him a great debt of gratitude. (It was not easy, and not all of the Big 3 voted for it in the end.)
In the final BPMN 2.0 draft, Descriptive class includes two task types, user (human) and service (automated); subprocess (embedded and Call Activity); exclusive and parallel gateways; 3 start events (None, Message, and Timer) and 3 end events (None, Message, and Terminate); pools and lanes; sequence flow, message flow, and association connectors; data object and data store; text annotation, documentation (invisible in diagram), and group. That’s it. It’s a small fraction of all the task, gateway, and event types supported in the spec.
The “hard” parts, from a tool portability perspective – i.e., many tools do not support them today – are message flows and data store. Message flows indicate communications between a process and external entities, important for establishing the business context for a process but not needed for automated execution. Oracle BPM 11g, for instance, doesn’t draw message flows. Do business people need them? I think architects and analysts need them. They identify the touchpoints between a process and customers, service providers, and other internal processes. That’s why I put them in. I expected them to get stripped out, but they’re still there.
In BPMN 1.x, a data object was just an “artifact”, effectively a decoration of the drawing with no associated semantics or rules. That’s no longer the case. In BPMN 2.0, a data object is a variable stored within a process instance; a data store is data stored outside of the instance, accessible to it but also from outside. It’s a subtle distinction. I wanted data store in Descriptive because modelers often use message flow to show information passing that is actually implemented via shared data. For example, to obtain billing information a process can either request it from a customer and wait for it in a message event, or look it up from customer account data maintained outside of the process instance. The latter method uses a data store.
Do business people need to understand this distinction? Hard to say. For modeling an executable process it’s obviously important. But even for basic process description, if a business user mistakenly draws a data object connected to a message flow or a directed association from another pool (neither allowed in BPMN 2.0), the tool will not be able to serialize it correctly. It will give a validation error. So I think it makes sense to put data store in Descriptive/Level 1 and then teach people how to use it correctly.
In a way, we’re still back to the question Michael and I were wrestling with a couple years ago. Do you want to limit the BPMN palette to what business users already know (or think they know) from traditional flowcharting, and allow them to bend the semantics and rules? Or do you want to raise the bar and say here is a common process language that can be shared between business and IT? That takes a bit of education or training, since they probably don’t already know how to use it properly. But it’s not rocket science.
Obviously, I favor the latter. Sandy comes out for the former, or maybe in the middle. She says the Descriptive palette is probably too complicated for business users and companies should define their own subset of it that business users will employ. Anyway, the debate is still unresolved.
And there is probably no resolution to the fact that business users want to (will always want to) describe their world using flowcharting methods they (we) all learned in high school; it’s easy, simplistic, what they understand. Conversing with the business user is just part of the methodology of BPM solution delivery that we need to develop as part of our process toward building executable models for the business.
At some point we (professionals) must realize that BPM is a real management discipline and gear our conversations about BPMN usage and tools toward professional BPM practitioners. We can’t continually dumb-down the tools and methods we need to deliver complex solutions.
//
[…] This post was mentioned on Twitter by kenlacrosse, The Tech Gang. The Tech Gang said: #BPM #News How Much BPMN Do You Need… Revisited http://bit.ly/9nArh1 […]
I believe that I said (or at least intended) that business users — as opposed to business analysts — may not learn all of the descriptive subclass well enough to create their own models using all of the elements, but that they would understand it well enough if there were someone else’s (such as an analyst’s) hand on the tools doing the process mapping: it’s like the difference between reading comprehension and writing skills. If business users are going to start sketching out process models on their own, they’re likely going to use a subset of that subclass, depending on their skill level. You consider “business people” as a single class, but in my experience, I see a fairly strong distinction between true business users/managers and non-technical business analysts: the latter are still business people, but have some degree of process analysis and modeling training or experience, as well as a focus on that rather than on executing processes. I believe that non-technical business analysts should consider the descriptive subclass as a minimum, and will need to understand many of the concepts in the analytic class if they are going to model exceptions, escalations and other process events.
I didn’t address the portability issue — and explicitly explained at the beginning that we were not addressing model interchange or execution today — because the focus of the short presentation today was on notation. Although I agree that portability is important, I don’t believe that many business users and analysts spend much of their time thinking about it.
Sandy,
I accept your distinction, and thanks for the clarification. I don’t think true “business users” (in your terminology) will do much BPMN writing at all, although they will need to know how to read the diagrams (sort of). The business users I was talking about are process analysts, business analysts, business architects – the labels vary by company, and they often report to the CIO anyway – the ones chartered to document, analyze, and ultimately improve business processes.
–Bruce
[…] Bruce Silver writes about the “right amount” of BPMN for the business: In a way, we’re still back to the question Michael and I were wrestling with a couple years ago. Do you want to limit the BPMN palette to what business users already know (or think they know) from traditional flowcharting, and allow them to bend the semantics and rules? Or do you want to raise the bar and say here is a common process language that can be shared between business and IT? That takes a bit of education or training, since they probably don’t already know how to use it properly. But it’s not rocket science. […]
[…] BPMN – Bruce Silver Do you want to limit the BPMN palette to what business users already know (or […]
Hi Bruce,
Thanks for your insight on BPMN Method & Style and the application thereof. An area I am still grappling with is in the “use” of BPMN sub-model types per the BPMN 1.2 specification (p12 or p34 in PDF). Like you know, it indicates the three sub-model types as:
– Private
– Abstract
– Collaboration
Any recommendations on where I can learn more about that?
I am losing traction because of the complexity of representing business processes across four separate entities (our company, the health plan or client, the provider or oncologist, and the pharmacy distributor). Because each entity will need to see their perspective of the process in sufficient detail, I am using the collaborative sub-model type to further leverage hierarchical expansion. This allows me to capture abstract activities that then drill-down into business activities and tasks.
I feel challenged by representing so many processes in-detail in all pools while maintaining a consistent hierarchical expansion diagram.
Thank you for your time,
Thomas Kirven
Thomas,
A private process is a complete activity flow (orchestration). It’s what we normally mean when we say a “process”. A collaboration is the pattern of message flows between pools, each pool representing (in BPMN 1.x) a distinct process. An abstract process is an abridged form of private process in which the only activities included are those that send or receive message flows; in BPMN 2.0 it was renamed “public” process.
I don’t quite understand your use of these in the context of hierarchical expansion. Typically my method and style recommends a collaboration diagram involving a single private process and one or more black-box pools. (In BPMN 2.0 a black-box, or empty, pool has no process. In BPMN 1.x, you can say it has one but it is unknown.) I never use abstract (public) processes, and always replicate the collaboration at each process level in the hierarchy.
–Bruce
Bruce,
Thanks for the reply. I recognize your time is valuable and am hopeful that continuing this dialog isn’t too much. One problem seems to be that I’m incorrectly applying concepts that I’m still learning and internalizing.
Another is, I might be trying to show too much in one top-level digram that can drill-down to sub-processes according to multiple user perspectives. In essence, I want one file that contains a high-level diagram for an executive of the client, my company, or the other two entities, and, also, be able to drill down to task-level details according to each perspective.
For instance, the first example in your book, BPMN Method & Style, is about a “basic order process”. Later in the chapter you explain why it is not important for that process to capture the customer completing the order form. Instead, you recommend identifying the actual process trigger, which is the submission of the order.
Continuing that example, I need to show our client how the customer’s process of submitting orders (or in my case, chemotherapy treatment requests) will change. That process change is necessary so that my company can ensure we get the right data. Then we can render our core service, which is reviewing treatment requests on behalf of the health plan. That core service involve all four entities, is complicated, and also needs to be communicated to each entity.
If you don’t see something that strikes you, that’s understandable. I’m trying to boil down a complex set of challenges and problems into a blog comment. I get we can only do so much here.
Thanks again!
Thomas
Hello every body please in this moment in my university it´s very important that we Know about BPMN but in our library haven’t got any book about bpmn — if you can send me tha guide reference of bpmn and modeling or bpmn stylus you will be a good man o woman. please help me.
correo altern pk2aldo@gmail.com
[…] Don’t bother to learn something that is about 10% harder than standard flowcharting (Bruce Silver has helpfully identified a subset of BPMN that is more appropriate for new-to-BPMN business […]