Welcome to episode 5 of the What’s Your Baseline podcast. Today we are talking about:

  • Definitions: Frameworks (structures), Methods (processes), Notations (languages), Reference Content (content)
  • How to implement these? This is part of the Technical Governance implementation phase; write it down in your EA Strategy document
  • Document your standards. When and how to change the standards (too often diminishes trust; org Change Mgmt / socialization is key)
  • Have your method and data define/support your standards so they are “fit for purpose”
  • Action-focused vs. function-focused notations
  • How to run process design workshops in multiple sessions
  • Geek-out over various notation examples (BPMN, DMN, EPC, UML, IDEF, ArchiMate) – observations on how they are used in real life
  • Use a common structure, such as TOGAF’s ADM, to train users and make finding things easier for them in the future

Please reach out to us by either sending an email to hello@whatsyourbaseline.com or leaving us a voice message by clicking here.

Ep. 5 – Notations, Notations, Notations – What's Your Baseline? Enterprise Architecture & Business Process Management Demystified

Additional Information

Additional articles that were mentioned on the show:

Governance

BPMN notation

Comparison BPMN and EPC notations

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

  • CP1 (Welcome)
  • Industrial (Interlude 1)
  • Wurly (Interlude 2)
  • Airplane Seatbelt (Interlude 3)
  • South Wing (Outro)

Transcript

(The transcript is auto-generated and was slightly edited for clarity)

Roland: Hey J-M, how are you doing?

J-M: Hey Roland, I’m really enjoying this. It’s a beautiful day and it’s time to talk about something really important in our journey into business process and enterprise architecture, which is how we represent how we think about business process and enterprise architecture at a notation / at a framework level. And this episode is all about it’s why we called it notations, notations, notations.

Roland: Agreed, but there’s four different terms that I see clients throw out of the window, use interchangeably, however you want to call this, that I think we should do some definitions first.

J-M: Absolutely.

Roland: The first term is frameworks. The second term is methods. The third term is notations, and the fourth term are reference models. So, maybe I start with the first term, frameworks. Frameworks are structures. Think about a high-rise building. You know you have a foundation. You have the steel beams that make up the skeleton of the building. You have the elevator being built in. You have the water lines, all these type of things that have been laid out before. That is similar with architectural notations. So think about TOGAF and DODAF and FEAF and all those wonderful things that end with AF. 

What they do is they define the structure, the views and areas that you see represented in a metamodel. They also might define how deep you should go. When I think about DODAF that has five different views being defined, they prescribe that you need an OV5 and an OV6 (which stands for operational view) to describe middle and lower level processes for example, and then they obviously have system views and other views as well.

J-M: But you’re talking about the foundation, and we’re thinking about building a building. That’s a lot of the architectural diagramming. The next layer we want to talk about is how you get there – the approach that you’re using, and we talk a lot about the ADM. Explain a little bit more about what we mean by methods or approaches.

Roland: Yes, so methods are processes. One example is for example the architecture development method, the ADM in TOGAF. So whenever you google TOGAF, you definitely will see a picture of a big yellow wagon wheel that has different phases being mapped out and the idea is that you would develop an architecture by simply following the phases in the ADM. So what methods describe is the process and the approach to create architecture artifacts.

J-M: That’s really important, and I know that that works not just in the context of the ADM. And  in a future episode, we’re going to be talking to our good friend Mike Idengren, who’s going to be talking a little bit more about Scaled Agile. There’s a lot of different approaches that give you a guide path to making the right decisions along the way for the way you structure your architecture and your processes.

Roland: Agreed.

J-M: But the way you represent your architecture and processes is in the title of the episode and something I care quite a lot about, which is notations. Those languages you think of, there’s a lot of the terms you might recognize, like BPMN, or Value Stream, or UML. Those sorts of things, the way in which you represent information. And I wanted to make sure we split those into the two things you’ll recognize when considering them. 

The first is that these often prescribe a metamodel. So the notation will itself ask for certain types of information to be captured and to relate to each other in order to properly capture the right information about the organization and its processes, its application architecture, those sorts of things, and that meta model is brought together as you understand and capture the data you’re looking to get. 

The other half is the symbology, the way in which you visualize that content. So a notation is split into those two things and symbology is often very locked down by what you recognize – so BPMN has its own symbology, but also needs to be (as we’ll talk about later) harmonized with the way you expect information to look in your organization.

Roland: That is true and we spoke about this in a previous episode when we were talking about the implementation approach, where we had that work package of technical governance, which includes obviously creating the data model, the meta model and all those things, that then, at some point, determine which notation is on which level. 

But I agree: notations are languages. They describe something and they are like real languages. When you think about it, you could say “I love you” in multiple languages, you know. You could say it in English, you could say it in German, you could say it in French and I think we all agree it sounds the best in French, so we need to see what is the right language for the right purpose. 

The last term that comes up is reference models. And reference models are content, so those might describe different areas that are pre-packaged, maybe in a format that your chosen architecture tool can use, or may be available as Excel that’s ready for import in your tool, but that could be, for example, reference process models like the American Productivity and Quality Council (APQC) has what they call the process classification framework. Or you have technical reference architectures that are provided by a software vendor.

J-M: Like an SAP will often provide its best practice repository – the BPR or its process step library to help you understand what it thinks is important or relevant. I’m also, as a note for you, there’s lots of consulting organizations who have pre-packaged referenced models / reference content that you can buy to give you a starting point. But we’re defining reference models, but we’re going to talk in the next section about why it’s important, how to do it, but just as a reference about reference models, those are a great starting point, but they’re usually not the ending point. I mean, how many times, Roland, have you seen an organization implement SAP exactly standard? No customization.

Roland: None, none, and that’s I think the key point right the’re re an accelerator, but you have to adapt them to fit into your architecture, right?

J-M: Exactly.

Roland: And that is mostly done as part of that technical governance work stream that I mentioned in the previous episode where you look at what is the impact of the structure of your reference content, if you want to use it, to your metamodel. For example, when I think about APQC – the Process Classification Framework, you see five to six levels being defined, well you will have to make the decision:  “Do I wanna have five or six levels in my process view” in this case, or do I want to have fewer, just four maybe? But we’ll talk about that in a couple of minutes.

J-M: When I take a look at the SAP structure, they have scenario, process, process step and that’s an important part of how they categorize processes. But it also is restrictive. It doesn’t get to the level that a lot of organizations need to or, you know, a three level structure simply isn’t sufficient to describe the decomposition of an organization. So I always find myself having to fill in layers above and often layers below to match what an organization perceives as its framework and hierarchy. 

So that’s an interesting way of looking at things, and I think that’s going to be an important topic of discussion for not just this episode, but as we go through this podcast, it how to approach this, how to build these all into a way that works for your company. Because a lot of the practice and recommendations we’re giving: they are generalized ideas. But the way you do it, that takes some consultation and some thought leadership to really adapt it to your needs and be able to help your organization grow with it. 

So this is a great way of setting those definitions or frameworks, the structures, the methods (our processes), the notations (our languages), and the reference models (our content), and those four pillars are going to be what we’re talking about as we get into the episode about “notations, notations, notations”. But in the meantime I would love to take a quick break and have you think about a couple things? What frameworks or methods or models have you come across in your organization or in your past lives? What have you used? And where did you find either the content or the structure helpful or harmful and costly? And we’ll take a quick break to let that sink in. We’ll be back with our thoughts and a little bit more about how you can put this into practice for your organizations.

Musical Break – “Industrial Beat”, Jeremy Voltz

J-M: And we’re back. Well, hopefully you’ve had a chance to think about the question we just asked for you. And also if you have some feedback or you’d like to let us know what you’re thinking all the way through this podcast, you could reach out at hello@whatsyourbaseline.com and that will give us a chance to hear from you and get some thoughts, feedback, and ultimately help to communicate our message even better. 

Meanwhile, we want to move on to the practice section of our podcast. We’ve talked a little bit about the definitions of notations and now we want to talk about two different things that are important about putting this into reality. 

Number one is about deciding the methodologies and notations, the approaches that you’re going to use to drive the structuring of your business, capture, analysis and ultimately decision making. And number two is implementing these methodologies, notations and frameworks. How were you going to put it into practice? How are you actually going to do it? What steps are required to make that come to life? 

And, Roland, I know you’ve done this all over the place for many, many, many years. So bring your wisdom, help us decide: what are we going to do, what do we need to think about when deciding on a methodology?

Roland: Thanks J-M, that’s so flattering. I think when we look at deciding about all those things, frameworks, methodologies, notations and so on, I think that’s when you look at the implementation. But even beyond that of a strategic conversation, think about where you want to go. What do you want to show in your architecture? What do you need to show in your architecture? 

And the question is, what do we try to achieve? So don’t look at the point like: which notation should I use? I think that’s the wrong way. Look at what is the objective that you want to accomplish? Or you need to create a blueprint for your projects? Or you need to create an information base to be able to analyze what’s going on in your enterprise baseline (what runs)? Oh you need to be able to support conformance checking in your process mining solution? So you need a model that you can upload. It is a strategic conversation that’s oriented by the objectives that you want to accomplish, and even those examples that I just mentioned. They are part of a bigger objective, that’s business oriented.

J-M: Right? ’cause if it’s going to stay in IT where all it is is deciding on the technical side of things, you’re really not getting the value in the exposure of the good work you’re doing, right? You want to solve a business problem and that business problem requires defining it up front and giving that really important weight during the decision making process allows you to make a better decision on how you’re going to approach it with the notation you choose and methodology you’re going to implement.

Roland: Agreed, and you would have to look at them once you made the decision. Yes, I want to capture my application landscape, for example. You will then have to decide “how do I do this”? Do I have one level? Do I have multiple levels? If I have multiple levels, what’s the detail of information on which level? So you go from a very rough view to a very, very detailed view on the level below, and that’s a conversation that you should have with all your stakeholders from all the different groups that work with you on those decisions, to say: “yep, that’s what we’re all going to do”. Because you don’t want to have a mix of those levels that one group does it very high level, the other one is very detailed.

J-M: Yeah, I can imagine that involving people in this sort of strategic conversation is really important, and I think it’s important for two reasons. Obviously you want to get feedback because it’s important to bring their perspectives into play when making a good decision. What do they actually need? Otherwise, you’re not going to get the full breadth of requirements set out in advance, but also, as we’ve talked about before, involving stakeholders early also gets engagement and buy-in. 

Because ultimately you’re trying to enable practice for your organization. Without bringing people into the decision making process on how that practice comes to life, man, you have an uphill battle ahead of you. When it’s time to actually engage in that practice.

Roland: Yes, and what I recommend in those cases to do is to be very agile with a lowercase “a”. So have quick turnarounds, have short iterations of what you’re doing. Bring the stakeholders in so that they really have a stake in things and not just play a representative role that might give the thumbs up or thumbs down on your ideas, but make them be part of the process, which I think is pretty important, especially when you think about: How do you create a group of those deciders?

J-M: Are those deciders part of the actual implementation team? ‘Cause I know we’ve talked about the segmentation between the CoE and the rest of the lines of business or your stakeholders at the strategic level.

Roland: I don’t think so. I think when you get started with it, I would set up a council or a temporary committee that does the initial cut. So when you have representatives from the business units that are part of the party, they have different needs. And by the way everything in architecture should be driven by needs and objectives, for what it’s worth.

J-M: Of course, yeah.

Roland:And they do the first cut, and you might come up with requirements for tool selection, for tool configuration, for your different architectural views and all those other things that will be written down in an EA strategy document. But at some point in time you might want to go and establish a more consistent and more permanent structure for deciding on all those topics of frameworks, usage and notation, update and whatnot.

