http://www.bpmn-selftest.org/

I made it to rank 14 of 394. However I wonder who the 13 were, that were better . So give it a try, maybe you can beat me. The test is anonymous however.

Nevertheless I want to share what I thought when I saw the models. They were quite complicated. I think if models are as complicated in a real project as those in the test, then something went terribly wrong in the first place. I agree, that it is fine for a research project to use artifical complicated models, to find out more about human model comprehension. And I am very interested in the research result. But models must be much simpler than those.

Simpler models could be reached by limiting the scope of one model – i.e. splitting it up in different parts, using submodels for example. As far as I remember human comprehension can assess 7 items at once, not more. So in essence I think a model should not contain more than about 7 important steps.

Also it can mean to model only the most important cases and model the special cases in a different model.

And it can mean to question, if BPMN is the right model language for the purpose chosen. I know that BPMN is popular and becomes even more, because it is a standard. But in my eyes the question remains, if the task flow oriented modeling it does is really the best way to do it. In my eyes it should be evaluated as a result of this research project, if goal driven and constraint based modeling would not result in much easier models.

So – it is very useful to have this tool for the top-down design of process interaction now. Inversely it can be used for the validation of an already existing bottom-up modeling. In reality it will be a mixture between the two. It is of central importance to have the enforceability in mind, that is to define a process, that is actually executeable by the participants. For this the model levels serve as basis for validation.

If we go down to the technical modeling, it is now possible to model Conversations, which are groups of Message Flows, Correlations, which are assignments between a message and a process instance, Service Bindings, Data Flow, … Compared to BPMN 1.2 the DataFlow is more than an artifact now (i.e. more than just a pictogram). It has a datastructure and the Activities have DataInput and DataOutput. Also the DataObject can be used as Parameterspecification for reusable Subprocesses. The Events have been enhanced. There are complex Events, Events , that can interrupt an activity or not, it is possible to define Event-Subprocesses that run aside from the Sequence Flow.

Here some critical comments from my side may be allowed. I think the workflow type of modeling is too strong in this. First there are strong sequence flow relationships established, only to be loosened later by many Events. I think it would be better for the future to define the relationships more loosely from the beginning. For example they could be modeled as preconditions depending on the status. That is something for the future.

Personally I found the discussion around the relationship between public and private processes very fascinating. One time it seemed like we had so many problems with it, that we could not do it. And additionally to this there was the climax of the debate with the concurrent submission. We were blamed, that our model was too strict. A very good discussion! But we found a very simple and elegant solution to these problems. The sequence flow is now not so strict than it was before. It has been loosened, and the difficulties disappeared.

Furthermore one important area is to have in mind the asynchronity of messages. That can produce race conditions between messages. However this in my opinion is not mainly a technical problem, but is due to the asynchronous nature of business processes, that I hope to discuss in the Blog as well in the future. Most problems on the message technology side can be avoided on the business process design level – and that is good news.

There are more changes from 1.2 to 2.0, but in my view these were the most important.BPMN has become quite powerful. Sometimes it is not so clear as to how to solve a certain modeling problem. However the success will depend on elaborating best practices and good guidance.

My wishlist for BPMN in the future? Modeling of Interactions with and of Business Objects. Find simpler ways to model special cases. Model a Process specific  Status.

But now is the time that BPMN 2.0 has to be used and proven in practice. After that we can establish our common opinion about the wishlist for the future. It is a language. And the vocabluary is only the beginning of the process to learn to speak that language. Therefore a good coaching process is what I can recommend.

This is my BPMN 2.0 Overview Map.

It shows a Choreography model in the middle, Orchestration with public Processes and private Processes, that belong to the public Processes.

Systems integration is the realization of the underlying business processes. This sounds so simple. But in reality there is often a misalignment between the business process design and the systems design. It is the wrong way to just implement business processes, that are as they are today or that are designed without discretion of the principles of loose coupling.

Often system designers need knowledge about how business processes work, but on the other hand business process designers need knowledge about how system integration works. As long as both sides are willing to learn and willing to share the knowledge, it is possible to come up with common principles of modeling, that avoid the most common mistakes, that lead to project cost overrun or failure.  I say it clearly what I mean: using BPMN 2.0 choreography modeling language in itself is no gurantee for success. But: It is a VERY useful tool for the communication between the business and system experts, which is a necessary condition of success.

So in other words, it is necessary, that the process design follows the principles of loose coupling of business processes. That is no design task, that can be solved by system designers alone, if the business process is modeled in a tightly coupled way. In other words: If the business process is designed in the right way – in the loosely coupled way – then the system design is without a hitch. If the business process is designed in the wrong way – there is no way to save the project on the system design level.

