Short description

The training explains how BPMN 2.0 can be used for these purposes: “documentation”, “specification”, “model execution” and “model driven development”. The goals for modeling are transparency, integration and flexibility.

The model types of BPMN 2.0 and their purpose-driven application will be explained. You will learn how to use the right modeling elements for the right purpose. You will learn how to assure the quality of the models and how a guideline will support your model creation.

The guideline taught in this training has been proven to achieve short modeling project duration and high customer satisfaction even for difficult modeling tasks. It is based on deep experience in the bpm modeling space and in bpm mentoring.

The training will be in german.

Audience

The training is ideally suited to give you a start in BPMN 2.0 and to have an overview afterwards.

Day 2 is also suited very well for those who already know BPMN 1.x and to learn the new modeling possibilities with BPMN 2.0.

For project leads, members of a modeling project, business process architects, director business process management, business architects, system architects, SOA architects, quality managers.

Dates

Registration and Details

http://www.adapro.eu/site/seminar/SEM-BPMN

He argues, that taylorism is good, because it makes work effective, predictive and scalable – which are in essence the same arguments that Taylor himself brought up – that´s why it is called “Taylorism”.

My answer to this is: It depends. Taylorism is not a good thing per se nor a bad thing per se. It is a good tool if it is used for the right purpose but it is a bad tool, if it is used for the wrong purpose. Take for example physical production of goods – cars, machines and jewelry for example. The production of these typically follow different production types. Cars are typically produced with the production type of line production (Linienfertigung) (this is where all the “Toyota production system” and “Lean Production” ideas come from). Machines are typically produced in job shop production (Werkstattfertigung) and jewelry is typically produced in manufacturing production (Manufakturfertigung). All of these production types follow different rules and management principles. The key is to use the right tool for the right type of product. It is not right to conclude from the fact that line production is good for cars that it is good for jewelry as well.

Now in the area of business process management we are talking in most part about intellectual work or brain work – not so much about physical production. We cannot conclude that if a management style is good for physical production that it is good for brain work as well. Also within brain work we have different types of work that require different styles of work. We cannot conclude that if a work style is good for one kind of brain work, that it is good for the other as well. We need to differentiate.

Yes, the discussions about Adaptive Case Management versus classical Business Process Management are sometimes heated – but I think this is fine. Sometimes it may sound like: “ACM is the only thing” – no – “BPM is the only thing”. Both is not true. It depends. So far we only had BPM and no ACM. So far we tend to see every problem as a nail because we only had a hammer. No – BPM is not the answer to every process management problem; especially not for knowledge work. So far there was no other solution. Now we have ACM – the new kid in town. Now we have more tools available and we are able to address more types of processes that we were able to address before.

BPM itself is a technology to make processes more flexible than – standard software. So BPM is more flexible than standard software and ACM is more flexible than BPM. We need all of the three. No one claims that we do not need standard software in the future. Nor anyone claims that we do not need BPM in the future – at least no one I know. But yes – we claim that we also need ACM in the future. It depends on the type of work. Knowledge work is clearly ACM. But there will also and in the future a lot of routine work that is best done by BPM or by standard software. In routine work effectiveness, predictiveness and scalability are the main attributes. But in knowledge work it is not. In Knowledge work problem solution, creativity and flexibility and goal achievement are the main attributes. These contradict with effectiveness, predictiveness and scalability to some degree. There are always work types that are kind of “in the middle”. For example customer problem processing. Who is more effective? The worker that solves 5 very easy customer problems per hour; or the one that solves a very difficult customer problem in three days? See – it is just wrong to measure work only by throughput.

So my claim is: The right type of tool for the right type of work.

It also depends on the degree of process maturity. If a process is immature – and we always have immature processes if we have innovation – then it is less predictable than a process that is mature. If it is a mature process, it is predictable and scalable.

This is why mature processes can be implemented in ERP Systems, half-mature processes can be modeled with workflow and immature processes cannot. However – now they can be managed by using ACM. In my view it is obvious that there are far more immature processes than there are mature processes. A typical employee has far more emails in his inbox than workflow items. Most of the emails represent knowledge worker processes – processes for ACM.

And – what we need is a “process funnel” – as I tried to depict in the diagram. That is – a process that today is a completely unmanaged process (only by email) should become an ACM managed process. After a while – if it is a mature process – it can become a BPM managed process (for example by exporting it from an ACM system and importing it into a BPM system). After a while – if the process has further matured – it may become part of an ERP system. This approach has the advantage that each step is easier than doing the whole thing from scratch. And only proven processes become part of the mature process landscape. But even then there will be new more unpredictable processes – and that is a good thing. Because they spawn creativity, challenge, competition, achievement and all things that make life interesting and companies flourishing.

