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.

The idea is to extend an abstract syntax, that defines a Domain Specific Language (DSL) – for example a finite state machine language – with a model that describes runtime instances of the model (including state, counter, … ) plus a declarative (in this case even graphical) model for the behavior of the model simulation.

What I like in the idea is the thrive to make the DSL architect more productive in his work by relieving his duty to implement a model interpreter or model to code translator, if he invents a new DSL. By this, he can write a new DSL (like for example BPMN 2.0) and would be able to simulate the behavior of the execution semantics without implementation work – just by declarative modeling. That is the promise of the approach.

One could discuss, if the chosen Language MAction is the best way to describe model execution semantics, but at least it has to be taken serious. For me this is an interesting DSL prototyping environment. If one looks at model execution at runtime, I do not think that the Eclipse Environment is the right architecture for this. But it is a start – as I said – for DSL Prototyping. Other points that should be discussed in the future in my opinion are:

• Runtime Optimization for the Model by adding shortcuts in the Runtime Model
• Modeling of big examples (like BPMN 2.0) with the new language
• Evaluation of different ways of describing the Model Execution Semantics

References

Soden, M., & Eichler, H. (2009). Towards a Model Execution Framework for Eclipse. First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA) (S. 57-71). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.

UML State Machines were discussed for the purpose of behavior modeling. It was rightly pointed out, that they have some severe weaknesses.

One weakness is that events trigger transitions, but if there is no transition with the event, the event is not inhibited. It just happens without any result.

A second weakness is the possibility of a state explosion in real scenarios. This can – in my opinion however – be addressed with state regions (see UML).

Another weakness is the lack of composition capability – i.e. the possibility to add a model part that does not modify another model part but has an effect.

I agree to these observations.

Furthermore It was distinguished between states that are actively set (like active or closed) and those which are calculated and whose transition are done by change of input values (like overdrawn or in credit with a bank account). While I see these differences as well, in my opinion they are not so strict. There are also cases where there is a state, that is changed actively (not completed) but the result state is calculated (partially completed, fully completed). For this case it was not taken account for.

As a solution it was proposed that protocol machines are constructed, that are able to Allow an event or Refuse or Ignore. While I can understand for what Allow and Refuse is needed (i.e. Buttons on a Screen) I see no direct use case for Ignore.

Also it was proposed a composition mechanism that provides for adding behavior to a model without modifying it. While I think this is pointing into the right direction and this should be achieved, I have doubts if the way that was presented was the solution. There were some ambiguities in the proposal – especially with regards to the question what the absence of a transition within a certain region really means (Refusal?)

All in all for me it was one of the most interesting presentations going into a promising direction.

References

McNeile, A., & Roubtsova, E. (2009). Composition Semantics for Executable and Evolvable Behavioral Modeling in MDA. First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA) (S. 41-56). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.

It was rightly stated in the presentation, that UML sequence diagrams are insufficient to model behavior and that a new kind of modeling method is needed. Also the lack of a modeling method for operations of a class was obvious – nobody knows in which sequence they have to be called – if not prose does describe it. Therefore a new modeling method was proposed, that displays classes as swim lanes containing the operation definitions of the class as nested activities containing actions. In this “action language” sequences can be expressed by arrows between actions of one swim lane and other swim lanes.

In my opinion this idea points into the right direction. Actions / operations must be set into relation with regards to their mutual constraints and a simple graphical notation for this is needed.

I did not understand however why it is necessary to distinguish between operations and actions, because in my opinion the actions in this method reveals details of the inner structure of the operations, which is in my opinion not relevant. Furthermore in my opinion the flow based modeling (arrows) leads into a model explosion, if big examples (business use cases) are modeled.

In my opinion the suggestion of (Engels, 2009) was more appropriate to the task in this aspect.

References

Engels, G. (2009). Keynote: Automatic generation of behavioral code – too ambitious or even unwanted? In M. Aksit, E. Kindler, A. McNeile, & E. Roubtsova (Hrsg.), First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.

