A Standard for Case Management?

The vote on BPMN 2.0 is not the only thing on the agenda at next week’s OMG meeting in Costa Rica. There is also the release of an RFP for a new Case Management standard, authored by Henk de Man of Cordys. Response to the announcement of same on OMG’s BMI mailing list has been sometimes thoughtful but mostly the kind of doubting, naysaying, and non-sequiturs you often get on that list. I once learned the hard way the danger of hitting Reply All to a BMI discussion thread, so I choose to post my thoughts here instead.

The RFP asserts that BPMN is inadequate for case management but that case management should leverage BPMN for the “process” part, and I agree with that.  It also seeks to tie in to OMG government task force effors on records management for the case folder part.  That might be useful as an option but I hope it’s not a requirement.

Of course, a major problem with case management is that there is no common definition for what it is.  I would assert you could say the same thing about BPM until BPMN provided a standard vocabulary.  Not everyone agrees with BPMN’s conceptualization of process as a centrally-controlled orchestration (the rules guys, the choreography guys…), but for most of us it works, whether you are modeling automated processes or just describing manual ones.

Here is how I see the differences between case management and conventional BPM as described by BPMN 2.0. 

• A “case” (instance of a case management process) does not progress from start to completion by following paths on a control-flow diagram like BPMN.  The case as a whole has milestones or states, so progress to completion is more like a state diagram than activity flow.  But we know that UML state charts are not “business-friendly,” so perhaps that piece needs a makeover like BPMN did for UML activity diagrams.
• Much work on the case is driven by external events, not control flow.  Those events, in combination with human activity responding to those events, determine the tasks and conventional processes that need to be completed.  So there is an ad-hoc nature to case management processes, in which activities are added to the case at runtime.  Usually these activities are not conceived on the fly, but predefined and selected from a menu or catalog.
• In conventional BPM, a task performer is not usually presented with every bit of detail about the instance, just enough to perform the task.  In case management, performers interact with a shared case folder containing all the artifacts related to the case… data, documents, tasks, processes, their assignees and deadlines, etc.  The notion that such a folder should be managed as a record, while obviously true, seems no more true than for the artifacts of ordinary process instances.  Yes you need records management for both, but that is independent of the process aspect.

I think these differences from conventional BPM are not so great that case management needs to start over.  An extension to BPMN to handle the case state progression model, in combination with a better solution for the ad-hoc/dynamic activity initiation part - let’s face it, today’s Ad-Hoc Subprocess notation is lame - is not beyond the range of possibility.  Because a case will inevitably contain conventional processes modeled in BPMN, a strong connection between the case modeling notation and BPMN would be extremely valuable.

Tags: case management

It came together faster than I thought!  BPMN Method and Style is now available on Amazon.com.  I had hoped to send out an email blast last night to announce it to all BPMS Watch subscribers from the Mailpress plugin, but I’ve been learning (the hard way) about gmail’s smtp limit… Apologies to those first 100 or so subscribers who probably got 3 or 4 emails.  For the rest of you, here is what I was trying to say…

If you’ve been following BPMS Watch lately, you know that I’ve been working on a book that explains how to use BPMN correctly and effectively to create process models that can “stand on their own”… i.e., be clear and understandable to anyone from the diagram alone.  The book is called BPMN Method and Style, and it’s available now on Amazon.com.  It’s based on the brand new BPMN 2.0 standard, set for approval by OMG later this month.

Creating business process models that can be shared effectively across the business - and between business and IT - demands more than a digest of BPMN shapes and symbols. It requires a step-by-step methodology for going from zero to a complete process model. It also requires consistent application of a modeling style, so that the modeler’s meaning is clear from the diagram itself. I not only explain the meaning and proper usage of the entire BPMN 2.0 palette, but call out the working subset that you really need to know. The book also reveals the hidden assumptions of core concepts left unexplained in the spec, the key to BPMN’s deeper meaning.

