Approaches to Process Data

Scott Francis
Next Post
Previous Post

Anatoly posted about Process and Data in “Process Meets Data” – and explains several approaches to process data employed by tools he’s worked with:

  1. Flat list of attributes
  2. XML document
  3. Entity-attribute-value
  4. Database by reference attribute
  5. Native relational database

It got my attention because on of the hang-ups that I’ve observed with BPM practitioners with formal object-oriented development experience is trying to over-design the object hierarchy.  Thinking of process data as “in memory” data structures in a language like Java or C++.  This leads to wanting to have circular references between objects (manager has a list of direct reports, and the direct reports each have a link/pointer to manager).  But in BPM systems it makes more sense to think of process data as a simplified bit of concrete data from the database.

Rather than a “pointer” from one object to another, we tend to prefer reference id’s (unique identifiers) that can be used to retrieve that additional object when needed.  Its just a bit different way of thinking about data.

The BPM software vendors have some tough trade-offs to weigh – whether to simplify how the design-time works by eliminating the need to design the database schema, or whether to focus on enabling all the customization and power of each software layer to the process developer.  Each step along the journey from one end of the spectrum to the other entails trade-offs.  Should the BPMS design and create the tables for you?  Should it require any schema changes at all?  What will customers allow or work with going to production?

Whichever product you use, understanding how it handles data is critical to understanding the real limits of what you can do with it.

 

Tags:

  • Pingback: BPM Quotes of the week « Adam Deane()

  • Jonas

    I find it very unnatural to think in terms of object-orientation when designing types for messages flowing in to and out of the process. I really don’t see the point by doing that, at all. A flat list of attributes is all there needs to be. Processes sends attributes needed to complete an activity/task, and receiving attributes that adds value to the process and provides information for down stream activities/tasks. Keeping state of that data through out the process is fine if the process can secure it’s integrity and handle all events that could change the state of it. Again, that statefull data shouldn’t be designed in an object-oriented manner. Object-oriented design belongs to the 90th’s. Message-oriented design is now …

    • I think I understand what you’re saying – but I’ll give you an example.  If you have two addresses being passed in – a billing address and a shipping address… flat fields?  Or two “objects” that each have street1, street2, country, etc. ?

      Taking it further, if I have two “persons” I need the interface or message to deal with – whether that is loading from a database or incoming from a message, it makes sense to keep your data structures as simple as possible – but only that simple.  Any simpler and you end up with something more complex again. (For example, you can pass in person identifiers to the process instead of “objects”… but then the process has to go look up the data on those persons, and again you have the same design decision to make – stay with flat fields – person1lastname, person2lastname – or go with objects person1.lastname).

      • Jonas

         Scott, reading your blog entry once again I realized that my comment was slightly off-topic.

        But, I can just agree with you about “BPM practitioners with formal
        object-oriented development experience is trying to over-design the
        object hierarchy.” The reason why they over-design the object spells r e
        u s e. They once learned that things we do must be designed for reuse.
        But, impediments to effective reuse are deeply rooted in human nature.
        Furthermore, reuse leads to dependencies and dependencies leads to
        inflexibility, and once we suffer from inflexible systems the Business
        will back bound by IT.

        At the end of the day I’m a BPEL developer and I never encourage
        service developers to think in terms of objects when designing
        contracts.

        – “Think in terms of flat style messages!”

        If a customer record should be requested along with account
        information then design the response message as a complex type with a
        flat list of elements. Reuse can be accomplished behind the contract by
        implementation, not within the contract. Achieving a canonical schemas
        and a company wide “business language” is by far the worst nightmare an
        organization can face out.

        :)) I guess that was even more OT than the first one.

      •  We’re in complete agreement! Thanks for the clarification and I agree with the philosophical points you made about re-use.  I had a good laugh in your last paragraph. We must have worked with some of the same projects ;)

      • Jonas

        Heh yeah, sometimes these reuse-dodos really makes me bubble over with frustration  …