Please enter your text to search.

Preface

Poosted by admin | Filed under Uncategorized | Apr 30, 2009

Why are you reading this book? Is it because BPMN is cool? No, BPMN is not cool or sexy. Neither is it elegant or especially profound. In fact, it looks a lot like plain old flowcharting that has been around forever.

I hope you are reading this because you want to improve how you manage your business processes, document how they really work, and then make them work better: faster, with fewer errors, more compliant with regulations and policies, and easier to change. Modeling your processes is the first step to all that, and today BPMN has emerged as the “right” way to do process modeling.

Why BPMN?

Why is BPMN - which stands for Business Process Modeling Notation - the right way? For starters, it is a standard. It is not owned by a tool vendor or consulting company. You pay no fee or royalty to use it. Because BPMN is a standard, the cost of process modeling tools has dropped by an order of magnitude. In fact, some very good BPMN tools are free. That means you can afford to deploy process modeling and a “culture of process” broadly across your organization - even across your industry.

Tool affordability is only a small part of the story. While BPMN’s similarity to flowcharting notation makes it friendly and familiar to business users, its unique advantages lie in features missing from traditional flowcharting. Each shape and symbol has a precisely defined meaning, with rules about what can connect to what and what those connections signify. That means others, inside or outside your company, can understand the diagrams you create without you being there to explain them. Actually, the diagram is just the surface layer of a complete XML language for process definition. Using that language, you can project process performance by running your model through a simulation engine, or even automate the process by executing your model on a process engine.

Moreover, BPMN adds a dimension absent entirely in flowcharts: support for event-triggered behavior. An event is “something that happens” while the process is underway:  The customer calls to change the order. A service level agreement is in danger of being violated. An expected response does not arrive in time. A system is down. These things happen all the time. If your model is going to represent the “real” process and not just the idealized “happy path,” it needs to say what should happen when those exceptions occur. BPMN lets you do that.

By combining business-friendliness with expressiveness for exception handling, BPMN has a real chance to achieve that elusive goal of business-IT alignment in BPM. From the beginning, BPMN was designed to be business-friendly. Its creators consciously rejected existing modeling standards like UML as too “IT-centric.” They gave BPMN an overall look - swimlanes, with boxes and diamonds connected by arrows - that was already familiar to business. At the same time, they made sure the BPMN diagram could be more than just a sketch. They gave each shape precise operational semantics, so that the meaning of the diagram was not dependent on the modeler’s whim, but standardized and subject to automated validation. 

In addition to precisely defining the semantics of the diagram, BPMN specifies the technical details that the modeler can attach to each shape in the diagram, details that can be used to execute the model as an automated workflow! With BPMN version 1, most tools for designing and running executable processes - so-called BPM Suites - have used BPMN just for the “abstract” flow diagram, ignoring BPMN’s execution-related attributes in favor of their own vendor-specific ones.  This is changing. Beginning with BPMN 2.0, software giants like IBM, Oracle, and SAP have begun to make BPMN simultaneously a diagramming notation for process description and analysis, and an XML language for executable process design.

BPMN doesn’t require you to create executable processes. In fact, most BPMN users today are simply documenting existing process flows and proposing “to-be” improvements, with little immediate thought of process execution.  But, if you want, BPMN lets you take that to-be model and make it executable, without starting over.

In other words, BPMN provides a common language for describing process behavior, shareable by business and IT.  We’ve never had that before.

Why This Book?

As you dig into it, you quickly realize that BPMN, while simple and business-friendly on the surface, can turn maddeningly complex when you want to harness its full expressive power. In fact, many BPMN examples you can find on the web - and even in BPMN books - are ambiguous, clumsy, or just plain invalid. That is the real motivation for this book.

I started BPMessentials.com in early 2007 to teach process modelers how to use BPMN correctly.  Since then around 1000 students have taken the two-day course, either in the classroom or online.  Initial versions of that training, based on BPMN 1.0, basically summarized the specification, with a bit extra on which elements were the important ones to know and how to project performance improvement using simulation.  I found the “techies” in the class usually got it; the business folks sometimes struggled.  Subsequent revisions of the training material, updated to BPMN 1.1, devoted more time explaining underlying concepts and practical tips on things not in the spec, what you might call the “art” of process modeling.  That helped a lot, but students would still sometimes say, “I see how this works and I understand the value.  But I’m not sure everyone on my team wants this level of detail in their models.” With BPMN skills and objectives, one size does not fit all.

