As a former glue person, I spent numerous hours trading acronyms and definitions with IT analysts on the subject of data and process modeling in the content versus data worlds. Circa 1999, my friend Bob Boeri and I even went so far as to relate logical data models and data dictionaries to DTD structures, using Near and Far Designer as analogous to the more entrenched data modeling tools.

Our goal was to create “common ground” between IT’s deep but solely data-centric view of business applications and the needs of various business units whose focus was decidedly document-centric. Once our “data is content and content is data” analogy was mantra, we had an easier time with subsequent process modeling discussions; i.e. “what we want our content to do with your data” and vica versa. (Reminiscent of those “how did your chocolate get into my peanut butter commercials”)

In the ECM and BPM intersection, those discussions are once again becoming commonplace as more and more complex business processes require hybrid combinations of unstructured content, structured XML content and traditional data from back-end systems. Hence, information analysts that work with IT and business units must define a common knowledge base of process modeling requirements, flows, and techniques.

More than simple workflow (a.k.a “create, edit, approve, publish”), process models for functions such as compliance, claims processing, and contract management need to combine data-centric techniques with the content-centric, human-driven interactions these functions require. In fact, just as data sources are now hybrids, so too are the processes that require, manipulate, and share them. The BPM suite market is increasingly adding simple document management functionality at the business monitoring level to account for content-centric requirements.

More interesting is the market’s approach to workflow, which still appears either data-centric or document/content-centric in terms of standards modeling languages. In fact, a BPM suite vendor’s architecture choice for process modeling and execution is also a clue to their data versus content strengths via support for XPDL (XML Process Definition Language) versus BPEL (Business Process Execution Language). Highlights:

  • XPDL – initiated and managed by the Workflow Management Coalition (WfMC), XPDL is decidedly human workflow-centric and more oriented for document-driven processes. No surprise that workflow, document management pure-plays, and some ECM players with BPM modules have strong XPDL modeling and processing engines. More info at
  • BPEL – originally submitted to OASIS from IBM, Microsoft and BEA, BPEL is decidedly data-centric and more oriented for straight-through processing. No surprise that platform and middleware vendors entering the BPM suite market have strong BPEL modeling and processing engines. More info at BPELSource and
  • OASIS One of the more significant questions at the ECM and BPM intersection is, “Where is the best of both worlds in terms of process modeling for complex workflow that is a human and data-driven hybrid?”