Episode 11 – Governance design

Ahh, governance – the topic that is boring to death and had complete EA groups being fired.

Love it or not, setting up the “rules of engagement” is still an important piece in an organization. And you can do it while having some fun when you remember the points that we are talking about in this episode:

• Role of governance in architecture activities and how it was seen in the past
• Archetypes of architects – governance as low/low activity (and hence the popularity of EA groups to focus on this topic)
• Who should be involved when setting up the rules of engagement
• Governance automation and how to implement it
• How to design governance processes – push/pull communication, elements of the implementation, measure gov. KPIs
• Organizational design for governance – three branches of governance (legislation / standards group; jurisdiction / ARB; executives / CoE), centralized / decentralized governance setups
• Additional aspects: enablement, project tracking, workload balancing, content freshness, confirmation management, dashboards / hold participants accountable / workflow routing / visibility
• Two client project examples

Additional information

• Archetypes of architects

• Governance as part of the architecture tool implementation (read more about it here and listen to Episode 3 for more info)

• Spotify’s organizational model:
  • Spotify Engineering Culture (part 1)
  • Spotify Engineering Culture (part 2)

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

• CP1 (Welcome)
• Airplane Seatbelt (Interlude 1)
• FC3 Groove (Interlude 2)
• Cowbell (Interlude 3)
• South Wing (Outro)

---

Transcript

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

Roland: Hey J-M, how you doing?

J-M: Hey Roland, I’m doing alright. It’s getting chilly out. We had our big first snowfall last

night and boy is a wintery Wonderland out there now. Man, I’m loving it though. I always dream of a white birthday. I’m born in the month of December, so if I can get a nice snowfall before then you know it’s lots of fun. I love it.

Roland: Well, what am I supposed to say? I’m a summer child, you know, early September. It’s just the best time of the year. And I wish I had a second home in the Southern hemisphere, you know. 

J-M: Wow, so you could completely avoid all the things that I love. Isn’t that why we’re perfect Co-hosts?

Roland: If I could, if I could not, not everything that you love, but at least the cold weather.

J-M: Well, one of the things that I really love is the topic of today’s conversation. And I’m really glad we’re getting a chance to get around to it. Because, boy, it’s a really important part of our ecosystem of making architecture successful. And that is governance and governance, design and role. And you’ve had a ton of experience with that. Before we get into the topics of the show, what brought you to focus on governance? What was the first sort of taste of the need for governance that pushed you towards interest in that topic.

Roland: Governance is a topic that nobody is super excited about, so you might be the only person in the world who’s really excited about this. But there is a need to set out the rules for engagement, right? You need to say OK, who’s doing what and it needs to be coordinated in some form of fashion and the challenge that I see with that is when I look at architects and architecture as a discipline. A lot of the organizations who did this were just saying, well, I don’t know what you do content wise, but I know for damn sure how I can control what you do. So a lot of those organizations went and became the Governance Masters if you will and they made everybody else’s life miserable, right? So one webinar that I participated in I had a moderator who just came and said look, the ARB is the committee of “No”. But most people think yes and no no because. That’s what they say and he said no, no, I want you to think about a committee of no KNOW you know. So how does that change? And I think we’re still in that phase that a lot of organizations focus on the governance instead of focusing on all the other things that you should do. 

J-M: I completely agree with that, but at the same time I really found the love for governance when working in unstable spaces. Teams that didn’t have the mandate or the drive or the skillset and expertise or the exposure to the rest of the organization and really well-meaning people moving into a Wild West, and that’s where it gets really dicey. That means that you’re releasing content, you’re rolling out best practices to a larger team that haven’t really been validated, and you’re not being able to see everything put in the same space, be able to validate that the best practices that you’re basing your work on are in fact current, and they have been seen, that they’ve been approved. Man, that really kills the motivation when people aren’t able to see all this stuff and trust all this stuff and governance really is that gatekeeper to trust and we want to take a look at that today. How can you make that happen?

Roland: Yeah, but that is a mechanical outcome of it. Yes, you need this, but I think maybe for our audience it’s a little bit more interesting to say what role does governance play in developing architectures. And one thing that we did at my previous employer, we had a nice two by two matrix because as you know, consultants love matrices. And in this case (and we’re going to put it in the show notes), the X axis is the degree of specialization and on the Y axis is the scope of contribution. So when you think about it, say we start in the lower right hand quadrant, right? We see very specialized people. But in the overall effort there is a relatively low contribution, right? You see all those specialists, you see your business architects. You see your application, architects, you see the specialist in tool “X”. You know it’s all important. And when I spoke with people about hey, I need an architecture or got this question asked. Everybody thought something different when I got this question. So in this case typically they asked for the content. And content people are important – that’s the whole meat of why we’re doing this. When you then go further to the left where you have a low contribution but also a low degree of specialization. This is where you see the governance. This is where just because it’s low and low right, most people thought they can make a splash and they can do something and this is how all those ivory towers were built. I think the more interesting roles are when you go to the high level of contribution, right? And when you think about the high level of contribution and a low specialization, which is the upper left quadrant, well you will see an architect as a strategic advisor, you know. Somebody who gets brought to the table and who helps defining the what. What should we do right? Because those are the folks that typically would see the relationships between the different views between the different things they know which projects are going on, all that stuff. And then inevitably, there’s the 4th archetype, if you will, in the upper right hand corner, high contribution as the strategic advisor, but high specialization. That is the transformation agent, you know. The how. How do we make this happen now? What are the details? And what I’ve seen in the past (when you think about those four quadrants), I’ve seen a lot of people in that lower left hand quadrant, you know, low contribution, low specialization governance. Let’s put on some rules and we’re good. And I think going forward that should be significantly less, and we’re going to talk about how that could look like in this episode here. And I think we should have more of the high contribution stuff. You know, the what and the how. 

J-M: Yeah, I think that when you’re talking about the “role” side of enterprise architects, I want to also scale this out to the different types of contributors to the governance process. And we talked a little bit about the “why” at a high level you should be implementing governance around EA and BPA, but in how you implement it and who it affects, let’s talk about deciding on who is involved in this governance process and when they get involved in the process. We have a model of course, as process experts we always have a model, but let’s talk about not just the roles of an enterprise architect but also the meta-roles of who’s involved across the organization. And I think that one of the things that is often focused on is a lot of ownership. The ownership of the architects, the ownership, the process, the owners are often involved, but I feel like we often miss the end-affected. The users, the specialists in their different domains. Who should be brought in. So let’s talk about how those governance rolls down and how you would roll governance up.

Roland: Yeah, so the question is when do you start with that exercise right? In an ideal world, that would be a topic of your implementation and you and I spoke about this in a previous episode where we said OK, where is it in the main work package in the implementation? And for obvious reasons governance is one of the important things here, but in general, to answer your question, I would start with any activity that an architect does with the stakeholders. Who is it for? What are their needs? What are their objectives? What is their role in that whole game? So that would be the first group, right? Because they will give you guidance. What do I want to accomplish? How complex is this? How big of an effort is this? And so on and so forth, right? And they might have conflicting interests. You know, one of the stakeholders might say let’s do quick and dirty while the other says no, no, no we need to follow that well laid out process and every step and every signature must be very very precise. So now you have a conflict. 

J-M: Yeah, that’s good though, right? You’re getting this healthy discourse between stakeholders.

Roland: The second one is the people who are tasked with implementing your tool. Those are the experts that might know limitations, what’s doable and whatnot when we think about automating governance processes. You know the best ideas die if they can’t be implemented. But then obviously your owners come in. If you have that set up in some form of fashion. And even if it’s just on a very high level that you say, oh JimBob owns this and Sue owns that. That’s helpful. Bring those people in. Those will be the guys who may be supported (and that might be the next stakeholder group) by the PMO, right? All those people who should then track everything. And if you recall, our little approach that we discussed in the earlier episode, we said, develop a strategy and then build dashboards and reports to see where you are. So bring those guys in. And then last but not least, I would have a look at other involved parties. And the first one that comes to mind is obviously your risk people. When you think about the three lines of defense, you know they have different objectives. One is interested in the operational risk management. The other one is interested in setting up a risk management system, which is the governance process in itself, and they might have made decisions. And the third one is your internal auditors who actually do the work. I think that’s very important. And then lastly, I would bring in a selection of users, so if you have an idea where you want to go. Do you do a business architecture development processes or is it a larger solution that you want to implement? Bring in people who will contribute as representatives of your end users because they are the guys who actually have to do it.

J-M: And I think you brought up a really important point and word there or representative. Remember that we’re talking about creating these groups of stakeholders and affected parties that are going to help contribute to the development of governance. So this strategy and design and also to the implementation and execution of governance. So that makes a lot of sense. But you can’t obviously hold them all in a single room, so one of the things you’re going to want to do is roll up insights from groups of people – get representation of those folks in smaller meetings where they have a chance. Bring together concerns and ideas and then roll up those insights through the representatives, maybe on a Governance Council or as part of the governance discovery and design process, and that’s really important to be able to manage the scale of contribution because everyone’s got ideas. As you said before, there might be some storming going on, but we want to come to a design that works for everybody in a timely fashion and that takes paring down the number of voices to what makes the most money sense for you. 

Roland: Wholeheartedly agree!

J-M: So along those lines, we talk a lot about making governance come to life and the last question I wanted to ask is a two parter. We’ve been talking about governance and the automation thereof. I’ll talk a little bit about why I think that’s really important, but then I want to talk about the implementation approach of automation and I know once again we’ve got a great graphic. And Roland, you’ve done a lot of this here, but from my perspective, automation of governance is really important. The very first reason is to reduce the perceived effort required to implement governance; the perceived effort required to maintain governance; and to incentivize people to follow along with governance design, governance strategy and governance requirements. The more you feel like you have to have a human touch them or do you feel you have to be involved in something, the more disincentivizing you are to people who are worried about that worry about efficiency. They talk a lot like “if we’re trying to be lean and agile and these governance activities are slowing us down” or “we have to have a lot of human beings, it’s a very costly process, we don’t know if that’s actually valuable” and there’s a lot of this that gets eliminated with automation. So one of the first big investments you’ll make besides the strategic design, is in finding a way to implement that in technology. In taking that as an advantage forward to, say, listen, we’re getting the value of governance, and we’re not even paying the people that we think we need to have to pay or doing the manual effort that’s going to cost a lot of money we would have to pay for in human labor. Instead, we’re going to be able to use those people for their intended jobs, and not for sort of keeping this governance process going. 

