EPC versus BPMN – What’s Your Baseline Shorts 1
This is the first podcast episode of the What’s Your Baseline Shorts series. We are talking about the topic of process notations, especially if you should choose the BPMN or the EPC notation.
High-level topics include:
- What are EPC and BPMN?
- A bit of history
- Specialties of each notation, and difficulties that might arise
- Data exchange with BPMN
- External standards
The two articles that compare the EPC and BPMN notations (from 2011)
(The transcript is auto-generated and was slightly edited for clarity)
J-M: Hello and welcome to What’s Your Baseline Shorts. We’re taking a look today at one of the topics with the most contention in terms of modeling notation in Roland’s and in my life. So first and foremost, my name is J-M Erlendson. I’m an architecture and business process expert and excited to talk to you about how we. Look at process notations … and, Roland.
Roland: Yeah, I’m Roland Woldt:, and I was the guy who had the idea for these shenanigans here and otherwise read up on my bio.
J-M: Ah, as you can tell What’s Your Baseline Shorts is unscripted but it’s exciting to take on some of these topics when a shorter format so you can understand how we bring these all together and this one is all about talking about BPMN and EPC now first and foremost. Roland what? What do you think about BPMN and EPC? What are they and why are they different? And how do they relate to the way people do their process modeling and process on architecture.
Roland: So that would be a very short session BPMN won, end of story.
J-M: Oh wow, and actually I don’t think it should be quite that short. I think there’s a lot more to discuss about it. But first and foremost, tell us about BPMN and EPC. Tell us about the two of them.
Roland: Well why? Yeah, they’re both process notations, right? So process notations are literally to be able to show from the beginning of a process through certain steps to the end of the process and who’s doing it and which apps are using all these types of things so they both capture the same information.
They do it just in a different way. They’ve represented it in a different way and when you think about it EPC which by the way stands for event- driven process chain was invented in in the late eighties early 90s as part of the whole ARIS method by Dr Scheer in Germany and became the de facto standard in the 90s and the 2000s forSAP implementations..
So you see things, the same things that you see in BPMN right? So you see events, you see tasks; you see roles; you see apps risks and all that type of stuff. There’s some certain semantics coming with it and EPCs can have swim lanes or no swim lanes and basically show the content, but J-M, what is BPMN?
J-M: Well, that’s a great question. BPMN stands for Business Process Model and Notation. And BPMN is a sort of rigorous guideline for how to document swim lanes, primarily swim lanes, in your business process flows. So once again, the same sort of symbology. You’d see, but it’s maintained by a larger group that sort of governs a lot of things. That group, I believe, also does something around DMN. They at least try to get the decision model and notation standard. That’s the OMG correct? The object management group.
Yeah, yeah, it’s the object management group. That’s the name of that organization.
J-M: So it’s sort of independent. They are not attached to any given platform.. I think EPC is much more synonymous with the ARIS platform or with SAP, although there are other platforms that certainly use EPC as how they do their modeling. And BPMN has a few different standards. It’s come through a couple different evolutions from – I mean, the old BPMN 1 spec that had sort of different types of diagrams that you could go into and very basic shapes that you would work with. That indicated the programmatic logic of how a process should work to what now is sort of the BPMN 2.0 standard. Which is all about bringing this bunch of different types of subs symbols. You can be more specific about the type of task you’re doing and mostly talk about process collaboration diagrams or other types of bpm models. We mostly do it with process and
Roland: So yeah, let me stop here. So that’s a good point; J-M. So, BPMN does not have only one model type BPMN actually has 4 model types, and so the spec is much wider.
J-M: No no, it’s a bunch.
Roland: And it should show things on different levels. You know, the collaboration shows the, what, about thirty thousand foot or ten thousand foot view. How participants interact with each other versus the BPMN collaboration diagram actually shows that on a who-does-what-where level, and I think the biggest difference is the intention. For both notations, you know, for EPC that’s embedded in a bigger framework, if you will. You know, where you have value chain diagrams and you can jump to org charts and all these types of things while in BPMN the main purpose is supporting automation of processes.
J-M: Right. And that interchange language .BPMN is a perfect example of that. They standardize on a way of importing and exporting from tools that are compliant to the BPMN 2.0 spec to create .BPMN files that other tools that are compliant to that spec can import. That could be business rules engines or like some RPA tools work with that, the larger systems like SAP can, process mining, those sorts of things, so they really designed it.
But once again it is programmatic, and this is where I think I want to turn the conversation a little bit because I think, Roland, you and I are on different sides here. I mean, I think you started the conversation by saying “BPMN won” and in some ways I think that you’re right about some of the market penetration things. But I don’t think it won in a lot of spaces that I play in, and I don’t think it will; it should win for a lot of reasons, and first and foremost, BPMN asks a different question than EPC by its very nature. In fact, every sort of swimlane modeling methodology asks a different question based on its very nature, right?
Roland: Hold on, you can draw a BPMN diagram without swimlanes and you still have a legal BPMN diagram.
J-M: It’s true. But most people that I work with think of BPMN as swimlane models. In fact, often they don’t even say BPMN, they’re just trying things in BPMN format because whatever tool they’re using requires that, but generally when we’re looking at BPMN people are often thinking. Maybe it’s not all in all cases, but people are often thinking who does this, what does this first and that conversation is what I call actor-focused.
They’re thinking first and foremost who does it and then answering the question. What do they do. Whereas when you look at EPC or top down or side or side on or whatever, they have this idea of satellites. The idea is that a task, around that task is displayed all of the contextual information that should inform what that task does when including people. So it is function-focused instead of actor-focused.
Roland: So that means it’s more cluttered and harder to read?
J-M: In some cases, absolutely. But think about it, in BPMN, a lot of that information is either lost because the BPMN 2.0 Spec does not include risk. It does not include capability and I don’t think it includes anything to do with customer journeys.
Roland: It doesn’t, no, not at all.
J-M: You know, it’s missing a lot of information. So where we finally feel … I find a lot of people doing, is they put that information in like textual attributes on the BPMN object itself. That stuff goes there to die. It’s incredibly hard to maintain text attributes.
Roland: Or your tool allows you to create relationships to other objects that exist somewhere else, which is, I think, the more elegant way. I think the biggest difference between those two is not so much whether it is actor-driven, process-driven or step-driven. I think the biggest difference is BPMN to me has a little bit of that geeky and technical flair to it. You know, it has a boatload of different symbols. For example, when you look at events, you know, who knows what a non-interrupting event-driven intermediate event is right?
So it’s super geeky and the first thing when I do implementations is basically talk to the client and say “hey, can we simplify this?” You know, what do you really need and then there’s some room for improvement, if you will, in the spec itself. You know there’s some conflicting or not well-defined things in there that you see so to give you an example when you have a task that does not have a little sub symbol that classifies it as a manual task or an automated task. It doesn’t matter. It’s a generic thing. But when you go to gateways, the object that routes the process flows and does not make the decision. That routes it because the decision was made in the step before, the empty gateway means XOR or while the spec also has an XOR symbol.
It’s inconsistent and illogical there. But these are all the quirks that you see there.
J-M: No, and I agree that it is a more geeky language and in a lot of ways, and in being geeky here I think it gives you a huge advantage and a huge disadvantage. The advantage is that people who are thinking programmatic logic, who come from that background. They understand it, like, instantly. They go “Okay I see what this is doing. I can follow this and I’m using systems that will understand and accept this the same way I do. I built this ecosystem around myself and [it was] perfect.” But it’s hard for your senior stakeholders, right?
J-M: They’re not going to understand this as well because you can’t communicate that, so I see people redoing BPMN often in PowerPoint and just turning into something simple so they can talk to a senior leader, that’s like double work for every single work.
Roland: Did you notice how I just shrunk by an inch or so when you said that? That’s horrible.
But yes I agree. So simplification is the key. I think that’s one takeaway when working with BPMN. The other one is we’re just, where I actually have a beef with, is. BPMN because it has that automation flavor does not know hierarchies. So it has an object in it that’s called subprocess and people say “oh yeah, it’s the sub subprocess. You know a level below and I can drill down 7 levels below”. And that answer is no, you don’t. Subprocesses as objects are meant to expand and contract, right? So that you have better readability of your models, right? To say okay, I can capture this type of content, put a box around it and just show the box named subprocess..
Roland: It’s also not reusable content which is something that people who use tools like ARIS sometimes forget, for that BPMN has a different symbol called call activity, which in all seriousness I’ve never seen used in a real life process. But anyways, that’s my biggest beef, and of course you mentioned it, it’s not meant for strategy modeling. It’s not meant for org modeling and all those things, and I typically point clients to chapter 7 of the spec. Oh, is it scary that I read it so often that I know what to find it, where on one page it describes what it’s for and what it’s not for.
But maybe to bring this to a close, I’m still a fan of BPMN, not because everybody and their grandmother uses it. I’m a fan of it because it’s an independent standard and standards are good. If we didn’t have standards, you could not plug in your laptop into an outlet. You could not have an adapter if you travel overseas and plug it in those outlets there. So standards are good and I think that is the big key for me.
The second big key for me is what you mentioned before. It’s not just a notation, a pretty picture in a diagram; it’s also a file format, and if it’s standardized, and unfortunately the reality is, it isn’t, right? Or no, let me rephrase it, it’s standardized, but the implementation in different tools is not consistent. If that comes to a little bit more maturity where then you can do those things like automation, process mining, all those wonderful things that I think everybody wants, and I think this is where we want to be right?
You don’t want to be tied to your tool. You want to be tied to your content. You want to take that content and be able to transform it into something that you can use elsewhere, and I think that’s the main reason why I’m a big fan of BPMN.
J-M: Ah, yeah, and I think that’s a great note to leave this episode on. We like both these standards. I think that we both agree that EPC has the capacity to tell a better story and a more comprehensive story.
But the truth of the matter is, more tools speak BPMN, and with an independent standard maintained by, I mean, I could say, debatably, a resilient group. OMG’s been around for a long time. They show no signs of slowing down. I have no reason to believe they won’t continue to maintain this.
Roland: And the major tool vendors are part of that. You know, you see the IBMs in there. You see the MEGAs in there. You see the Software AGs in there. So it’s all a consortium of the different firms, and everybody has their stake in there with a little twist in there. But I think that’s a good thing.
J-M: Yes, so tell your story, however it makes most sense. But from our perspective, BPMN is more transportable; EPC is a better storyteller. Now it’s up to you, and so we leave you at this point for this What’s Your Baseline Shorts.
Any last thoughts, Roland, before we go to the comments.
Roland: Oh yeah, a very last thought is – I wrote two articles about the comparison about EPC in BPMN back in 2011, so take it with a grain of salt.
J-M: Did you, did you?
Roland: You obviously find that on our website whatsyourbaseline.com and I will put some links in the show notes somewhere here.
J-M: That’s a great pitch for whatsyourbaseline.com. Remember folks, that’s got all the information about this episode and all of our other episodes from the podcast. And of course, you can always leave us feedback there because these What’s Your Baseline Shorts are meant to answer the hot questions you’ve got burning in your heart.
So if you can answer those for us, you know, and give us certain topics you’d like us to talk about, we guarantee you we’ll take a look at them and maybe even show them in one of our future Shorts.
Roland: Where then, J-M..
J-M: Well then, Roland, I’m J-M.
Roland: I’m Roland.
Both: And we’ll see you in the next one.
Roland Woldt is a well-rounded executive with 25+ years of Business Transformation consulting and software development/system implementation experience, in addition to leadership positions within the German Armed Forces (11 years).
He has worked as Team Lead, Engagement/Program Manager, and Enterprise/Solution Architect for many projects. Within these projects, he was responsible for the full project life cycle, from shaping a solution and selling it, to setting up a methodological approach through design, implementation, and testing, up to the rollout of solutions.
In addition to this, Roland has managed consulting offerings during their lifecycle from the definition, delivery to update, and had revenue responsibility for them.
Roland is the VP of Global Consulting at iGrafx, and has worked as the Head of Software AG’s Global Process Mining CoE, as Director in KPMG’s Advisory, and had other leadership positions at Software AG/IDS Scheer and Accenture. Before that, he served as an active-duty and reserve officer in the German Armed Forces.