Is this Data for BPM?

[tweetmeme source=”ashish_bhagwat” only_single=false]

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!


, , , , , , , , ,

  1. #1 by Dave Duggal on May 2, 2010 - 11:51 pm

    Nice assessment.

    Folks doing sophisticated SOA/BPM implementations certainly already manage business entities at some level. It’s 2010 right, this does seem like late news.

    As you note, the announcement does highlight the component-creep conundrum of the SOA/BPM approach (i.e. middleware bloat). Another way to look at this is to consider that perhaps the original SOA/BPM approach was misconceived, all of these component layers seem corrective or remedial.

    As to motive, I think you are spot on. The SOA/BPM industry is not living up to expectations. If the web is the network, then the future of web-based information systems is resource lifecycles and state management (SOA/BPM has little to do about the web).

    The good news is that existing Service-Oriented investments (non-green field deployments) can be addressed by Resource-Oriented investments, and extent their utility/capability.

    • #2 by Ashish Bhagwat on May 3, 2010 - 3:30 pm

      Dave, while I agree that state management and resource life-cycle management are important for handling certain types of business operations and transactions, I wouldn’t think that the SOA approach or BPM approach have conceptual limitations or flaws.

      What I comment here is in the context of the data standard and not for the BPM concept as a whole. BPM has prove its worth in the areas fit for BPM and when done the right way…

      And actually I wonder if the approach that you mention would be successful without some form of SOA based integration with other pre-existing systems and applications at enterprise operations level.

  2. #3 by Prabir Nandi on May 3, 2010 - 5:21 am

    The BEDL spec or for that matter the Business Entity abstraction is not meant to be a data-control language. Again please check out the definition of the Business Entity closely – hopefully the “business” part of it is not lost around the data mgmt side of things. Our claim is that one can define the operations of an enter enterprise with a handful of such KEY business entities. As such process modeling needs to treat this as first class citizens at MODELING time. For example BPMN has started to bring this into the fold with their DataStore element, although its still woefully inadequate. Agreed, data architecture and standards around that probably already has this covered adequately, but I have not seen anything yet which suggests that it has made any fundamental impact on traditional process modeling practices. As we will cover in the next few articles, we will show using BPMN notations, the interesting process patterns and scenarios we will now be able to model when the BE abstraction is given a proper seat at the table. There will also be discussions around the effectiveness of this approach for brown-field scenarios.

    So although it appears we are proposing a technical spec here, the real impact will be how this could affect process languages like BPMN and business process modeling best practices.

    • #4 by Ashish Bhagwat on May 3, 2010 - 5:47 am


      Thanks for adding your perspective, I’m on the same page so far as the objective and the underlying concern that this research is trying to address. I also agree that a common standard would help the modeling domain in longer term.

      I don’t quite agree that the modeling notations or tools have not been paying attention to BE definition. Tools have had ways to do that, but the real deterrent has been the amount of effort it takes to tie in the Business Operations with Business Entities and the modeling around those. And when having done that, not having a direct linkage with the IT implementation would make it a futile exercise on paper, and hence the deterrent becomes stronger – it takes years of efforts to standardize Data structures within the organizations even at business level.

      What I’m saying is, modeling cannot be the end. When one puts in that enormous effort in defining the Business Entities, and even bigger effort in defining the access mechanisms, state-event models, notification models around those entities – it is expected that the implementation leverages the same. And from where I see, having a standard could be a beginning, but doesn’t seem to make it any easier for anyone to tie the solution together in a BPM scenario, esp in brown-field (I’d rather call it concrete-jungle case actually) for the reasons mentioned in the post. In case of Enterprise Architecture, organization level standards have existed and even domain models like eTom have been available for us.

      It would be really interesting to see those process patterns and scenarios, and of course discussions would be worthwhile in my view. Looking forward 🙂

      – Ashish

      • #5 by Prabir Nandi on May 4, 2010 - 4:51 am


        I should have mentioned Modeling and execution. In fact articles #2 and #4 will be all about execution covering both the green-field case(Business Entity runtime owns the data)and brown-field case (Data is owned by “legacy” applications). Yes, of course, modeling without execution is a set of pretty pictures only. So really two changes from status quo – (a) how the business entity affects process design best practices and (b) how design-to-deploy is additionally enriched with the additional semantics including UI generation.

        Lets touch base again after #2 and #4 comes out 🙂


        • #6 by Ashish Bhagwat on May 6, 2010 - 1:04 pm

          Will look forward to #2 and #4 🙂 When are they expected?

  3. #7 by Max J. Pucher on May 3, 2010 - 9:28 am

    Ashish, good point. SOA/BPM is a dead-end and most standards will be way to limited and small in their perspective. A canonical data model on top or below the process flow is a substantial limitation. Additionally the complete mapping has to be done manually and there is no central point of control.

    The data elements are essential and is one of the key differences between BPM and ACM Adaptive Case Management. To get to truly adaptive processes the FIVE ACM ELEMENTS have to be managed in a model preserving strategy: data entities (state/event), activities (actors, tasks, todos), rules (goals), content (in, out), and presentation (forms). If you miss one, the process has to have some hardcoding and stops to be agile and certainly it is not ADAPTIVE. We also enhanced our BPMN view to allow for DATA, RULE and FORM artifacts as part of the case/process presentation. In ACM it is not necessary to model the flow beforehand and as a matter of fact, there may be no flow, but a simple rule that defined under what conditions the case has reached its goals.

    So even an additional BEDL ‘standard’ does not do much. A complete definition is needed at all times to make a process usable and real-time access to that definition is needed to make it adaptable. In the Papyrus Platform repository all those five elements are change managed and deployed. That includes the mapping to SOA. In fact we even support that we discover a WSDL via UDDI, and as we read it we on the fly create the data entities in the repoitory and they are immediately usable in the process, content, forms and rules. One has to consider however that most SOA interfaces are not transaction safe.

    Thanks for highlighting this important subject. I had planned to write a post on THE FIVE ELEMENTS after our currently running OpenHouse. Too busy … with 150 guests!

  4. #9 by Ashish Bhagwat on May 3, 2010 - 3:49 pm

    Max, Interesting that you also chose to separate SOA and BPM by just a slash, just like Dave did. I’m assuming it’s to just making the point easier and you do not actually construe both being the same or just two flavors of the same stuff…

    In the post, where I mention ACM is while making a point that certain architectures like state-event models or resource oriented architectures are more conducive for handling business entities relative to stacked/layered integration based aproach.

    You mention a term “model preserving strategy, would like to know more about it, may be outside this discussion. Sounds interesting.

    As for the Five ACM elements, I would not go outright and support the argument that it’s a better strategy than the one proposed by the BEDL team. In fact, if the approach being proposed by BEDL team was part of a long running enterprise strategy, I would have supported it in the Enterprise Architecture context. Just that, I have my doubts on the standard and supporting components around it as a proposition. There is a very good structure to BEDL, supported by some good concepts, so not to take anything away there.

    It will be interesting to see how your proposed design does in a ‘concrete jungle’ (brown field) scenario where the users need to see all the data that they need from the back-end systems/applications, while also maintaining the source of record sanity, and the business entity definitions at enterprise level – and all this while going through the case management or process management layer. We’re not talking swivel chair here. (So, the original challenge remains the same?)

  5. #10 by Dave Duggal on May 3, 2010 - 7:15 pm

    Hi Ashish – As always I appreciate your posts, and enjoy the exchanges.

    The IBM announcement is premised on the SOA/BPM approach, wherein SOA is used for externalized services, including data services, and BPM provides orchestration. I was building on your comment “…may spin-off another industry or set of products…”, which I think is the crux of the problem – conceptual architecture vs reality of concrete architecture.

    I don’t believe that SOA or BPM are bad, I just question whether a SOA/IBM stack arrangement is the best tool for the complex composite applications being envisioned. Conversely, I’m not saying Resource Oriented is the only way to go, but I think that business should take stock in what they are building and consider alternatives based on desired properties.

    As to your question – Resources are anything that can be addressed by a URI, so a Resource Oriented Framework can exploit services, while expanding on the overall capability of the system. Services are pre-encapsulated functions – they intrinsically constrain interactivity to facilitate interoperability – that’s the trade off. Resources don’t have that constraint and therefore can better support customization and re-use – system flexibility.

    That’s my two cents.

  6. #11 by Iyigun Cevik on May 6, 2010 - 12:46 pm

    Ashish – I don’t see this paper as an IBM approach to introduce something which was not done before. Of course business were always there, some folks payed attention to them, some others didn’t. It’s also not about introducing a new standard. The language introduced is not very mature as I mentioned in my blog.
    I see the paper valuable because it’s another effort trying to remove walls between different approaches like BPM approach, business rules approach resource based approach or however you call it. These walls needs to be broken, modeling should contain all elements as first class citizens. In the paper this is mentioned as ‘holistic approach’.

    • #12 by Ashish Bhagwat on May 6, 2010 - 1:00 pm

      @Ivigun, yes, I agree the effort needs to be appreciated for the intent to break any barriers preventing us from achieving the full potential of BPM due to the data related challenges. And as I also mentioned that there are some good concepts reiterated or revisted here (hence the term data modeling redux :)).

      The problem, as you also mentioned would be to call this a standard. We seem to be on the same page. (I actually visited your blog as well, found your inputs valuable too :))!

      Additionally, as I mentioned, we need to get to concrete solutions for these problems, with examples, scenarios and relevant practical components.

      Thanks for adding value to this discussion – helps our audience have another place to gather further inputs!

  1. Quicklectic: Popular Posts and Redux Update « The Eclectic Zone

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: