Through a fog of BPM standards

If you’re still confused about BPM standards, this article by Bruce Silver at BPMInstitute.org may not help much, but it’s a start at understanding both modelling and execution languages including BPMN, UML, XPDL, BPEL and how they all fit together (or don’t fit together, in most cases). I’m not sure of the age of the article since it predates the OMG-BPMI merger that happened a few months ago, but I just saw it referenced on David Ogren’s BPM Blog and it caught my attention. David’s post is worth reading as a summary but may be influenced by his employer’s (Fuego’s) product, especially his negative comments on BPEL.

A second standards-related article of interest appeared on BPTrends last week authored by Paul Harmon. Harmon’s premise is that organizations can’t be process-oriented until managers visualize their business processes as process diagrams — something like not being able to be truly fluent in a spoken language until you think in that language — and that a common process modelling notation (like BPMN) must be widely known in order to foster communication via that notation.

That idea has a lot of merit; he uses the example of a common financial language (such as “balance sheet”), but it made me think about project management notation. I’m the last person in the world to be managing a project (I like to do the creative design and architecture stuff, not the managing of project schedules), but I learned critical path methods and notation — including hand calculations of such — back in university, and those same terms and techniques are now manifested in popular products such as MS-Project. Without these common terms (such as “critical path”) and the visual notation made popular by MS-Project, project management would be in a much bigger mess than it is today.

The related effect in the world of BPM is that the sooner we all start speaking the same language (BPMN), the sooner we start being able to model our processes in a consistent fashion that’s understood by all, and therefore the sooner that we all starting thinking in BPMN instead of some ad hoc graphical notation (or even worse, a purely text description of our processes). There’s a number of modelling tools, as well as the designer modules within various BPMS, that allow you to model in BPMN these days; there’s even templates that you can find online for Visio to allow you to model in BPMN in that environment if you’re not ready for a full repository-based modeling environment. No more excuses.

Swimming with Fuego

A few more random thoughts in my journey through trying out Fuego.

My first thought on playing with the process designer was that I really liked it because it shows the process activities in swimlanes. The activities are colour-coded (red for human interaction, blue for system-executed), and the shape of the activity icon tells you something about what it is, or you can define your own activity icons on a per-activity basis, which is kind of cool.

But wait… swimlanes are supposed to run parallel to the flow, not perpendicular to it: if the flow runs horizontally (as it does in Fuego and most other process modelling/design tools), the lanes should be horizontal (which they’re not in Fuego). This has the effect of projecting (in a mathematical sense) the two-dimensional orthogonal nature of a swimlane diagram (activities in time sequence versus role) into one dimension: time, with roles dependent on the time axis. This makes for some weird anomalies such as roles repeating along the time axis, and showing automated steps as part of a human role assignment.

Whether you use UML activity diagrams or BPMN or venerable old LOVEM diagrams, swimlanes are supposed to be, by their very nature, orthogonal to (and therefore independent of) the time-based flow of the process, so that you can see all the activities for a single role in a single band regardless of their position in the flow.