An important aspect to this is, that the seamless integration best works if all of those levels follow some basic rules, that I call rules of adaptive processes (that covers more than just adaptive case management). I work to promote the concept of adaptive processes that is a holistic approach to the whole process landscape – be they standard processes, workflows or adaptive case processes – and makes all levels fit to each other.

It is not possible to map behavior.

Assume there is a given system landscape of different business systems each fulfilling a part of the business processes. Now assume the goal is to model a common layer of services around these systems, a SOA layer, and to map this layer back to the different business systems. The purpose is to allow flexibility in the underlying system landscape, because the SOA layer remains stable, even if underlying systems change.

I wrote about this already here.

The Enterprise Service Bus (ESB) is designated to fulfill the mapping job. This – often – is a naïve assumption. Why?

What is an Enterprise Service Bus able to do? It can route and transform messages (if we omit the discussion of technical adapters that is irrelevant for now). This is not very much. Message transformation is not enough for mapping the process logic of different application systems. Yes – they can map interfaces from one format to the next – if the mapping is easy. Even if we start to discuss structural transformations and key mapping it is not so easy – but I want to omit this discussion as well.

The point I want to make is about behavior. What is behavior? Behavior is the contract that a service provides to service clients with regards to the messages that it is able to receive or send depending on the state of the business process that the service offers. A service contract that only defines the signature of service operations (WSDL) is too less to understand a service. It is necessary to know if it is possible to send an order cancellation after an order confirmation has been sent from the supplier to the customer or if it is not possible. It is necessary to know if it is possible to send two purchasing change requests in a row, even before the first purchasing change request has been answered or if it is not possible. This is a contract that a service offers to its clients – and it has to be defined. This is behavior. A means to define such a behavioral contract is the BPMN 2.0 choreography and interaction modeling for example.

So – now – if one participant – the customer – of the interaction is able to send a cancellation of an order after the order has been confirmed, but the other participant – the supplier – is not able to process such a cancellation request, then there is no way to make this scenario work by mapping. What should an Enterprise Service Bus do in such a situation? The Enterprise Service Bus certainly does not solve the problem.

So – how can the problem be solved? The only way is to agree on the contract before the business system(s) that should interact are purchased or developed – or to be lucky and thus be able to configure each of the business systems to comply to a contract that is defined afterwards. But good planning is always better than hope to be lucky.

How can this planning be done? Use BPMN 2.0 choreography and interaction modeling.

I want to share some thoughts about it.

First Prof. Börger looks at some of weaknesses of the BPMN 2.0 Standard.

He sais:

The crucial criterion is how well the practitioner is supported when walking through the different levels of detail (refinement levels).

The standard does not support process structure at the risk of producing incomprehensible spaghetti diagrams.

The standard document fails to provide a seamless systematic mechanism for refinement from conceptual to executable models, which is necessary to guarantee the reliability of the implementation.

I discussed the same topic some days ago. I agree that the standard does not prescribe a solution to the problem, but as I said keeping some basic rules the solution is easy. It is always a question of discretion how much should be prescribed by a standard and how much should be described in a guideline or methodology or best practice how to use a standard effectively. There are always many ways to do it wrong, but as long as it is easily possible to do it right, it should not be such of a headache. As I said I will discuss the way to do it right in the seminar BPMNexpress. In general also I teach it also in the mentoring.

He also sais:

Furthermore a statistical evaluation (of BPMN 1.1) shows that `the average BPMN model uses less than 20% of the available vocabulary’ and that, out of the more than 50 graphical elements in BPMN, `Only five elements (normal flow, task, end event, start event, and pool) were used in more than 50% of the models we analyzed.’

Yes, and this is why it is possible to learn what you really need to know about BPMN in half a day. Of course full mastery is only reached within a longer process of modeling, mentoring and quality assurance. But this is normal with any modeling method.

The he talks about difficult modeling concepts in BPMN 2.0:

The lifecycle concept is an example of an underspecified feature, particularly in relation to the equally underspecified interruption mechanisms like exceptions or cancellation or compensation for transactions.

I have the same opinion. I tried to convince the BPMN 2.0 standardization team that these concepts are too difficult and problematic. Now I recommend to my clients not to use them. However for all of these problems, there is an easier way to solve them.

A general notion of state is missing and, as a consequence, the specification of relevant data dependent conditions is only poorly supported.

In fact BPMN 2.0 has a notion of state for data objects. This already helps a lot! I do recommend to my clients the use of state for data objects and it makes many modeling problems much simpler.