Now in its third year, my BPMN training continues to be shaped by the most basic student questions:  Is the customer part of the process or external to it?  If a message can only express communication with external entities, how do I show communications inside the process?  How can I show a possible ad hoc user action from the middle of an activity?  Basic questions like these have made me really stop and think. In a few areas, BPMN provides no good solution. In most cases, however, BPMN provides an answer, but you would not find it spelled out anywhere in the specification.

Out of my BPMN training experience I have gained two important insights, which form the central themes of this book (and of the latest version of the BPMessentials training):

1.       Clarity and effectiveness of BPMN diagrams depend more on things not stated in the spec than on the official definitions and rules.  I call those other things method and style.  The BPMN spec proudly offers no guidance on either one, but they are critical to effective modeling.

2.       While BPMN diagrams can indeed serve as the common process language shared by business and IT, that is not its only value or its only level of use.  For example, detailed modeling of exception paths may not be necessary for business users trying to do basic process mapping and improvement. Those users get benefit from BPMN as well, but using a different method and style. There must be multiple levels of BPMN method and style in order to address the separate goals and concerns of business users, analysts and architects, and IT developers. The trick is aligning them so that each level is a refinement of the previous one. This allows groups at all skill levels to collaborate in BPM around a common view of the process.

These insights as a BPMN educator, an outside interpreter of the spec, were the original motivation for this book. But another important one arose only after I began writing it.  It was essentially an accident.  In the fall of 2008, one section of an early public draft [1] of the BPMN 2.0 submission to OMG was so tangled and obtuse that I rewrote it and sent it to the team drafting the submission.  The team informed me that if I wanted them even to look at my language, I would need to sign a ten-page participation agreement and Fedex copies of it all over the world. Was that an invitation to join?  OK, I took it!

Thus I became an active member of the BPMN 2.0 working group.  This gave me a close-up view of how standards like BPMN are created and the thinking that goes into them. What I found in this case surprised me, since the team, led by IBM, Oracle, and SAP, was not thinking about the kind of process modeling my BPMessentials students were trying to do. Their focus was creating an executable process language behind the notation.  In the revised specification, the execution tail would be wagging the modeling dog!

Actually, there is little cause for worry. The basic notation is mostly unchanged from BPMN 1.x, and includes some additions extremely useful for all process modelers. But the spec itself has increased an order of magnitude in technical complexity.  Moreover, since its focus is on executable processes, the spec still does a poor job of explaining fundamental concepts as they relate to non-executable modeling. These remain matters of method and style.  That makes a book like this one more important than ever.

The Missing Piece: Method and Style

So we come back to the central themes of this book: method and style. My goal is to explain how to create BPMN diagrams that stand on their own, that express the exception paths as clearly as the happy path, and that can be shared effectively by business and IT.

To do it, the book weaves three elements.

1. The notation

The first is the notation itself, what the various shapes and symbols mean, and rules about where each can be used. It starts with information defined in the BPMN specification, which you could download for free from the OMG website[2] or from www.bpmnstyle.com, the website for this book. A digest of the spec, however, is not everything you need to use BPMN effectively.  Not even close.

BPMN is, after all, the work of a committee, a compromise. In fact, BPMN 2.0 is a negotiated settlement between rival committees! Consequently, it’s a bit of a hodgepodge. It combines the notation for modeling business processes with an alternative notation, called choreography [3], for modeling trading partner interactions, and forces them to share a common metamodel.

Even within the process modeling section, the spec fails to distinguish the elements needed for creating non-executable models from those only needed for process execution.  Nor does it distinguish the important shapes and symbols - the ones all tools support and modelers actually use - from the unimportant ones, seldom used, and missing from the palette of most BPMN tools. 

The notation contains redundant elements and patterns. There may be three different ways to express the same thing in the diagram. In addition, some diagram patterns are allowed that probably should be illegal, while for some other useful behaviors BPMN offers no solution at all. Most unfortunately, the narrative portions of the spec still fail to explain the deeper meaning of its most basic concepts, such as process, decision, event, sequence flow, or message.

Thus information provided in the BPMN spec is insufficient for learning to use the notation properly. Effective BPMN modeling requires understanding things not stated in the spec.  This book shows you which elements and diagram patterns are the ones you really need to know, and when and how to use them. It explains the deeper meanings of the BPMN shapes, and reveals the hidden assumptions underlying them.

