Anatoly posted about Process and Data in "Process Meets Data" - and explains several approaches to process data employed by tools he's worked with:
- Flat list of attributes
- XML document
- Database by reference attribute
- 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.