The Eclectic Zone

In what looks like a new standards wave that IBM wants to drive after BPEL, they have published a new research topic and a wanna-be standard called BEDL (Business Entity Definition Language), the theme is named Data4BPM.

This is just Part 1 of what we’re going to see in a series of four parts. So, some of my comments could be premature. But later won’t be timely enough!

They start off on the right foot when the authors say –

In most business process management tool suites, 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. The presentation and aggregation of data is handled outside of the process definition, and implemented through generic service calls. This process-only approach ignores the important data perspective during business operation analysis, often obscures key aspects of the operations, and can lead to costly re-factoring throughout the solution life-cycle.

I agree to this in parts, not verbatim, but somewhere we do have a consistent concern on handling the UI and data aspects when dealing with BPM solutions using a process layer on top of existing systems and applications (Pl remember this as I’m going to revisit this point). I had highlighted some of these in my post “Do not treat Process Solutions as Applications”.

The research paper introduces the concept of Business Entity and the four main components (Information Model, life-cycle Model, Access Policies and Notifications model), provides examples around Courier Shipment and provides certain details (sometimes somewhat superficial or high level and sometimes getting to the details of hinting at what XPATH could achieve in a situation) around the structure of BEDL, how it can work with BPEL or any other execution language, and of course advantages of using BEDL.

I’m not sure what they are trying to do, except for one (fear) that it may spin-off another industry or set of products (may be within IBM?) that would be looking for the white space in an industry that is already overcrowded with such noise.

Here’s why?

One, the concepts being introduced here are not new, and in fact, done and dusted with in most enterprises that look at data as a critical aspect of operations management. What is being proposed here, as a component that really addresses this standard, is already implemented in many organizations along with the data architecture and data governance. There are more comprehensive sources available on Data modeling, data architectures, and how they can be addressed in Enterprise operations.

Two, if one assumes this is only in the context of BPM, one needs to understand that Process Layer can sit on top of existing applications through some hooks and plungers, but the data control layer needs to sit under the applications and systems that process layer integrates with. Big difference! It is difficult to imagine the implementation of this standard at the process engine level unless it’s a green field. And this article dodges the question on the non-green field implementation and put it on the lap of “Linkage Data Persistence” that is still under research. So, this standard doesn’t really address the real concern, the one that I brought up earlier in the post (remember?).

Three, in the context of what BPM vendors  need to do, you cannot expect them to drop everything they’re doing and jump to this, especially when this ends up becoming more of an implementation level item as against the product design level. Any product design level changes will also not happen just because you have a new standard. In fact, most of the concepts being introduced here are not alien to any product architect, there just isn’t a way to really address this in conjunction with the target enterprise architectures. And obviously vendors had their own priorities and constraints.

Having said all that, I think there’s one reason that vendors as well as organizations would move towards data and resource oriented architectures, and that’s because of the unstructured process and collaborative operations getting better attention. A state-event model, or Event driven architecture are conducive for business entity driven data models. With the industry taking note of the impact of such business problems requiring solutions in case management, complex event processing, dynamic process management, etc. this effort to revitalize the Data Architecture may be timely.

Or maybe it’s not just a coincidence and IBM is indeed making conscious attempts to address this market with ACM and BEDL, will know soon with IBM Impact just around the corner!

But, standard? I wanna-be yes, but wouldn’t call this one really yet! This is Data modeling redux. And please do not call this as Data4BPM – right concepts but not applicable to current state of BPM!