The book addresses BPMN at three levels, with primary focus on the first two. Level 1, or descriptive BPMN, uses a restricted palette in combination with some relaxation of BPMN’s rules to meet the needs of business users doing basic process mapping. Level 2, or analytical BPMN, takes advantage of the notation’s exceptional expressiveness for detailing event and exception handling, key to analyzing and improving process performance and quality. Level 3, or executable BPMN, is brand new in BPMN 2.0. Here the XML underneath the diagram shapes can be deployed to a process engine to actually execute the model.  The method and style recommended by the book aligns these three levels, facilitating business-IT collaboration throughout the process lifecycle.

Inside the book you’ll find detailed discussions, illustrated with over 100 examples, about:

• The questions BPMN asks, and does not ask
• The meaning of basic concepts like starting and completing, sending and receiving, waiting and listening
• Subprocesses and hierarchical modeling style
• The five basic steps in creating Level 1 models
• Event and exception-handling patterns
• Branching and merging patterns
• Level 2 modeling method
• Elements of BPMN style: element usage and diagram composition

If you have an interest in learning how to do process modeling the right way, or just want a heads up on what’s new in BPMN 2.0, I hope you’ll take a look at the book.  If you are interested in training based on the new “method and style,” I’m doing a 2-day class in San Francisco on July 1-2, hosted by the BPM Institute.  Click here for details.

Tags: bpm, BPMN, bpmn book

The book should show up on Amazon in the next couple days, but probably not orderable until Ingram (the distributor) gets it set up, which takes  up to 4 weeks.  But you can be first in line to get the book, and I’ll give it to you personally… for free!  All you need to do is sign up for my 2-day class at BPM Institute in San Francisco July 1-2.  Here’s all the info you need on that.  Hope to see you there!

I’ve taken an interest in cloud-based modeling tools, so I decided to check out a new one from Signavio.  This is a German company related somehow to Gero Decker and colleagues at HPI, the authors of that steamy BPMN “novella,” The Process.  A 30-day trial is free.  Here’s a quick review.

• You have to sign a click-through agreement in German to get started.  Oh well, who reads those things anyway?
• You can invite others to share your online space, which stores models in a repository.
• The BPMN editor requires Firefox 3.0 to run.  They don’t tell you that until you actually try to create a diagram.  That’s annoying.
• Besides BPMN they also support ARIS EPC.  OK, it’s Germany…
• It supports the ful BPMN 1.x palette, and the website says they are adding BPMN 2.0 “soon.”  Very nice.  Lombardi Blueprint has just a limited subset.  For BPMN 2.0 support, they seem fired up about Conversations and Choreography… strange.
• Also, unlike Blueprint you can actually export the diagram info in XML.  It’s a proprietary format but easily mapped via xslt to xpdl or BPMN 2.0.
• All the BPMN 1.x attributes can be edited in a popup property sheet.  But they don’t seem to change the diagram.  For instance, you can set a task type, but there is no icon in the diagram.  I suppose that applies to things like loop markers, etc., as well.
• There is no documentation or help.  But you can email questions to them for help.  Yeah, right.  Weak.
• Hovering over a hotspot on a selected node in the diagram, there is a graphical “menu” of connector and node shapes, similar to Lombardi Blueprint except a bit harder to use.  If you want to draw a second sequence flow out of a node, you need to draw one to a dummy activity, move the sequence flow to the real target, and then delete the dummy activity.  At least that’s the only way I could figure out how to do it.  (Blueprint is only slightly better.)
• From a collapsed subprocess, hyperlink to a separate diagram to create the expanded view.  The model keeps them together (at least for navigation).  That’s pretty nice.
• No label allowed on a gateway.  What’s up with that?  You need to add it as a text annotation.
• You can save versions in the repository, but it doesn’t have the nice snapshot and revert capabilities of Blueprint.

After the trial period, of course, you have to pay.  The price seems high for what you get.  It’s EUR 30 per month for the basic edition and EUR 75 per month for the enterprise edition.  Not sure if that’s per team or per user… I guess that would make a difference.  The enterprise edition has a lot more functionality, like saving to xpdl or bpel (I assume saving to bpmn 2.0 will be enterprise-only too, not sure…)

The thing that I’m not crazy about is that the diagrams just don’t look that good.  Mostly the problem is lack of bendpoints in the connectors, and the way labels look.  For this kind of money I would expect better.  For example, here is a diagram used for the Level 1 (”Descriptive BPMN”) portability work in XPDL, first in Signavio and then in the ITP desktop tool I use in my training.

