Don’t model Business Behavior in Objects!

During the past years I saw many projects where nearly any kind of business requirements was modeled into the technical object model, independent of the reason of the requirement. In many cases, modelling business requirements into a technical object model is quite ok and I agree with it in general. But also modelling business requirements into the affected business objects can lead into a ugly and complicated data structure. Let’s look into a short example to illustrate my thoughts:

Let’s assume we have an imaginary software project. The goal is to build an online-sales-system for a small car manufacturer who is selling sport cars. (May be, I’ve seen such a similar problem at a large car manufacturer in the past.)
Our system deals with cars and orders, so we can design a typical technical object for the order process into a data table like this:

The order table has an unique id, a modeltype, a price and a color. This is enough data to manage an order in our case. But in an agile software project, the business requirements typically change and evolve during the development cycle very fast 😉 So one day, the marketing team tells us, that the color of a car can only be changed by the customer until the car was ordered. We believe that this new requirement is essential and we begin extending therefore our existing technical object model by adding new attributes:

Our web developers ca easily check the new flag ‘isOrdered‘ to decide, whether  the color selector is still available in the GUI.

Modelling Business Behavior

What we have done so far, was adding a new business behavior into our technical object model by changing the database schema. Is that a wise strategy?The alternative that I want to propose here, is the design of a business process model instead of a object model. If we have a workflow engine, we could model the given requirement like this:

Now we have modeled the different business states into a new business process model called ‘Car order‘. The information, if the car is ordered or not has moved into a BPMN 2.0 business process model. A workflow engine can read such a model and synchronize a new process instance with this model. So when we now link our technical object model with the business process, we can still go on with our initial first object model version Table-1. Our web developers can simply ask the process state against the workflow engine to decide whether the color selector should be available or not.

....
// load a process instance by id...
workitem=workflowService.getWorkItem(id);
if ("Ordered".equals(workitem.getItemValueString("$workflowstatus"))) {
    ....
}

But a workflow engine manages not only the process flow but also all information about the process like the creation and order date, or all the actors involved into the process.

One Object Model – Many Business Models

Let’s go further increasing the complexity: On day, our marketing team brings up another new idea: VIP-Customers!

VIP-Customers should be allowed to change the color of a car, even 30 days after ordering. Back to the concept of modelling such requirements into the technical object model, this can lead to a more and more ugly data design like this:

We have added a new flag indicating VIP-Cusotmers and also additional data about the possibility to change the color. (Don’t argue about the data modelling here – this is only for demonstration purpose and we all know that data models can grow very quickly and can be designed in different ways. But this shouldn’t be the point here.)

Our CAR_ORDER table looks not very trustable, even if we split it up into different tables. And we can not be sure, that this was the last idea of our marketing team. But what would be the solution in case we use a workflow engine? The strategy looks very different.

The new requirement of VIP-Customers is in deed simply another business case. So we can create a different process model reflecting the requirements to those kind of new customers. Our new process model for VIP Customers can look like this:

This alternative process model defines now a new state ‘Pre-Ordered’. This task contains a timer event which monitors the order date and automatically updates the state of the order based on time period defined by the model. Again we do not need to change the technical object model here! We simply assign new orders for VIP customers with a different process model. Also our Web developer team has no need to change anything. Still the color selection is hidden if the status ‘ordered’ was reached. This all is defined by our new process model and can be controlled by the workflow engine.

One Process – Many Views

At least I want to extend the requirements once more to dive deeper into the idea of business process management. Our marketing team brings up a new ‘Family-Car’ Series. This is of course a fancy great new idea! The requirement is, that families will be allowed to change the color of the car even after they had ordered the car. But this change must be agreed with the production team. I’ll spare you the draft design of an even more crazier data model here. Let’s look like a new business process model will reflect this requirement:

What we have done here, is simply moving the task “Ordered” into a separate lane. A lane in a BPMN 2.0 model defines a specific actor in a business process. By moving a task into a lane, the task is assigned with a different actor. In our case the ‘Production Team’.

Human centric workflow engines like Imixs-Workflow are specialized in modelling such user centric behavior. Each task can be assigned to different persons, groups or roles. The access level can be modeled in a fine grained way, by assigning the read and write access to different actors.

So what we do here is simply changing the write access of the ‘Ordered’ task to our production team. This means that only the production team is allowed to modify the process instance during the task ‘Ordered’.

For our web developers this means, that they can ask the workflow engine if the current user is still allowed to change the process data:

....
// load a process instance by id...
workitem=workflowService.getWorkItem(id);
if (("Ordered".equals(workitem.getItemValueString("$workflowstatus")))
    && 
     (workitem.getItemValueBoolean("isAuthor"))) { 
   .... 
}

Now with this new process model, members of the production team will see the color selector and will be allowed to change the data, even if the car is already ordered. But the family members may only see a message to ask the Sales Agent if a further change of color is possible.

Note, that we still had not made any change to our original data model! But through the use of a Workflow Engine we solved three very different requirements with three separate process models!

Conclusion

What I wanted to show you here is, that modelling a business requirement in a business process can be much more efficient as in the object model. With the help of a workflow engine, you can change the behavior of an application without changing your technical data model. At the present time, where agile projects has become self-evident, a software system should provide the possibility to implement changing requirements independent of the technical object model. Workflow engines and BPMN 2.0 are a powerful extension to object orientated business applications. Think about that!