Kalnis, A., Celms, E., Kalnina, E., & Sostaks, A. (2009). Behaviour Modelling Notation for Information Systems Design. In M. Aksit, E. Kindler, A. McNeile, & E. Roubtsova (Ed.), First European Workshop on Behaviour Modelling in Model Driven Architecture (BM-MDA) (pp. 29-40). Amsterdam, The Netherlands: Centre for Telematics and Information Technology Workshop Proceedings.

The second Presentation was about Weaving Executeability into UML Class Diagrams from Elvinia Riccobene of the Universtià degli Studi di Milano, Italy.

The introductory criticue about describing object contracts with a constraint language only (like OCL – or pre- and postconditions of methods / operations as mentioned before) was, that it was not possible to change the state of an object or a system by a postcondition. It was said, that it was better to describe this in an Abstract State Machine (ASM).

An ASM does not only describe preconditions for the execution of a function, but also the transition of the state – i.e. it is directly executable – platform independently (and thereby simulateable).

My personal opinion about this is, that in modelling the behavior of a business object a certain kind of nondeterminism is needed. For example if there would be a function “check credit limit” for a customer – this can be quite complex in terms of business functionality. So in an ASM you have the choice to model all the complexity of this decision, but then it is not a model any more, but it is the system implementation itself. So there is no other way than to do an abstraction and only model that ther outcome can be (granted, denied) or (granted, denied, manual decision needed) or whatever decision result needs to be modeled. If that is true, even in the ASM some nondeterminism is needed, which leads to limited executeability (i.e. a user must decide or chance or some simplified algorithm or the formalism is used for state space search).

But then the difference to modelling postconditions is not so big, because, the postcondition only states as well, that the result of the operation can be (granted, denied) or (granted, denied, manual decision needed). If the result is unary, then also the postcondition modelling can be used for execution.

In the succeeding part of the presentation it was explained in detail how ASM and UML class diagrams (as one example of any metamodel) can be weaved together to form new classes which are able to model the behavior in this language. But in my opinion first a common understanding on the more fundamental questions should be tried to reached, which I mentioned, before too much specific should deviate us from the discussion.

Why is it, that the structural aspects of software enjoys universality of modeling (UML) while the behavioral aspect does not (yet) and what can and should be done about it?

The same is – obviously – true for Web Service Descriptions. You will get a WSDL description which describes the syntactical aspect of the services, but the behavioral aspect is left undescribed.

The invited speaker was Prof. Gregor Engels, University of Paderborn about “Automatic generation of behavioral code – too ambitious or even unwanted?”

I am – as always – only giving my personal opinion here. I agree to the goal of behaviorable modelling. It was proposed, that preconditions and postconditions of operations should be used to do this. The advantage of the approach has been proposed to be able to become more specific step by step or level by level.

I mainly agree to the statement and I think it is pointing in the right direction. My personal opinion is, that preconditions alone are not enough, as long as they can contain every expression, because then they can not be linked with each other. Postconditions are in my opinion important, but they do not describe, how the state is changed by an operation. This is a difference to the ASM (Abstract State Machine) Approach, that was presented later and that I will discuss in another post.

Furthermore I think that code generation is the wrong way. The reason is, that code is too static to be extended later. A runtime model interpreter helps to avoid many problems, including extensibility and the deviations of models from the implemented reality. Furthermore in my personal opinion graph transformations should be avoided.

So this is my personal opinion about the first talk, which I think pointed into the right direction in general.

If there are many process instances in a system, it is also a lot of work to realign them, if necessary.

What do I mean by realignment of process instances?

For example, if there is a process instance – which is a simple example – that needs a one step approval in case of an order of below 1000€ and a two step approval in case of an order of 1000€ or above.

Now if there is an order of 900€ then there exists a process instance for a one step approval. If later the order is changed to have a value of 1500€, then the process instance needs to be realigned to have two steps of the approval.

