Almost everyone is familiar with the famous Edison quote: “Genius is 1 percent inspiration and 99 percent perspiration”. To know much about Edison’s life, is to know that was certainly true for him – and many other creative individuals when you take the time to learn how they worked. Yet, there is still a strong sense among many that great ideas come to the gifted in the way lightning strikes, unpredicted and unexpected.

Insights as Idea Sources

In my experience, great ideas more likely come from great insight.

The BPMN specification presents lots of technical definitions and rules, but it does not teach you how to create process models that are effective in their primary mission – maximizing shared understanding of the as-is or to-be process. To do process modeling effectively, you need to go beyond the spec and learn a basic methodology, best practices, and specific diagram patterns to use in common situations. To illustrate the point, here are ten tips for effective modeling in BPMN.

I have long railed against OMG’s inexcusable omission of even minimal support for model portability in the BPMN standard. In the forever-stuck-in-final-edit version 1.1, they still haven’t even provided an XML storage format, or serialization, for BPMN, much less a list of the elements and attributes that any “compliant” tool must support. Yet in my BPMN training, students simply assume such portability exists.

In the early days of BPM – four or five years ago – everyone thought BPEL was the BPM standard, at least for runtime execution. Not long after, the importance of business-friendly process modeling came to the fore, and BPMN emerged as the standard for that. The mismatch between graph-oriented BPMN models, where you can route the flow just about anywhere, and block-oriented BPEL, where you can’t, didn’t seem to worry BPM vendors. After all, a model was just a model, a business requirements document in diagrammatic form.