In this interview with Stephen White, who was closely involved in the developed of the BPMN language, we discussed the myths that been swirling around the internet about BPMN. More specifically, we talk about some crowd-sourced myths and weaknesses that people had been discussing on the BPMN wikipedia page.
Sandeep Johal: The first myth is that there is ambiguity and confusion in sharing BPMN models.
Stephen White: To me this more of a tool vendor issue, perhaps. A lot of it just had to do with mobility or quality of the import export capabilities of the tool. I've soon tools that are very good at it, and other tools that are not as good at it. When you share a BPMN model, you might have issues importing it into a different tool. You might have to do some work after that, but I think that is a vendor issue. The specification itself gives the XML schema or metamodel behind it so that tools can do that.
There were a couple of minor issues and I think that OMG has been addressing that. There's a committee that does interchange formats, and they've been working on that, and showing demonstrations at conferences. I think any of the technical issues are being solved, and I think it's mainly up to the tool vendors to support that .
Sandeep: Next myth ... That BPMN does not allow for routine work.
Stephen: Don't really understand this at all. I think that's kind of what one of it's main capabilities is ... is to be able to create simple straight through processes, a series of activities. We got ways of doing looping based on data or based on a list of items. Like if you have an invoice and you have a bunch of items in that, you can do a loop that supports or that manages all the different items on the list. I think BPMN does this very well and kind of what it was designed for.
Sandeep: Next myth ... BPMN does not support knowledge work.
Stephen: It does support some knowledge working capability. Our case management processes are unstructured. When BPMN was created back in the early 2000s, those kind of unstructured processes were out in the business world. We knew about them, but weren't able to get in all the things that we needed to do to support that. We created a subprocess called an ad hoc process where you could do the activities in any order that you want, and create a condition to say when you're done. This was kind of a step in that direction, but it wasn't complete. In version 2, we didn't add enough to it at that point.
In the meantime, OMG also created another standard called case management model and notation, CMMN, to kind of fill in the gaps there. Unfortunately, it's a separate spec so if you want to do unstructured processes, you go to CMMN. If you want to do the structured ones plus maybe a little bit of unstructured, you go to BPMN. I think this in the long run could be addressed by BPMN 3.0 where we can consolidate that. We can use one tool, one model, to create all the variations of business processes.
Sandeep: Converting BPMN models to executable environments is impossible.
Stephen: I don't see that at all. I think that's really up to business process management tool. There are tools out there that do this. You can go into a BPMN tool, import a business BPMN model, and then create, make it executable. You can do that now. They're lots of tools that do that. It's really handled by the BPMN tool. I worked at IBM. They do that. Other tools do that, so I think this myth should be busted.
Sandeep: There is no support for business rules.
Stephen: First off, BPMN isn't intended to do business rule or decision modeling. It's intended to do business process modeling as we discussed. It does provide hooks into these other tools or other models. For example, there's a task in BPMN called a business rule task. It specifically was added so that BPMN tool could use that task to interact with a decision engine or business rule engine, come back results, and get it back to the process. BPMN has the technical capabilities to support it, but it wasn't intended to do that kind of modeling.
Sandeep: BPMN is way too complicated.
Stephen: This is kinda been a long standing complaint. It was there even before we finished the first specification. I kind of get the complaint. When we started building BPMN, we were intending it to be for business people. It had to be simple enough for business people to do and understand. We didn't want it to be very technical looking. It had to be graphical, etc. It had to be simple, but all the people in the room would have had years of experience with actual business processes. We had been consultants. We had trained people.
We had understood what the issues are for our business people out in the world, and real business processes are complicated. If you look at one company, they need a special kind of loop. You go to another company, they need a transaction or something. You go to another company, they have some other requirement. We add those things up, there's a lot a little details that have to be added to the business process. Real business processes are complex, so it has to be complicated but it has to be simple at the same time.
We knew this going in, and so we came up with an approach to try to deal with that. That approach was to build some simple building blocks. For example, we have 3 main objects. We have circles for events, rectangles for activities, and diamonds for gateways. Those are the basic elements, so there's 3 things. You can see them. They look very easy. You can create models with them, and you have that simplicity. To add the complexity, you can add then variations of those things. You can add different types of tasks, different types of gateways.
There we add the different markers to tell people what is this particular type of task, what is this for, what do those behaviors mean. With the basic building blocks, you can build up the complexity within the simple structure. That was the intent, and that was the approach we took. I guess it's up to individual people to decide whether we were successful in that approach.
Sandeep: Finally, last question is what about BPMN 3.0? Do you know anything about it?
Stephen: At this point, I don't think there's any major effort in OMG to do 3.0. I would like to see it done eventually, and I think it will be. To be honest, for tool vendors to add a new support to new standards, it is a lot of work. The vendors out there that created version 2 kind of want the stability in the marketplace for awhile. You want to be able to build up the customers they have, and they also want to gather more requirements over the time. We'll know more about what is needed for a version 3. A couple of the things that we mentioned earlier, certainly we need a beefed up support for case management or unstructured type processes.
We could add lower level processes at doing service level modeling. Those are the model inside of a tasks. How do you implement those kind of things? There are things at both high and low levels that could be added to BPMN in version 3. Unfortunately, I don't know exactly when that'd happen. When it does, I certainly would like to be involved.