In one of those weird coincidences, JBoss World is happening simultaneously in the same conference center as ProcessWorld; Tom Baeyens noticed that I was blogging from ProcessWorld and contacted me, and we had a chance to meet up today.
We had a great discussion about model-driven applications, and finding the dividing line between what works and doesn’t work in a model-driven paradigm. Tom’s premise is that model-driven development can work in simple cases, but that it’s not possible to generalize: at some point, enough technical underpinnings need to be added to the model that it’s no longer understandable by a non-technical business analyst. Although the business analyst can still create a model and pass it for translation to a developer for augmentation, it’s going to be a one-way trip in most cases.
I definitely see some validity to this position; what typically ends up happening in today’s model-driven development in BPM is that either the developers just take over maintenance of the models at some point (even if the tool allows the models to be shared), or the business analysts learn enough of the technical side to be able to understand the fully-executable model which is, unfortunately, no longer really a business model.
jBPM is not at all about model-driven development, but provides a BPM engine that can be embedded directly in your Java code. Tom shared some of his vision of the future for the project with respect to expanding modeling capabilities and other areas; suffice it to say that total BPM world domination is on the plan.
The new version of ARIS SOA Architect provides a graphical merge functionality. You can transform a business process model into BPEL and change the BPEL as well as the business process model. If you transform again, it will detect conflicts and the user can solve them using the graphical tool. This is a little like a diff tool for ascii files, but here in a graphical way for process models.
It is good to see some clear thought and concern for the limits of the flow-centric emphasis of most BPM. As with procedural code, the more you try to model a real business, the more complex and tangled the flowchart becomes and, consequently, the more maintenance becomes a technical matter at which even the most skilled become less productive as the “logic” grows. As this happens, it certainly drifts from a business model to an implementation. We believe the cure involves both an emphasis on decisions (not just from the BRMS side, as advocated by James Taylor, but also from the BPM perspective) and a more knowledge-centric approach. This knowledge centric approach should include decisions, obviously, but also the vocabulary (e.g., SBVR) and ontology (i.e., the model). Until BPM and BRM share vocabularies and models, BPM mayappeal to the business but be largely confined to IT.
Parenthetically, I believe that JBOSS, which has both the jBPM platform and JBOSS Rules / Drools, is positioned fairly well to lead the converging markets in this regard.
Sebastian, was your comment intended to be attached to one of the posts about ProcessWorld rather than this one about jBPM? The graphical merge functionality is interesting, and likely related to their new versioning capability, in which differences between versions are shown.
Paul, thanks for your insightful comments. We definitely need to have a way to bring together BPM and BRM in the minds of both business and IT — they do seem to be considered as quite separate technologies within the customer organizations that I see.
Perhaps one of the limitation with current thinking around BPM is the focus on flow-centric modeling instead of discrete functionality whose behavior is controlled by rules & metadata. Typical BPM efforts attempt to weave these into a "diagram", which further obfuscates the problem (and complicates the solution). The problem with most of these diagramming tools is that they don’t support business rules modeling. Once that hurdle is passed, then complexity can be abstracted in rules not the hard-coded process flow (which is our current conceptualization).