So are business experts forced to design business processes different, just to make the job of system designers easier? No. If it is designed that way, it is a better business process. It would work even better even if there was no system, but just paper and phone. It is more tolerant to errors. It gives the individual more freedom to decide. It makes it easier to reach the goal. Yes, it requires a little bit more brain power than just modeling the sunny day case. But in the end it pays off abundantly.

And in my eyes this is good news. It is NOT the system programming that dominates the design and dictates the constraints. It can be the business process needs again, that prescribe the way to go. And that is why BPMN 2.0 is so helpful, because it starts with the business process model.

If you are german speaking, you might like this short video explaning the new possibilities of BPMN 2.0.

Neue Möglichkeiten mit BPMN 2.0 from AdaPro GmbH on Vimeo.

First: What is the purpose of BPMN?

1. Description of as-is processes within a company and cross companies
2. Using the models for subsequent system development. The model is the high-level specification.
3. Execution of the model (for example in Appian Anywhere) – probably translation into another execution language like BPEL.
4. Model driven development of systems.

If we want to reach and achieve the fourth step, it is clear, that the execution semantics must be clearer as before – unambiguous.

On the one hand it is required to have “soft” models in the description of as-is models and also shall-be models. This will be so in all future. But especially the connecting of business domain models with system models within a holistic model cycle is a new level of effectiveness that we set our hope to.

In my opinion, this hope is not in vain.

Furthermore a complete meta model is needed for model exchange. This is – in my opinion – overdue anyway.

Why do we model at all? We want to utilize and connect flexibility with quality. This is reached by transparency. Only by transparency it is possible to execute the needed quality assurance on this level. If this is connected with model execution or model driven development, this is even better. We have laid the foundations.

This sounds quite enthusiastic. However I am a notorious BPMN critic. Even now more than enough critics comes to my mind. However I am exhilarated what we have reached within the scope of BPMN 2.0. We have made enormous progress in some key areas. I will elaborate on this in further blog posts.

So if in this example the incomplete model is validated against the meta model, then it fails, because the meta model requires at least two participants for the conversation node. However it makes completely sense to have the cardinality 2..* in the metamodel, because there is no meaningful Conversation without at least two participants. A possible solution would be to water down the metamodel. This is not discussed for BPMN 2.0, but may be for XPDL.

So in this watered down metamodel the participants cardinality is only *, allowing for 0 participants as well. The validadion succeeds, but the semantic suffers. Furthermore the check has to be done whatsoever at some stage. So watering down the metamodel is not a good idea in my view. Instead the solution should be a model lifecycle.

In this proposal the model itself has a lifecycle, which can be active or inactive. If the model is inactive, the validation reacts gracefully against the metamodel. Only if the model is active, the validation fails, but this is indeed intended. So it is unter the control of the modeler, if he wants the full strength of the validation or not.

Such a model lifecycle is not planned in BPMN 2.0 as far as I know, but I think it is a good idea and should be considered. There is a MOF 2.0 Facility and Object Lifecycle Specification that might be considered to be used in order not to invent something new that exists already.

In the BPMN 2.0 Spec there is a proposal, that builds on a generic OMG proposal, which is not finalized and which will be standardized independent of the BPMN 2.0 standardization.

In this proposal the idea is to have a Diagram Interchange Model independent from the Domain Model, which is in my opinion, a good idea. It is generic, so that other diagram types could be modeled. The diagram validation is done agains a so called Diagram Definition Model, which is also new. The Diagram Definition Model defines, which Attributes a Diagram Interchange node or connector can have, the allowed references and additional (OCL) constraints. Furthermore each Diagram Interchange node or connector is refers to a Domain Model class – in this case a BPMN Task or Gateway or Sequence Flow for example.

Advantages I see:

• Seperation of Model and View – Model maintenance
• Multiple Diagrams for the same underlying BPMN model are possible
• Generic format for different diagram types – tools can use synergies

Disadvantages I see:

• Tools vendors can not use XSD validation. They have to implement the validation against the Diagram Definition.
• The constraints of the Domain model (e.g. Sequence Flows can only be connected to …) must be repeated in the Diagram Definition Model.
• Grafical Attributes (e.g. line thickness) must be repeated as per modeling element.
• Attribute Format (name / value) too generic in my view.

The XPDL Format used to include the Graphics Info into the Elements of the Domain model.

This is simple and straight, and current tools support it, but has the disadvantage, that it is not possible to have one modeling element (e.g. one process) appear in different diagrams. Instead, the modeling elements must be repeated as per diagram, which has many disadvantages in model execution, analysis and model driven development. The Signavio modeler, which was discussed at the meeting, follows the same approach. However it is good as long as only diagrams are drawn for visualization purposes.