Others might disagree, but for me there’s no comparison.  And if you don’t need to export to xpdl or do simulation or validation, the ITP tool is free.  The funny thing is, Signavio is based on a free online BPMN editor called Oryx, available from HPI’s website, and the Oryx diagrams look better. 

I’m not sure what Signavio’s value-add is, maybe the online team repository, but in the diagram itself it looks like a value-subtract.

Tags: BPMN

I finally shipped the book off to the printer yesterday!  Wow, why does the last 5% take 50% of the time?  Not certain how long before it ships, but June almost for sure.

I’ve been using the new levels-based method and style approach in private classroom training for the past couple months.  I think it makes learning BPMN much easier, especially for business people.   On July 1-2, I’ll be doing a public two-day class in San Francisco, hosted at the Parc 55 Hotel in Union Square by the BPM Institute.  Get out of the heat and come to our beautiful city by the bay… and learn some BPMN while you’re at it!

The course info page on the BPMInstitute site still has the old version, so until they update it, this is the info on the new course:

Traditionally, process modeling has relied on proprietary tools and methodologies, raising the cost and limiting shared understanding. Today we have a widely accepted standard for process modeling, the Business Process Modeling Notation (BPMN) from OMG, with near-universal adoption by modeling tools. BPMN looks a lot like traditional swimlane diagrams, but adds powerful new features that allow exception handling - the hidden cost of real-world business processes - to be modeled explicitly in the diagram.

This course shows process modelers how to use BPMN correctly and effectively - to document existing processes, to analyze and improve processes, and even to collaborate with IT in executable process design. Creating “effective” models - those that stand on their own, clear and complete from the diagram alone, without accompanying explanation - depends on more than knowing the catalog of BPMN shapes and symbols. It requires understanding BPMN’s hidden assumptions about basic concepts - What exactly is a process? What do sequence flows and message flows really mean? What does BPMN mean by starting, completing, sending, and receiving? You won’t find the answers in the BPMN spec, but they are critical to using BPMN effectively.

But that alone is not enough. Effective modeling also requires a methodology, starting from a blank page and progressing to a complete diagram. And it requires a style guide, a set of rules and best practices for making diagrams clear from inspection. This course provides those as well.

This course, based on Bruce Silver’s new book BPMN Method and Style, will show you how to use BPMN at two different levels, with a method and style applicable to each level. Level 1, or descriptive BPMN, is intended for business users. It relies on a basic working set of shapes and symbols, familiar from traditional flowcharting, but aligned with the basic structure and meaning of Level 2. Level 2, or analytical BPMN, is intended for business process analysts and architects, as well as developers planning to collaborate with business on process design. Level 2 BPMN represents a common process language shared by business and IT, but achieving that common language demands attention to method and style. Level 2 refines Level 1 models with an emphasis on events and exception handling, the source of problems in most existing processes. We teach specific diagram patterns that signify a particular type of exception and its effect on the process, so that exception behavior is captured explicitly and clearly in the diagram itself.

You can’t learn BPMN from lectures. You need to be hands on. That’s why the training uses a BPMN tool, an add-on to Microsoft Visio. Each student is expected to bring a laptop to the class and will use it to complete exercises, both in class and afterwards. The post-class exercises are optional, but give students the opportunity for individualized feedback and instruction. The price of the training includes 60-day use of the tool, Process Modeler for Visio from ITP Commerce. In addition to certification through BPM Institute, students who satisfactorily complete the post-class exercises are eligible for certification of proficiency in BPMN modeling from BPMessentials.com.

Course Outline:
Day 1
1. Why BPMN?
2. Getting Started: BPMN Level 1
3. The Level 1 Palette
4. Level 1 Method
5. Level 1 Style
Day 2
6. Deeper Meaning: BPMN Level 2
7. Events
8. Branching and Merging Patterns
9. Exception Handling Patterns
10.Repeating Activities and Pools
11.Level 2 Method
12.Level 2 Style
13.Gaining Proficiency