J-M: And tell me how that more permanent structure looks like, relative to that initial structure. Obviously when you’ve got the start up, you’re going to be bringing a different set of stakeholders in. Or would you see them as being a similar set of people? You’re actually asking for an ongoing commitment when you’re saying “let’s start this off, I’d like you to continue to be engaged with me as we evolve.”

Roland: Yeah, I think that’s not so much a big problem to get the people to the table. The question is how much work can you unload on them and how deeply are they involved there? Because obviously everybody who chips in with their budget for, like I said, buying a tool, or buying consultant work to implement it, or to get something done. They obviously want to have a say. 

What I’ve seen is a lot of people who have the opinion to say “hey I already pay for this so I don’t have to do any work”. Right, and that’s obviously the question: who’s going to do the work. 

So what I’ve seen in the better projects was obviously where people were chosen that were invested in what you were doing, and not having that sideline perspective. But it also helps when you think about setting up that permanent group. If you have something like a division of labor. And I’ve seen clients who put that task either into a dedicated EA group. And those guys become super, super busy with defining the standards and they don’t get anything else accomplished. Or they put it into a CoE – a center of excellence, which in my opinion should be more a doer organization. And they don’t put a separate group up for discussion.

J-M: Right, so it’s kind of like an ARB-style Standards Council that that would be controlling, but it’s controlling the methodology.

Roland: Yes, yes agreed, think about our three legs of government. You know you have the executive, the doers.You do have the legislators who come up with the rules, which obviously would be that group that you just mentioned. And you have the judiciary which is basically the ARD who checks how the laws will be applied. And I think that’s a good example to see how you would set up those groups. 

And I’ve seen that in one project again, like I mentioned in a previous episode, with the German armed forces like 15-20 years ago and what they did is they had a department in the Department of Defense which they called ‘modernization’ because they realized if they would have done projects as they have done before, separated by branch of arms (you know you have the Army and the Navy and the Air Force and so on) that doesn’t cut it. Because what they needed to do was a huge transformation of the whole organization after the Cold War, and obviously with outdated IT and shadow IT and all those wonderful things that you see. They figured out they can’t afford those practices anymore. So what they did is they put up a whole department within the Department of Defense and that group was responsible for the method and the approach that the whole program took. While on the other side the agencies, there were the executive arms of that program who actually did the work. 

So the interesting fun was there was a lady in that modernization department who was responsible for the whole methods, and they had their printouts of their method and conventions manual, which actually was four different documents. So they had a base set and three auxiliary documents, which in total was like 400 or 500 pages. So it was quite a bit for different purposes. And the funny thing is, she printed it out – all those 500 pages – and she had a big binder that she ran around with and she brought it to meetings. And whenever somebody had an idea, she grabbed a post it and put it on that page, you know and said “Oh yeah, on page 200 we’re talking about blah blah and I think it’s a good idea to change this” and she put her posts-its in there, and when she couldn’t close the binder, that was the time when the next change of the method and conventions had to take place.

J-M: That’s  a good trick. Oh my goodness, that seems like a heck of a job. She dedicated her whole life to carting around a big piece of big piece of paper with all the things that were written on it. I’ve also seen organizations really struggle. 

I remember working in a transportation company and we had essentially one center of excellence team that was defining everything for everybody. And they were defining it based off of what was most convenient for them. So they chose a framework. They chose a notation. They chose everything because it was what the team wanted and then they went out to the lines of business and told them “you shall do this”. This is what you should do because it’s the best idea, because it’s the one we’re using.

Roland: I’ve seen that too.

J-M: And as you can imagine, there wasn’t so much engagement. In fact, I would say that most of the time we ended up having to do an internal exercise to translate the documents they refused to put in the approach that we were taking, or the notation we were using, and had to do an internal exercise to translate that into our own language before we published it to a portal they never went to. So that can be a downfall if you don’t have that engagement right off the bat.

Roland: Maybe just to chime in. I’ve seen the very same scenario that you just described it in with other customers as well, and unfortunately those are the projects that in the long run failed because what you need to do is you need to create the acceptance of all the people that are involved in the program, and ideally you can grow that to the whole organization. But that brings us to another point. We were thinking about changing standards. I think you should not change the standard so often.

J-M: No, no, of course not.

Roland: Right, so when you think about your example. If that company says, “Oh yeah, we found that new thing that we like. Let’s put it into our next standards document and just push it through.” People lose confidence if every month or every three months, something new comes up because that typically means rework.

J-M: Of course.

Roland: The second thing, what it typically means, or what is perceived by the people, is that the people who make up the standards don’t know what they’re talking about. So it’s a delicate dance that you have to go through because you obviously don’t want to be a blocker and not work on change requests or requirements that come from your audience. But on the other side, you don’t want to change things too often so that you are busy with busy work of updating your models and other artifacts. 

Typically I see an annual renewal or update cycle as a good time frame, because then people get used to your releases. They say “yep, maybe within a year we get something new.”

J-M: Yeah, you want to give people the benefit of new approaches and developments in technology and new thought leadership in terms of notation. But they need to be able to be socialized. They need to be able to be discussed. They need to have buy-in achieved from your teams before we just push out a standard, and we need to have a business justification for making that change. Otherwise it’s just change for the sake of change. That doesn’t add any value.

Roland: And it actually has costs assigned to it. So to stick with that example of the German Armed Forces, I ran into the situation that they had a minor change that they wanted to change. You know, data on process steps and roles, and the colonel that we reported into – the client that we reported into – says “what’s the effort” and we basically did the math. You know, we said “oh yeah, we have seen so many process steps in our part of the whole process network and so on so many events and so and so many data objects” and we just said “well, it takes maybe a minute to identify it and to the to do the actual change in the model”. And then we just did the math, and at the end of the day applying the regular consulting rate we came to a price tag of 100,000 euros in this case and the colonel just said “that’s great. Thanks for the number”. And he went to the ministry and said: “yeah, give me €100,000 so that I can accomplish what you’re asking me to do” and guess which standard was not enforced going forward?

