Business Process Management (BPM) differs from Workflow in many ways, but its native support for data might be the most critical one. When BPML was introduced eight years ago, its most fundamental innovation (later embraced by BPEL) was to treat data as an integral dimension of processes, rather than simple parameters of workflow activities. Assaf Arkin, Intalio’s CTO, deserves credit for such a major contribution to the field of enterprise computing. Nevertheless, neither BPML nor BPEL went far enough along the data axis, and never allowed developers to properly manage data objects or entities. Instead, it relied on a service model to access externally-managed entities, and only cared to carry the process’ data, thereby limiting the BPMS’ ability to be used as a general purpose development platform for enterprise applications. This is about to change, and once again, Intalio is on a mission to bring such innovation to the market. Let’s take a look at what’s coming up…

At a high level, an enterprise application is made of data objects (entities) which canonical methods (create, delete, set, get, etc.) are accessible through service interfaces, processes transacting against such interfaces and third-party services exposing external systems, and user interfaces supporting interactions with human beings. A proper business process platform should support the development, deployment and maintenance of all three artifacts (entities, processes, and user interfaces) through a single tool and unified life-cycle. Unfortunately, most BPM systems (Intalio|BPMS included) only support two artifacts out of three (processes and user interfaces), leaving entities pretty much out of the picture.

To be fair, Intalio|BPMS is halfway there, supporting the development of pseudo-entities in the form of processes. Since processes managed by Intalio|BPMS can carry any kind of data elements as part of their instances, they can be used to manage data entities which service interfaces are represented as end points in the process. This is what we did for implementing the Task entity in the Tempo workflow framework, and it works. Nevertheless, it’s far from perfect, for a few reasons: first, data elements have to be modeled as XML Schemas rather than Class Diagrams; second, neither BPMN nor BPEL support the advanced constructs found in modern object-oriented programming languages, such as inheritance of polymorphism; third, embedding data objects into a process makes it very difficult for third-party systems to access data-objects directly, even though Intalio’s external variables make it a lot easier.

Clearly, an integrated development platform must support the development, deployment, and maintenance of data objects independently from the processes that transact with them, while providing canonical service interfaces for them. Such interfaces must be dynamically and transparently exposed through multiple protocols, WSDL to be consumed by BPEL processes, and REST to be consumed by SimPEL ones. In a perfect world, your development tool would let you design these data objects using UML Class Diagrams or Entity Relationship Diagrams, and produce code for a variety of platforms, such as Rails or Spring. In between, an XML-based serialization format would be helpful, along the lines of what WSPER is proposing (nice work Jean-Jacques!).

Such is pretty much the vision we have for Intalio 7.0, due to be released in 2009 or 2010. In order to get there, we will re-write our Task entity using a prototype of this upcoming process data object development tool (thereby eating our own dog food). If that sounds like fun, feel free to join one of our Open Source projects (ODE, Singleshot, Tempo), or send us your resume. We’re always on the lookout for ridiculously smart people…