I completely agree with your thoughts on modelling versus graphical coding. Since I’m often involved in the business requirements and modelling end of projects, I find myself constantly reminding people of what’s a business requirement and what’s a specific implementation detail/decision. When it gets to process mapping in a BPMS, it is graphical coding, yet the vendors all claim that this is a tool for business analysts, who likely have no coding experience and may not understand concepts of properly structuring code even when it’s generated automatically from some pretty diagrams. That’s still one of the fundamental issues with the linkage between the business and the technology today.

I look forward to digging into BPDM more at the Think Tank next week, see you then.

Second, and more important, there is a thread running through many of the questions which is (crudely put) “at what level should I model using BPMN?” The underlying issue is that people confuse “modeling” with “coding graphically.” When you draw a workflow, whether in Visio or using, say, a BPEL tool, you are actually not “modeling” as much as you are “drawing an implementation” or “coding an implementation.” This is also true for XPDL (although XPDL is more abstracted from implementation conceptually, in practice most companies use XPDL to represent the implementation).

When you are stuck in the world of implementation, you often lose sight of the business requirements… and you certainly have to draw at a level well “below” what is useful for the business to measure. Indeed, the whole value prop of BPM is that any given implementation is just a tactic, to be changed and improved over time. This notion fundamentally implies that the _process_ under management is not tied directly to any specific implementation… but rather on some higher level abstraction that can be measured and managed.

BPDM has no implementation. It only represents the concepts and, going forward, the various contracts around an implementation. In BPDM, then, the focus is on “modeling” to the level required to understand, measure and manage the process. This is the level of detail that BPMN should be modeled to… and any further details (whether “work flows” or “screen flows”) are best left to implementation-specific tools (which may also be based on BPMN, but might be based on BPEL, XPDL, UML or any other language).

BPMN is, therefore, a notation that can span uses. But in its most powerful – when combined with the metamodel that is BPDM and the choreography extensions in BPDM – it offers the first possibility of true business process modeling that can be connected to the execution levers, without being locked in to any specific ones. This “higher level of abstraction” means true modeling of the business services that are important, long-lived, measurable and re-usable.

BPDM is a huge advance not only in the portability it provides, but in the promise for real Enterprise Architecture and business service understanding.

Thanks… and see you at Think Tank!

Fred

John Evdemon, who headed up the technical committee on the BPEL standard at OASIS, stated at the BPM Think Tank last year that most vendors (including Microsoft, who he works for) were not implementing BPEL natively, but were using it as an interchange format and converting to a proprietary execution language internally for their engine. Now that we’re a year later and the standard has been released for a few months, that’s starting to change, but there’s still many (I’d say a majority of) existing systems out there that are not running BPEL natively as an execution language, even for pure web services orchestration.

Furthermore, the primary context of this post is about BPM, not web services orchestration. In fact, the specific question to which I was responding was “What’s the proper perspective BPM implementers should have on BPMN, XPDL, BPEL, BPEL4People, and BPDM?” In BPM, BPEL is not typically used as an execution language because it doesn’t support everything that you can do in a full BPM suite that includes human-facing support as well as service orchestration. Although there are a few exceptions, such as Intalio, a majority of the BPMS vendors include BPEL only as an interchange format, and don’t use it as an execution language. In fact, although many of them support BPEL as an interchange format, it’s not their preferred method since it doesn’t support everything that you can do in BPMN, which is the direction that they’re all taking with their modeling tools. Instead, they’re using XPDL or (in a few cases) BPDM because both of these support the full BPMN specification, which BPEL does not.

Sandy, statements like the above do a disservice to your readership. All one needs to do is set a Google alert for “BPEL” to read about the multitude of cases where BPEL is being used precisely as an execution language. Substantive, thoughtful insights on topics such as BPEL, whether pro or con, add to our collective understanding. Vacuous pronouncements like the one above add to the collective confusion.

Fred