J-M: Yeah, turns out, it just got deprioritized somehow. Who knows? It wasn’t as important.

Roland: That was surprising, wasn’t it?

J-M: Yeah, well we also want to talk about how (in the second point of this), how do we implement this methodology, notation or framework? Because we’ve been theorycrafting about what the decision making would be and how we can bring this to life for all the different people who are talking about it before it comes into play. But what does it mean to actually put it into practice? 

And I think the first thing we’ve been talking about is the people and socialization and onboarding. I can’t stress how important this is as you put things into practice because one of the most important things you’re going to have is practitioners, and one of the biggest risks you’re going to have is non-compliance. If people are doing their own thing using their own language, you lose all the benefit you have of harmonizing this conversation through a common framework, a common language, a common approach to your whole business process and architecture discussion. And so, if you are having specialized methodology, plan to have specialized methodology training. Plan to have a walkthrough with your practitioners. Help to socialize that with them and get folks comfortable using this methodology. 

So what does that look like? Well change management is going to be involved, probably learning and development is going to be involved. Having an environment (if you choose to use a tool to implement this methodology), have a test and practice environment where they’re able to actually go and put their hands on the methodology. Play with it before they are expected to do it for their jobs, because if they’re expected to do it on day one, you know what they’re going to do. They’re going to fall back on their good old reliables to make sure that they don’t look bad in front of their colleagues. So that’s a very important first part, and I’m really concerned because a lot of organizations I see don’t invest enough in that part of the puzzle. What do you think, Roland?

Roland: Yeah, nobody is born with the knowledge about frameworks, notations, reference content and so on. This is all “artificial”. So somebody invented it and then it became the standard in quotation marks and you need to learn this. 

And what I’ve seen is just like you said, is groups that bought into something and said, hey, we want to use BPMN, for example, and they just don’t know what they’re talking about. They just heard the term and they heard that this seems to be an industry standard. Of course, we need to do it. And that is a big challenge. 

So I wholeheartedly agree. You need to somehow make it digestible for your stakeholders, who might or might not be even interested in it, because you might have people who are just sitting at the table because somebody ordered them to sit there and they still have to learn about this, and I would not go and hand someone the TOGAF spec, which is like 950-1000 pages and say yeah, read it until our next meeting. Because deep in the belly of the beast, it’s a snooze fest. It’s good information, but it’s super dry-written and nobody reads this just for entertainment on a Saturday evening on the porch in a rocking chair.

J-M: That’s a great quote. Nobody reads this for fun. This isn’t your thing. This is how you do your job. And along those lines, the second piece is how to do your job in a platform or tool. 

We’ve talked about this in a previous episode about selecting a tool, but once you’ve got that tool in place, you’ve got that mechanism by which you’re going to deliver the content, you want to make sure that the methodology or your notation is implemented within that platform, particularly on the notation side. Talking about your meta model and the data structures, you’re going to be choosing and using, talking about the symbology in the visual representation, you’re going to be drawing with. You need to build that into your platform. 

Now, a lot of platforms are out there, have their own preconfigured methodologies that restrict you and force you into a particular box. And for some folks who are just getting started or for whom their scope is incredibly narrow, that can be OK. For instance, if you’re looking at just implementing a single platform, like a single transactional platform with a single set of processes. Sure, maybe you can be boxed into that tool’s front end development visual language. OK, I get that. But for most organizations when you’re thinking about an enterprise context, you’re making decisions that cross a lot of boundaries. And to do that you’re going to need to have the notations available that will help you to diagram and layout how those boundaries are defined and how they connect. 

So we think about method filters. Really, that’s an important piece of the puzzle. What’s a methodology? What are the data structures and how do they connect? And we think about five things in that method filter. 

  • What models am I going to use and what’s going to be on them? 
  • What types of objects am I going to be using to capture information and that could be represented on a model or just independently as a business element? 
  • What are the attributes? So what kinds of information am I capturing about my models and objects beyond their visual representations? 
  • What additional details are important? Sometimes you think of those as properties, page properties, shape properties, different types of attribution that organizations need to add to contextualize the information they have. Then how am I doing connections? How does information tie to other information? What properties or attributes am I seeing in those connections themselves? Where can those connections exist? Are they on a model or are they simply a database level connection between two elements? 
  • And lastly is: how does my hierarchy breakdown? What do I do in terms of things like assignments? So how does a single object break down into a lower level model so I can traverse the various levels? 

That’s the method filter you’re trying to lay out. 

On top of that is a layer of template. What is the notation, the visual notation? So is the symbology? What is the size, shapes and colors that makes it comfortable for my practitioners to use a diagramming platform based on the decisions I’ve made? Something that’s familiar to them, something that they can feel like they can communicate properly through. And that’s really important to establish and then implement in the technical configuration of your platform. 

‘Cause you’re looking to both enable by giving access to this information capture method in a palette, but also govern and restrict by not giving access to a sort of freeform Wild West of content that people could just put on the page. I mean Roland, you’ve seen the Wild West go wrong, right?

Roland: I was just thinking about one project that I worked on many, many years ago and we were using a professional architecture tool there and the default color for process steps was a very nice salmon color, like pinkish.It was kind of fancy, but we were not in the not involved in the configuration of the tool at all, so we just took what was given to us and we created processes. And that the whole project was about improving their project management process. So from getting an idea for a new project through financial planning, budgeting requirements, management, blueprinting, blah blah up to the benefits realization. 

And for one scenario where we had to talk with a VP or SVP stakeholder there was a need to show parts of the process and they were used to having things being done in PowerPoint. So what I did is I just created a mini process in PowerPoint. Good consulting PowerPoint engineering, black and white using BPMN shapes and the first feedback that I got while talking to this gentleman was like “oh this looks so much better than what you’ve shown me before”. And it was the same content. So I agree, the adoption is very, very important. And we spoke about personas and the needs of those folks in previous episodes, but I would focus on getting the adoption right. 