This will remove much of BPMN’s mystery, but you still need more to use it effectively.

2. BPMN Method

If all members of your team are going to create BPMN models that can stand on their own, understandable without an accompanying narrative, you also need a consistent method. By method I mean a cookbook approach starting from a blank sheet of paper and leading to a complete BPMN model. OMG boasts that BPMN has no methodology, since how it is used depends on what you are trying to do. But confronted with a complex palette of shapes, symbols, and connectors, modelers need a methodology or they will get lost. That should not imply, however, a single method used across the board. The details of the method necessarily depend on the modeler’s objective.

For that reason, the book describes three distinct levels of BPMN use, each with its own methodology.

  • Level 1, or descriptive BPMN, limits the palette to a basic working set of shapes and symbols readily understood by any business person and supported by almost all BPMN tools. The Level 1 method starts from a blank sheet of paper and provides a basic framework for structuring the process model: What starts and ends it? What does the instance represent? What are the basic steps in the so-called “happy path”? What steps are concurrent or conditional? Besides the happy path end state, what are the important exception end states of the process? The Level 1 method relaxes some of BPMN’s more restrictive rules without sacrificing semantic clarity. It also conditions the modeler to BPMN’s top-down hierarchical style, important to handling complex real-world processes.
  • Level 2, or analytical BPMN, draws on the full palette of BPMN shapes and symbols, but the method emphasizes the diagram elements and patterns most commonly used. It picks up where the Level 1 method leaves off. The primary emphasis is on events and exception handling, matching each type of event or exception to a specific pattern in the diagram. The method emphasizes consistency with the more technical meaning of the BPMN shapes, critical to the goal of a common process language shared by business and IT.
  • Level 3, or executable BPMN, deals with the XML language underneath the shapes. It is brand new in BPMN 2.0, and as of this writing, tools implementing it have not yet been released. This book does not provide a Level 3 method, but illustrates how details such as data, services, messages, and human task assignment are specified and used in executable BPMN.

3. BPMN Style

The final element, style, reflects the “art” of process modeling. It is easy to create models that are perfectly valid according to the BPMN spec but are ambiguous, difficult for others to decipher. Style means consistent application of principles and best practices that allow diagrams to be readily understood even when they express complex behavior. Some of these principles and rules are implied by the spec even though they are not clearly spelled out. Others are admittedly personal preference.

It is perfectly fair for you to ask, “Who appointed you the arbiter of BPMN style?” And I would have to answer, “No one.” But someone has to be the first to do it.

The style sections of this book are structured after Strunk and White’s The Elements of Style, still a reliable set of principles for writing effective English prose. Even though that book goes back to Professor Strunk’s lecture notes of 1919, it demonstrates that basic principles of style can stand the test of time. My book tries to apply similar principles to the creation of BPMN models, with the goals of clarity, expressiveness, and consistency with BPMN’s precise technical meaning.  There are separate chapters describing Level 1 and Level 2 modeling style.

BPMN Training

The book provides many examples, and I encourage readers to reproduce them using a software tool. It is difficult, if not impossible, to become proficient at BPMN simply from reading a book. Like any skill, you really learn BPMN only by doing it, working through the creation of diagrams that clearly express your intended meaning. But this book is meant only as education. It is not BPMN training.

There is an old joke about sex education vs. sex training that I won’t repeat here. But you get the idea. Training involves practice, exercises and discussion of solutions, why certain ways work better than others.  I provide such training, both online and in the classroom, through several channels: BPMessentials [4], BPMS Watch [5], the BPM Institute [6], and other venues, and others provide it as well. This book could be used as a reference for that training, or as a textbook in a college course on BPMN, but by itself it is not training.

BPMN Tools

The method assumes use of a software tool. BPMN diagrams can be drawn by hand, but serious modeling requires using a tool. With BPMN you have many to choose from, including good free ones. While BPMN is a standard, the tools are not all the same. Many of the free ones are essentially just drawing aids. They can reproduce the standard shapes and connectors but do not “understand” what they mean. They cannot, for example, validate your model, or create XML interchangeable with another BPMN tool.

The non-free tools are not all the same, either. Some support all of the BPMN shapes and symbols, while others - particularly those from vendors with a process execution engine - may support just a subset. Some tools adhere strictly to the symbols, markers, and semantics specified by the standard, while others do not. Some allow you to create collaboration diagrams linking the process with external participants, while others do not. Some naturally support hierarchical modeling with subprocesses - essential to the method and style described in this book - more easily than others. Some let you simulate process performance without providing executable process components, or even providing technical detail of process activities, while others do not. Simulation is not part of the BPMN standard, so each tool does it differently.