Because the BPMN Digram Exchange Proposal was too generic for some, Bruce Silver proposed an BpmnDI.XSD for a concrete XSD validation.

This approach repeats basically all or many BPMN domain modeling elements. This of course is the disadvantage, because it is but a redundant repetition of the already defined domain model. However it is no complete repetition, because the gateway type for example is not included. So a tool must look into the domain model anyway to render the gateway.

Within this discussion it came to my mind, how the GMF (Graphical Modeling Framework) solves this question. I think it is well worth to have a look at this approach, because I think it may be a good compromise.

The GMF defines a Grafical Definition Model, which only defines Shapes. This is simple to understand and straight. Then it defines a Mapping Model. Within the mapping models, nodes and connections are grouped as needed. For example it defines, that there is a node lane which can contain node Activity and Sequence Flow. As a followon the Acitivty node is connected to the Activity domain class and the Shape, that descibes how an activity should look like. The shape can be re-used, which is an advantage of the BPMN Diagram Exchange Approach. The Structures of the Diagram is already contained in the Mapping Model, so it can be serialized to XMI and XSD, which is also an advantage. However still the diagram logic is separated from the Domain Model, which is an advantage over XPDL. And it is a very generic model, which is an advantage over a mere BpmnDI.xsd.

I personally worked with the GMF, and found it quite practical. I am not proposing to use GMF per se, but maybe the approach should be further considered.

I must admit, I was a little bit surprised about the result. For me BPMN is not flexible enough and it has too many modeling elements. While this is not the majority opinion, a grave minority has the same opinion.

Some comments:

I think BPMN is great – but we just had to add on a few bits to define value add and non value add activities so that larger maps had more to narrow your focus on areas that need attention

Alan Crean, CEO @ Process Master

I agree that this is necessary to not overload the modeler with too many modeling elements.

Flexibility is a vague term that can mean many things in different situations. I would define flexibility as the ability to make changes over time as needed to respond to changes in the situation. In order to be flexible, there have to be constructs that afford the kinds of changes you will need. For instance, flexibility implies some form of control. A common pattern might be that parts of the process diagram are controlled by different people. There is no consideration in BPMN for specifying who has control over different parts. Instead, there is a built in assumption that the entire diagram is designed and maintained as a whole. That reduces flexibility.

Different people controlling different parts of the process diagram is definitely a very important part of the flexibility requirements I see. There is no concept in BPMN for this. It may well be, that it is not possible to add this concept later, because of the current semantic of BPMN.

I consider BPMN still more as a (high level) programming language for automated processes which provides rather poor support for flexible human processes.

I agree.

Just one examples of too less flexibility: Consider a process where one task can be executed by different roles (e.g. via delegation). In which Lane should I place the task? Should I show it in the “Default”-Lane? Or a copy in any other related Lane? Or even draw it across multiple Lanes?

While I know that Lanes are just a graphical partition of the process and we could easily address the problem via performers (BPMN 2.0), this is not a graphical solution. Many users (and tools too) use Lanes synonymous to performers.

Interesting case.

I guess it depends on the tool you use. We have created a new tool generation which hides the complexity of the BPMN notation against the user by using intelligent algorithms which support a highly efficient modeling process.
Our BETA was anounced on Nov 10. Innovator for Business analysts will be available shortly. C. Bergner.

It is worth trying. However my doubts are that certain limitations in the metamodel can not be overcome by a tool. However a tool can improve.

We feel the technology driven approach of BPMN when it comes to high level process landscape description. This seems to be out of scope at least in the BPMN 1.x standard.BPMN is good for visualizing low level processes that ar candidates for workflow implementations.

I agree.

It’s really interesting to see your opinion. In my opinion BPMN has a workflow modeling background. That’s why it is good for workflow type of processes. However there are a lot more of other processes.

Suddenly I felt like in a lively discussion about what I thought for some time about the inflexibility of BPM models (what if the approver is on leave?), the ad-hoc nature of real processes (like in a court trial) and the small amount of system support for these.

Yes, Business Process Modeling to a degree rests on the assumption, that there are repetitive procedures that are triggered by a business transaction, and which is described in terms of which steps to execute as a result of it. Like a machine.

Did you ever wonder why there is so little standard software for startups – or business process models? If it where a standard process, it were not a startup. The driver in the seat hopefully is the founder of the startup, not a process.
I agree to the observation, that there are much more processes like this all over the place. And maybe there should be even more again, reverting the feeling to be but a cogwheel in the engine, but a responsible contributor – even for the benefit of the whole.

Still, what we need to work effective is system support for

