Why the obsession with object Life Cycles?

The less we understand something, the more variables we require to explain it.

-- Ackoff, The Art Of Problem Solving

The obsession of designing IT systems by using the notion of Life Cycles of business entities has bothered me for many years. This is not specific to IT but rather to modeling at any level within an enterprise.

Let me give an example of the absurdity of modeling a business by describing life cycles of business entities.

Say I'm planning to fly to London early tomorrow morning. A person of normal constitution would plan the trip according to something closely following the sequence:

·         Set the alarm clock

·         Go to bed

·         When the alarm clock rings get out of bed

·         Eat breakfast

·         …

·         Go to the car, start it and drive to the airport

·         Get on the plane

·         …

I can with almost certainty say that few, if any, persons would describe their plan in terms of the life cycles of the alarm clock, the car, the plane and so on. What I mean by this is that few persons would describe the trip in terms of internal state transitions of the alarm clock, the car and the plain. This sounds pretty obvious but it is not uncommon to do just that in many large IT shops such as banks.

Let's look at an example. A Financial Instructions in a bank can be seen as an object that transitions between states. For example, an instruction may be in NOT-VALIDATED state, then transition to INVALID state, continuing to REPAIRED state, VALID state, PROCESSED state and so on. Valid transitions are often described in a state diagram where events trigger state transitions. The state diagram is what is normally called the life cycle of the Instruction.

Now, let's see what's wrong with this picture.

If I describe my business in terms of life cycles of business entities I'll run into trouble. The reason is simple: the lifecycle of a business object is a consequence of one or more processes managing the object. Making life cycles of many business objects smoothly work together is a non-trivial tasks that inevitable will create a rats nest of design and code hacks.

When fusing a lifecycle together with an entity I effectively grab the entity and eliminate the chance that it can easily be used in some other processing or, even worse, modified to serve the business better. After all, I'll have to associate a state attribute to the entity keeping track of where in the lifecycle the entity is. If by any chance I one day decide that the entity is to be used in some other processing scheme, I'll have to add another state variable to the object which, by the way, must cooperate with the other state variable.

Clearly, this situation is non-manageable – so what's the solution? Let's start with looking at business processes as a potential solution.

There are two common views of what a business process is. The first one is simple. A business process is a sequence of events that are ordered in time. Processes are commonplace in everyone’s life. Waking up in the morning, starting the coffee machine, eating breakfast, showering and driving to work is part of a process many of us have to endure in everyday life. Whether the events are planned ahead or not, the events form a sequence that is ordered in time. They form a process.

A second – more meaningful – view of what a business process is goes as follows:In a business process exists for the purpose of achieving some goals that have been setup by a business. Processes manipulate business entities in such a way that they optimize some state of the business. Typically that state is called profit. In other words, the purpose of a business process is to move entities in a business to what would be seen as an optimal state for the business. Essentially, a process describes how you want the world – i.e. your business - to behave.

Does this not slap Object Orientation right in the face – having manager objects (processes) manage other objects? If we really want to get into semantics we can always say that a business process IS AN object that knows what and when something needs to be done. Separating the what and when from the how to do something follows good IT practice. The process knows when and what needs to be done whereas business objects knows how to change its internal state in a consistent manor. Isn't that what software design is all about – avoiding tight technical coupling between concerns that are not conceptually tightly coupled?

And by the way, why is Object Orientation seen as a sacred cow? Whatever OO means it should not be the guiding principle when modeling or developing software. The guiding principle should be to create simple and clean software.

Now, why am I writing a blog entry about all this stuff? The reason is that more than often designers, managers and architects enforce the view that business entities has life cycles. In a naïve simplistic view business entities do have life cycles, but only as a consequence of the execution of one or more business processes. It must not be the life cycles of entities that drive processes but rather the opposite - processes must drive sequences of state changes of objects which are often called life cycles.

At the end it all boils down to what perspective we want to take. Should we model our business by having a bird's eye view of the management of our business entities? Or, should be manage it as a bottom up approach where we start with the intricate details of business entities and work ourselves up. Viewing myself as lazy – hating to keep track of lots of state variables - I would go for the former approach anytime!