And if there’s one term you should take away from the whole conversation is that you need to make all your reference content, your notations, your frameworks and approaches, make all that stuff fit for purpose. And that’s actually written, for example, in the TOGAF spec that you need to adapt it. Most people like to oversee this. But, J-M, talk to me once you’ve put everything in your 500 page binder and you’ve put it into your Bible, what do you do next?

J-M: Well, the next piece of the puzzle is actually making sure people do it. I feel like there’s a lot of talk that goes into making all these decisions, but we want to enforce these decisions on organizations on people. Really, ’cause once again, we’re involving people in every stage of this process, and that means rules, establishment and rules enforcement, and the way in which people get to work. 

And what does that take? That takes the use of automation and evaluation tools. A perfect example that is like a semantic check, and that’s going to look through the way you’ve modeled and ensure that you’ve followed the conventions that we’ve spoken about, the methodology that we’re using as an approach. You’ve got the right artifacts captured, they’re structured and connected in the way they’re supposed to. And those semantic checks, they can be automated. In fact, I would highly recommend that you automate them, but then you also have QA to make sure and go through and check and do a business validation on what those structures are, how things are laid out. So if you’re looking at processes, making sure that they make business and structural sense beyond just being correctly notated. 

That’s actually something I used to do. So when I first discovered the platform I use every day these days, ARIS, I was using it to do QA on a very large transformation – an ERP transformation at a utilities company up here in Canada. And being the person at the end of the line that had to go through and check all these models, I was able to do two things, and this is an important piece of both the enforcement and the ongoing learning and development. 

Number one, as I was able to help correct errors and make sure that everything aligned properly with the notations we’ve chosen and fit into the method we were going with and the framework that it was supporting. The second thing is taking these issues and errors and corrections and turning them into individualized personal training plans that made people get better at using the thing we had decided on. That meant that ultimately the team overtime improved as a result of QA’s involvement. 

That’s the way to do it. Now you’ve got an iterative process of team improvement, as well as methodological harmonization as well as project advancement. Those things put together are great, and if you put things like rules associated with quality associated with stages and gates for those stages as part of project and deliverable completion. Well, now you’ve actually got a hard check to make sure people have done things the right way.

Roland: Which I will find a very interesting question to ask Mike Idengren when we talk about Scaled Agile and how agile and architecture go together hand in hand.

J-M: So now we’re going to ask you another question. I know we love getting people thinking on this podcast, but giving you a couple of seconds to sort of internalize this. It’s really important to us. And once again, reach out with all the ideas you have after you think of them, and after this podcast is complete. Now our call to action for this segment is for you to think about the frameworks, reference models that you were thinking of using, and justify them in your own mind. Why do you think these are relevant and what do you think the impact is of those frameworks or methodologies or notations on your plans and the meta model you’re going to ultimately use? So let’s give you a couple of seconds to think about that and we back with our conclusions and thoughts for the future.

Musical Break – “Wurly”, Jeremy Voltz

Roland: Welcome back! In our next segment, we’d like to talk about common notations and how they are used, and there’s a couple of them that raise up to some prominent position. J-M, can you talk or can you give us some examples of those?

J-M: Yeah, I think that there are two different styles of modeling. Let’s start, before we even get to the specific notations, there are styles of modeling that focus on different things. There’s top down, which is sort of a procedural model and there is side on or “swimlane” and each one has its benefits and value and the way in which we choose depends on what we’re focused on for analysis. 

Top down, I think of its function focused. Action focused. Task focused. That’s focusing on what happens next first, so the first thing we do is we lay out a flow of the steps in the sequence that they happen, and the different intermediate events that are powering or powered by those steps. And that’s going to give you a better understanding of what happens next, what you have to do next, and what you’re going to model around to help contextualize and add details to it. 

The other one is actor focused. Swimlanes are very actor focused and either in terms of organizational units like roles or systems as you want to see handoffs, and that actor focused perspective really forces you to first think about who is involved or what is involved and then from that perspective you can put on to the model: what they do. So it’s sort of a different mindset now. 

Perfect example of the top down, a function-focused modeling methodology, is something like EPC, like an Event-driven Process Chain. It doesn’t necessarily matter the orientation like from side to side or from top to bottom, it’s still function-focused and some other things like value stream mapping is a very function focused type of modeling notation particularly for process. Conversely, if you’re looking at actor-focus or swimlane, by far the most common is something like BPMN, business process model and notation. Particularly since BPMN is an international and global standard and it’s maintained by a separate and independent body, and in particular it’s been built to incorporate into an interchange language and XML-based interchange language that a lot of platforms ingest or export.

Roland: Yeah, and interesting enough. That’s obviously a gray zone in that scenario as well, because a perfectly valid BPMN model does not need to have swimlanes or pools for that matter. I think I’m with you J-M, and in the end I think it really doesn’t matter so much what you put on your paper and how the symbols look. It’s more getting that distinction between is it more active focus or function focused? And if you ask me, I would always look for the function-focused approach, because when you think about process improvement and the objective to make a process maybe faster or using less resources and other objectives that you might have as soon as you bring up swimlanes and you put a role in there, people start getting afraid about losing their job and then they stick to their little part of the process and fight till the bloody fingernails come off. That obviously does not help if you want to improve the process.

J-M: Well, every time we talk about ownership or organizational involvement in business, then we get two camps of: one – “this is mine. You can never take it from me” and the other one being like “I don’t want my name on this. That’s going to oblige me to work.” And so both of those are going to cause us to have additional complicated discussions.