• our information
• Collaboration and Communication over the information
• a clear status of all of the process and all parts of it
• Decide about next steps as you go
• Decide about required information as you go
• Decide about groups and access policies as you go
• Decide about information structure as you go.
• Overview and Tracking

Only to mention the most important ones.

This is not what you can to with BPM . Therefore we need a new breed of software which is not BPM, even if it is related to it.

I want to mention two things, that were not or not deeply discussed in the meeting as an additional contribution and defence of what I said.

First: Even with all the ad-hoc type of processes it is clear that over time some of them evolve in standard processes, which is a good thing. Because that is the time to earn money for the process owner. So there must be ways to

• pick best practices and develop them into standard processes
• re-design a bunch of local best practices into a global standard process.
• impose constraints of a standard process on the business

All of that as you go – i.e. without interfering the running processes.
Which is easily said – sounds a little like marketing buzz – but certainly challenging in terms of technology. But I wouldn’t say it, if I didn’t think it’s possible.

In Process design and re-design I disagree here with Max J. Poucher’s more philosophical statements about evolution. I do not believe as much in evolution as an unguided process as he seemingly does. I believe that redesigning processes as a whole makes them more effective, and more rewarding to everybody if done right.

Second, I think that we need is a seamless integration (A word that you first learn in marketing) with structured processes – be they classical workflows or classical ERP processes. In my opinion there is much ROI to be found.

Related Blog Posts

Adaptive Case Management by Max J. Pucher

Complex Adaptive Business Process by Max J. Pucher

Ad-Hoc Processes by me

Intelligence in Business Processes by me

Compatibility of the services is not so obvious in the first place. The question to be answered is, if for all possible sent messages the other participant (or service) is ready to process it, and if both can complete their control flow in all cases. For example if one participants sends an order cancellation, but the other participant cannot process it, because the order is already delivered, and it has no control flow to deal with the late cancellation, then the services are not compatible.

Typically this can be checked by comparing all possible states of all participants and all messages. However this brute force method consumes much memory and computing time. Probably this is one reason, why it is not yet offered in so many or even a modeling product at all – which I do not exactly know. The proposed method in (An efficient necessary condition for compatibility, 2009) is to use a method known from petri nets: to convert them into matrices (state equation) and use the matrices to determine the compatibility in a much more efficient way. This is definitely interesting to consider.

The paper states, that this can be used for service discovery and mediator construction. In my personal opinion these use cases are very advanced research use cases, which are not yet so relevant in the practical industry application. Even the mediator construction I have severe doubts, if this is a way that will lead to somewhere at all. But I might be convinced later.

But very relevant is to support the design process of services which need to interact. If there were a repository, that would contain such compatibility determination method – that would be a great step forward. Furthermore it would provide the industry use cases that are needed for further research on the matter.

References

An efficient necessary condition for compatibility. Oanea, Olivia und Wolf, Karsten. 2009. [Hrsg.] Oliver Kopp und Niels Lohmann. Stuttgart : Universität Stuttgart, Fakultät Informatik, Elektrotechnik und Informationstechnik, 2009. Services und ihre Komposition, Erster zentraleuropäischer Workshop, ZEUS 2009. Bd. CEUR Workshop Proceedings Vol. 438, S. 81-87. http://sunsite.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-438/paper13.pdf.

Models must have a meaning within a context in the end, otherwise they are useless. For example what does a model mean, where there are acitivies like “go to the shop” and “buy some milk” and “pay”? It is a modeled description of what a person sometimes does, if he needs milk. But nothing else. The process model is to be used as documentation only. This is the context of the model. Such a model can not be used as a workflow. There is no need to create a workitem “pay” for buying milk. This is done by the shop’s design anyway. Also it can not be a web service orchestration description, because there is no web service “go to the shop”.

Modeling a process makes sense, if the context is know, in which the process will be embedded. The context is what I call an architecture. An architecture is a set of rules that determine under which boundary conditions a software system is to be designed. As part of such a design the design of a process makes sense. For example the architecture could be to design a system that is capable of performing the functionality of a milk web shop, that milk order and milk delivery are business objects that expose web services like “order” and “pay”, that there will be a workflow system that is able to compose these services – for example. The architecture are the rules that describe the creation of the system, the business objects, the web services and the workflow. These first need to be professionally defined and confirmed. They need to be obligatory for the whole project.

Only after that it makes sense to create models, which then will have a meaning within the context of the defined architecture. And therefore it is of very limited merit to “just model” or to train or coach modeling of a modeling language without a reference to a defined architecture or without the preceding process of professionally defining the reference architecture before. On the contrary – if the architecture is defined, then it perfectly makes sense to coach and govern a modeling process, because then there are the rules, that are needed for coaching and governance.

This is my opinion.