Roland: Yeah, I think the challenge with that is you can go overboard with that. You know you can build the most elaborate toolchain of whatever you cobbled together and that will kill the joy as well. So my recommendation would be instead of trying to bring various tools together, have a look at your architecture tool. If that has a workflow engine being built in, it’s seamless. You can create custom dialogs, and you have task lists in the tool so that you get nagged and have all the links available in there. Because what I’ve seen is organizations who said no, we don’t need this. We have our ITIL certified ticketing process in JIRA, so this is just another ticket type. And I can promise you those tickets will never be closed because people might do the work and then they simply forget to go back into JIRA and close it. And when you run the reports you get obviously an undesired result. 

J-M: Yeah, you want to do governance closest to the source. And that’s very easy for you to take that work that you’re doing, be able to govern it within its own confines, and then push that governance inside out to a larger group of stakeholders, right? That seems to make a lot more sense to me. But implementing that – and Roland once again, I know you’ve got this under your belt, tell me about the implementation approach you would take to governance. 

Roland: That’s a very good question, so there’s obviously different aspects of governance and we will talk about all three of them. One of them is what I’d like to call the technical governance, and we spoke about that in the episode when we spoke about notations and frameworks. This is all about what is the method that we want to use? How do we configure the tool? What are the different views and viewpoints and models and what not, what we create? This also includes the integration of your tool with other systems of records you know, building the interfaces and building the reporting and the automation so all the technical stuff in some form of fashion. The second part is looking at the processes, so we’re talking about what we ask people to do and this is why it’s so important to have the representatives that we spoke about a minute ago to be in the room. They will say hey, I want you in your role as “modeler” to do this, or I want you, J-M, in your role as the release manager to do that. And obviously those folks should have a say in there. It shouldn’t be somebody in a closet who just comes up with the best idea defining those processes. And my recommendation would be to map them out. Take your architectural tools so you have something to show. Create a value chain, one diagram, put all the steps in there. What you think people should do, and then create BPMN diagrams underneath that. Then show who’s doing what and where the process interfaces are and what are the artifacts that somebody should create. And so on and so forth. And then the last step is looking at the organizational side. Which roles do we have? Which skills do we need? How do we organize in groups? Do we need a CoE? Do we need an ARB? Do we need whatever, right? That will then have an impact on the training. And then lastly, once you have all that put to paper then just like any other automation project I would say let’s have a look at which parts of that value chain we can successfully automate and which ones we should automate? Because then, sticking with that example of your role as the release manager. Somebody who packages everything. For example, a certification of models every 180 days. Needs does that person have? I can definitely imagine a dashboard that tells him, oh those guys are late, you know? Or I have those exceptions, or I have those guys who come in for this and that reason who want to be part of my release. So I have to change my release plan. You don’t want to have a third person mapping this out but bring the people, the representatives who will do that work in those conversations. And then it depends on your tool how that works. In the tool that you and I use (ARIS), it’s all graphical. You model a process, you model the screens, you wire them up, and then you press the magic button. And lo and behold, it executes that process, so that when you go into the tool and you have a model, you have a button to click on and say “submit for approval”. And there might be others who do that differently. Other tools. But at the end of the day it should be a custom process that meets your stakeholders and your representative’s needs.

J-M: Yeah, of course we’re going to address it later on, but you’re talking about really doing discovery on your stakeholders needs and keeping those discovered needs throughout the process of development and execution of governance. We never want to walk away from our stakeholders. They’re who we are serving with what we do. And I think we talked a lot about this “ivory tower syndrome” where we lose sight of who we’re serving. Well, this is a time to reflect, remember that they are who you’re looking to support and build structures, processes and interfaces to best meet their needs. So I know we’ve talked a little bit about this and there’s a lot that we’re going to put in the show notes, but I wanted to stop for a moment to ask a question to our audience because we love to get some thoughts in there and give you a chance to reflect on what you’ve heard so far. And our question for right now is: what are you doing today around governance, in your role, or at your organization? Things you have visibility to things you’re involved in. If you are involved in governance, what is working about that versus what are you struggling with? What is a challenge for you? If you’re not directly involved, then what are you seeing as challenges? We’ll give you a couple of seconds to come up with one to three ideas or change requests. What would make this process easier for you? We’ll leave you for a moment and come back with our thoughts and a little bit about the “how” of process and governance.

Musical Interlude: “Airplane Seatbelt”, Jeremy Voltz

Roland: So welcome back, I hope you had some time to think about it. As always, the PSA “don’t take notes while driving”. And now I want to switch topics a little bit. J-M, and get into the realm of ‘how do we make these things happen’. And two things that come to mind are processes and organization. You know, how do we set this up? So let me start with the first area, the process governance, J-M. What have you seen in the past and how do you design those governance processes?

J-M: That’s a great question, and I think the first part of it is getting information. The governance of process and architecture is about designing a process, and that process is going to revolve around your stakeholders needs, your organization’s needs and ultimately what you want to be able to produce with this governance. You want to be able to produce governed validated architecture artifacts and process models and everything that goes into the way your organization works. So the first thing you want to do is talk to the people who are creating those things, so you’re looking to discover things from your architects, from your process modelers, from the people who are actually at the ground level working. What are they doing, what are they able to give and what do they need to get back? So a perfect example would be architects – might need validated, reusable knowledge. Think about those as like your standard objects of applications or data or organization or things that they’re going to be using in their models, regardless of how you’re doing your modeling methodology. These are standards that they want to be able to get back, so the first thing they’re going to say to you is we want to have a process by which we can ensure the information we’re using has been validated. OK, so now I understand I need to have reusable knowledge objects as part of what we do.

Roland: So you’re talking for example about things like technical interfaces to other systems of truth, you know, yeah?

J-M: Exactly, yeah, and the next thing I need to understand is what is being put upon my company as a requirement of those things could come from external sources like regulators or regulatory requirements could be internal or external auditors for the purpose of certifications. If you’re like ISO certified, or if you’ve got other sorts of compliance to regulatory sets that will allow you to get a certification that’s really important to know so you can design your governance process to make sure it fits within those parameters. The third piece of discovery is of course from management. What’s necessary for them to feel comfortable with the work that’s being performed? What expectations do they have on the content the architects are creating and the way in which that content is disseminated? So you need to know what the expectations are on you from above. So now we’ve got from below we’ve got from inside and outside and we have from above. That information is really good to start making a model. And I think Roland alluded to it in the previous section, you’re actually creating a process model, a BPMN-style or EPC style in any style process model. It doesn’t really matter, but what we’re doing is creating our own process for governance and that process for governance is going to have a few different things. First and foremost, it’s going to have a flow. So you’re going to have a series of steps that will occur in an order that will allow you to achieve this governance goal. And that flow is something we will later on talk about how to automate, but let’s start with the flow. What happens in what sequence? 

Next, we’re going to have conditions and variations, business rules of our flow. So why would I have to seek a secondary approval? Are there certain conditions, like, for instance, is a priority, this is a concern with this particular project, this is part of a certain business line. Those rules are going to help us have a variation to that flow. So we’ve our standard flow. We have all of our variations to that flow. The next piece of the puzzle we’re going to need to know is: at every step in the process, what is executing that process? Are we looking at somebody as part of a governance group, or are we looking at automation that goes in and does something for us to support governance? A perfect example of that is: a lot of the processes that I’ve designed for governance, it includes what we call a semantic check. We’ve talked about this before, but it’s the idea of evaluating the content you’ve created for semantic accuracy. Does it follow our standards and guidelines for how to represent information and connect information? You might as well automate that, because if you’re looking to do that manually, having somebody eyeball every process, that can get quite cumbersome on your governance structure. We’re seeing are there things in place that are automated? Are there things in place that will require a human touch of sign off? And once again, that could be something that’s discovered from those previous three groups.

Roland: Yeah, when you talk about sign offs, maybe one trap that I hope not so many projects fall into is something I’ve seen in the past. People looked at existing governance groups because there’s a governance for your risks and there’s a governance for your projects and there’s a governance for your technology XYZ and so on and so forth. And then they designed a governance process that had 50 players in there and each of those 50 players was expecting to get that little snippet of information being served on a silver platter. And I think if you design your governance process in that fashion, you don’t do anyone a favor. J-M, what are your thoughts on that? 

J-M: Yeah, I think you want to make sure that you understand ‘us’ versus ‘them’. What are the edge boundaries of the concerned stakeholders of your process and narrow down your governance touches to the people who need to see it and need to be affected by it. Otherwise, you’re opening up the world of possibilities to everyone around who wants to chirp in on everything that’s associated or you’re opening yourself up to a world of hurt, of trying to wrangle the cats of your organization to come in and give you their two cents when you don’t really need them. Or somebody within your own house could have done that same job. You’ll end up paying in time. You’ll end up paying in frustration, and ultimately I think you’re not going to get a better result. It’s just going to cost you more.

Roland: Yeah, and when you think about it, it’s always push or pull right? And obviously have a favorite on this, but if you always go push, that obviously puts a load on the people who execute those governance processes. And that’s something that you want to avoid because at the end of the day, I think you want to have your roles, your architects, your modelers, everybody who you’ve designed in there. They are here to create something; to create your solution. They’re not here to execute that governance process. So just food for thought, when you define those interfaces to existing groups or involve stakeholders and whatnot, think about push or pull, and in most cases I would recommend to make it a pull exercise. But say, hey, you get pinged to give you $0.02 to this, but don’t expect me to present that stuff to you. I build a dashboard, for example, or I build a report for you and you just press this button and grab it from there. And I know, because I’ve worked in those organizations that are very quote unquote, traditional, you know where people live in their inbox, those have a hard time adjusting. And that’s a cultural aspect that you have to have in your mind when you design your governance processes. 

J-M: Yeah, those are really good points, and we’re bringing in all those elements to create this physical model that represents it. Now that model has a few different components to it that will help you to achieve that automation or achieve that connection; achieve that relationship. And we talk about that in the implementation side of things. In your model, each of those pieces of text saying  “hey, do this thing” – this little box becomes a code block. And to do that you need business services. Either you’re writing code for each piece of that puzzle, or most tools have standard code blocks you can pull from. For example, once again that I use all the time is code blocks that will allow me to pull information from somewhere or code, like for instance, who’s the model owner of this thing that’s being approved, or code blocks allow me to move information around. Like, once this model has been approved, I’d like to migrate it to a production space where people can see it. Those are really handy things, ’cause once again each of those steps is going to have some component of automation to it, even if there’s a human touch. The next thing you’re going to need is screens. Screen Design is an important part of it because you want to make your interface as easy as possible for people to use. Remember, as much as it is a part of their job, we are kind of asking nicely for people to become involved in this. And if they don’t, there’s some recourse, but we can make this go a lot more smoothly with honey than vinegar.

Roland: That’s a good point, J-M. When you look at what do you ask people to approve? Typically it’s just a subset of a bigger artifact. You know when you think about the solution design you have your processes, your apps, your works, or whatever. You involve people to say, hey, you’re the expert for this. Can you give me a thumbs up on that? And one thing I would recommend, and this is against everything that you read in the TOGAF spec, for example. Don’t create a big document. Because if you get a big document of 500 pages and somebody says I think you should approve somewhere around page 324, it will not happen. Or they read everything and it’s not interesting for them. However, if you do this in your architecture tool, you then say: look we created this model, this narrative for you that is relevant for you. Can you have a look at this? And your screen for that role has a link that says ‘click here’ and then only that information opens for them and they can give their comments. They obviously can navigate in auxiliary views that are somehow related to it, but the focus is still on that single thing that you asked them to approve. And if they get lost they can cancel and they can do it again and start over. And I think that’s one thing you should keep in mind. Don’t create the 500 page documents that we all know. Nobody will read anyways after the project.

J-M: Part of their job here is in experience design. Not just for external, not like our customers or clients or our partners, but for our people, internal. The better experience we can have interacting with them and they can have interacting with our process the more they’re likely to do it, do it right, do it quickly and be happy in doing it. So that’s the last piece of the puzzle here is that there is a technical component to it. Sometimes you’re going to have to add additional components besides the business services, things like messages and the screens we talked about before, the forms people have to fill in, the different interfaces they’re going to go to. But lastly, you want to get the information to wireframe up dashboards, because ultimately you want to present information back to them in a fashion they can consume. So that’s the standard UX conversation. Things like placements and emergent features, and all these sorts of things you’re going to want to do for a dashboard designed to help pass that information back. But once again, you are relying on drawing on that discovery you do at the beginning of process design to say, OK, this was really important during the process discovery side, it’s probably going to be very important during the dashboard design side. And ultimately I want to be able to provide that back to those stakeholders. So that’s the technical side of things and there’s a lot more to do with this, but I wanted to call that out as if there’s a few different things in process governance.

Roland: Yeah, to add to this because we haven’t spoken about that. If you think about one aspect of the whole program of the whole governance is to make sure that we’re successful. So as part of your strategy, you should have identified your KPIs and how you measure those to say, Yep, this is exactly when we say it’s good. So to give you an example, when we think about that release cycle, the renewal or recertification of processes on a regular basis. You want to measure how long it takes, how long it takes from initial submission to first rejection or approval, right? And any wanna have this on a per model base. All those little things that I just mentioned, but you also want to know where am I with the whole package? Do I have 95 of my stakeholders pressing the accept button and then love it while those 5% don’t open their emails? And they don’t see it, and they don’t click on it and what not and you have to nag them. Because obviously you as the release manager might get measured by how fast you can push a batch of models through that recertification process. So think about the KPIs on how you measure success. Just like with any other process design. What’s the outcome? But also define KPIs for your governance processes and that obviously then will lead into quote unquote SLAs, your service level agreements. That then will drive things like, well, how long am I willing to wait for J-M to press the button? Or, when do I start re-routing it? When do I start to escalate it? And those are also things that you should have as part of your process and in your automated process as well.

J-M: And that would imply when you talk about escalation, a hierarchy of approval, sort of delegation, or a substitution that’s available, which means you’ve got an organization behind how governance is done. And I know, Roland there, was some talk about the governance process itself, but behind that is the organization of governance that you’re trying to design and use technology, use practice to really bring to life. Tell me a little bit more about that organizational governance side. 

Roland: Oh yeah, so there’s multiple aspects to it. One is obviously the organizational side. That is where you need to go in deeper into what your roles are doing to be able to derive permissions, for example, or to be able to configure them as participants in the governance process. But let me take a step back. When you think about governance, each and every one sees that (some of us just every four years) in how we manage our society. You know, we have three branches of government. You know we have the legislation which is in our use case, our methods and standards tool group, which most likely is the one that we were just talking about in the last half hour, who define the governance processes. Then you have your judges. You need some form of group, and what I typically see there are groups like an architectural review board, for example. Those are also part of your governance process. Those are the meetings. Those are the groups where you find consensus during this process. And then last but not least, you obviously have the executive, and those are the people who drive everything. And what you typically see there are centers of excellence. This is the place where you have the enterprise architect role being in charge to define the system. How people do things. This is where you see the places where you have all those specialists. For example, your developers, your administrators and all those guys who work on behalf of other people. Your modelers, your solution, architects, and so on. So I think you need all three areas. If you think about governance or government in this case. If it works well, I think those three areas should be in some form of fashion reflected in your organizational governance.

J-M: If it works well…. How do we set them up for success?

Roland: Yeah, the good news is you designed it, with all the stakeholders that we have involved. So hopefully they do have a stake in there.

J-M: Yeah, the good news or the bad news is that you designed it right. If it goes well, you’re golden. If it goes wrong, it’s on you. 

Roland: The question comes up, now you have defined it. You said yes, we need an ARB. Yes we need a CoE right? Then the question comes up. That’s great. But how do we build this, right? How do we set this up people wise? And by the way, how do we set up our governance? And when you think about it, that’s different aspects of it. You know you could do it in a very hierarchical way. You have the boss approving everything every step? Every decision goes to the boss. If the boss is not there, the process stops, right? In some organizations in the past I’ve seen the governance groups playing that role. This is how the committee of “NO” came into life. Another way to do this is you could do this in a consensus-driven way and some of the concepts that made it in the business world are, for example, what we see at Zappos with Holacracy, where people build circles and they have a very fine measure of connecting those circles to each other and then they make the decision. So it’s a decentralized, consensus driven way of making decisions which obviously comes with its challenges. You have nobody to nail or to put in a barrel of tar and feather if you don’t have a hierarchy there, right?

J-M: I see Roland is used to this kind of approach for “organizational punishment”

Roland: No, no, but I do think accountability is very important!

J-M: Accountability IS very important.

Roland: The third way you could do it, you could have a laissez-faire approach to it. You just say: “I don’t care how you do this, you’re responsible for that”, and everybody works in a silo, right? And I think everybody on this call and listening to this podcast has seen that siloed organizations have their own issues, so you don’t want this either. Another way of doing this is you just define the guardrails and you have a cross-functional decision-making mechanism, and that is a little bit of a mix of siloed and consensus driven. It’s like you write down the specifications of a thing that you want to do and you hand over the specification as good as you can, but the person who reads it understands something different, and then the thing that you get is not what you expected. And it’s the same way that you could see here when you have those border impacts, if you will, and you hand it over to somebody else. And you don’t know what they make of it. Or you go into a big mix, and as you can see, your creativity can be endless here, you have some form of Federated model. When you think about the Agile folks, that’s oriented on your different solutions and your products that you build, right? So you have your architects that do the domains and then you have your solution architect and maybe you have a solution portfolio manager on top of it and they work in their little bubble. When you think about the Spotify model, and when we spoke with Mike [Idengren] about the Agile and Architecture topic I put links in those show notes which I’m happy to put back in here. Think about how Spotify is organized. So I think to get closure on this, when you think about setting up your organizations, you should think about the three functions. Make laws, make sure that the laws are followed and execute on it, just like any government should do. But when it comes to the details, it’s very dependent on your organization and what will fly in your organization, which structure you will come up with? J-M does it make sense for you? 

J-M: It absolutely does, and I think that it’s a great way of building-in success because if you start and you structure your organization, you create and you iterate and you validate your processes. Then when you’re ready to automate and execute. You have everything you need covered to give yourself the best chance for excellence in governance. And that leads us to the second of our questions for today, because we’ve talked a little bit about the “how”, the practice of putting process governance and organizational governance into play. Think about you now, what is essential for your governance process? What do you need to see from an organizational perspective? What do you need to see from a personal perspective? What’s nice to have? And what tools put those into place? Think about those two things, the essentials, the Nice to haves, split them up in your mind. Figure out how close you are to each and what those gaps are and we’ll see you in just a couple of seconds to reflect on the value and the meaning of all this governance and governance design. 

Musical Interlude: “FC3 Groove”, Jeremy Voltz

Roland: Welcome back to the next segment of our show today, and as we all know, J-M was asking us about what’s essential for your governance processes. You know, the nice to haves and all these things. The tools that you have in place. I’d like to switch topics a little bit about this because we spoke about how to implement these things. J-M, tell me a little bit about what we’ve seen in the past. What are the practical uses for governance that you’ve seen in projects?

J-M: Yeah, that’s a really good question. We want to talk about where we are getting the reason for governance? What’s the meaning of all this governance? And there’s a few different practical things you can do with it. The first is enablement. Governance is great for helping to support organizational change and organizational change management. Get input and be able to be an input for that process itself. So you can be able to push out changes to a larger community with validation, with authority behind them, and give them information in a timely fashion in fashions that they can consume so that they’re ultimately able to feel more connected with the change that’s ongoing. That’s something we talk about a lot in the more consultative side of our roles. But enablement is definitely something that governance can really support. The next thing is project tracking. We can understand that these large implementations and initiatives have a lot of pieces to them and we implement governance and particularly process-driven governance on top of an implementation, we can see ongoing how far that project has progressed. And it’s perfect for your PMO as an input into their status reports, I mean I personally worked on a project where I was using governance processes to inform the PMO of different team statuses – where they’re lagging, where they’re leading, and what outstanding issues had yet to be addressed in this project. The third thing that’s really good for governance, and particularly automation around governance when you start to track it (like Roland said) and dashboard it, is to take a look at work load balancing. Understanding who is doing what – so which governance tasks are being addressed by who, at what time? Where are things waiting for someone’s input? Where are people excelling? And you can stack this up. You can go by org. You can go by individual. And you can use this as a driver for better and more consistent behavior in terms of reviewing and approving content, but also in creating and addressing ongoing updates of content. And speaking about updates of content, one of the things we use governance for and we alluded to it earlier, but I want to be specific about this here. We talk about using governance as a mechanism for keeping content Evergreen. Your organization has a ton of collateral and it’s slowly going through attrition down to nothing. It’s going to have no value after a certain amount of time and using automation, and specifically automation and governance, is going to help assign tasks to individuals who are responsible for keeping that content Evergreen. Keeping it refreshed with the newest set of information around how that works and ensuring that everyone who’s looking at your knowledge repository is looking at the latest and best available to them. And lastly is the end state of enablement – confirmation management. One of the things that governance sort of falls into and ties into is a confirmation management approach. As information is rolled out, you can assign governance tasks. And Roland talked about this before as a poll versus a push, but you notify people and push information to them. Say: “hey things have changed. Can you, as part of a small governance workflow, approve that you have seen this?” Not that you’re saying, oh, I agree to the change rather than you’re saying I validate I have in fact read those changes. I’ve understood those changes and I commit to putting those changes into practice in my life. And that does tie sometimes with audit management that sometimes ties with regulatory compliance. Those are really important parts of how your company operates and the governance process you build is going to bring that all together with automation. 

Roland: Yeah, that makes sense. J-M. If I could summarize it, what’s the value of governance? Well, I think the big idea here is to make the process run as smoothly as possible. And while you’re doing that, that you have the needed visibility into where you are. Because as we all know, what’s not measured will not be improved. So that, I think, is the big idea behind it. And in our reality, what do you see? You see artifacts like dashboards. You mentioned the PMO that you delivered something to it. My comment on this would be: “Dang. Why didn’t you create a dashboard for them and they had to pull it for themselves if they’re interested in that?” 

J-M: That would have been better for me, for sure!

Roland: Yes, so take out the waste right of that process. The other thing is, keeping track and keeping everybody honest. We spoke about this when we spoke about the automation of governance processes. If you give somebody a task list and you track if they have done that task and you can act on it if somebody doesn’t work on that task, that is helpful, right? Because then you avoid the bottlenecks or you avoid that somebody takes forever and everybody downstream is waiting and then they get that big wave of work coming their way. Which you obviously don’t want. And then, maybe in the same way, and you also want to see the ways how you can route that flow. When do you need to escalate? When do you need to delegate? And we spoke about that a couple of minutes ago, right? So there is a role when you think about your role setup and most likely it’s in the CoE of somebody watching and monitoring those governance processes and then actively interacting with those participants and saying “hey. What’s wrong, you know? Can I help you? Why doesn’t it go forward? Where’s the issue?” You know, in a helping approach, not in a I’m the Big Brother with a big carrot – or in this case the Big Brother with a big stick and and I will beat you with a stick if you don’t do it.

J-M: That’s the Roland Way (™)

Roland: The other thing is, in general, just bringing visibility – dashboards, notifications, all those things that need to become reality when you execute your processes. But enough about theory, J-M, can you give us an example where you seen those governance flows in action?

J-M: Yeah, absolutely. So I had the pleasure of working with a major retailer a bunch of years ago actually, and one of the things that they were really struggling with is crossing the ‘great divide’. We’ve tried to break that down in a couple of different episodes here, but they had their EA group and their BPA group in completely different silos that were never interacting with each other other than to throw requirements over the wall. There was no sort of iterative design process at all. And what we did is we threw a governance process in halfway. We said: instead of just sending requirements over at the end of an exercise within your own team, why don’t we build automation that forces designs, as they’re being proposed, to be pushed over? So somebody would say, hey, I’d like to redo my architecture, here are the new capabilities I’m going to offer. Let’s push us over to the business group where those capabilities were previously offered and see whether or not this new architecture still fits with their needs. And I’m going to force them to pivot to factor into my own way of harmonizing. Well, that may be good but may be a problem for them. Conversely, the business group would go back and say, hey listen, I’ve got this idea. It’s going to rely on new services, new capabilities. In the middle of my design process, I’m going to get input from my architecture group. By automation, it’s going to force the conversation to happen and we essentially built a big circle of governance. And the end of this is that you kept going back and forth between these different parties halfway in their process. The end of this is once both of them clicked, yes we could move this into something that they could implement, both in the practice on the business side and the technology on the architecture side. But by making that conversation come to life through automation, it took away a lot of the personal issues that were coming up. There was no human involved in pushing this information to somebody else; it was just part of the automation, and so there was no tribalism. The conflicts were substantially reduced and ultimately better information got passed across the wire, and that’s everything we wanted with this governance process. But Roland, I know you’ve also worked in pretty large organizations in some pretty major players in the industry. Tell me about what you’ve seen from governance.

