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.

The business processes are reflected by business objects themselves, which are linked with each other. Events are correlated to the business objects. This makes sense, because the business objects are clearly identifiable, because they are related to a concrete business transaction. There are concrete customers related with it, suppliers, products, dates – the things that make them easy to identify and find.

In contrast, if there are process instances, which have only an anonymous ID, like a Globally Unique Identifier (GUID), then the relationship to a concrete business transaction is rather loosely. Therefore it is hard to manage them. Furthermore if there are business attributes inside of the process instance, typically they are in generic containers (not always) and therefore difficult to use in queries.

So which process instances are needed within a Business Process Platform beside the business objects themselves? Probably some for approval. Some for ad-hoc processes. Not much more comes to my mind.

Monitoring a business process itself is a different story. For this not process instances are needed, but chains of business objects that are actually process objects and some process instances – that I already mentioned.

• 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.

In Procedure vs. Process it is discussed from the angle of if it is a sequence or order of action or not sequence or order. Also Merriam-Webster dictionary is cited to say that a process is

a series of actions or operations conducing to an end ; especially : a continuous operation or treatment especially in manufacture

I fundamentally disagree with this definition. In my opinion the series of action is only one half of a process. The state is the other half. A process must always have a defined state. Either it is not started, it is finished or in the middle – in process. If it is in process, it needs to be further defined, what the detailed state is. So if a process is modeled in terms of actions, then the question is, which state do the individual actions have.

In the Blog Column 2 – links for 2009-02-02 we see the statement that refutes the difference between process and procedure as claimed by Procedure vs. Process . For my taste this is a little bit a too technical discussion.

I rather approach it from a little bit different angle. For me a busines process is the sum of all business objects and process objects that are needed to achieve a common busines goal, their state, their actions and the constraints between the actions and the state.

You might argue, that I define process by process – i.e. business process by process object. But they are different. Process objects are like workflows and have a rather small business goal , but a business process has a much broader scope. All process objects are small business processes, but not vice versa.

By such a definition I exclude such things like interactions with the system, because they do not have a state. So adding a sales order, saving it, adding another sales order and saving it is no business process by this definition, because it has not state and it does not achieve a common business goal. A business process would be to deliver goods which have been ordered by customer orders and bill them, and collect payments for them. This is a common business goal and the whole process has a state which is reflected in the state of it’s business objects, namely the customer order, the delivery, the invoice and the payment.

This may happen: The right means are used for the wrong purpose, and the result is a disaster.

I have already discussed, that the modeling purpose does determine the outcome of a modeling exercise.

So what happens, if you use the right modeling language for the wrong purpose? It ends up in spaghetti models.

If you try to use a BPMN model for the purpose of model driven development – as mentioned in the blog (i.e. to generate coding) – for a business process with many special cases, then the result can be a spaghetti model. But this is not because BPMN is not good, it is because the right means for the wrong purpose has been used.

What is the level of detail that should be modeled? By which modeling technique it should be modeled? These difficult questions are best solved within the scope of a model governance process. As soon as a model become a subsitute for coding only – i.e. it is not human readable any more – it misses it’s purpose. Then it would be better to code. A governance process makes sure, that it is still human readable.

Furthermore it needs to be considered, that BPMN is not the only modeling language in the world and should not be used for purposes, where other means are better. I will elaborate on this later.

In itself this is not sufficient to achieve a consistent model quality in designing BPMN models. More is needed. The missing element is a governance process.

What is a governance process in this context?

What you need to design high quality (BPMN) models is experience. It is always possible to solve a certain modeling problem is different ways. Which is the best way for which kind of modeling problem? Unter which circumstances is which solution better? Is a certain solution consistently applied across a large set of models, if the underlying modeling problem is the same? What are the modeling rules, what are the patterns?

Theoretically it is possible, that a single person has all the experience needed. But still then this single persons approach differs from an approach of another single person. Also it is not clear if this single person is always available. Furthermore we are humans and we err.

So the elements of a governance process, that produces consistently high quality in modeling are these:

1. A defined number of modeling experts with different background, which collaborate over a long period of time with some, but little fluctuation.
2. A defined review process with enought time to study a model for all reviewers (experts) and the possibility to accept or reject a model.
3. The possibility to raise issues, discuss pros and cons and find solutions.
4. A list of quality criteria, patterns and modeling guidelines which each model needs to fulfill. This grows over time by common action of the experts.

Each expert that takes part in such a governance expert council will learn from each new model review and the common expertise will rise. The quality level of models can be held consistently high. Futhermore is the feedback of such an governance expert council to the standard – in this case BPMN – invaluable, because they are those who find out even the subtle weaknesses of the standard over time. Each modeler, that commits to the governance process learns more than any theoretical class can ever teach him.

What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance [...] Kiran Garimella

from http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
That is an concise list of what is important within BPM, although I to not share the view of the author, that BPM is a kind of proces operating system. ImhO it is a design principle and a management paradigm. It must be supported by system design, to become effective, but it is not an operating system, upon which higher level solutions will be developed. Yes, it is an architecture – and the Business Process Platform architecture that I already mentioned is one important part of it. But it is not merely a separate software layer.
Now let us look a little more into detail of these elements:

Ad 1) Business Semantics.
It is obvious, that it is inevitable to take into accound the process, that is realized by Business Objects (Ordering, Selling, Payment, Stockkeeping, Billing, …) if the process semantics is important. Each of the Business Object types have a business semantics. Each of their states has and the actions, that can be performed with them (like release). It is not possible to ignore them, if an holistic view on the process semantics is necessary. The other way round said: It is often necessary to realize the process semantics by means of implementing Business Objects, because it is so sophisticated business semantics – if I mention prices calcuation for example.
Ad 2) It is impossible to do process design and not take into account the process, that has been implemented in Business Objects already – if it is not a very simple case like a very simple workflow. But even with a simple worflow, there often is a Business Object (Invoice, Project, Order, …) behind it. So the process can not be designed completely free, but within the limitations of the Business Objects, that are going to be used. Or the other was round: if the Process is Designed completely free, then Business Objects need to be implemented or extended to realize such a behavior.
Ad 3) Process Metrics.
Is it possible to think of process metrics and not take into account the state of Business Objects? Plainly said: No. It is relevant, if orderes are Released or not, if Invoices are posted or not and how long it takes from ordering an Order (i.e. reaching the state ordered of the Order) and posting an invoice (i.e. reaching the state posted of the Invoice). So process metrics need a tighter integration with Applications – in the form of a Business Process Platform BPP.
Ad 4) Process Goverance
Process governance can only be realized, if the necessary process metrics is provided. As a result of process governance, the process needs to be adapted. This can – in certain limits – be done by changing some modeled workflows. But often it is needed to utilize different functionality which is implemented in Business Objects or to adapt Business Object functionality. This can only be done, if the application has been built in a way, which makes this possible cost effectively – i.e. by conforming to a BPP architecture.
So the different elements of BPM can better be reached, if BPM is tighter integrated into applications – i.e. if applications are BPM enabled – and if a Business Process Platform (BPP) programming model is followed.

“By the year 2012, BPM will be subsumed into major applications.” Simon Hayward

See also:
http://www.ebizq.net/blogs/bpmblog/2007/03/the_death_of_bpm_it_aint_over.php
An interesting statement. Especially in the light of the remarks about “What is a Process?” that I made earlier:
http://www.bpmnforum.net/blog/bpmn/bpmn-in-research/what-is-a-business-process/
I suggested, that there are commonalities between Process Objects (Workflows) and Business Objects (like a Sales Order). They have a state, they have actions or activities, they have constraints. There are differences, but as long as we focus on the commonalities, we can think of utilizing this common ground for common frameworks.
Applications are made up of business objects and their relations. Very often these business objects are programmed. In contrast workflows are modeled. So if we can achieve modeling business objects in an application, then the business object model is the foundation for better integration of BPM functionality with the application. I call such a modeled application Business Process Platform or BPP.
To not remain too abstract, I make a concrete example.
Think of a Project Management Application, that has a Business Object “Project”. Now, a Project BO is created. Before the Project is released, there must be an approval. So – when does this Approval start? It needs to start, if the Project business object has reached a certain state – for example “Data Entry finished”. Only then a workflow or task needs ot be started. The workflow or task is what we traditionally understand as being part of BPM and what we model by BPMN for example. But if the state “Data Entry Finished” of the Business Object “Project” is also modeled, then the foundation has been created to use it in a generic framework, that enables BPM – for example by providing events to the workflow to start.
Furthermore if the Approval is finished, a subsequent step (action, activity) must be performed with the Project business object: Release, changing the state to Released.
That is a very simple example, but often difficult to achieve if not these preconditions are met:

1. The state of the business object is modeled.
2. The action of the business object is modeled.
3. The action is provided as web service
4. There is a generic framework utilizing it to make the integration of the workflow and the business object happen.

This can only be achieved, if an application is designed from the beginning to provide such modeling information. This had not been completely done in the past. But there is no reason why this should not work. However if an application fulfils 1-4 it should be called a Business Process Platform or BPP.

So with the upcoming advent of BPP, the Applications will be BPM enabled.

[ad]

There have been complaints, that BPMN 2.0 is only designed with the goal of defining an executable process modeling language and that this impairs the usage of the modeling language for the purposes that it is currently most often used for: documentation.
http://www.brsilver.com/wordpress/2009/01/19/bpmn-20-update/
The complaint is that a model would not be counted as valid, if it is not executable. The demand is that it should also be valid, if it is not executable.
To shed some more light on the issue it is necessary to discuss several aspects. These come to my mind immediately:

1. Choreography Modeling and Execution
2. The concept of enforceability
3. Conformance
4. Abstract Processes

Ad 1) A new feature in BPMN 2.0 is the choreography model. Modeling a choreography model with BPMN 2.0 means modeling an abstract process representing the view of an independent observer on the exchange of the messages that are exchanged between participants. This process is by definition abstract, because it is “in the middle between” the participants. So by definition such a process can never be executed directly or be executable. It can only be realized by means of processes within the participants. But the realization is not necessary for a choreography model to be valid.
Ad 2) Enforceability of a choreography process is an attribute, that holds true, if a choreography model can be realized at all. Not all choreography models are able to be realized. This is completely independent of any technology. It is because of logic only. To make an example If we define this process between John, Mark and Jane, which are in different cities: First John calls Mark and tells him the weather. Then after this Jane calls Mark and they plan the weekend trip. This process is not enforceable. Because Jane cannot know when John has called Mark. So to make the process enforceable, John or Mark need to call Jane to tell her, that John and Mark have phoned. Which of both is better is another thing – but the first process is not enforceable – completely independent of the technology.
So yes, there are some rules in BPMN 2.0 Choreography model that must be kept with a choreography process so that the enforceability is not destroyed. But this has merely logical reasons.
Ad 3) There is a difference between Process Modeling Conformance and Process Execution Conformance. Process Modeling Conformance does explicitly not require that the Process Execution Semantics is kept. However the Process Execution Semantics is most clearly defined. But because this is optional, it is only for those who want to execute. And for those, an execution semantics is very helpful.
Ad 4) Abstract Processes are Processes that have the process type abstract. By definition they are not executed as is, but they are an abstraction of the process, that is really executed.
Good discussion though and I might continue to post on this.