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
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.
thank you for your comment, I am not sure I was aware that Wil was aligned with the concept of BEL. Do you have specific references? Most of the BPM intelligentsia is conveniently ignoring the concept as it would amount to admit 20 years or more of erroneous work. That’s not usually what a scientist likes to admit.
There is of course little option to implement BEL and even BPEL engine vendors make it difficult to create the right articulation between BPEL and BPMN. We truly live in a surreal situation. So I am not surprised that people that use lifecycle often have to implement them in an “executable” BPMN environment.
Of course I do believe that it is very important to implement the BEL in its own container. A BEL is highly reusable and can be changed rather independently of the processes that manipulate them, and vice versa. This is key to BELs and information system construction in general. A BEL is self standing and independent of the combination of BELs that are associated within a business process. Tremendous benefits can be derived from such an application model when compared to CRUD or MVC.
I have provided comments on BEDL here: http://www.ebpml.org/blog2/index.php/2010/04/21/mde-bpm-ibm-s-bedl-analysis
Unfortunately the authors have chosen a very poor articulation to keep the brainless BPM people happy. I am sure there are many people at IBM who are against BELs, admitting that there is indeed a BEL independent of processes would mean that there entire career was a mistake.
yes you are correct, the problem lies exactly here. No vendor has yet delivered a combined engine to manage both the processes and the BELs.
The way I view it (after physically trying to use these engines on real projects -BPEL or executable BPMN) is that you cannot “program graphically". You very quickly his a “wall” drop from the graphical notation into some obscure vendor specific script.
So you are left with
a) build your engines yourself (task engine, process engine and BEL engine).
b) refactor the model of an existing product to make development easier using a textual-DSL (http://www.ebpml.org/blog2/index.php/2010/07/16/mde-more-evidence-that-xtext-is-pure-freedom)
c) use a code generator that generates executable directly from the textual-DSL
I am not quite sure why a vendor jumps on this, they could definitely create a competitive advantage as there is enough evidence now of the validity of the concept.
I had posted to Linked in a question “Has anyone got an example service portfolio that can be shared that demonstrates business entities mapped to that service portfolio?” in the Group “SOA Service Oriented Architecture Technology Architects".
I then found this article that I referenced in the posting. And I would like to raise the same question here. My feeling is an example Service Portfolio bridges this concept from theory to practice as it is services and operations that are designed and built.
I assume it would be hard for anyone to publish a service portfolio. All I can say is that I worked with a company recently that was using this concept successfully as a core design pattern for pretty much all their services. These services are of course very concrete and used in production to solve real business problems.