Prior to version 2.0, the BPMN standard did not even attempt to specify requirements for “compliance”. As a consequence, many tools claim to be BPMN-compliant but really are not. BPMN 2.0’s section on “process modeling conformance” does little to improve things. It says that tools claiming such conformance must “support” all parts of the metamodel related to process modeling, even those just important for executable design. Strictly interpreted, no tool will likely be conformant for a long time. Loosely interpreted, it’s no different than before. Other efforts to promote interoperability of BPMN tools are going on outside of OMG, and we discuss them in Chapter 17.

The diagrams used in this book were created using Process Modeler for Visio, an add-in to Microsoft Visio created by ITP Commerce [7]. This is the tool I use in my BPMessentials training. It supports all of the BPMN standard, and I had access to the new BPMN 2.0 shapes through a pre-release version. But in principle, the BPMN models you create should not depend on which tool you use. BPMN is a standard. That’s the whole point.

Nevertheless, some readers will surely find that the BPMN tool they are currently using does not support all the shapes, symbols, and patterns described in this book. The most likely reason is that the book is based on version 2.0 of the BPMN standard, which at this writing is brand new. Tool vendors are often loath to advertise which version of the standard they support, so here is an easy way to tell.

If your tool can draw a shape that looks like this
eventgateway10
but not a shape that looks like this
msgthrow
then it is based on BPMN 1.0. It is fine for BPMN Level 1, but not the best for BPMN Level 2, since events that send a message and those that receive a message both use the white envelope icon and are indistinguishable in the diagram.

If your tool can draw a shape that looks like this
eventgateway1
or a shape with a black envelope like this
msgthrow1

then it is based on BPMN 1.1 or later. This is a better choice for Level 2 modeling, since it uses the color of the icon to distinguish “throwing” events from “catching” ones, and adds a valuable new event type, called Signal.

BPMN 2.0 is even better.  It adds an extremely valuable new class of non-interrupting events, describing common real-world behavior that was not easily captured in BPMN 1.x.  It also formalizes the metamodel and execution semantics, important to software architects, and adds a standard XML interchange format, important for interchanging models between tools. If your tool does not yet support BPMN 2.0, don’t worry. There are relatively few notational differences between BPMN 1.x [8] and 2.0, and even tools that claim BPMN 2.0 compliance still may not support all the new shapes and symbols. If your tool includes shapes that look like these
 
msgnonint  or  timernonint or  escalation  (non-interrupting events)…

then it is definitely based on BPMN 2.0.

BPMN’s Unlikely Road

The ability to go from documentation of as-is process flow to executable design of an improved to-be process, within the confines of a single notation, is unique to BPMN. Nevertheless, BPMN’s road to widespread acceptance has been an unlikely one.

BPMN began as the visual design layer of a new type of “transactional workflow” system created by a consortium called BPMI.org, led by a dotcom-era startup named Intalio. Leveraging the distributed standards-based architecture of the web and web services, this new type of BPM would be a radical break from the proprietary workflow systems of the client/server era. One key difference would be making the process execution language - the code that runs on a process engine to automate and track the process flow - a vendor-independent standard. As it developed the language, called BPML, BPMI.org reached a peak of 200 members, essentially all the major software vendors except IBM and Microsoft.

Another difference would be business empowerment. “In a nutshell,” recalls BPMI’s founder Ismael Ghalimi, “it would allow less-technical people to build transactional applications by drawing simple flow charts.” [9] BPML would not be coded by hand, but generated from a diagram, which would also be standardized: BPMN. Existing process diagramming standards like UML were rejected as too IT-centric. BPMI demanded something more business-friendly. Howard Smith and Peter Fingar fleshed out the promise of business-empowerment through BPMN in a seminal 2002 book, BPM: The Third Wave. Although the book has been criticized for blurring the line between vision and reality, it correctly predicted that empowering business people to manage their own processes would be  critical to the evolution of BPM.

BPMI.org produced a spec for BPMN 1.0 in 2004. Ghalimi continues: “Among [the BPMI members were] very many process modeling tool vendors who loved the idea of a standard notation for processes, and very many workflow vendors who hated the idea of a standard language for executing them. The former understood that they could provide a lot of value around the core process modeling tool. The latter knew all too well that fragmentation of the market helped preserve the status quo…”

