Carnets de bord

I built a simple business entity lifecycle example for someone who had some questions about the concept. I wanted to share it here since this type of concept is still foreign to most people in the industry. The example is about a stock order (buy or sell). At a high level, the lifecycle of the order looks like this:

The order is "prepared" by the customer, who can update it until it is submitted. If the order is a sell order, it needs to be "funded" before it reaches the "submitted" state. From there, the order is waiting to be "executed", the lifecycle allows the order to be "replaced", "revoked", "executed" or "expired". Once the order has been executed it will be settled and then "archived" for a retention period after which it is "deleted".

Business Entity Lifecycle provide a natural "service boundary" where most transitions correspond directly to a service operation. I cannot emphasize enough that orchestration languages (such as BPEL) are a reasonable fit for implementing a lifecycle and if you do so, you exercise one of the key fondamental difference between SO and OO, that is, an implementation element is defined at the service level (not at the operation/method level like in OO) as several operations point to the same implementation element, again unlike OO. When you use a traditional programming model, you spend most of your time, writing and rewriting a BEL engine. There is simply no other way, because this business logic is intrinsic to your information system.

What is interesting too is that each state defines the operations that are enabled (or disabled). They each correspond to a transition from the current state. So you have a very clear view of when exception conditions occur when operations are invoked outside of their desired sequence.

A key concept to understand is that the order lifecycle is independent of the business process that manipulates it. The same oder lifecycle should be valid for a high-frequency trading process, a retail investor process or a private banking process. In a high frequency trading context, some transition might have different guard conditions (for instance the transition from prepared to submitted is likely to be automatic. For private banking customers, the "funded" state might be reached before the funds are actually deposited in the brokerage account, and the "fund" operation might ensure that other securities will be sold to make the funds available before the settlement date. The bottom line is that a business entity lifecycle represents some business logic that is "business process independent". This is probably news to many of you and some of you might say that a BEL is a "long running process" but it is not. It is long running. It is a process in the sense of an operating system point of view (nearly), but it is not and will never be a "business process". The business process is represented by the activities (human or automated) that advance the lifecycle of one or more business entities.

Here is an example of a plausible "retail process", as you can see, it has little to do with the lifecycle itself (in blue the activities of the process, in red the operations invoked on the order service:

So today, you have at least 3 models to implement an information system:

a) CRUD / REST

b) MVC

c) Something I call WSPER ("whisper" stands for Web Service, Process, Event, Resource). WSPER is a programming model that supports this combination of business processes and business entity lifecycles

CRUD is the worst possible model, it works ok for business entities that have a CRUDish lifecycle (e.g. Contact). MVC is probably the most tragic mistake of our industry. MVC is a technical pattern. It is good for implementing the GUI part of an activity, but the Model is the model of the view not the "domain model" where Business Entities/Resources can be found. It does not understand anything about users, roles, activities, processes, services .... "Models", "Views" and "Controllers" have no physical counterparts outside the GUI they support. Both CRUD and MVC are responsible for the high level of inefficiency and the low level of reuse that our industry has experienced for decades. The translation of business activities, business processes and business entity lifecycles into CRUD or MVC code is highly inefficient, it leads to tons and tons of boiler plate code being written and rewritten, horrific patterns and frameworks, and ultimately, disillusioned business owners who see how inflexible the resulting solution is. CRUD and MVC code can't be evolved rapidly, and becomes brittle after a few versions.

I am not quite sure why our industry has not "discovered" these concepts yet. If you know the answer let me know. Ah... one more thing, the BPM people don't even understand this, they only care to sell you an executable process layer that dissolves the business entity lifecycles into the process definition. As you can see, that's fantastic for reusing the business entity lifecycle logic across business processes, not to mention when you need to change that business logic, I am sure you'd be jumping at the idea of changing the 15 processes that manipulate that particular business entity.

So why don't you give BEL a try next time? even if ultimately you implement the BEL with some CRUD/RESTful or MVC based programming model? Very quickly you will realize how powerful this concept is and you'll probably want to write your own BEL container or start using something like an orchestration language.