Roland: Well the way to get around this is to basically develop your process is not in one session, but in multiple sessions, and make it pretty clear in the first session: let’s talk about what needs to be done. How do we decompose the process? How do we set borders between process data process? Be on a very high level so that we say, Yep, A is followed by B is followed by C. And then you go a level deeper to the “who does what when where? Where you would typically see swimlanes. And then say “let’s just not worry about this. Let’s just put the task at hand. What needs to be done? What does my system tell me what I’m supposed to do?” And then you send everybody home and you clean up your process model that you modeled during your session and send it to the audience of your workshop and say “look at this. This is the result.” 

And when you come back to the second session, you ask them: “do we all agree that this is the structure that we put in place, that this is the tasks that need to be done in the sequence that I mapped out?” And I literally wait until I see people nodding one by one, and at that point in time, then I start the conversation about who’s doing it, because then they have already agreed that the steps are in the correct order and you have the loops captured and the feedbacks and whatnot.

J-M: I think that’s part of why we want to harmonize language so very much. I mean, that’s the crux of notations, right? It’s giving you this common language within which you can talk, and so by being able to have that conversation asynchronously with everyone, because of this common language, you’re gaining a ton of value in speed and accuracy in your business conversations. And that happens both at the high level in terms of the structure of processes, the hierarchy of architecture. The medium level, so the task and process step level and then even at the decision level. But I know when we talked about some common notations and their usage, I know DMN or “decision model and notation” was something that was really hyped and got a lot of organizations really excited about it. Tell me about how you’ve seen it used or has it actually had a chance to penetrate the marketplace?

Roland: Well, I think that let’s take a couple of years back so DMN came out (and I don’t want to lie) in the mid 2010s – that’s when I first heard of it. So it’s not that old, but it came on the tailwind of the BPMN notation. And BPMN was invented, the first steps were invented in the 90s and then you had a version one of the standard in the early 2000s and then by 2010-ish, version 2.0 came out, which was significant changes to the 1.x standard that was in place at that point and that is, at least in my observation, when that whole holy war “ should I use BPMN or EPCs came up and became a focus. 

And my employer at that point in time was really eager to get EPC being the standard because the tools synchronized with SAP and SAP was using EPCs. They couldn’t foresee that that would be replaced with another notation. By now they’re cooler with BPMN for obvious reasons because everybody has adopted it. But if you like I’ve written three articles on our website back in 2010, 2011 about “what is BPMN and what do I have to learn about BPMN?” And I also wrote two articles together with one of my friends for his blog thatI cross posted where we did a comparison between EPC and BPMN.

J-M: And we’ll talk about this more at the end of the show, but of course, if you’re on the What’s Your Baseline podcast, you will know that whatsyourbaseline.com has all those articles and sets of information for you, and hopefully you’ll be visiting that and taking some lessons learned from this and the articles combined there and putting it into practice for your organization.

Roland: But to come back to your question about DMN, the decision modeling notation that came in the tailwind of BPMN because it was published by the same standards organization, OMG [Object Mangament Group]. The idea behind DMN is to have a standard notation for how to model decisions and I remember in the 2000s a big topic was business rules and tools where you could capture business rules that then could be automated in business process management systems. And OMG tried to push out that standard and make it a wholeheartedly accepted standard. 

In my observation, it didn’t have the same success like BPMN. So when I go to a client nowadays and I show, say to stick with that example an EPC and show a BPMN model, people say “Oh yeah, we want to have BPMN” because they’ve heard about it. They might have learned the notation at a previous employer and it just feel comfortable with it. If I do the same thing and show them DMN, I just get the stare and they don’t know what I’m talking about and they try to address the relevance of that notation.

J-M: Yeah, I mean the one thing I will say about BPMN and this is, you know, I do certainly hear clients of the same thing. I recognize this, I’m familiar with this. The one thing I don’t love about BPMN in terms of putting it into practice is that it is often quite restrictive on the kinds of information you can capture on the page. So the symbology set tends to be less than what most organizations would like to associate with processes and process steps. Perfect example is capturing a KPI right on a model, capturing a risk right on a model, which is why I’m always happy to use tool sets that don’t closely or perfectly conform to just the symbologies set that’s included with the BPMN standard. Things that have an extension beyond that.

Roland: But I have news for you that you don’t like. BPMN won. There’s no doubt about it, so I think it’s a good thing if you, dear listener, have a look at process notations. Look at BPMN as your lower level. Who does what, when, where. 

And that is for exactly the same reason that you mentioned earlier, J-M. BPMN does not only come with a visual representation, which at some point is funky, when you look at all the different event types for example, and gateway types that are possible in BPMN that not everybody uses. So you would, as part of your configuration, you would just omit some of those. But on the other side, you obviously get the technical file format with the BPMN spec, and this allows you to integrate with other tools. Some examples would be the integration with business process management execution systems that typically run on BPMN. Or when you think about conformance checking with your process mining application where you upload a BPMN process, that’s obviously ideal because you have that common interchange format.

J-M: Yeah, if your system you’re using to document process can’t interchange file formats like that. Boy you are pigeonholing yourself into using that forever and ever and not being able to communicate with anyone else.

Roland: And there are tons of tools out there that have their proprietary notation and you should be very aware of what you buy into if you choose one of those.

J-M: Absolutely yeah, you’re buying yourself a prison! Oh boy! But talking about beyond just that sort of standard, we talk about architecture model styles and architecture model notations, and there’s a few I’ve definitely come across and worked in. Archimate in particular, it comes up a lot. I know UML has got a couple of different degrees of standard, whether it’s the 1.X or 2.X, I think it’s 2.6 now or even IDEF, which is a bit of an older standard, but certainly in practice in a couple of organizations I’ve worked with. Roland, how do you see that from an architecture modeling notation standards choice?

Roland: Yeah, little fun fact – have you looked into the UML spec and one of the first sentences says that the Unified Modeling Language is a language to describe processes?

J-M: Oh yes, we do have sequence diagrams, right?

Roland: Yeah, I have not seen any project who was using it in that effect.