Course Objectives:
· Understand where BPMN fits in the overall framework of business modeling and its role in business-IT alignment
· Learn a “cookbook” methodology for creating business-oriented Level 1 models
· Learn elements of Level 1 style essential to clear and effective models
· Understand the hidden technical meaning behind BPMN’s shapes and symbols
· Learn a methodology for refining Level 1 models to show the exceptions and variations important to key performance indicators
· Learn the “art” of process modeling, diagram patterns and best practices that allow your diagrams to stand on their own

If you are interested in BPM Suites, I’ll be doing a session on BPMS vendor selection and a vendor panel at the Brainstorm BPM Conference at the same site on the preceding day, June 30.  Brainstorm is offering BPMS Watch readers a limited number of Complimentary 1-Day Passes* (a $795 value) to the Conference for that day.  Register with Priority Code SILVER when requesting a Complimentary Conference Pass.

To sweeten the deal, if you sign up for the class I’ll also give you an autographed copy of the book.  Now how can you resist that?

Tags: BPMN, bpmn 2.0, bpmn book, bpmn training

That’s the title of my new book.  I’m planning for release end of June, coinciding with approval of BPMN 2.0 by OMG.  The basic idea is that using BPMN effectively requires more than a summary of the spec… especially with BPMN 2.0, on which the book is based.  It needs three things besides that. 

• First, an understanding of BPMN’s most basic concepts: what is a process? what do sequence flows and message flows really mean? You won’t find this in the spec, but BPMN is built around very specific assumptions on these and similar conceptual foundations.
• Second, a cookbook methodology that takes a modeler from a blank page to a completed diagram that stands on its own, i.e. is understandable by others without further explanation.  The book provides a two-level methodology.  Level 1 is for non-technical business users.  It combines a limited palette of shapes and symbols with a step-by-step approach to constructing a BPMN model.  Level 2 is for business process analysts and architects.  It focuses on a core set of event and exception-handling patterns that allow BPMN’s expressive power to be understood consistently across the organization, creating that common language shared by business and IT.  Of course, the methodologies need to be aligned, so in the end there is one model, not two.
• Third, a manual of style, with sections applicable to Level 1 and Level 2.  These are rules and best practices for making diagrams clear, consistent, and true to the modeler’s intent.  The BPMN spec gives the modeler wide latitude, enough to create bad models that are technically “valid.”  The style sections give prescriptive guidance to avoid that.

I’ve set up a website for the book where you can see the table of contents, read the preface and first chapter, testimonials, etc.  The method and style presented in the book also form the basis for new versions of my BPMN training.  The full Level 1/Level 2 training based on BPMN 2.0 and Process Modeler for Visio is available in San Francisco July 1-2 through BPM Institute.  Also, I am developing a  2-day Level 1-only “live online” class based on Lombardi Blueprint, available through Lombardi University.  No dates set for that yet, but probably in late June or July.

Tags: BPMN, bpmn 2.0, bpmn book, bpmn training, process modeling

BPMN is sometimes criticized for being too complicated for business users.  That charge assumes that users need to understand every shape, symbol, and underlying attribute.  But no one does, not even the experts, and most tools don’t even support them all. 

The way around this problem is through a hierarchy of modeling “levels.”  Levels are often used in modeling to distinguish views at different degrees of abstraction, from high-level business-oriented views to detailed technical views.  I tried to get OMG to support something like this in the conformance section of BPMN 2.0, but without success.

Nevertheless, I have used BPMN levels successfully in my BPMessentials training, and have formalized it in the methodology of my new book, BPMN Method and Style.  In that methodology, Level 1, or descriptive BPMN, is based on a limited working set of constructs familiar to most business users and supported by most modeling tools.  Level 2, or analytical BPMN, draws on the full palette of BPMN 2.0 shapes and symbols, but omits the executable details underneath.  The most commonly used event, gateway, and task types are included in what I call the Level 2 “core” palette.  Level 3, or executable BPMN, is new with BPMN 2.0.  There the diagram, elaborated with XML for data mappings, services, messages, and human task assignments, becomes executable on a process engine.

The key question is what to include in Level 1.  I have two objectives here, which unfortunately are not always aligned. 

