I’ve been quiet lately for a number of reasons. A very significant one is the fact I am now participating with the technical team developing the BPMN 2.0 specification for OMG. I am trying to be a good team member and not scream too loudly about the things that are driving me crazy about it. Particularly when the probability is even slightly greater than zero that one or two of my suggestions will make it into the spec. But I can share a few impressions.
First, how I joined the team. Any OMG member can see the public drafts of the specifications. The last one was in November. One section of it was particularly obtuse and annoying so I rewrote it and sent to Steve White. It turns out the BPMN 2.0 team can consider one-liner comments and requests from outside, but for them to even look at something like a paragraph I would need to sign a simple agreement. And to be taken seriously, I would need to sign a 12-page agreement and Fedex copies of it all over the world. Which I did.
OK, welcome to the team. It is led by IBM , SAP, and Oracle. Mostly the first two. There are others involved, like me – and the BPDM crew as well! – but you need the Big 3 to bless any new idea for it to be dealt with seriously. The weekly calls are at 7am on Monday, and I have been dutifully getting up early to call in. To be fair, most of the team is in Europe and it’s late afternoon there.
The big surprise for me was that BPMN 2.0 is all about executable BPMN. Not executable like the way Lombardi, Tibco, Appian, Adobe et al do it now, where BPMN is just the “model” and the executable part is specific to each vendor. Executable as in the implementation details – data, services, messages, task performer assignment – are all specified using standard BPMN attributes! Wow, who asked for that? Maybe the BPEL vendors. Hmmm…
My big thing right now is trying to make sure that BPMN models without all that stuff can be schema-valid. And we’re not there yet! Yes, sad but true.
The other revelation for me has been the whole xmi vs xsd business. One is O-O and the other is about XML. They seem to exist in parallel universes, as do their partisans, with only the vaguest notions about the other. I’m an XML/xsd person. I see a lot of BPMN tools and I don’t know any that use xmi. But even on the IBM-Oracle-SAP team, the xmi mindset is paramount. I often hear that “most tools” use xmi not xsd. Like I said, parallel universes.
The team is shooting for a votable submission in March. There is a huge amount of work left to do. People are working very hard, but I don’t know if we’ll make it.
Hello Bruce,
Nice to read something from you again, after long time. Thanks for the update, I agree with you on everything except one; XMI format.
It?s a key standard for tools to exchange metamodels.
The XMI file released by IBM-SAP-Oracle group is so valuable, where it includes information that captures the semantic of BPMN-2.0 in a consistent and an explicit way, for the first time, rather than the implicit vague one in BPMN-1.1. I think this is the first sign of “tipping point” you talked about in [BPM Standards in Perspective]. For example, you can take that XMI file and manipulate it in whatever way you want with any standard tool such as RSA, and even open source tools, like Eclipse.
As a feedback for you; that XMI file released by IBM-SAP-Oracle group, is missing information about all metamodels in chapter-12 of the latest specs. I know it?s not final yet, but I hope see it complete in next release.
Finally, please write more, because you?re a great educational source for me and I?m learning a lot from you.
Scott
Bruce –
great post. in particular, I would like to see the BPMN 2.0 spec continue to support (schema-valid) non-executing BPMN models. Its hard to believe that people won’t still be doing non-executing models – OR – writing models that aren’t executable *yet* – that will be moved between users or tools or installations for final fit-and-finish.
A non-executing model that is well-formed should still be a valid model…
Also, kudos for helping out – I know participating in OMG processes is time consuming and hard work, but I’m glad the consulting point of view is being represented in there by someone with your experience.
Scott
If it wouldn’t be possible to create non-executable BPMN models, the rising attention towards this standard would vanish very soon. BPMN would be turned into a rather technical workflow specification language – only to be used by specialists in an IT project, and only if a process engine happens to be used as part of the solution.
During the last year, I have held a number of BPMN seminars in large companies (in industries such as manufacturing, chemicals, media, finance). All of them are looking for a standard which can be used for modeling business processes on a business level. These models should be suitable for communicating requirements to IT, based on a common language.
All of the participants liked BPMN, and most of them have started using this notation – but none of them is currently considering it as a language for specifiying executable processes.
The reality is: Today most IT projects do not make use of a process engine. Still they do need a common language for business and IT. My understanding was that BPMN aimed to provide such a common language. BPMN has a good chance to become an accepted standard and to gain widespread acceptance. This success will be destroyed if BPMN is reduced to specifying executable processes.
I am very concerned about what I am reading in your post about the current development in the OMG. Please don’t let them kill the BPMN success!
@allweyer,
It’s even worse than that, since I really doubt the non-BPEL BPMS vendors will rush to embrace executable BPMN. I think they are quite content to use BPMN only for the “abstract” flow model, and rely on their own proprietary tools for executable design. The good news, however, is that the question of non-executable BPMN is now front and center with the BPMN 2.0 technical team, and I expect some kind of resolution in the March submission. But time will tell.
–Bruce