J-M: Not just about process, but also about architecture, because I know that there are tons of different architecture models and frameworks and approaches, and all these sorts of things we’ve talked about some of them in the past, but particularly on the modeling side. I’ve worked with Archimate as a modeling standard. I’ve worked with and tried to dissuade folks from using UML as a modeling standard, and I have been put in a position to have to understand IDEF modeling, even though it’s a pretty old standard for us. Talking about how you use architecture models and modeling notations.

Roland: In general, it’s the similar thing to the process notations that we just spoke about. They come from a certain background, like IDEF, they come, maybe as a newcomer like Archimate, 10 years-ish / 15 years-ish ago, and they have different objectives. Like with Archimate, the objective is obviously to be able to have different levels, different views being integrated in one notation, but it also has that approach factor being built in, when I refer back to segment one of this show. 

The challenge that I see with Archimate, but that might be just my flavor, is that the symbols look completely differently than what you typically see in other notations. So what BPMN, for example, did well was it was using standard quote, unquote flow chart symbols. You know, rounded rectangles are tasks. Gateways represent the points where you route a process. All those things were things that people used from modeling in Visio, right? Creating a quick flow chart since the 70s. With Archimate you have a different symbol set and I think it’s a little bit hard to understand. Not that it’s not possible, but there’s a learning effect and you might want to make it as easy as possible for users to adapt to it.

J-M: If you’re starting from zero and you’re trying to build an architecture practice, I’ve seen organizations get started and just say “hey, listen, we’re going to use Archimate” and everyone goes “OK. I mean, I guess I’ve been using PowerPoint, so this is at least making a decision that’s consistent”. And it does have a pretty comprehensive symbol set.

Roland: It does.

J-M: I kind of like it, but to use it right requires an organizational decision and a practice that is established and maintained through change management.

Roland: It does, on the other hand, it’s also maintained by the same group, The Open Group who maintains the TOGAF standard, and what I’ve seen in clients, is that an IT group (for whatever reason) chose to use TOGAF. And don’t get me wrong. I’m a big fan of TOGAF. But then they said, well, if you use TOGAF, you must use Archimate, and I think that’s just not the case.

J-M: The other thing is that if I’m looking at interchange languages, it’s not quite as well established and accepted, but I know .archimate as a file format does exist and does import and export from a few different platforms, so it’s not. It’s not actually an island. You do have the ability to move data around, not to push argument, but just say I like it.

Roland: I agree and I have to admit our Dutch neighbors, for me as a German speaking here now, our Dutch neighbors are always very creative.. And I see a couple of tool vendors that come out of the Netherlands and I have to say chapeau, they’re doing a good job. I like what they do compared to other vendors from the rest of Europe or from North America who are very confident in what they’re doing right now. So the Dutch people obviously seem to be the shakers and movers. Which I like.

J-M: Ooo excitement! Well thank you so much to the Dutch people for inventing and creating these new ways of doing things that are pushing the boundaries of our industry while talking about pushing the boundaries and getting places. We want to get benefits out of using this content and using these structures and, Roland, obviously from all your project work and from the different contexts you’ve done this in, what have you seen as benefits of frameworks, methods, notations and reference content? We started with those four pillars. What do they give you if you do it right?

Roland: Maybe we just go through those four different topics just to close the loop. When I look at frameworks like TOGAF and all those, I think the big benefit for those is you get alignment of your users and get an alignment in the expectations of your stakeholders. I will point in the show notes through an article that I wrote about the structure that you should set up in your database, your architecture tools database, that then can reflect this. 

So when we think about, for example, the TOGAF ADM, the Architecture Development Method. I typically like to put in two main folders. One is what runs the enterprise baseline and the other one is called Projects / Solutions, which refers to phases E & F of TOGAF. But within that you describe architectures. So you would have your Phase A strategy, or vision as it’s called, Phase B business architecture, phase C applications and data and Phase D technology and it’s shown in both in the enterprise baseline (what runs) as well as in the project solutions (what changes). So basically you train your users to look for a certain piece of information in the same place. And that is, I think, a big benefit that you have. 

And it also, obviously, when you think about the stakeholder never you can always say look when you go through the life cycle of your solution. You have your baseline. You do analysis, you derive your improvement points and then you create solutions to tackle those improvement opportunities. Once you implement them, obviously your blueprint will update. Once you go live, it’s easy because you have the same structure to merge content from your solution folders into your “enterprise baseline” and replace the outdated “what runs”. So I think it’s a benefit and you can sell that to your stakeholders to say: “yep, you accelerate your projects because the next project does not have to reinvent the wheel” and start thinking about what’s my application landscape or what’s the process that I want to change. It’s already there.

J-M: And we think about that a lot in this podcast is what does it take to lower the barrier to entry to project initialization and success through architecture and process improvement, and having that in place, making those decisions, and implementing that as sort of a guidelines and a guide track that someone can follow makes it way easier to get in for this project and for every subsequent project.

Roland: Fully agreed. When I move on to the next point, the methods, we spoke already about this. I think the biggest benefit is to establish your methodology group, your methodology committee – think about the three branches of government. That also has an impact on the notations and the metamodel that we spoke about. 

One thing that I would ask you to do is when you adapt a method, have a look at the rituals that come with that method. So for example, the first time you do some Agile or you do Scrum, you have some weird terminology. You don’t have the traditional status report that you give, but you have the three questions. What did you do today? What do you do tomorrow? Where are your impediments? And that might seem to be silly in the beginning, right? Why should I tell you that? It’s my gig that I do here. So follow the rituals, at least for a certain amount of time to see how it works out. Because they are brought in by experienced people who brought then to pen and paper.

