Episode 12 – Ten things I’ve learned

Here it is – the end (of season 1 … no worries, we’re back with the podcast in January 2022).

In this episode we are mixing up the format a bit and are talking about the 10 things that we learned in 25 years of architecture and process management.

Approach / strategy segment

Let’s talk about the bigger picture, the why and larger setup. What are the thoughts that get organizations started?

• Why: You’ll end up paying for it somehow. End of the line in people or risk.
• Don’t do a “big effort upfront”
• Develop and create in releases / have a release plan
• Processes and architectures need to be measured

Organizational segment

Architectures win and fail with the people. If they don’t want to cooperate or be involved you will fail.

• It’s the people, stupid
• Do not separate areas of your architecture into different groups
• Risk & Controls folks are your friends

“How-to” segment

Once you get started the task of developing an architecture seems daunting. This segment has a few tips to make it more manageable.

• Start small but don’t settle on the lowest denominator – choose a tool and have a minimum set of artifact requirements
• Have the full lifecycle in mind and don’t get distracted by the latest tech
• When developing models do this in multiple iterations (esp. processes)

Additional information

No additional information for this episode…

Credits

Music by Jeremy Voltz, www.jeremyvoltzmusic.com

• CP1 (Welcome)
• Lofi Lobby Loop (Interlude 1)
• Airplane Seatbelt (Interlude 2)
• Be Loved In Return (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 on this wonderful wintry cold December day?

J-M: How am I doing? Why, I’m so excited! This is the last episode of this season of What’s Your Baseline! What an amazing accomplishment we’ve had so far. Such amazing people on the podcast. Great listening from some of our favorite people in the industry, and I’m so excited to keep on doing this. And of course, you know, maybe we should start the show with the announcement. This isn’t the end. 

Roland: That is true. That is true. We’re going to take a little break over the holidays. So when you listen to this, it will be the week of the 13th, not our regular bi-weekly schedule. So we’re a week early, which is good. And then we’re going to take a couple of days off over the holidays, and we come back in mid January-ish, week of the 10th, maybe. So we’ll see how we can get that started, and we’re currently in the planning of our season 2 and we already have lined up a number of very interesting guests and topics for you. And I’m pretty sure we’re going to talk about this award. You can read about this in the newsletter if you sign up on our website, whatsyourbaseline.com?

J-M: A couple of good pitches thrown in there, but one thing I want to pitch back to everyone in the audience. I know folks are listening to the episodes and enjoying them, but if there’s something you’d like us to address, please reach out to us. As Roland said, we’ve got lots of great ideas, but the best ideas will come from the people we serve. So folks, get in touch. Let us know what you want to hear and for season two, we still have a couple of slots open for topics that are going to come from our audience. So wonderful, wonderful.

Roland: Speaking of ideas, we’re switching up the format of the show today a little bit. So it’s not like what we did in the past, the why, the how and the value, but we’re going to have three segments today where we’re going to talk about 10 things that we’ve learned over the last 25 years that we do this job here, and we will have it structured in three segments. So the first one will be where we talk about the high level approach about the strategy and the bigger picture, and why you should do architecture and process management. How do you get started and the thoughts that you had behind it. And then the second segment is talking about the people, right? The organization and the roles that we will have and what are the pitfalls and the gains in this area. And then the last section is a “how-to” segment where we look at what we have learned while implementing architectures and developing the artifacts.

J-M: And this is called “ten things I’ve learned”. One of the things that I really love is reflecting on some of the experiences you’ve had and what you’ve taken away from it. I mean, we talk about in this podcast a lot of practice ideas, strategy, ideas, implementation ideas. But the most important thing you can do from everything that you’re doing in our industry or even in life is to be reflective and learn from your experiences. Really dig into the successes, and in some cases the failures more than that, to get a handle on what you can do better next time. And what are some mantras or strategies or phrases you can repeat to yourself that say: hey this is what we should be doing better and this is what matters to me in my industry and in my role. 

So I’m really excited to dig into this and I want to start us off with this approach and strategy segment. This very first foray into the 10 things that Roland and I have learned on the road. And Roland, this one’s a tough one because I think that this is a hard sentiment for people to hear, but it’s one of the things that it’s core to how both sell the platform that we work on. More importantly, I’ve talked to people about some of the reservations around investment. And that thing that I’ve learned is: “you will end up paying for it somehow”. 

Let’s explore this concept a little bit more, ’cause one of the things that I see a lot of people trying to do is save money in the way that they operate their business units. And that can come in a lot of different ways. The most expensive thing to do is change and the most expensive thing to do is not to change. And people choose to save money through things like avoiding purchases of new technologies or engagement of services or deferment of projects or status quo thinking, and that happens all the time. They say we’re saving money by not doing things. 

Roland: Yeah, I think you’re right on that point, J-M. What I see and what I like to reinforce is the inactivity of people. You know it’s the daily churn. The daily activities that they have to do, the next crisis that’s on their doorstep. And the question is when you find the time to do important things, not the urgency is the important things. And one thing that I noticed here when I came to North America is the short term thinking. Even if people realize it would be a good thing to do something, if the return on it is not feasible or realized within one or two quarters, they just won’t do it. And this is what we see in our day-to-day work is fighting the status quo. How do we get over this? Because typically it’s easier and it’s cheaper to not do something, and people just don’t see the opportunity costs of that. So for example, if you don’t improve your processes, your business might fall behind your competitor because they deliver a better service, right? Which then obviously has an impact on your market share. Or if you don’t automate things, your folks will do all those time-consuming and minutia tasks. So the cost is on the people because they lose motivation. Or maybe a last example, without the practice, the cost is on the customer experience or you don’t manage the risks because you don’t have the visibility. So J-M, talk to me a little bit about how architecture can then help mitigating these things. 

J-M: Yeah, the very first thing about that is in visibility. When you buy visibility, you buy the ability to address a problem. So first and foremost, you need to invest in seeing things ’cause otherwise, and I’ve worked with a ton of companies (and I’m thinking particularly about an auction and online services company that I worked with) where they came to me and they presented a piece of paper. He said this piece of paper costs us something like $30-40K to produce this one  sheet of paper. I said “that seems like a lot of money for this one sheet of paper”. And of course what was it? It was their current state architecture. And I said, well, what do you do to produce this architecture? And they said, well, we’ve got a whole bunch of people we need to bring together, and we need to go and troll all of their knowledge banks of how they do things and what’s important and where are people using certain things and what’s the sage knowledge we can pull together, and that’s a manual process every so often. And I said, why didn’t you invest in a platform like an architecture, platform and architecture discipline to make this a single click every time? And they said, well, we just didn’t think about that. I said how many quarters have you been paying $40K a quarter for this one sheet of paper? And also what happens if somebody needs something midstream? How do you understand and improve that? Wow, we don’t do that. It’s crazy, so you’re paying for it. You’re paying for this in a huge amount of human resources time and an architecture discipline and platform can give you that visibility and a space in which you can collaborate and grow from so you’re not having to pay for this all at the end of the line. And so they were lucky that the risks didn’t realize themselves. Not to mention the fact that they were spending a ton of their human resource time not innovating, but rather just keeping the lights on.

Roland: Agreed, agreed and that is, like I said, the inactivity that people choose. You know, the status quo. But that brings us to our second point, which is: don’t do a big effort up front. 

And let me take a step back with that. Remember an architecture that you build is not the running process or a running system that you’ve implemented. It’s a depiction of it. It’s your plan to implement it and then, like J-M said a minute ago. It obviously helps you to analyze your runtime systems, so that poor organization that does this exercise every quarter for a certain amount of money obviously needs that. Or if you think about a real architect, you know, nobody will live in a cardboard model of a hotel that this architect has planned, right? However, if you want to do changes to the hotel, you know once it’s built, you better know where your load bearing walls are, where your power and water lines are, and all these things.

J-M: Oh yeah, so that’s the other thing is that while you’re saying don’t do a big effort up front, you also do want to invest in strategy and planning. We talked about this in an earlier episode. The first thing people like to forget is the first step, which is strategy and planning. So tell me about where doing that big effort upfront would cost the company and where have you seen that specifically fall short? 

Roland: I’ve worked with two organizations who did this and they said, well, we have all that stuff documented somewhere, be it in architecture, databases, in their tool, beard in videos or PowerPoints or napkins or whatever, right? And they said well we need to understand in detail what we’re doing before we even can think about improving things. And one of them was a bank who wanted to improve their processes and operational efficiency. And the other one was a manufacturer who wanted to save on shared parts. So it doesn’t matter in which area you are, but they both said “no we need to bring in everything that we have and then we need to sort it out and sift through and then figure out what we’re going to do”. The pushback on this is obviously it costs a lot of time. In that bank example, their planned time frame was about a year and I think in all reality it needed more like 15 to 18 months, right? And they obviously paid a gazillion to their outsourced IT organization that they tasked with putting all that stuff together. 

I think it’s a 3 point approach. The idea behind it is to first come up with a strategy. What do I really want to accomplish? So that you can say, OK, these are the views. This is what you have to do. This is one when we expect the outcomes to be visible and so on and so forth. And then you bring in your stakeholders and we spoke about this in the last episode when we spoke about governance, right? Same group. Define or align on a higher level structure. So to make it a little bit simpler, as an example, you think about processes. When you put in processes, you want to have a functional decomposition. So think about a pyramid that has slices. You name your owners, you name the groups that should develop those slices down to the Nth level. And my recommendation is to agree on the first two. Agree on the level one: these are the 10 areas of the organization that we look at, and then the next level below. So if we have things like finance, well who owns accounts receivable? Is it the project management organization or is the finance organization? Duh, you know? So to make this clear. And then build your detailed views bottom up. So don’t do the effort that those two organizations did, but rather go and look at your projects that you have and your end to end processes and all that type of stuff. Develop it and bring it back into that functional view. 

J-M: Yeah, that’s true, Roland, but I also want to highlight one of the tragedies a lot of organizations go through, and it’s I think it’s a process of letting go. I know a lot of organizations are kind of collateral hoarders. I speak to them all the time and they say “well, we’ve got all this great stuff. We’ve done all this work. We’ve paid all this money. We’ve sunk all this cost into things – assets we think are valuable that we have to absolutely hold onto that. Value”. And I’ll be honest with you: your dragon’s hoard of collateral – it may just be full of costume jewelry. When you want to look at importing good content, you need to make sure that: A) it’s good content, B) that it’s up to date content and C) that it’s right for you to keep that content. So maybe don’t do that big effort up front of trying to retain everything. Maybe be agile and try and just move forward. And of course we want to make sure we know where we are before we try and say where we’re going, but where you are isn’t that Visio model archive that you paid a big 5 consulting company 20 million bucks to make for you. It’s not. It’s what you’re doing today. Interview people, talk to people, look at systems and data. That will help give you the information. Those documents from eight years ago? Sorry my friend, they’re not as valuable as you think they are. 