The first is pedagogical, related to the business-oriented methodology.  The Level 1 palette should be familiar to business users, but the basic structure of Level 1 models must be preserved when moving to Level 2.  Otherwise you cannot achieve that goal of a common language shared by business and IT.  So I have included in my Level 1 palette some things that others may question.

The second is portability of BPMN models across tools.  The BPMN 2.0 team failed completely here, despite the lip service to that goal in the specification.  Portability demands levels, at least if you want any tools to claim they support it, and there are no levels in the BPMN 2.0 spec.  There are levels, however, in XPDL 2.1 - WfMC’s serialization of BPMN 1.1/1.2 - and there will be levels in XPDL2.2, the BPMN 2.0 version.  Robert Shapiro, driver of that effort, and I have been discussing what should be included in Level 1, or what XPDL 2.1 calls the SIMPLE class.  We will continue to talk about it, but I think there is value in soliciting other views as well.  Hence this post…

Here is a table comparing my Level 1 and Level 2 core palettes with XDPL 2.1 SIMPLE and STANDARD classes, and with Lombardi Blueprint.  I picked Blueprint because it offers a limited BPMN palette for business users, and because I am offering a version of my Level 1 methodology using that tool. 

Since I worked with Robert on the XPDL SIMPLE class, he asked me why my Level 1 palette was different from that.  The honest answer is when I was working on SIMPLE I was thinking about commonality among BPMN tools, and when I was developing my levels I was thinking about methodology and business-IT alignment.  I always imagined those two goals were aligned, but obviously not entirely.

I invite discussion on the following points:

• Expanded (inline) subprocess.  I don’t use it in my methodology but it is useful pedagogically, since you can show the child level and parent level flows in the same picture.  Since I use it for that in the Level 1 part of the book, I put it in the palette.
• OR gateway.  It’s confusing to some users, so I leave it out of Level 1. It’s not used that often.  The Level 1 method ignores the error of using AND-join where the technically correct gateway is OR.
• Pools, message flow, and Message start/end events.  Showing the “customer” (process requester) as a separate black-box (empty) pool rather than as a lane within the process is fundamental to my Level 1 method, and essential for business-IT alignment.  So I include pools and message flows in the palette, as well as Message start and end events. 

The last one may be the biggest obstacle to unifying the methodology with the tool interoperability classes.  It’s a change from my thinking about SIMPLE class in XPDL 2.1.  The question is should they be added to SIMPLE in XPDL 2.2?  Technically, in BPMN 2.0 you cannot even draw a pool unless you show two of them interacting via message flows.  That’s a change from BPMN 1.x, and we’ll see whether tool vendors and users complain about the new rule (or simply ignore it).  On the other hand, many tools - e.g. Blueprint - cannot have multiple pools and message flows. 

I can see how multiple white-box pools could be an architectural problem for some tools, but usually there is only one white-box pool (the process), interacting with black-box pools representing the customer (requester) and possibly other service providers.  That’s just a drawing issue.  Alternatively, BPMN 2.0 provides a notation within a process diagram (no pools) in which a message symbol (envelope) is linked to activities and events via data association (dotted line) to signify an incoming or outgoing message.  This accomplishes the same thing.  I would hope to keep the notion of process requests and responses in the Level 1 palette somehow.

Your comments are welcome.

Tags: BPMN, bpmn 2.0, bpmn training, methodology, process modeling

[My May column on BPMInstitute.org]

“Cool” is not a word I would normally apply to IBM’s BPM software, but for the new BPM BlueWorks offering announced at Impact this week, the term is appropriate.  IBM bills BPM BlueWorks as a BPM community in the cloud, and it is that, plus a lot more.  Actually, I think its greatest immediate impact could be to transform the market for business process analysis (BPA) tools.  The essence of BPA is a suite of tools for modeling the business and a repository for those modeling artifacts: not just processes, but strategies, goals, and metrics; value chains and capability maps; process models, from high-level maps to detailed BPMN diagrams; organizational entities and roles; policies and rules.  All of these models are linked through the repository.  Such suites are central to business process management at the enterprise level, and historically they have been aimed at a small priesthood of architects who don’t mind the 5-figure cost per seat, mind-numbing complexity, and three weeks of intensive training.  But you can’t really create a culture of BPM within an enterprise, or move from isolated projects to an enterprise BPM program, without democratizing modeling and analysis.  BlueWorks does that.

