During the past few years, I've seen many projects where nearly any kind of business requirement was modeled into the technical object model, independent of the reason for the requirement. In many cases, modeling business requirements into a technical object model is quite OK, and I agree with it in general. However, modeling business requirements into the affected business objects can also lead to an ugly and complicated data structure. Let's look into a short example to illustrate my thoughts.

Let's assume that we have an imaginary software project. The goal is to build an online sales system for a small car manufacturer who is selling sports cars. (Maybe 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:

Table 1.

The order table has a unique ID, a model type, a price, and a color. This is enough data to manage an order in our case. However, in an Agile software project, the business requirements typically change and evolve during the development cycle very quickly. 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 our existing technical object model by adding new attributes:

Table 2.

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

Modeling Business Behavior

What we have done so far is add 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 an 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 about whether the car has been ordered 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.

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

A workflow engine manages not only the process flow but also all information about the process, such as the creation and order date and all the actors involved in the process.

One Object Model, Many Business Models

Let's go further increasing the complexity. One 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 modeling such requirements into the technical object model, this can lead to a more and more ugly data design like this:

Table 3.

We have added a new flag indicating VIP customers and also additional data about the possibility to change the color.

(Don't argue about the data modeling here; this is only for demonstration purposes, 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 now looks not very trustable, even if we split it up into different tables. We can't 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 indeed simply another business case. So, we can create a different process model reflecting the requirements to those kinds 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 development team has no need to change anything. Still, the color selection is hidden if the status Ordered is reached. This all is defined by our new process model and can be controlled by the workflow engine.

One Process, Many Views

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 have ordered the car — but this change must be agreed with the production team. I'll spare you the draft design of an even crazier data model here. Let's look like a new business process model will reflect this requirement:

What we have done here is simply move 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 modeling 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 change 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"))) {
   ....
}

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 did not make 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 modeling 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 have become self-evident, a software system should provide the ability to implement changing requirements independent of the technical object model. Workflow engines and BPMN 2.0 are a powerful extension to object-oriented business applications.