Roland: And then you also should think about involving all those auxiliary people that you have. So, for example, your app owners, right? There’s no need for you to sit in your project room and think about and try to investigate how many apps you have. Involve them. Let them bring in the information about how many users they have and how many instances in all these types of things. Or if you think about business architecture, identify a pilot line of business that you will actually give access to the tool and they enter data there. For example, how long does this step take? And we will talk about this in the organizational section after the break. This will also then create involvement of the other people, which is something that you want.

J-M: So the next thing that we want to talk about – the next lesson we’ve learned is that you want to develop and create in “releases”, or have a release plan. Roland, talk to me about releases. How does that make things easier for you? How does that make your customers happier and more successful?

Roland: Yeah, that is a conceptual switch that most business people don’t do or don’t understand or don’t want to do. While this is very obvious for IT people because they’re just used to it, you know you get a new batch of software updates and they’re all packaged in what they call releases. And they also have the understanding of forking and merging code? So that you can go on a detour and you try something out. And if it doesn’t work, it just doesn’t go back to the main line of your code. And I think this is the attitude that business people should adapt for their activities when they, for example, develop business architectures. So a release is basically the logical construct that you package your results in. And that has a couple of benefits. The first one is you can define what is in a release and what is your release schedule. So is it a fixed schedule which will create expectations – oh every quarter or every six months there will be a new release of this thing called architecture that we have and we’re looking towards what has changed and what is the impact on my daily job. Or you could have a release that just gets released when it’s quote unquote, feature complete. So you’ve completed a project or you’ve implemented a big system implementation or did a re-org or whatever. 

J-M: And remember that your release plan and the idea of creating and developing and releases helps to ease the idea of communication. You have a centralized message that you are consolidating around at a point in time. You have a lead up, so you’ve got a strategy in a timeline that lets you prepare to communicate that message, and then you can send that message out to all of the people who need to change the way they do it, with change management. And that whole organizational change management around releases is much much easier than if you’re having these sort of ad-hoc random packets of information going out at times. You want to keep it into a streamlined and clear process.

Roland: And it also makes it easier for yourself. You know when you have to release, you can define the process of that release, what needs to be done first, what is in, what is out when can you intersect. And you can say, hey I got this late thing that needs to go in and so on and so forth, right? And you create transparency. It’s not that some people sit in a dark corner of the organization and come up with evil things. It’s in full transparency what’s going on. And we spoke about that in our governance show, but you can obviously support those releases with rolls and with automation. So it’s transparent, for example, whatever a release manager role does, and it’s not that somehow some person steps on the stage and says “this is the new stuff. Live with it. “

J-M: Nope, that’s not going to fly at all.And those people are going to become your biggest advocates, not just for the release itself but for the success of your organization. Because what is the release looking to do? The release is looking to help augment your capabilities as an organization, and so by speaking about and evangelizing the value of the release, you are also speaking to the value the organization puts on its own practices and people, and that’s really important. 

And the last thing I want to talk about in our lessons learned here in our very first section before we go to a break is about measurements. And I know we spoke about this in a couple of the episodes, but let’s contain it into our thoughts and our lesson learned here. Process and architecture needs to be measured. Now Roland, why do you think that needs to happen?

Roland: Well, this is one of the most underused features, if you will. People say “yeah we need to change” but they never define the why. So you have change for change’s sake, but you don’t define the purpose of what you’re doing. Sometimes it’s obvious, you know when you have, for example, a system implementation. Yes, you need to upgrade this system and that has changes associated with you. Or if your risk folks come and say “hey we got those things from the regulators that we need to work”. So sometimes there’s a clear purpose. Sometimes I see organizations defining the purpose for themselves, and that’s just happening in a group. So the idea is obviously to define what is the “why” for that change.

J-M: And I think that leads us to some of the conversations we’ve had about the difference between soft skills decision making and data driven (or evidence based) decision making. A lot of times I feel like if you don’t have the measurement in place, then your only option is to use soft skills and best practices and people’s thoughts and what you got pitched by some consulting company. But if you have the data in place, then you can really connect that “why” at an organizational level with what you’re going to do, and then measure it to make sure that it gets there. 

Roland: And as we said before, you should have a strategy. Your development should be aligned to that strategy and one of the first things you should ask yourself is: what is the end of all these activities that we do? Why do we do this? So begin with the end in mind and figure out “how do I measure success? When will I know that I’m successful?” And I’ve seen some projects who just fell short on it. They said  we’re going to measure it, for example, by how many trainings we do for the organization at that rollout, which is obviously a big fail, right? That’s a second or third level KPI that you might want to have. The more important KPI would have been:once we’ve ended this project six months down the road, have we improved our process performance? Having improved our business performance? Are we faster? Are we more agile? Do we have more customers? These types of things.

J-M: Yeah, those are really important things to measure and the help to give your business case some weight for the next improvement project, as you see the successes you have achieved with what you’ve implemented now I wanted to put a pause here because we’ve been saying some great lessons learned, but now is time for you, our lovely listeners to reflect. So this is our first section. We’re going to ask the same three questions every time as we go through these segments, and this is our strategy and approach section. So, what are your biggest lessons learned in strategy and approach? Think about your experiences. Where have you directly interacted with those organizational tasks and what did you learn from what you found there? And where have you seen similar struggles to what we presented in our use cases and examples? We’ll leave you for a second to reflect on your past, and then we’ll come back and talk about some more ideas and lessons learned in process and architecture.

Musical Interlude: “Lofi Lobby Loop”, Jeremy Voltz

Roland: Hey, welcome back. Let’s move on to the second segment in which we will talk about three ideas around organization. So when we look at it, J-M, architectures win and fail with the people. If they don’t want to cooperate or be involved you will fail. So maybe you can give us a little nugget of wisdom on our first idea that we have in this segment. 

J-M: The easiest way to put it is: “it’s the people, stupid”. I see in our little podcast software, Notion, that is how it’s written. But the truth of the matter is that people are your most valuable resource. The way that I put it is: data may be king, but context is its crown. You need those business experts to shape your understanding of how your business works, and that’s particularly relevant in evidence-based decision making. We talk about that a lot here, but you can’t just use the data, you have to have business experts that help you to understand what you’re seeing on the page, be able to segment it into what’s important, and be able to address the challenges that you find as a result of root cause analysis. It’s the people.

Roland: Yeah, and that’s the development part of it. What I also think is important is that you need to convince people who are not part of your team, so that could be your stakeholders, right? The people holding the purse. But it also could be obviously your modelers. You know that the people who don’t necessarily sit at the desk when it comes to decision making, but are part of the program. So I think what you should do is when you set up your architecture, always, always, always, always think about org change management. It’s the most underrated activity. Everybody is making fun of it, you know, but I think it’s the most important one. Because you can put as many wallpapers as you want on your wall and you can put as many black boxes in your basement as you want. If the person behind the screen doesn’t want to do it, they won’t. 

J-M: Something that’s part of the change management of convincing people to “come along with me”. I hear that people use the phrase a lot, “come along with me”, and that indicates something that maybe isn’t quite so intuitive. But that’s a physical gesture. That’s holding your hand out, not to give away free goodies, but rather to take someone else’s hand and to direct them into the light; to support them with guidance and with a friendly disposition and composure. And that’s important to know you’re not literally just coming down with a hammer, you’re giving them not just a carrot, but you’re giving them a leg up. That’s really important. The other piece of the puzzle is that the technology you introduce isn’t going to fundamentally change your people. People have to change themselves, their practices. And so we say the words “a fool with a tool is still a fool”. That’s a very common adage in our industry. It’s very true, but it also speaks to a deeper truth, which is that platforms and architecture are catalysts for changing people. They enable new capabilities of the organization that your people can use. And that automation may replace some of the low value tasks people do or augment the tasks people do, but ultimately it’s your people – those resources that you need to enable to make the change to make that implementation of technology really stick. 

Roland: Yeah, and I want to focus on that last point. I think about the individual in this people section – everybody is responsible for the correct information that you capture in your architecture, right? That’s not just an activity where you see some geeks hanging out, drawing pretty pictures and all that type of stuff. It’s you, as the end user. You, as the application owner, you as the data architect, you as the process modeler, who’s responsible for feeding the tool with the right information so that when it comes to analysis you get the correct analysis result that you desire. Because that will have an impact on the end users and all those other groups that we spoke about. 

J-M: Yeah, I hear a lot of people saying oh we have a small but dedicated team undergoing this Herculean effort to get a handle on our data and on our architecture and on our processes. And what a demoralizing thing to be called a Hercules. Because in some ways that feels like a compliment. Look at how big, how strong this person is, but in practicality, it’s a curse. Because you have to be that strong. There’s nothing to back you up. There’s no one to contribute to it, it’s just you and your fellow Herculeses going and doing all the work for everybody. No, no, that’s a true curse. And so instead let’s make everyone a collaborator. Let’s bring everyone together, so it’s not a small team of Herculean efforts of the “some do all” perspective. But it’s a community of “all do some”. Everyone contributing a little bit. And us getting greater than the sum of our parts. 

Roland: I’m pretty sure we’re going to talk about that in a future episode when we talk about maturity. Because the Herculean effort or the Hero syndrome is actually a sign of low maturity. You know, you have the hero individual who pulls everything with personal power, right? And at the end of the day, you want to mature the whole organization so that it runs like a well oiled machine. It’s not dependent on that single individual. But that brings us to a related topic, which is our sixth “lesson learned” that we have, which is do not separate the areas of your architecture into different groups. J-M talk about that please for a minute. 

J-M: Well that’s the thing: the organization has really just one architecture. It’s a consolidated enterprise architecture. And business architecture fits into that. It’s not that only IT architecture is enterprise architecture. And we talked about that in a very early episode how they are two sides of the same coin. But if you see those architectures as separate structures, you are literally developing in diverging paths. And that’s so scary, because now you’ve got either somebody holding on for dear life like that scene from Spiderman 2 where Tobey Maguire stops that running train by shooting spider webs at buildings on opposite sides of the tracks and his face shows the effort as he holds on with dear life to stop this train from running off the tracks. Somebody is doing that to try and keep your architectures in alignment. That’s crazy. That’s so much effort, and there’s such a huge amount of risk that you’re introducing by keeping those as separate elements. I can’t more strongly recommend you to see it as the same. It’s one architecture. There are different perspectives on it, but it’s one architecture. Roland, what would you think about that? 

Roland: Yeah. I agree, and I’ve seen clients who deliberately separated it. Yeah, we have the business architecture group and we have the enterprise architecture groups, the IT folks, and we have the data architecture group and then it all went sideways. One group chose this tool. The other group chose that tool. One group had ideas of developing content in this area. The other group had ideas of developing content in the other area and it was not coordinated. So it was not aligned to the strategy. It was not aligned to the release plan. All those things that we spoke before, but it was just three different groups doing their thing, and that typically is not a recipe for success. 

J-M: Oh yeah, and three or more? Now you have your integration and your security people and you have your strategy. It’s all these different silos that are just not communicating. That sucks. That sucks. Let’s do it better than that folks. We have one architecture.

Roland: Speaking of silos, J-M. What about our risks and controls folks? Are their friends, or are they foes?

J-M: Well, that depends on how successful you want to be, because the truth is, the more you consider other concerned parties, collaborators and stakeholders as adversaries, the more you’re going to lead to the organizational communication breakdown that causes real lasting problems. The truth is the risks & controls people are your friends. Not only do they have the power and mandate behind them, and not only can they create budget for initiatives, but they’re trying to do the right thing and they’re trying to help you with what they’re doing. So if you view them instead as a welcome guest, if you view them as a resource, then they can be such a powerful force for good for your team, regardless of who you are, because they’re here to help. They’re here to support. They’re here to protect, and that’s good. 

Roland: It’s the basic concept underneath, you know. Making their life easier makes your life easier. So bring them in at a very early stage. Have a seat at the table for your GRC folks and say “hey, we’re going to do this and this and this. Can you give us your professional opinion on what the impact on our compliance on our risk landscape will be if we make those changes?” And in my experience, if you approach them in that friendly way, they are more than happy to help you because people want to do the right thing.

J-M: Yeah, people want to do the right thing. We have to believe that. If we believe that the organization is full of bad actors, malicious people, people who are trying to actively harm the way in which we do business, that is the path to the dark side. It really is. And believing in people will let them believe in you and together when you believe in each other then you’re able to do so much more together for the organization and for each other. And that leads us to our second question of today. And as I said, it will be very similar to the first, but let’s put the context of your thinking towards organizational design. What have you been involved in? What sort of organizational design have you participated in the process of? Or what are you currently doing right now, and what challenges have you faced in that? What lessons have you learned? Have you seen similar struggles in situations to some of the adverse situations we’ve described in this segment? Let’s leave you for a couple seconds to think about those, and we’ll come back with our third segment. The “how to” in our ten lessons I’ve learned.

Musical Interlude: “Airplane Seatbelt”, Jeremy Voltz

Roland: Welcome back, this is the final segment of our show today. It’s the “how to” segment where we will have a look at the tasks of developing an architecture, which can be daunting once in a while. So we have a couple of tips for you to make it more manageable. So maybe J-M, kick us off with the first one of the ideas. 

J-M: The first idea we have is going to concern scalability of solutioning, and we understand the need to start small. So the idea here is: “start small but don’t settle [on the lowest denominator]”. And when you look at architecture tools and how to make this come to life, a lot of organizations get caught up in that first level of maturity of platforms because they have a first level of maturity in their organization. And we cannot more strongly dissuade you from going down that path. It’s really difficult because as your organization matures, you’re going to end up continuously re-selecting new platforms that meet your capabilities and needs as they evolve. But in doing so, every time you’re going to go through a translation error and a change management effort, and all those sorts of things now instead upfront choose a platform that has a minimum set of artifact requirements. But keep in mind the scalability of that platform. Sure, don’t start with enterprise deployment. Sure, don’t start with all the modules and features. But start with something that can scale with you ’cause you have confidence in your future. Have confidence that the platform you use will support that future. 

Roland: Yeah. The example that I gave in the last episode when we’re talking about governance in that very same organization where we’re designing the ARB, and we said “hey just come in in the first step and talk about what you’re doing”. What we should have done there is in parallel to this also start a little education initiative to say “hey, we’re thinking about in phase two making some artifacts a standard. So let me teach you what you are supposed to create”. And what I realize is people are typically very willing to do this. Say “hey, if you tell me what I’m supposed to do, if you give me the tools, if you explain to me how I should do it, they will”. When they don’t, that’s typically a situation where it’s too hard on the modelers. You know, you say, yeah, you must create this! And then they might refuse or they can’t learn or whatever it is. And then they don’t do it because they don’t want to be seen as “stupid”, you know, because they don’t know how to do things and don’t dare to ask and say “hey, J-M help me. How do I do this?” So that is, I think the other side of that coin. You obviously want to have some form of standardization, but you also need to make sure that you enable your people.

J-M: And that’s the thing you need to balance. We talk about this a lot when we’re talking about what we call “methods and conventions”. We talked about that in a previous episode, but you want to balance between guide rails and over-governing things. So you’ve got the small set you have to do a lot of training, put in a lot of requirements vs. the Wild West. Because the Wild West is just as confusing and annoying and difficult as it is to have way too many requirements on people. So you need to find that intermediate balance where you’re providing a helping hand in terms of standards and practices and templates and useful features and requirements in a clear outlined plan for what people have to have an easy access to systems and tools that will help them get there, but also not over-controlling and over-putting-on these requirements to them until the fact they don’t want to do the work anymore. They might refuse that work. So find that intermediate balance that’s going to be important. And also see that balance grow, right?

Roland: And it comes back to what we said in the other tips that we’ve learned, right? Put the maturity growth as an objective in your release plan. It’s not just the architecture that you want to develop in your release. You also want to build up capability and skills in people and make that a KPI that you measure. Align it to strategy and measure things. 

J-M: Yeah, ’cause you’re building organizational capability through building people. They’re your most valuable resource, so put that in your plan to make your people better. That’s a great value. So we have a couple more of our lessons learned to bring to bear, one of which is talking about the life cycle of processes and architecture versus the lifecycle of industry trends and buzzwords. Roland, how often are you distracted by the newest shiny thing and really achieve the success you want off of it?

Roland: Whenever I can get my hands on something new and shiny, and I can procrastinate, I will do it in a heartbeat. If you ask me this. 

J-M: Because you’re human, but everyone is human and that’s the problem. The newest technology, the newest shiny buzzword, the newest three letter acronym. Everybody loves that more than they love the fundamentals. The blocking and tackling. What makes you successful? What made your company successful? Don’t forget those things. Avoid having a technology driven approach where the latest technology builds your capabilities as an organization. We’re talking about stuff that people love to focus on – process mining, different types of automation, RPA and IoT, IaaS and all the aaS-es and things like that – those acronyms and new technologies, and really splashy things and AI/ML. Don’t get distracted by those. 

Focus on the fundamentals. Have a life cycle for your organization in mind. Otherwise you’re going to be pulled in a punch in different directions and not get the business value you are actually looking to achieve.

Roland: Yeah, but to make it a little bit more specific and I agree, all those things that you mentioned, you know the automation, the mining and all that stuff. That’s not a value in itself. It’s embedded in a solution lifecycle. And when you look at that solution lifecycle, you have basically two big lanes. One is the design lane and the other one is an execution lane. And when you think about how to develop architectures, you start in that design lane where you create your enterprise baseline and you identify your improvement potentials and opportunities that you have. And then you create your solution designs, right? And then you go into your implementation and once it’s live, you execute and then you take a step back and you look at process mining, for example, to do analysis. We see it in our industry right now where processing task mining is the hottest thing right now, as was automation a couple of years ago as well as ERP, implementation and standardization years before that. That’s just one aspect of it. Our recommendation here is to take a step back and say: what does that full solution lifecycle look like? What are the tools? What are the practices that I need to integrate in that lifecycle at a certain point in time when we go through those five phases? 

J-M: And the last point for this episode – my goodness, Roland, we’re already there! We’re already at the end of the 10 things I’ve learned, but this one is a big one and I want to leave this to you to talk about. When developing models (’cause you do this a lot), we want to do this iteratively, rather than a single shot. Especially for processes, we want to do this in multiple iterations. 

Roland: Yeah, I think it comes together, and I think you will hear a theme right now. It’s again, the people that come into mind. This is why I’m not a big fan of swimlane notations when we talk about process modeling. You will see that people grab ownership of a thing. So if you go and you have a BPMN diagram and they say “oh, this step moves now from this lane into the other lane”, somebody will say “no, that’s mine. Don’t take it away from me.” And in the back of that mind, it’s like the thought that “this is the next rationalization exercise and I’m going to lose my job, and how do I provide for my children and bring food on the table?” Even though the objective might be completely different because typically the purpose of all those activities is to make the process better. So create value for customers or reduce waste. But we as humans typically don’t see this.

J-M: Yeah, if you don’t have enough boxes in your lane, suddenly you’re redundant? No! Suddenly you’re able to use your skills better elsewhere inside the organization. We’re trying to optimize around everyone’s best ways of contributing, and that’s where process design and iterative process design – function focused – really gets there. 

Roland: So what I recommend to do is to have at least multiple sessions around your process workshops. The first one should only focus on: what are the steps that we need to do and what is the right sequence, independent of who does it? Because at some point in time you might want to rationalize your roles anyway in a separate activity. So come up with a map and say step A comes before step B comes before step C. And then look in everybody’s eyes and say “do you agree?”. And I look throughout the room and want to see people nodding. And then we end the workshop on a high note. Look what we’ve accomplished. Isn’t it awesome? And then I go back and clean up the process and put it in the tool and whatnot. Then, after a couple of days, the same group comes back and we start the conversations around who’s doing it. What applications are there? And then all those things come up, like, wait a second: I’m responsible for this application, and I’m responsible for this step. And then you can go back and say: look, last session we agreed on these other steps. Perhaps the best way to reduce waste or make the process more efficient is to change the sequence to take out this step or to have somebody else do this step and do the handover at a later or at an earlier point in time. And since they’ve all committed in the first session to the task sequence, it’s an easier sell, and people don’t have that reaction of snapping into a preconceived notion that they might have before.

J-M: Yeah, that’s that’s much, much better. I wanted to take a moment here to give people one last chance to reflect on what we’ve been talking about. You know, you’ve been hearing some of these “how tos” – starting small, having a full lifecycle in mind, building iterative model design processes themselves. What are your biggest lessons learned in the practice of architecture and business process, and where have you been involved in making things come to life? What struggles have you seen? Are they similar to ours? Have you brought up different challenges to your management or have you felt different challenges when engaging in this? We will leave you here for just a few more seconds before we come back with our conclusions., a wrap up of the show and of the season, and a call for you to enjoy us coming up next year. 

Musical Interlude: “Be Loved In Return”, Jeremy Voltz

Roland: Welcome back! So we made it to the list of 10 things, and this is the proof that we learned something over all the years. So J-M, can you give us a quick rundown of what we spoke about in this episode? 

J-M: Absolutely. And once again folks, Roland’s going to have this in the show notes and you’ll hear about that in just a second. But let’s talk about those ten things we went through today. We got through all ten of them and hopefully you’ve learned a little bit like we have in our time in business process and architecture.

#1 You’ll end up paying for it somehow. 

#2 Don’t do that big effort up front.

#3 Develop and create in releases and have a release plan. 

#4 Process and architecture needs to be measured. 

#5 It’s all about the people. 

#6 Don’t separate the areas of your architecture into different groups. It’s just one architecture. 

#7 Risks and controls people are your friends. 

#8 Start small, but know you can scale with the right tool.

#9 Don’t get distracted by the latest technology. Have a full lifecycle in mind. 

#10 Develop your models with people in mind iteratively to build buy-in and consensus with those people. 

That’s ten points, Roland. One to ten of our many, many years of doing this. I think we’ve learned a little bit more than 10 things. Maybe if you stick around for season 2, you’ll hear the next 10 things we’ve learned. And aren’t we learning all the time? Isn’t that what we’re doing as part of the show? And of course, in getting feedback from our audience, we have a wonderful opportunity to learn from the consensus of our community. 

Roland: Speaking of which, Friends, thanks for listening to this episode. The last episode of season one. And I’m pretty sure I speak on behalf of J-M as well. I’m super proud of us that we made it to this episode, #12, in time. 

And we would be very, very grateful if you would reach out to us by sending us your feedback to hello@whatsyourbaseline.com or leave us a voice message that we could play in one of our future episodes. The link is in the show notes. And of course, it would be very much appreciated if you leave us a rating and review in your podcatcher of choice. 

And lastly, you will see the show nodes at whatsyourbaseline.com/episode12. 

J-M: Well, thanks again folks, and for the very last time this season I’ve been J-M Erlenson. 

Roland: And I’m Roland Woldt

J-M: And we’ll see you next year.