Frank Michael Kraft's Blog

If there is an architecture with a Business Process Platform, then there is the question, which role do the process instances play in such a system.

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.

If we look at executable processes, we will have process instances. A process instance obviously lives from the time, it is created, to the time it is terminated. During the lifetime of the process events occur, that need to be assigned to or correlated to a certain process instance, if not to many process instances.

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.

What is a Process? This discussion seems to be still ongoing, and I have my own take on this.

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.