And yes, the state model is not very elaborated – but it can be extended.

Communication and process interaction are poorly supported for concurrent execution, e.g. of independent (not embedded) subprocesses or of processes belonging to different parts of one organization or to different cooperating organizations.

An analogous problem results from the poor interweaving of different BPMN diagram types, in particular that no consistency criteria are imposed for them, for example collaboration vs choreography vs process diagrams.

I do not agree at all. This is one major part of what is new in BPMN 2.0 compared to BPMN 1.x. I will teach this in BPMNdelta.

Later Prof. Börger looks at difficulties with WPI Workflow Patterns

The workflow patterns, as presented by the WPI, come without pragmatic or rational foundation. In fact there is no statistical underpinning showing how frequently which patterns appear in real-life business processes.

My opinion is that some of these are of practical relevance and others are not. I am preparing a publication on the topic, but it is not finished. Also most of these patterns that are relevant in practice can be reduced back to very simple principles of modeling.

Prof. Börger has the same opinion as he sais:

In fact most patterns are not of fundamental character but are easily definable from a small set of more basic and rather simple patterns.

In the last section Prof. Börger discusses YAWL and coloured petri nets. Some of his statements:

In this section, we show that the purported semantic foundation of YAWL using coloured Petri nets is not `suitable’ for the practice of BPM.

… deal with patterns that Petri nets have difficulty expressing, in particular patterns dealing with cancellation, synchronization of active branches only, and multiple concurrently executing instances of the same task.’

… languages which `lack the concepts to be able to deal with the broad range of requirements one may encounter when trying to precisely capture business scenarios’ directly applies to Petri nets, work flow nets, reset nets and other extensions proposed for modeling business processes.

I already discussed some days ago, why I would not build a new standard for Adaptive Case Management based on BPMN and I argued it is because of the “token logic” – actually what is meant is the petri net logic of BPMN. So we – Prof. Börger and me – have the same opinion on this if we refer to advanced scenarios. These are some of the topics that I will discuss in BPMfuture.

As I said BPMN is good for some problems, but it is difficult with more flexibility as it is needed for Adaptive Case Management and in general for the work of knowledge workers. Instead of building more and more complex formal constructs to address all of these special cases it is easier to not use petri net at all for Adaptive Case Management.

However I am more optimistic than Prof. Börger when we refer to cancellation scenarios and BPMN. Yes – he is right it is very difficult with petri net – but BPMN also has other features of modeling. It is possible in BPMN to use data objects and state – and therefore it becomes easier to model cancellation scenarios. I do teach this in BPMNexpress.

Finally he proposes to use a concept of introducing Product Lines to BPM. I have to study this more, before I say something about it.

I think we should not do this.

Remark: Re-reading Mr. Bartonitz Blog I must admit, that he did not propose to extend BPMN, but was talking about CMPM, the effort of the OMG to standardize (Adaptive?) Case Management. So it turns out – we – Mr. Bartonitz, me, and the OMG are in agreement of the future strategy. The only thing I have a different opinion is, that I think it is too early to standardize. However I leave my text in the blog to reason about, why a separate effort is the right way and to show how migration and integration can work.

I have a high esteem for BPMN if it is used for the purpose that it has been designed for. That is classical process modeling, workflow modeling, and a two phase lifecycle:

1. Modeling and deployment
2. Execution

This is what BPMN is designed for and this is where it works best.

On the one hand I understand the request of people to extend BPMN with modeling elements for ACM, because BPMN is what they know and people tend to love what they know. And this is a good thing! And even BPMN 2.0 is quite fresh on the market.

Adaptive Case Management is a completely different kind of process management. There are no two phases, but only one: Modeling and execution at the same time. It is MUCH MORE flexible than BPMN. If you do not understand this statement, please read the books “Mastering the Unpredictable” and “Taming the Unpredictable“.

There are many attributes of BPMN that are not needed in ACM, even are burdensome. For example there are now so many gateways and event types and modeling elements in general that are not needed in ACM. I estimate that ACM can live with between 5 and 10 modeling elements overall. It is a different modeling philosophy. BPMN`s execution semantics is flow based. I.e. workflow engines manage “tokens” flowing between the activities. ACM must not have tokens. That is my conviction. If we introduce token flow to ACM, then we have lost. The reason is it makes the model too inflexible. If you do not believe me, just model a single approval, and then start the approval and later on while it already runs, add another approval. You will see how difficult this is and that is because of token flows. There have been many scientific efforts to make this easier, but it is not possible. The token flow logic however has been grained into BPMN from the very beginning. I would say ACM is rather constraint based than token flow based.

There are other attributes of BPMN execution semantics that makes it unfit for ACM. For example a sub-process is completed if all of its subtasks (following the token-flow semantics) are completed. This is not the case with ACM. As I use to say: Not in all cases when you shoot you actually hit the goal. But this is grained into BPMN as well and it is impossible to remove it. All BPMN process engines have been built around these basic assumptions. I believe that an ACM engine has to be designed as a Greenfield approach and trying to change a BPMN workflow engine to make it more “ACM” like is wasted time. I think I have agreement on this with most of the other authors of “Mastering the Unpredictable” and “Taming the Unpredictable”. This is why I designed the AdaPro Workstream Platform from scratch.

Also I believe it is too early to standardize ACM. Tool vendors have to have freedom to design and apply the new modeling concept to the application domain first, and then later, when a lot of tools are around, it makes sense to define a common exchange format and standard.

Of course I believe ACM is backward compatible to a degree. That is – it is possible to import BPMN models into an ACM model snippet. I already implemented this in the AdaPro Workstream Platform. I think also it makes some sense to export ACM models to BPMN models. I also believe that it will be possible to model all kinds of predictable process models with ACM, but with different means than with BPMN. I also know that it is possible to use BPMN already today, so that it is “kind of adaptable”. Is this not a contradiction to what I said before? No! This is possible by defining a modeling guideline that restricts the use of modeling elements for a BPMN model to make it more adaptable and better suited for exchange between the ACM and the BPMN world. I already have defined such a guideline and I teach it in my seminars here and here.

So, I think what people want is a “smooth migration” path from BPMN to ACM, and that is a very valid requirement. And what they want is a “smooth” integration of ACM, BPMN and SOA. And this is even more of a valid requirement. I am convinced that the way to this goal is to first learn the “adaptive way” to model. Then, second, is to use ACM tools for real use cases and third to create a new Greenfield standard for ACM and fourth to define a model exchange between BPMN and ACM.

I disagree.

My modeling guideline gives some basic rules, and if they are followed, this does not happen.

• First it is important to distinguish between level of granularity and degree of detail. These are not the same thing.
• Second it is important to model the data objects and their state.
• Third it is necessary to model different variants of one and the same process in different models.
• Fourth we mostly do not work with sub-processes but with call activities
• Fifths we model the preconditions and the post-conditions of a process in such a way, that they fit together.

If these simple rules are followed, then I can guarantee a concise and well integrated set of models.

You can learn this and more in the half-day seminar BPMNexpress.

1. The Web Service Operations that are the interface to the application must be described as WSDL.
2. Technical Means must be available to connect the application to an Enterprise Service Bus (ESB).
3. WSDL is not enough, because it only describes the signature of the service interface. What is also needed is a model of the service behavior. The allowed sequence to call service operations must be modeled as business process model (for example BPMN 2.0 choreography diagram). For example it must be modeled if or if not it is possible to cancel an order after it has been released or not. This is not visible in the WSDL signature, but can only be visible within a service behavior model. And it is decisive to integrate.
4. The application should not be monolithic, but decomposed into components that represent individual process participants that communicate with each other in a loosely coupled way.
5. The granularity of the service operations must represent real reuse. This means, that the service operations may only do one thing at a time and not a chain or sequence of many activities. This is necessary to compose the service operations to new composed services. For example it must be a different step to create an order and to release it.
6. Extension Points must be modeled. Extension points are those points in an application process where extenders are allowed to attach an individual process. For example it might be possible to add additional an approval to a purchasing process. This must be modeled. Also integrity conditions must be modeled. For example it is necessary to have exactly one purchase order for individual purchase order confirmations. This is an integrity condition that must be modeled.
7. It must be possible to define new business objects or extensions to existing business objects.
8. All of this model information must be available in a repository.

This is my requirement list for a SOA enabled application. Yes, I admit, these are many requirements and I do not know one single software package that does fulfill them all. I know software packages that come close. I would not buy any software that falls short of many of these points.

I think most would say, that 1 and 2 is sufficient. I wouldn’t. I think that 3 till 8 is also necessary to make a SOA integration project successful. This knowledge often is only available through the individual knowledge of consultants. But there is no reason to not model it and thus make a SOA project much more economic.

In my first discussion with Max J. Pucher I said, that I still struggle with the “Case” in the “Adaptive Case Management”. He proposed the use of the term “Adaptive Processes” instead.

Later, following our talks, the audience also raised the same question. They said: Why “Case”? I said that a “Case” is the business object that is the reason to start an adaptive process or workstream. However the generic “pure” workstream would be a set of activities with status somehow (loosely) related – comparable to a workflow that is also not a business object, but a generic “pure” entity.

I believe that Case is a business object, and a Case may as well relate to Workstream or also to Workflows. The distinction between Workflow and Workstream in my eyes is this:

• A Workflow is a flow oriented model of interrelated Activities that is preplanned.
• A Workstream is a set of Activities, that is not necessarily preplanned, that are related, but not necessarily in a flow oriented way (probably in a constraint oriented way).

These two are generic while the Case is a business object of a certain form. For example there may be Customer Service Cases or Insurance Claim Cases – both of which have different attributes. The Case is the common super class of all of these possible variants of Cases and maybe their predominant commonality is that they can be related to a Workstream.

However why only Cases should be related to Workstreams? Why not Opportunities, Campaigns, Sales Orders, Logistic Orders, Accounts, and in general all Business Objects that may exist? I believe there are use cases for all of these business objects to be involved within an unpredictable Workstream.

That is the Case Part of the discussion. But there is also another part of the discussion.

As I discussed in Dead or Alive! I have the opinion, that it is also possible to define characteristics of Workflows and of SOA that make them adaptive. In this case we would have three categories of adaptive processes:

1. Adaptive Case/Workstream Management
2. Adaptive Workflow Management
3. Adaptive SOA

If this is true, then I would use the term “Adaptive Process Management” or “Adaptive Business Process Management” to name everything that falls into one of these categories. So an Adaptive Process would be either an Adaptive SOA process, an Adaptive Workflow or an Adaptive Case/Workstream.

I suspect that if Max J. Pucher sais “Adaptive Process” he means something within Category 1), while I mean all three categories.

So – I think there is still something to discuss before we have a common Taxonomy for Adaptive Processes and Adaptive Case Management.

Yesterday I was invited to speak at the BPM | SOA Integration Days, a conference that I really liked very much. My talk was about Adaptive Case Management and how it can improve the work of the knowledge worker – actually we had a whole afternoon about Adaptive Case Management. I also met Max J. Pucher who delivered a keynote. Hajo Normann also talked about the repetitive nature of predesigned forms and screens and how it quenches creativity.

At the end of the day there was a very interesting speaker panel discussion about SOA and about the question if SOA is dead or not. Does it add value? Is it too risky? Does a BPM model help or does it lead into a dead end, because it becomes too complex?

I did not join the discussion because I had to digest what I heard from the panel. But two points became important to me after thinking about what was said, that I want to share.

The first point is what I wrote about in Dead or Alive! Exactly the same discussion arose in the panel only with a little more pessimistic undertone. It seemed like doing the BPM model first before starting the SOA was a bad idea, because it inevitably ends up in complex unusable models and a long project. I was surprised by so much provocation, and part of it certainly was only rhetorical. But it underlined, that what I discussed in Dead or Alive! is very relevant. Also it seems to be some kind of gambling, if you get the BPM modeling project to be successful or not. What the “Adaptive Process” strives for is a guideline that will ensure process models that serve the purpose that is defined and be flexible enough for necessary changes. Not too complex, but enough detail for the purpose defined – in this case for the purpose of specifying SOA. I am convinced that it is possible to have such a guideline and the guideline that I am using in my projects so far works very well to serve the purpose. In the future I want to contribute some of these concepts to the discussion.

The second point I had to think more about. It was obvious in the discussion that it is hard to justify a SOA project within a company, because the big risk and the investment often is not outbalanced by quantifiable returns. One return surely is the reuse of components that is then possible and defined process exit and entry points – and therefore more flexibility. Another promise of SOA is, that it is possible to exchange underlying software components without too much impact on the whole landscape. The latter one I deem to be quite unrealistic. It only works if the new software basically does the same thing as the old software – which is very improbable in my eyes – and not a good case to buy a new one. So the main benefit is the re-use aspect. Now – considering this, I cannot understand, why the duty to do SOA is not more loaded onto the software vendors. I cannot understand, why a company does SOA all on their own. I would expect the software vendor to provide a software package SOA enabled and I would only buy it if it is. I would not do SOA without buying new SOA enabled software. Following this principle, the re-use aspect is much higher, because it is multiplied by the number of customers my software vendor has – and thus much more economical – also for me – because I am only paying a fraction of the whole SOA effort. I would only concentrate on interweaving SOA enabled components for my specific purposes – I think this is enough of a challenge.

Those were my personal thoughts following the very interesting panel discussion.

http://www.adapro.eu/site/seminar/BPMNexpress

http://www.adapro.eu/site/seminar/BPMNdelta

http://www.adapro.eu/site/seminar/BPMNfuture

The language of the seminars is german.