For starters, BPM BlueWorks is free, hosted on an ibm.com website.  Users get their own private spaces within BlueWorks where they can model their own business and collaborate with others that they invite into their space.  BlueWorks includes modeling tools packaged as “widgets,” web 2.0-based UI fragments that can be mashed up inside IBM’s BusinessSpace environment.  In the first release, which goes live June 26, the most important is the Business Strategy widget, which lets you model strategies and metrics, capability maps, and process maps.  Strategy maps link business factors (strengths, weaknesses, opportunities, and threats) to goals (actions and metrics).  You can copy and paste text from Microsoft Office and the strategy map graphics update automatically.  It’s very cool.

The widget also supports capability maps, functional decompositions of the company’s business derived from IBM’s Component Business Modeling methodology.  Organizations use these maps to separate core competencies from non-core capabilities as an aid to guide strategic investment.  Individual capabilities link to process maps, and activities within those maps can be expanded into detailed BPMN models.

Thus the widget provides a chain of links from business strategy all the way down to BPMN.  For over two years, students of my BPMessentials BPMN training have been asking for this.  Outside of super-expensive BPA tools - most of which did the BPMN piece poorly - I could never give them an answer.  Now I can.  And it’s free.  The strategy widget doesn’t have everything my clients want.  I think they’d like a way to link in models of RACI roles and policies and rules.  But those are coming, too.

Even better, IBM is populating BlueWorks with prebuilt models and maps, much of it industry-specific, taken from vertical industry standards like eTom and from IBM’s own industry frameworks.  Again, all free.  You can customize and reuse them within your private space in BlueWorks.  So you can align your strategy, goals, and metrics with industry standard capabilities and process maps.  This places your process models not only within the enterprise context but within the context of vertical industry standards.  All of these artifacts are managed in Rational Asset Manager within BlueWorks, the model repository.

BlueWorks manages to avoid the complexity of traditional BPA tools.  It is simple and straightforward, all web 2.0, easy to use.  Bottom line, it’s a tool for “business users” not just “architects.”  I can already hear the wailing from architects that business users can’t be trusted with such powerful tools.  But sure they can.

In addition to repository-based business modeling, private team workspaces, and prebuilt industry content, BlueWorks also provides collaboration tools based on Lotus Connect, so you can find and collaborate with experts within your organization (or outside it) to assist in the modeling effort.  Last, but not least, BlueWorks supports a public BPM community with articles, podcasts, blogs, and forums, a central location for learning about BPM, and is looking for content contributors.  I plan to be one of them.

So this is BlueWorks as BPA in the cloud.  But IBM doesn’t think about it this way.  IBM is about executing processes, not just analyzing them.  In fact, they tend to describe BlueWorks as linking strategy to execution.  And it can do that, too, if you want.

You can take the BPMN models and export to WebSphere Business Modeler, either on the desktop or in the online SOA Sandbox.  In the SOA Sandbox, which is also free, you can add details in Modeler, bind to services in your registry, create task user interfaces and KPIs, and then execute those processes in a development/test environment in the cloud.

These efforts are all just part of a broader IBM initiative in cloud computing.  In addition to BlueWorks and other solutions hosted on the public web, IBM is actively promoting the concept of private on-premises clouds.  Private clouds allow software to be virtualized behind the firewall, with rapid provisioning and elastic scaling, but with the security, reliability, and integration features of traditional enterprise IT.  If you are interested in the intersection of BPM and cloud computing, click here to get my new white paper on the topic.

Tags: BPA, BPMN, cloud, ibm

