|« [SOA,BPM,REST] Nick's "Conceptual" Model||[MDE, BPM] Business Entity Definition Language »|
I could not agree more with these introductory statements about modern BPM:
data is treated mostly as an afterthought. Activities and their flows are the main abstractions and the data manipulated by the processes is essentially hidden in process variables...
Business Entities provide a new basis for specifying business operations that combines data and process at a fundamental level...
A Business Entity includes both an information model for data about the business objects during their lifetime, and a lifecycle model, which describes the possible ways and timings that tasks can be invoked and performed on these objects...
The lifecycle models are specified using finite state machines, where each state of the machine corresponds intuitively to a business-relevant milestone, or operational objective, that might be achieved by a Business Entity instance. Business Entities define a useful way to understand and track business operations...
four essential aspects of Business Entities: information model, (macro-level) lifecycle model, access policies based on role and lifecycle state, and notifications of state and data change events...
I like the general structure of the BE metamodel. However, I do find the Lifecycle part kind of weak. I would expect that even at this stage the team would understand and master the need for concepts such as pre/post conditions as well as pre/post actions (not just events, even though events are great of course). Introducing a "pure" state machine concept here is not going to drive the specification very far. Don't get me wrong, I am happy to see a company like IBM scouting the link between Business Entities (and BELs) and BPM.
As you can guess, the part that I really, absolutely, positively don't like is the link with BPEL. Frank Leymann continues propagating his legacy of force fitting an orchestration-based programming language into a "Business Process Whatever Language". It is impressive to see, even here, IBM feels obligated to honor this deeply flawed legacy, nearly 10 years after BPEL/BPML set foot in our industry. To reiterate my position, BPEL is a perfect implementation language for Business Entity Lifecycles, BPEL does not sit on top of BEDL, it sits within. IBM sees BEDL as a set of rules and constraints, not behavior. Yes, the Business Operation Model sections explains:
[A software component supporting BEDL (a BDEL engine if you will) supports] Request to execute a transition of a Business Entity instance from one state to another: This enables a process to move a Business Entity from one state to another. This includes the creation of a BE instance, that is, moving it from the initial state to another state. If the state change request violates the given BE lifecycle, an invalidState fault is thrown. If an access policy concerning guards is violated, an inconsistentData fault is thrown.
Yet, they explain later (can IBM do something without a database lock? -guys we are in 2010):
In a typical interaction between a WS-BPEL process and a BEDL component, a process will request to lock parts of one or more BE instances, access and possibly modify some of the attribute values held by the instance, possibly request a state transition, and then release the locks on the BE instances.
Unfortunately, I fundamentally disagree with that "orchestrated process" view of the world. As I explained several times and recently in my discussion with Keith Swenson, a process is observed, not executed. It is the mere flow of activities performed to transition BEs from one state to another (but controlled by BEL definitions) that can be represented by a process definition (expressed in BPMN). BPEL has nothing to do with "business processes" and will never have anything to do with it because a process is not orchestrated. This view of the world actually eliminates all the positive side effects of adopting a BEL view. BELs can be maintained and versioned very easily without disrupting in flight BELs, which is not the case of processes.
I'll pass on the BEDL language itself, I have no idea why someone would write a specification with just state and transitions, this is beyond simplistic. It is almost insulting to the readers.
The authors introduce yet another BPEL extensions BPEL4Data, to annotate BPEL definitions with BEDL semantics (states and what not). BPEL is so "extended" that one could finally conclude that its design was completely flawed. Thinking that a "Business Process Whatever Language" needs extensions to deal with Human tasks or Process Data is not just comical, it is ludicrous, and we have not even started to talk about B2B Collaborations.
The REST section makes sense to me, this is what I have tried to explain to the RESTafarians for 3 years now:
Conceptually, Business Entities can be made accessible as REST  resources. In the BPM context, the states of Business Entities reflect the progression of business data as it is “touched” by business processes. Thus, the lifecycle of the Business Entity provides a layer of business-relevant governance around the CRUD access of the generic resources managed through the Business Entity. Note we are drawing an analogy to the enablement of the REST “style” with Business Entities. This is independent and unrelated to the usage of REST as a data access protocol. How Business Entities enable REST-style BPM is discussed in more detail in .
Stu? Do you see the light now? Or are we still stuck at the "uniform interface" / CRUD level?
So in all, I have mixed feelings about this new initiative. There is the part of me that say, Yes ! Finally, BPM is going to grow up, a unified Service Oriented, Process Centric, Model Driven programming model is going to emerge quickly from this work and there is the part of me that say, No ! not again, why is IBM stuck on BPEL as a "Business Process Programming Language"? So I don't know where things are going to go. I would have liked to see a more complete Lifecycle definition, based on an explicit programming model, not just a State/Machine definition, this is way too weak to be useful. I also would have liked to see a direct connection between (human) activities and transitions between states. I am not sure why they go through so much work to publish something as simplistic and flawed as this paper. We are in 2010, guys, this is not 1995. That spec could have been written 15 years ago and even look a bit sexy, in 2010, this is just an homeopathic dose of Business Entity in an ocean of BPEL.
Hi, I am one of the authors of the article. Two things I would like to point out. The first is, yes, we have taken the behavior out of the BEDL and left it with the barebones states/transitions and constraints around that. The reason being is that there are lots of ways out there to express behavior, BPEL being one of them. If you look at Fig 3, you will note, how the BEDL can essentially work with a plethora of “behavior” types from BPMN, or a web-based UI accessing BEDL’s directly etc. So in essence we have followed a M-V-C split (with M & V in BEDL, and C can be your favorite control language), but in doing so I dont think we have lost the power of Business Entities to ensure the “behavior” is properly constraint and doing the right things. Also note that BEL “events” can trigger/effect process behavior. This brings me to the second point. Note the “Design patterns involving Business Entities and processes". Although it will be more clearer in Part 3 of this article series, what we are saying is that the BPEL with BEL no longer plays the “orchestration” roles, but gets “fragmented” around the entity states. Part 3 of this article will delve into the new set of patterns this combination can now enable. Agree with the rest of your comments :-)
thank you for your comment. As I explained in my analysis, I don’t see the light with Fig. 3. The whole point of BEL is to express behavior that is actually process independent. If the “behavior” is outside the BEL, what have we gained. The beauty of a BEL based model is that it is versioned easily (activities, states and transitions can be added or changed ad infinitum). Fig 3 keeps propagating the idea of a central coordinator of the process and see BELs as just an adjunct of rules, I am not sure I can ever agree with that view. It simply does not reflect the reality of a “process".
MVC is another hot button for me. The controller is the BEL, it does not sit outside the BEL. Once you transition to a new state, the BEL expresses which activities are “enabled” in this new state (and which ones are no longer available). That statement itself explains why MVC does not necessarily apply well in BPM: a) because the next view might be on someone else’s computer b) there can be multiple views possible (enabled), not just one. MVC is a technical pattern, not a business pattern.
>> Part 3 of this article series, what we are saying is
>> that the BPEL with BEL no longer plays the
>> “orchestration” roles, but gets “fragmented”
>> around the entity states.
I can’t wait to read that part.
Note, this rendition of BEL ensures that it can still be plugged-in with huge investments we already have around process-orchestration like technologies. Its value may not be significant in this “mode", but at least it implicitly forces the processes to be constrained by BEL’s and if I may use the phrase, “behave properly". Of course what we are hoping is that going forward the best practice would be more of a “holistic modeling” where irrespective of how you on-ramp (process-first or data-first) you end up with a combination model that (as you say) treats BEL’s as first class citizens. In article 3 we will try to cover such holistic modeling details and how it eases the modeling of very complex, generally ad-hoc processes.
yes, I understand the investment that IBM has made in traditional BPM models and I respect that. I can see how BEL can be used to establish compliance of a particular process (as it has been described by the work of Kesnia Whaler)
I am however concerned that the current paper describes a model where the lifecycle is only a set of rules.
I will patiently away section 3 before making further comment. Ultimately our industry needs a holistic model for BPM, stitching old bits with new bits does not help much, though I understand -of course- that people who have already invested may want to have an upgrade path and that’s very laudable.
jdubray - cannot agree with you more - my scenarios:
#1 In most organizations, the a “Business Entity” itself morphs into different BE(s) with business processes execution (duh, there was a reason why BPEL is named what it is)
e.g. employee’s pay in the HR department vs an expense entry into a ledger in the finance department or a product defined in terms of functional content vs product defined as designed parts … So, unless you draw definite boundaries around these morphing areas, and somehow be able to relate them together, pretty useless (considering we are in 2010 and looking forward) for the “Enterprise” and will create a lot of re-work managing changes and proliferation. It may work well, if we had a few of these identified (like ONE, with all of its variations). The “attribute/value pair” is over simplifying the problem and making it trivial and cumbersome for customers to manage (sounds like excel sheet replacements).
#2 Like most of these models, no direction in the level of detail - you can take this tool and hand it over to a customer and make a quick win - and walk away; people are going to figure out that BEs are either proliferating at godspeed or that they just cannot convince internal groups on what all does one BE mean.
#3 A very lateral sense of direction, Semantics / ontologies when applied aptly with BPEL/BPMN can void this whole move in a heartbeat - good luck adopting this !!!