J-M: And of course we also want to talk about the benefits of establishing and maintaining a consistent notation right? You’re looking at something that’s going to help you with your technical governance of all your models of all your data and information you’re bringing in when your notation is consistent, you’re better [be] able to understand the contents of what you have, share it with the people who need to see it, and be able to analyze and improve it with the same baseline conditions. The same baseline approach to visual representation and conversation, and you’re ultimately creating a documentation set. This sort of canonical set of information that you want to present to both the stakeholders who are sponsoring and supporting these process projects and improvement initiatives and ongoing support, but also to your practitioners. Your end of line people. 

And the more consistent within which you can present this information, the better you can get out of those people. They’re able to consistently see the same thing the same way every time, and they know what they see and how to put it into practice. That’s really important. 

Also, when you’ve got notation that is flexible and powerful, you’re able to better gather feedback from a variety of different groups. If they can’t understand it or it doesn’t apply to them, people can feel like they’re uninvolved and inspired. They’re not enabled to affect change the organization. That consistant notation gives you the capacity to evolve, involving more stakeholders and involving more different types of use cases and concerns, and ultimately bringing that business together, becoming the connective tissue of your business. So establishing and maintaining that notation is incredibly important to bring everyone together. 

And then lastly, we talked about reference content briefly, but remember that reference content is a great way to get started as an accelerator. It isn’t the only way to go. In fact, it’s meant to give you that sort of rolling start, as they say in NASCAR. It’s the rolling start of your process improvement, your process design, but it certainly isn’t the whole race. Think about it as a great way of bringing in a vendor perspective. In the case you’re looking at implementing a tool set or bringing in perhaps best practices from SIs and other consulting organizations and what they have done in the past is a good place to see where pitfalls might come up, what KPIs you should be looking at. How that might interact with systems at a sort of system agnostic level, and that’s great, but ultimately reference content is going to be a pattern upon which you build. It’s sort of the weave that you’re going to thread your company’s special sauce into, and ultimately be able to adapt that to what you need to see. 

So that’s the great value of it: it gets you started. It gets you moving it. Gets you going without any additional work to start from zero. You don’t have to wonder, hey, how do people think about these processes? Well, here is how other people did it. Now how are we going to do this?

Roland: When you think about going forward, that’s obviously when you mature in your capability. You obviously would develop your own reference content going forward, because that’s what a lot of clients have asked me with a low maturity to say, yeah, we want to have reference models. Typically they’re thinking about technology in this case, you know IT folks. And they’re super disappointed when I come back with the Spiel and say “you’re not mature, you don’t have the foundation in place for this”. You have obviously some stuff collected in various formats, PowerPoints, word documents, whatever you find on SharePoint, but it’s not consistent enough because you don’t have the necessary catalogs that relate things to each other that you would need to build as a foundation of your content in your architecture tool.

J-M: And this is also great advice for smaller consulting shops or independents who are looking to try and later on sell their knowledge. I mean, you want to get a repository of what you’ve done, how organizations have used different platforms, how organizations have approached processes, but you need to establish a constant notation or framework or structure that you’re going to put that in so everything slots nicely as you accumulate it into an overall content package. So that you can later on harmonize all that and then structure it so that new clients can take advantage of those learnings as part of your offering. 

I talked to a lot of the partners of the company we work for and they always ask what’s the reference content? Would you have things that you can use to help our clients get started and answers? Yes, because we spent 25-30 years accumulating it in relational database repositories. So let’s structure it, and that governance, that control, that management of content? That’s what gives you the power later on to start the next project at 30-40-50-60% of the way there.

Roland: Agreed, agreed, but maybe to close out this segment when I think about looking at industry standards in all four areas, frameworks, methods, notations and reference content. I think overall applying those industry standards will make your architecture better. 

You know you learn from the experience from others that have been there before who went through that Valley of Tears and developing those content, J-M, that you just mentioned. You can reuse and adapt stuff that already exists.

And then maybe the most important part of it is when you invent things by yourself. Organizations typically like to get into a groupthink mode where you see that ‘not invented here syndrome’, and they reject everything that is not invented in their organization, which at the end of the day it’s the survival of the fittest, the organization that can adapt the best, not necessarily the one that has the best technology. Because otherwise we would all have Betamax and not VHS.

J-M: Well, that’s wonderful, and that gives me a good jumping off point for the last of our thought exercises today because one of the things Roland and I have been mentioning all the way through this particular podcast is reference to external materials that are relevant to you, and you’ve heard a bunch of our thoughts on notations, frameworks, methods, reference content. But what’s the next step you’re going to take? So think about: what are you going to do tomorrow? What are you going to do next work week as you approach your personal evolution into these four topics? And what are you going to do for your organization to help them better understand what’s possible as they evolve into their next phase of getting better with notations, notations, notations?

Musical Break – Airplane Seatbelt, Jeremy Voltz

Roland: Welcome back and I hope that you thought about what J-M just asked you to think about, which is great and I hope at the end of this episode you took away the big blocks that we’ve seen and we discussed in the last 45 minutes. 

It is frameworks, methods, notations, reference content. What is it all about? How do you decide on those? How do you implement those down to the nitty gritty of: which notations should I use? And then we spoke about the benefits of those external references and industry standards usage. 

As always, you find articles on whatsyourbaseline.com that cover those topics, and we will build out more of those. So stay tuned and subscribe to our newsletter that we’re starting to set up, well by the time you listen to this episode, it is set up.

But as always, please reach out to us via email at hello@whatsyourbaseline.com and submit us your feedback or click on the link in the show notes that allows you to record a voice message on our podcast host, Anchor.fm, and we’re happy to bring in your feedback into a future show.

J-M: And as always, thank you so much to everyone for being here listening all the way through to the end. We’re really excited to have all of our thoughts and your thoughts combined together to make our lives and your lives better and around business process architecture and enterprise architecture.

Roland: And don’t forget to rate and review this episode in your podcatcher of choice. And as always, you will find the show notes at whatsyourbaseline.com/episode5.

J-M: As always, I’m J-M Erlendson.

Roland: And I’m Roland Woldt.

J-M: And we’ll see you in the next one.