The central tension seen today within BPMN’s stewardship thus was present from the beginning. Originally intended as a business-empowering tool for process automation, BPMN was instead embraced for non-executable process description and analysis, while BPML - the “code” it automatically generated - was seen as a threat by workflow automation vendors once they understood the implications of standardizing the runtime.

As it turned out, no one had anything to fear from BPML. IBM and Microsoft countered with BPEL, a slightly different language layered on top of the new web services standard called WSDL. In an instant those two vendors trumped 200, and BPML was effectively wiped out. In 2005, needing a new home, BPMI.org was absorbed into the Object Management Group, ironically home of the spurned alternative, UML. OMG formally adopted the BPMN 1.0 spec in 2006 and a minor update, BPMN 1.1, in January 2008.

It’s a familiar cycle in the world of IT standards, one that normally leads to quiet oblivion. By the end of 2008, however, against all odds, BPMN turned out to be not on the road to oblivion but approaching a tipping point of mass adoption. And here, most ironically, the credit has to go to those proprietary workflow - today we would call them BPM Suite (BPMS) - vendors who supposedly hated BPML from the start! Along with Intalio, these vendors were the ones who developed and widely disseminated free BPMN tools and popularized the notion of business-IT collaboration via shared BPMN models. Savvion, TIBCO, Lombardi, Appian, BizAGI… thank you!

The explanation is simple. Smith and Fingar were right… sort of. Business empowerment is the key to BPM, and BPMN provides that - not the executable code, but the precise flow logic that code would have to implement. Even though the BPMN specification makes no explicit distinction between its elements that are part of the process model and those required for executable design, it is pretty obvious which is which. The “model” elements are essentially those displayed in the diagram; the execution-related elements don’t appear in the diagram, but are captured in the XML underneath.

The BPM Suite vendors simply adopted the modeling parts of BPMN - the diagram - and ignored the execution parts. Executable details could be added to the process model, but each BPMS would do this in its own way. Thus BPMN 1.x today - as implemented by the majority of modeling tool and BPMS vendors and as it is actually used in practice - is not by itself executable, although it is incorporated in many vendor-specific executable design tools. And that suits the vast majority of process modelers just fine. Few are even thinking about execution in a BPMS, anyway. They are business analysts and process architects, not developers.

That summarizes the current situation, but it’s not the end of the story. Now BPMN 2.0 is on its way. It will deliver at last a key missing piece, an XML interchange format for BPMN models. It’s amazing that BPMN has achieved the success it has without that feature, but somehow that was never a priority at either BPMI.org or OMG. The new version will also connect BPMN with OMG’s broader Model Driven Architecture (MDA) efforts by means of a formal metamodel.

In fact, it was OMG’s original intention that this metamodel, called BPDM, would redefine BPMN 2.0, taking the emphasis off the particulars of the notation and placing it on abstract semantics that could be mapped to any process modeling language. That was a bit too abstract for three BPMS heavyweights - IBM, Oracle, and SAP - who countered with a rival proposal that formalizes the execution semantics of BPMN itself [10]. Their vision would return BPMN to its roots, as a business-friendly graphical front end to a standardized process execution language! In the end, the BPDM team withdrew their submission, electing to merge their ideas into the IBM-Oracle-SAP proposal, which is now BPMN 2.0.

The notation is mostly unchanged from BPMN 1.x, but there are some valuable new event types and, of course, the long-awaited XML interchange format. Most of the change from BPMN 1.x to BPMN 2.0 concerns executable BPMN, but even for non-executable modeling, BPMN 2.0 is a big step in the right direction.

In world of BPM tools, BPMN 2.0 marks a tipping point. BPMN 1.x adoption was spearheaded by the small BPMS “pureplay” vendors.  With BPMN 2.0, the biggest software companies in the world are leading the charge. Going forward, if a process modeling tool uses some other notation, it will be seen as “proprietary,” “legacy,” or some other euphemism for software dinosaur. Somehow, against all odds, BPMN has become the important standard in BPM.

“Business Modeling” Is More Than BPMN!

Business architects and other BPM practitioners never cease to remind me that process modeling, as defined by BPMN, is only one component of the business modeling needed to properly describe, analyze, transform, and optimize a company’s business processes. I don’t disagree with this. BPMN really just describes processes in terms of their activity flows. That alone encompasses quite a lot, but admittedly more information is needed to do BPM.

