If you start developing a business application you have two different approaches. In the first one – and this is the typically one – you start with the modelling of business objects. For example you have a “car” which can be easily modeled in a business object. You have a “buyer” and a “seller” which can be also simply stored into separated data tables. That’s it! It looks so easy to develop a business applications like in this example for a “used car dealer”. What you do is to describe the real things from the surrounding world into objects using a programming language of your choice. Today we have a lot of frameworks to map the real world things into databases and object orientated application frameworks. This all works well – at a glance. But as we all know, the real world is anything but simple. And in the moment when you realize that “used cars”, “sellers” and “buyers” have more complex relationships you need new objects like a “sales contract” and a “driver‘s license”. A “credit agreement” and a “warranty”. And you see that the things of the real world are not so easy as they seems to be in the first time.
A complete different approach to develop a business application is to get rid of the things of the real world. In this case you don’t look for what the persons do with the things. But you look for why they do the things they do. Now you are looking at the process behind the things in our real world – the business process. In the example of our “used car dealer” you can see a buyer showing interest in a car – his desire to buy. You see the dealer who tries to regulate the payment and all the things which can happen when you buy or sell a car.
Now when you try to model this in your business application your thoughts revolve around what people do and what happened during the entire process. And this is the idea of a business process application or a workflow application. Talking about the objects and data tables as we do in the beginning we now need objects like “events”, “activities”, “process states”, “actors” and “time ranges”. This is more abstract because we are now looking behind the things in your visible world. The funny part of this developing is, that you will realize that it does no longer matter if your seller sells cars or flowers or if you buyer is interested in a used car or a holiday travel. Your application becomes more abstract and you begin to model the real abstraction of the world.
When you start developing a business application in the second way you don’t ask your customer what the things are he what’s to save into a database. You ask him why he need an application to do his work better.
Take a look at our open source project Imixs-Workflow. It maybe can help you to get on that way.
Hi,
I have a confusion about second approach .
I have good idea about first way but no idea about second way . can you give a description
what is the benefit Ist over 2nd approach ?
The second approach allows the development of a database schema that is not bound to specific things. As a result, you increase the flexibility for future changes. What I want to say is: don’t concentrate so much in modeling things – better concentrate on the how and why we interact with things. Just abstract.