Roland: Yeah, I have a different example for you and I like what you said because to come back to your example first, I think one of the things that we mentioned in an earlier episode is you should have something like a release plan of what are your artifacts. So part of that visibility that I just spoke about is obviously what I have to expect. So it would not be good if the automation that you just described just dumped something on somebody’s lap if they didn’t know that it was coming in some form of fashion at a certain point in time. But anyways, let’s go to the example that I had and that was a different organization, an organization that was very affected with managing projects and they were a die in the wool waterfall-ish organization, right? And everything they did was waterfall, waterfall, waterfall and they forced that on their customers as well. What they realized was that obviously in the 21st century Agile comes in. And Agile was eating their lunch. You know their customers went to other organizations who basically were, well, more agile, more open to changes and not just following the strict process that you see in waterfall. So they came back and said hey, we want to change two and kudos to them. So what we did there is we implemented the Spotify model that I mentioned a couple of minutes ago with product owners and guilds and all those wonderful terms that nobody in real life uses. But they said, yeah, we want to have this. But we also realize that we need to have the three areas of governance in place. So we need our judges, right? We need somebody who makes the call. And they had an ARB. The Architectural Review Board in place before which was the committee of “No” N.O. And they didn’t like it and they got rid of it. And then they ran into the situation that they didn’t have the coordination. They didn’t know what other groups were doing, but other projects were creating, which was also not a desirable situation. So we were tasked with helping them, defining and standing up a new ARB . And the way we did this was to, say, look, we want to be nimble. We want to be agile in doing this, and we want to be first and foremost oriented on the outcome. So why don’t we start it with a very very light touch and we defined 4 phases. And the first phase was: OK with standing up this organization, but the only request that we have is that you tell us what you’re doing. And we invited the various groups – we defined who should be there in all these types of things. But then we also invited individual projects that were when you think about their development lifecycle, either somewhere close to the design phase or somewhere close to going live, you know. And we said, come in, tell us what you do. And that helped a lot because that was that eye opening moment like oh, you doing that? I thought I did this! Or I had that planned in whatever the next release for me. So that was the first thing and we didn’t put in any formal standards, right? We said, OK, bring what you have. This should not be an effort where you have to create something specifically for it, so they brought their PowerPoints and they were talking about it and it was good. The next phase was where we wanted to put a little bit more formal structure in there, or he said, OK, let’s make it comparable. Give us your artifacts, but give them to us in a way that is comparable. So go into the architecture tool and if you create an application landscape, this is how it should look like. Or if you create processes, this is what we expect, and you could tell us where it lives in the hierarchy and so on and so forth. The next phase, which interestingly enough we didn’t get to because it wasn’t needed, that would then be the approve phase. You know what happens if you have a conflict. If you can’t get to an agreement, somebody needs to flip a coin because otherwise you have that stalemate and people don’t move on. So the question is then, what’s the approval authority that this group has? You know, is it yes they have the last call? Or is it? Yes they flip the coin? Or is it no – everybody does what they want? And then the next, the last phase that we conceptualized, and again we didn’t get to this was the helpful older guide if you will. Hey J-M, you have that new project. Look, we have this governance process that you should go through. This is what’s expected. Let me help you with best practices. Let me help you with the tools that you need and so on and so forth to make this process not just painless projects but an enjoyable process. 

J-M: Yeah, a “come along with me” kind of thing.

Roland: Yeah yeah, and like I said like I said, it went well, right. We went up to phase two and that was all that they needed right? Because they came to the consensus that we spoke about a couple of minutes ago and they could find an agreement and it was a forum where they could exchange their constraints that they had. They could talk about the dependencies that they have between the different groups and at the end of the day they found agreement and the ARB became the committee of Know – KNOW. 

J-M: Ah, isn’t that a good story? Well, you can see these things going into production and being very, very helpful to organizations on their journey. But our question for you is: what’s your first step? So first and foremost, what’s the first step in your team to implement or improve your governance processes and organization? So who’s responsible? Find out who’s responsible for driving this conversation at your organization. Think about that in your mind. Figure out who you need to talk to and then, let’s come up with some ideas. What is the value that you think matters most to them? What’s the case for good governance and governance design for your organization and for your whole company? We’ll leave you for a second here to think about that, then we’re going to come back with the conclusions and the end of the show. 

Musical Interlude: “Cowbell”, Jeremy Voltz

Roland: So welcome back to the last segment of this show, and this is basically the summary we spoke about. So we spoke about the different types of architects that we have and where governance comes in and that you should have less than you had before. We spoke about the implementation, the three different types of governance, technical, process, and organizational governance. We spoke about the stakeholders and how you implement that, how you get the information from them, and design your governance processes in a way that it meets every stakeholder’s needs. And then we obviously spoke about the organization. How do you do this? From free-for-all to strict hierarchy or something in the middle in a Federated approach? And lastly, we spoke about practical use cases and the whole purpose of governance, the value and visibility of governance. So, J-M, what are your thoughts on the show today? 

J-M: Well, I think this is a really good exploration of this topic. I think it’s really important and often underserved, particularly in the strategy and design around it. I think there’s a lot of people who sort of clamped down, holding on for dear life, but not really having the right information in the right engagement to get us started. And I’m so glad we were able to bring our expertise and experience today. And Roland, it was great to have you to start this conversation for a lot of folks who haven’t been involved yet. So first and foremost, to those folks, and to everyone, thank you so much for listening. We really enjoy being able to share our thoughts and best practices with our wonderful community of folks. And of course, you can get lots more of those thoughts and best practices on the website, which is kind of a companion to this podcast at whatsyourbaseline.com? Remember, if you’d like to be part of the conversation, you can reach out to us by email at hello@whatsyourbaseline.com? Or you can even leave us a voice message on Anchor. Please make sure to leave us a rating as well and a review maybe on your pod catcher of choice. The more ratings and reviews we get, the more we’re able to push this great content out to lots of folks just like you. And of course, if you haven’t been taking notes because you’ve been driving (please make sure not to do that) you can visit the website at whatsyourbaseline.com/episode11 for a full transcript of the episode with the full show notes, all the graphics and everything you might need. Well Roland, any final thoughts for our wonderful audience before we say good afternoon?

Roland: I couldn’t have said it better, J-M. I’m just wishing that this episode was very helpful for somebody who’s tasked with setting up their governance right now. And I invite you to give us feedback – we’re happy to help and give you our two cents on that topic. 

J-M: Wonderful. Well, thanks again, folks. As always, I’ve been J-M Erlendson.

Roland: And I’m Roland Woldt.

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