[This month's BPMS Watch column on BPMInstitute.org]

Last month I gave you five things to love about BPMN 2.0.  This time it’s five they left out.  As a member of the development team, I understand why they were left out.  And as a BPMN educator and author looking to add value on top of the standard rather than just to summarize the spec, I’m glad they gave me room to do that.  I’ve developed my own methodology and style to fill in the gaps, but most people might be disappointed to find the following items missing from the standard.

1.  Distinction between modeling-related and execution-related information.  BPMN 1.x failed to make this distinction as well. It mattered less then because no tools used BPMN for the execution-related attributes.  They all used their own instead.  The only part that mattered was what was visible in the diagram, what I call the modeling part.

It’s more of an issue in BPMN 2.0 because the new standard is conceived first and foremost as an executable design language, effectively a BPEL replacement.  The team could barely imagine why anyone would care about non-executable models, and would not waste time on which parts of the metamodel are modeling-related versus execution-related.

This issue was my top priority when I joined the team in December, but all I was able to accomplish there was ensuring that BPMN models could be schema-valid without specifying all the data interfaces, WSDL operations and messages, and other implementation details.  I could never get an enumeration of the information elements expected to be supported by non-executable modeling tools.  Because the spec mostly deals with execution-related information – and no tool with a runtime will support all of that – it is easy for each tool to select subsets of the modeling-related information they will support.  That’s not good.

2.  Semantics of non-executable models.  This is related to the previous issue, but not really the same.  I did manage to get “non-executable” added as one of the allowed process type values, but its only defined effect is to excuse the modeler from providing the aforementioned data interfaces and WSDL references.  Otherwise, BPMN semantics still assume a central orchestration engine, whether one is there or not.  For most BPMN modelers today, not only is there no process engine behind the scenes, but no conception that things like process engines even exist.

BPMN essentially assumes the semantics of non-executable and executable models are the same, but the former are merely underspecified.  One consequence of this is that sequence flow – the solid arrow connector – really means a token-based flow of control, whether the modeler intends that or not.  When activity A completes, the sequence flow to activity B starts activity B immediately.  Sure, that’s how it works in BPEL and other workflow systems, but what if you want to say only that B occurs sometime after A, not immediately after?  There could be something in between, not shown.  Or, simply that B starts sometime after A starts, not necessarily after A finishes?

These are not uncommon in high level modeling.  I proposed a flag that would distinguish such lax sequence flow semantics from the strict control flow interpretation, but it never got out of the batters box.

3.  Model portability.  Most people simply take it for granted that the first goal of any standard like BPMN is portability or interoperability between tools.  You should be able to create a BPMN model in tool X and open it in tool Y.  That takes more than a schema.  It also requires the spec to enumerate the elements expected to be portable between tools, i.e. that all tools must support and understand.  In an execution language like BPEL, this enumeration is the entire set.  But for BPMN, currently used as a diagramming notation rather than a complete execution language, no tool with a runtime supports every last bit of it, and that probably won’t change with BPMN 2.0.

The team should have followed XPDL’s lead and defined multiple working sets – a hierarchy of portability levels – from a simple basic palette supported by essentially all tools, up to the full set, with portability conformance requirements spelled out for each level.  I drafted language to that effect, but it didn’t get off the ground, either.  Instead, the modeling conformance language is so vague as to be meaningless.

My interpretation of the reason is that team members were uncertain how much of the BPMN palette their own tools would support in their first “2.0-compliant” release.  So don’t expect much portability when BPMN 2.0 tools first come out.

4.  Graphics interchange.  If I interchange a BPMN diagram from tool X to tool Y, I may not expect it to look exactly the same, but I’m hoping that the basic layout of the graphics is preserved.  And when I think about the tools involved, I’m thinking about today’s BPMN tools, like Appian, Lombardi, Savvion, TIBCO, and ITP Commerce.  But that’s not what OMG was thinking about.

Instead, they wanted to make sure BPMN diagrams could be integrated with generic drawing tools like Eclipse GMF, maybe mashing up UML and BPMN shapes, and other conceptual possibilities far from the real needs of process modelers.  The BPMN-specific graphics information, like the size and positions of pools and lanes, activities, gateways, and events, is not even defined by an XML schema, just what is called an M1 library, making it harder to validate and transform using XML tools.  It might be UML-friendly, but not XML-friendly.  That’s a geeky way of saying that most of today’s BPMN tools will probably not adopt this part of the BPMN spec, so a wasted opportunity there.

5.  Simulation properties.  Here is another case where the team’s focus on execution not modeling is in evidence.  Most BPMN tools today provide model simulation based on assigned parameters of activities, performers, gateways, and events.  Standardization of those parameters was omitted from BPMN 1.x, and it only makes sense to add them in to 2.0.  There are sections of the spec – essentially empty placeholders – devoted to “auditing” and “monitoring,” things few would associate with BPMN.  But nothing on simulation.

Simulation has the potential to be an important modeling feature, despite the poor quality of most of today’s simulation tools.  I believe including it in BPMN 2.0 would have raised the quality of those tools, as well as the general level of understanding of what simulation can do and how to use it effectively.  Sadly, another missed opportunity.

Tags: BPMN, bpmn 2.0

Keith Swenson has a nice post on the representation of human choice in BPMN.  He objects to the use of a gateway to represent a human decision at the end of a task, like clicking either Approve or Reject.  Instead he proposes a new boundary event for this purpose (he suggests the None boundary event, currently not used in BPMN).  He raises some good points, and the comment thread generally agrees with him, but on balance I don’t agree.  Here’s why.

BPMN constantly has to balance expressiveness and complexity, while maintaining some measure of consistency in the metamodel.  Compared with other modeling notations, BPMN is notable for its expressiveness - ability to distinguish in the diagram fine differences in meaning - and has been rightfully criticized for the notation’s resulting complexity.  So there is a “cost” to adding any new shape or variant of a shape, such as Keith is proposing.  I am not in principle against enlarging the notation; I’ve proposed several additions myself.  It’s just that there must be a good reason why the existing notation is inadequate.

Keith is fine with the following:

… but he objects to this:

What’s the difference?  To BPMN, there is none.  A gateway does not perform work.  It has no “performer.”  It just directs the flow down this path or that based on evaluating a data expression.  Keith is fine with the first one, because the item to be purchased is implicitly a data element of the process.  For some reason, however, he does not consider the hiring decision variable to be such an implicit element.  I can sympathize with his logic, but I disagree. 

The hallmark of what I call “Level 2″ modeling is going along with BPMN’s hidden assumptions, of which there are many.  A big one is that even for processes that are not automated in a BPMS, the notation acts as if it is.  This should not be an issue for Keith, because Fujitsu also assumes a BPMS.  Apparently Fujitsu’s process engine does not implement human choice by populating a variable with an enumerated value and testing it in the routing logic, but I would surmise that most BPMS’s do it that way.  In any case, this mechanism is a hidden assumption of BPMN., built into the semantics of gateways. 

Keith suggests instead something like this, because it more directly connects the user’s decision to the subsequent flow:

Well, it does, but it has other issues.   On the consistency side, a boundary event on a task implies the task completed “abnormally.”  In fact, here there is no “normal flow” exit from the task, just two exception flows.  This is not technically illegal, but I would maintain it is inconsistent with the usual semantics of boundary events on tasks. 

This is mostly about methodology and style, which I have come to see is really at the heart of using BPMN effectively.  (Hence, my upcoming book, BPMN Method and Style…)  The letter of the law, as stated in the BPMN spec, allows inconsistency in the notation, but it is better if you apply principles consistently throughout.

In my method and style, a gateway following a task that completes normally is usually testing the end state of the task, as in the human decision example.  But it could be simply testing a property of the instance, as in the first example.  A boundary event on a task, whether message, timer, or error, means the task was interrupted before it completed normally.  That is, it does not imply a normal end state of the task.  That is not what Keith intends in his proposal, and thus I believe it is inconsistent with the rest of BPMN. 

Even if you still like the boundary event for this, is a new None boundary event the way to go?  BPMN 2.0 provides a new event type, Escalation, which on a user task boundary implies an ad hoc user decision in the middle of a task.  It is normally non-interrupting, meaning the task continues in parallel with the exception flow, but it could be drawn as interrupting, and I suppose one could interpret this as a “human decision” at the end of the task.  But to me at least, it implies an exception, not normal completion.  So I just don’t think a boundary event is consistent with the rest of BPMN if the intent is to describe one of N possible branches that could be taken following normal completion of the task.

Tags: BPMN