So what is missing? I asked Brett Champlin, president of the Association of BPM Professionals (www.abpmp.org) and a BPM practitioner himself at a major insurance company, what information, beyond that captured by BPMN, needs to be modeled to support a process manager in an enterprise BPM program. He gave me a long list, which I have rearranged as follows:

Enterprise or Line of Business

  • High-level business context, describing the business’s relationships to Competitors, Regulators, Suppliers, Business Partners, Customers, Community, etc.
  • Strategic Objectives and Performance Metrics
  • Controls and Constraints
  • Markets, Customers
  • Products (goods and services)
  • Locations

Operational, Cross-Process

  • Value Chains and Process Portfolios
  • Operational Goals and Objectives
  • Policies
  • Performance Metrics and KPIs
  • Organizational Structure and Roles.

Process-Specific

  • Activity resource requirements
  • Revenue and Costs, both activity-based and resource-based
  • Job Aids (instructions for human performers)

Technical

  • IT Systems
  • Services
  • Data

Each of these items can be described by one or more models and attachments, linked in some relationship to the BPMN model. The fact that BPMN itself does not include them is not, in my view, a deficiency. In fact, a single standard describing all of these models and their interrelationships would be nearly impossible to create. A key reason why BPMN is so widely accepted as a standard is that it does not attempt to do too much.

Business modeling, or BPM at the enterprise level, generally requires a suite of tools built around a repository, a database that maintains the relationships between all of the different models, along with governance and change impact analysis. So-called Business Process Analysis (BPA) suites link the BPMN to models of business rules, organizational roles, strategic goals and problems, and master data. Enterprise Architecture (EA) suites link the BPMN to technical models and executable artifacts. The boundaries between these tools and suites will likely blur as vendors begin to implement “executable BPMN” in version 2.0.

Keeping Up With BPMN Changes

As this book goes to press, BPMN 2.0 is entering the Finalization Task Force (FTF) phase, the final stage before official adoption by OMG.  It could change a bit in that phase, but typically such changes are minor. In order to keep up with these changes, as well as news about tools that support BPMN 2.0, initiatives to promote BPMN tool interoperability, and other information relevant to the BPMN modeler, readers are referred to the website for this book, www.bpmnstyle.com.

 

Bruce Silver
June 2009

 

 [1] “Public” to OMG members only.

[2] See www.omg.org or www.bpmn.org.

[3] This is not the same as choreography as defined in BPMN 1.x. Message flow interactions between a process and external entities are now called collaboration. In BPMN 2.0, choreography is an entirely new conceptual/notational framework. It might become an important part of BPMN someday, but it is not a concern of process modelers today, and we ignore it in this book.

[4] Online, classroom, and train-the-trainer. For more information, see www.bpmessentials.com

[5] Private classroom training and consulting. See www.brsilver.com/wordpress

[6] Public 2-day classes. See www.bpminstitute.org/index.php?id=523

[7] Pre-release of Process Modeler for Visio 6.0. See www.itp-commerce.com for more information.

[8] BPMN 1.2 is virtually unchanged from BPMN 1.1, which is more widely adopted. In this book I refer to them collectively as BPMN 1.x.

[9] For a firsthand account, see Why All This Matters, Ismael Ghalimi, http://itredux.com/2008/10/24/why-all-this-matters/

 [10] Author’s note: In December 2008, toward the end of the drafting cycle, I joined this submission team and have tried to represent the interests of business analysts and process architects - the actual users of BPMN today - in the final specification.


 

2 Responses to “Preface”


 
  1. Patrick Podenski says:
    July 3, 2009 at 10:06 am

    In Chapter 2 BPMN Level 1 By Example, in Figure 2-9 Order process in collaboration diagram the event ‘Receive Order’ seems inconsistently named to me.

    While the name ‘Receive Order’ is consistent with the VERB-NOUN naming pattern for an activity, I would have expected the event to be named ‘Order Received’ which is much more consistent with the naming of other events in Chapter 2.

    I would like to say that this book is the best I have seen on the subject of BPMN. Your examples are excellent!

    Thank you for writing this book.

  2. Patrick Condon says:
    August 12, 2009 at 4:53 pm

    Bruce, it would be great to have a Kindle version of your book. Of course, I bought it on Amazon.com anyway, but wish I had the instant gratification of reading it tonight!

Leave a Reply