Business process modelling notation is something that has plagued many process modelers all around the world. One of the key things that gets asked is, "What sort of notation should any process model be using?" In this chat - Sandeep Johal talks to world-renowned expert and thought-leader in this space - Stephen White from BPM Advantage. Stephen led the initiative of the BPMN development. BPMN, as most of us know, stands for business process model and notation.
Sandeep Johal: We've got many questions for you Steve. Many, many questions so let's get started right away. First let's dive in by just setting the stage. Tell us, in your own words, what process modelling notation is?
Stephen White: Basically it's a human readable language for defining the structure and contents of a process. In this case, in this context, we're talking about business processes. To emphasize, it is a language. That means it has a defined vocabulary and it's a semantics. As such, being a language, it allows an organization to use that language to tell the stories of the work that they do. For example, these stories could be about how the organization interacts with its customers or how it does its finances or how it works with its employees and human resources etc. This language allows them to create, define, in a reusable format, the work that they do.
Sandeep: It's quite ... I get from what you're saying, process modelling notation is an important thing to have. Can you elaborate a little bit more of why it'll be important for all of us, in the modelling space, to consider and make sure that it is front and center?
Stephen: Sure. It's important because it does provide a consistent way to capture the work. Beyond just having someone writing up an explanation or write a few paragraphs about what that is. The notation could be the front end of an underlying model. This model defines how the processes work. By creating a model, supported with the proper tool, an organization can understand, analyze, begin changing and even automate those processes. Like any other language, it does require some learning so people do need to learn the vocabulary and how that language works.
Sandeep: It seems to me that themes such as consistency and having a modelling notation that allows a larger group of people to understand what's being said, it's crucial. I've talked about this on several of my own videos and what I don't cover is the types of notations there are out there. As I understand it, there is more than a handful. Could you tell us a little bit more about that?
Stephen: There's been many, many process notations out there over the years and there's many types of them. Some of them are, you could say, are textual so they are, like a programming language is a textual notation. Or they could be structured in rule format or tree structured and some of these might have icons to represent different ... The way the process behaves. More commonly though, they are graphical in that they are based on a flow chart. Not all of them but most of them are based on similar variations of flow charts. There's been many "standard" ones and I can just list off a few of them.
One could be the UML activity diagrams, event process chains which are EPCs, going way back to 1962, WFMC created XPDL and Government created standards like IDEF, IDEF3 and so forth. There was even one called YAWL, which is Y-A-W-L, which stands for Yet Another Workflow Language which was just to notate that there are plenty of them out there. There are lots of them. Those are the, what you would call, standard ones. There's lots of other ones, proprietary ones, created by tool vendors or by academics in universities who are studying business processes and wanted to create their own languages.
Sandeep: With so much choice out there Steve, I can probably guess what my next question's going to be, it's all about how does a modeler select which notation he or she should use in their process modelling effort?
Stephen: First off, I would say pick a standard. Don't necessarily pick one that someone has created and it's isolated in its own. Pick a standard because standards have usually an ecosystem around them. What I mean by that is there are tools that support that standard. There are resources, such as books, papers, training, available for people to understand that standard. There are people who have learned it. They've been trained on it and so there's consultants out there who understand it. With this ecosystem, an organization who is trying to make this decision knows that if they pick something that is supported out there then they save money on training.
They don't have to train everybody who comes in and works on it or retrain if they change the tool. Using a standard means that they are usually transportable between tools if you do change a tool so pick a standard. In my case, I'm biased of course, so I would pick the BPMN standard which was developed just for the purpose of creating basically an ecosystem for the end users. As background, BPMN was started mainly because there were so many standards or different notations out there, so many tools that were out there.
There were too many and it was difficult for organizations to pick and choose what they wanted to do, to pick something that would last them and create internal information that they can reuse. When BPMN started, there were quite a few process modelling tool vendors who joined that effort. These were people who had created their own notations, but they saw that there was a need for a common language that a lot of tools can use, the community can support and people can get trained on.
That was the purpose of creating BPMN, to create a language that the industry could support. It's actually been very successful in that regard since there are more than eighty tools right now that support it. There are books about it, there are people training, training classes and so forth. It is probably the most widely used language. Given that, I would think that it would be a good choice. It wouldn't be a bad choice to pick BPMN.
Sandeep: There are many other notations out there that people can select. If I understand correctly, there are really three aspects that I picked up from what you've just said. They are just pick a standard based on the, first off, what are you trying to do. Ensure that it has wide tool support and finally it has a rich set of references such as training etc.
Stephen: Yeah, that's basically it. Certainly you want the tools, you want the reference material and you want people who understand the language and the overall ecosystem that supports that. A lot of times, in my experience working with companies that have used non-standards or even some standards that aren't supported by tools, what they ended up getting is a large set of materials and they end up ... It becomes shelf wear. They print out all these documents, they put them on a shelf and then maybe they'll look at it at some point. It just becomes a lot of work to create a lot of material without much use in the future. That way using a model supported by a tool that has standard, then that way it becomes an electronic asset that is transportable, executable etc.
Sandeep: That helps most modelers make the decision as to what modelling tool or modelling notation rather to select. What we often get is this whole step into getting or just taking something on, not really thinking it through and then regretting it down the road. The number of times people have told me this issue, it makes me think that there should be a framework to help out. With these three factors that we mentioned which is pick a standard with a purpose, wide tool support and a rich set of references, I think our viewers can have a very ... Something they can hang onto, hold onto to provide some guidance as to which modelling notation to get.
If they do a comparison of several modelling notations, especially the ones that you mentioned before, and did that, honestly and perhaps a few stakeholders, I believe that there is a lot of value that they can bring into selecting the right notation. Speaking of actually references, what are your thoughts on where our viewers can get more information about modelling notation?
Stephen: Specifically focusing on BPMN, there is, if you want to know about that language, there's the BPMN specification which is a technical document of course. It does go into the details, what is the language, what is the vocabulary, what do the images look like, what do they mean so there is that. You can get that at the OMG website, will provide the link for that. There's other reference material there as well. You can buy books, amazon.com has books on BPMN. There are websites that have posters that define the elements of the language, what they look like, what they mean and so forth so as reference material. There are also online training courses, many courses out there to get trained and certified. I'm actually developing my own course, should be out in the very near future. There's lots of resources out there.
Sandeep: That's good to know that modelling notation is something that the larger community does take seriously, and has accordingly the right amount of information out there to check. In this case, particularity with BPMN, there seems to be a rich set of resources that our viewers can tap into. I think that is a great insight into process modelling notation, how to approach it and what it is and, most importantly, how to select the best kind of notation that fits a viewer's modelling purpose. With that, I'd like to thank you very much for your time Steve. It's been great having you on Process Sessions and we hope to see you again next time.
Stephen: Great Sandeep, thanks. I enjoyed it.