Start a Discussion
BPM
user-pic

Is There Place in BPM for a Data Standard? If So, What Would it Be?

Vote 0 Votes
Ashish Bhagwat: Is there a place in BPM for a data standard?  Is so, what would it be?

13 Replies

| Add a Reply
  • Depends what you mean from data standard....I think there are three ways of looking at standards when thinking BPM.

    1. BPM as a "practice" and not as a solution
    2. Enabling solution integration
    3. Standard way of storing process definitions and functions

    If no. 1, then sure, BPM or BPMS could benefit from a standardisation of approaches. However this could also mean that as a practice, we may again become too rigid and not adaptive, agile, or flexible enough to really identify all of the business requirements...

    If no 2. then YES, there should be a standardisation, SOA XML Web Services should be it. If all BPM products had this kind of API, it would mean a standard way to integrate with that solution, across the eneterprise. Using XML Web Services would also ensure BPM solutions integrate X platform.

    If, which I fear this question is more likely to be aimed at, No 3. the NO! I know people love standards, and they love the fact that, in theory at least, you could then move between BPM vendors for your processes. However, back in the real world, this just isnt the case. These types of standards will hinder innovation and stop BPM evolving quickly enough to keep up with new business requirements. If there were standards in place (think something like W3C) then how long would it be before businesses had the option to use Social BPM from a vendor that was standard compliant?

    Though in theory, these types of standards are great, in practice and with the need to be highly adaptive and agile, they simply dont work...Just look at HTML 5. It has been on the way for almost a decade now, and it wont reach recommendation level until 2020....Can you imagine if businesses had to wait half that time to get the BPM solutions they need???

    This is something I have posted about in the past,

    http://andrewonedegree.wordpress.com/2010/04/06/does-bpm-need-a-w3c-type-standard-no-way/

    and in some ways, standards in this fashion stop BPM from being truly adaptive...Again something I have posted about in the past...

    http://andrewonedegree.wordpress.com/2010/03/24/adaptive-bpm-no-mapping-tools/


    So to answer the question, a standardisation of BPM the practice, YES, a standardisation of how BPM integrates with third parties, YES, a standardisation on how a particular BPM systems stores data and works.....NO...

  • I've read the Data4BPM/BEDL white paper and I am dubious. I understand what they are trying to do, but I think they are inventing too much new technology and users aren't ready for it yet (if they ever will be).

    They are inventing new technologies for data's information model, lifecycle model, access policies and notifications. For the information model, a business entity is specified as a "family of attribute/value pairs, where an XML schema is associated with each attribute." Of course XML schema already has a way of creating new attribute/value pairs called "elements". So, while XML Schema is already pretty complicated, this adds another layer of modeling on top of it.

    For the lifecycle model they have a new technology that looks a bit like a state machine (i.e. a set of valid state and transitions). Of course UML and other modeling techniques have had a way of doing this for a long time. They aren't reusing these because they want the lifecycle policies to be actually enforced at runtime, so they must be much more formal. This is the part where I'm concerned that users aren't ready for it. Formally modeling all of the ways that their data can change and who is allowed to do it is something that might seem appealing to the more controlling managers in the world, but I suspect that in practice, there are so many exceptional circumstances that would have to be accounted for that it would be unwieldy.

    I would rather see more concentration on the value of using the new content management standard with standards-based BPMS's. The standard is called Content Management Interoperability Services (CMIS) and is a very effective way for a business process to work with documents in a content management system. The content management system is the right place for handling policies associated with information management. They also can handle a wide variety of content, rather than invent a new concept of information such as a "business entity".

    My evaluation of BEDL is certainly preliminary, but because of these issues, it would take a lot for me to convinced that this is the right direction for the industry.

  • The initial concern "the data manipulated by the processes is essentially hidden in process variables" is valid but it's just a bad practice or reasonable quick prototyping technique.
    It's amazing how we use to grab everything we can reach under our own umbrella: business methodology is BPM, content storage is BPM and now data management is BPM, too.
    Others do the same: ECM people believe that docflow is the process and BPM is a hype, ERP consultants believe they know everything about processes.
    I believe there is DBMS for structured content, ECM for unstructured content and BPMS for dynamic aspects of both (i.e. processes). Data is stored in proven RDBMS, documents are stored in ECM and process attributes keep references to both. (If talking about a production system - it may and should be streamlined during prototyping phase.) Composite applications tie it all together. MDM helps managing distributed and duplicated data.
    Let's be professional in our core competence and leverage achievements in other fields (more mature than BPM by the way) instead of making "discoveries".

  • Anatoly goes in the right direction with this. It's not a case of creating (yet) another standard for people to adhere to but to manage all that data in a coherent strategy in the first place. MDM provides that framework and solution to manage all the data at an enterprise level which can be leveraged by a BPM solution in the one place.

    Can you imagine trying to create a BPM Data Standard and then having to translate 20/30/40+ systems that it potentially could interface with to meet that standard ? We can't even get wholesale adoption of BPMN as a notational standard so why try to muddy the waters by introducing something else which has wider implications ?

    Sort out your enterprise data first, let's worry about this for another day.

    And Andrew is right: too many standards create rigidity and stifles a creative solution.

  • Hello Anatoly,

    referring to your statement "I believe there is DBMS for structured content, ECM for unstructured content and BPMS for dynamic aspects of both (i.e. processes)", I would like to ask you:

    Do you agree, that data (structured or not), as soon as they are stored (at whatever storing medium), are taking on a social nature, since (in principle) everybody, and everyone's programs can access such data and process them freely (within certain limitations, which - again - are of social nature)?

    Are you quite sure that the BPMS paradigma is sufficiently general to cover all that 'processing' dynamics?

    Regards, Peter

    • Peter

      Of course I was talking about a particular kind of data dynamics. There may be others, possibly many others. What I did mean is that it's a bad idea to implement process-like dynamics within the database or ECM (although there are such examples). And it's equally bad idea to invent new data standards specially tailored to processes. I'm a proponent of layered architecture.

      But I'm not sure I've got your point. Ideally, data storage should be agnostic towards data processing: it may be transactional systems yesterday, social stuff today and something else (e.g. a super-spy system knowing every move, every breath and every word of every man and woman) tomorrow - we can't afford re-sort the data and data interfaces each time, as Theo rightfully noted.

  • Of course there's a place for a BPM data standard, and some would argue that this standard is already in place - XML. XML data is a natural fit for BPM collaboration within a browser-like setting, such as MS SharePoint 2010, and it certainly involves simple, usable APIs. BPM is moving towards fully-automated, cloud-based unstructured data management. XML was create to facilitate interoperability and electronic compatibility - with .NET, Java, XQuery and dozens more.

  • Anatoly

    Sorry for having been not precise enough. Let me try to improve.

    1. As to the social nature of stored data (whatever, wherever), I mean data-usage rather than data-reference.

    Example:

    - Data stored in a DBMS (even a CMS) may refer to
    (a) the value chain of a production (product & production-means) or
    (b) the people enganged thereby in some complex Workflow

    - Both kinds of stored data may be used for all kinds of processing, from fully automatized processing by whatever CA-systems (CA: computer aided), to spontaneous, informal processing by people - the whole 'spectrum'.

    I am holding that a BPMS can cover only a minor part of this spectrum. Most types of processing cannot be described (let alone modelled) in terms of business processes, as used in a BPMS.

    2. As to your point that data storage should be agnostic towards data processing, I would like to distinguish the case

    (a) of stored data, which are consumed by applications, e.g. applications running within a BPMS, from the case

    (b) of stored data, which are consumed and uploaded by people for the sole purpose of collaboration (coordination), such as in a bill-board, functioning as a kind of generalized KANBAN.

    While I fully agree with you in case (a), I cannot follow your argument in case (b): data at a bill-board DBMS, for controlling a specific task-completion, cannot (I think) be agnostic to the corresponding workflow.

    • Peter

      Thank you for the clarification. Your case (b) refer to unstructured content for me. It may be considered as data in some broad sence but clearly it's not the D letter in DBMS, I agree.

  • Concerning the question of data standards for BPMS, I would like to make another remark.

    If you change from the BPM-paradigm to the WSM-paradigm (WSM = Workstate Management, as proposed on my Website: www.mastering-it.com), you have to deal with just two issues:

    (1)  real-time Workstate data on a bill-board DB,
    (2)  Input-Validation rules for data-uploads to that DB.

    Workstate-data show some kind of regularity, which seems to lend itself to some standardization. If Wokstate-data format is XML, standards could possibly be formulated in terms of task-specific XSD data-types. But this is an open question - let us wait and see.

  • As most have noted in this discussion, a data standard for application of BPM principles or implementation of BPM technology seems like a futile exercise in my opinion too.

    I have more details on my post that this question refers to, but here's a quick summary of reasons:
    - Data Architectures at Enterprise levels already exist for most mature enterprises - and most of those that actually do BPM right now. No specific reason to build data standard within BPM. Challenge lies on the ground, of course, but the solution may not lie within BPM is what I mean.
    - As an approach, a standard way to connect all data makes sense, but that is already being beaten to death by SOA and MDM, and even as a separate DA discipline altogether in bigger enterprises
    - If we're expecting BPMS vendors to align with a new standard, we can forget it. At the Process meta-data level itself we have little progress on standardization, thinking about the business data standardization looks far-fetched
    - Even if we're able to conceptualize a data standard, it's going to be an enormous task to implement it. Process layer sits at the top of the pile, the data sits at the bottom while there are multitude of applications and systems in between. A Business Entity makes sense at Process level but the effort should not be within boundaries of BPM, but at MDM, SOA etc
    - This is relatively easier done on State machine based models but for the other reasons mentioned above, will find it hard to get adoption.

    And of course there're more specific technical points like the ones Michael, Anatoly, Peter have made.

  • Yes I agree that the standards for business process management varies from each other as how you treat business process management as a solution application or practice management. If looking for solution applications then there are various firms offering solution application for business process management. One of them is Cygnet Infotech offering you business process management solutions and applications using .net and sharepoint technologies

  • Ashish,
    Products such as BizAgi provide a virtual structured data model that sits between the process layer and the legacy systems, i.e. in BizAgi the business analyst assumes that all data is local to BizAgi and then the systems will go and grab the data from the right system at the right time. Access to the data en BizAgi is already done through Xpath, so this standard wannabe is already available.
    Without structured data, no business objects can be defined and hence, no advanced case management capabilities can be supported by the BPM…
    Regards
    Gustavo Gomez
    BizAgi CEO

Add a Reply

Recently Commented On

Monthly Archives

Blogs

ADVERTISEMENT