The realignment can typically not be done from within the process instance itself.There is some logic needed, that does such a realignment and works in all cases. Furthermore as of my knowledge there is no generic algorithm to describe all needed realignments based on such changes. So the rule do assign one and two step approval to the values of below and above 1000€ is not enough. It is further necessary to describe the realignment logic.

This is especially challenging as it depends on the state of the process instance itself.For example if the one step approval is the manager approval and the two step approval is the revision department approval which has to take place before the manager approval. Then it may challenging to realign a process instance in the case of a value change, if the manager approval is already in progress, because a different step has to be inserted before.

So the process instance realignment problem is not simple, but a solution is needed, as soon as there are process instances in the system.

The more process instances are created in the system, the more care needs to be taken that they all are managed correctly. Some unwanted effects may occur:

• An event is not correlated to the process instance it should have been correlated to (e.g. because of wrong correlation rules)
  • As a effect the event disappears without any effect.
  • As another effect the process instance, that the event should have been correlated to is stuck in an unwanted state.
    • A subsequent event, that is correlated again to this process instance, may find the process in the wrong state, causing more problems.
• An event is correlated to a process, that it should not have been correlated to.
  • As an effect the event is consumed and may not be correlated to the process instance, that it correctly should have been correlated to.
  • As another effect, the event will cause a problem in the wrong target process.
• Process instances may be started, even if there is already a process for the same thing, because of wrong correlation rules.
  • This may lead to starvation of other processes.
• There is no guarantee, that an event is correlated to any process.

So in the end there may be a system with many problematic process instances. Especially if not care is taken, that the correlation rules are absolutely consistent. This is difficult to achieve, especially if they can be maintained independently from each other.

So many problems? Well, at least problem recognition is the first step to the cure.

• structured,
• unstructured and
• semi-structured

processes, that I like. It is interesting, that in the definition of process the emphasis on the post is less on the sequence of activities, but more on the business goal to reach. That was, what I proposed earlier. And it makes sense. In the end it is more important, what the result of a process is, than what has been done or should be done in which order to try to (!) achieve it. I said “try to” because sometimes just doing a thing can not guarantee that the desired result is achieved. That’s why I say that the result is more important than the doing of an activity or task itself.
Of course it is inevitable that when a business process is implemented in an business process platform, that it is structured. Otherwise it is impossible to implement the business functionality that transforms the business objects that are part of the business process from one state to another. That is said modulo that there may be some generic functionality like a process engine for workflow or generally for execution of modeled process parts of course.
BPMN supports some Ad-Hoc modeling cababilities. There are Ad-Hoc tasks where the sequence is not defined or where it is not defined if none, one or all of them are executed. However one would expect, that any task that can be executed is modeled – at least if it is not, it can not be system supported. Also it is a difference, if the Ad-Hoc cababilities are on the process type level, or on the instance level, meaning that a concrete process instance can be adapted to a new, unexpected flow, sequence or even new Ad-Hoc Tasks.
However the more the tasks become Ad-Hoc the more they become an empty shell. What do I mean by this?
Create an Ad-Hoc task “Calculate stock losses based on financial crisis”. Of course if this is done the first time, there is no busines logic implementation for this. Even if there is a SOA service offering the solution, there needs to be some implementation of calling the service, which means gathering and providing the needed parameters and using the result in other processes.
So – as soon as a process is implemented in a business process platform it has at least some constraints.
Which is ok – because it has been formalized, because it’s execution is more repetitive.
On the other hand especially in times of crisis the importance of Ad-Hoc processes grows to account for the need to compensate unforeseen difficulties in the daily “business as usual”.
The important thing is, that the structured, the unstructured and the semi-structured processes can be integrated as seamless as possible. This is only possible, if there is a common notion of result of a process or of an activity in the process. Furthermore it is an interesting question – especially in semi-structured processes – how much constraints are desribed.

• None Constraints: Unstructured.
• Some Constraints: Semi-Structured.
• All Constraints: Structured.