Claus Møller Jensen - Enterprise Architect at Novozymes

(Joel Beasley at 00:00:00) Hello, my friends. Today we are talking to Claus, an enterprise architect at Novozymes, and we discuss how you can effectively use enterprise architecture to optimize your organization, how to gain visibility into shadow and rogue IT, and why the ability to communicate pain points is almost as important as solving the problem itself. All of this right here, right now on the Modern CTO podcast. Here we go. This is the Modern CTO podcast.

(Claus at 00:00:42) We're closing in on something like 30 years of actual experience post-college. And I've done sales, I've done solutions, I've done implementations, I've done presales, project management, solution architecture, and now enterprise architecture. And I was actually fortunate enough—I started in sales because I talk a lot, I talk fast, and so people naturally associate that with the sales process. So it was sort of always a given that, you know, people would tell me, you need to go into sales.

(Claus at 00:01:17) As it turned out, I was actually really bad at it because I talked so much that people didn't have a chance to say yes. So at one point in my career, I actually got fired as a salesman. But the company said, look, we need a consultant for presales and for implementations, and you know your stuff. So do you want to try your hand at that? And it turned out that I was a much better salesman as soon as I started coming in after the guy who got the customer to say yes. Because coming in with, let's say, that sort of pre-approval meant that when I talked to new customers—I was selling CRM systems at the time, this was pre-Salesforce—and so when I came in and said, look, I think we need to do this, we need to do some development on this and some of this stuff, people were like, yeah, you're probably right. Because I needed that sort of initial leverage.

(Claus at 00:02:08) And so that brought me into consulting, presales, implementation, and then from there into solution architecture with the largest pension firm here in Denmark, which is—it's a difficult construction to explain, but it's semi-public, which means that it's partially owned by the government and partially by some organizations. But it's basically everyone who lives in Denmark and works in Denmark has a—the employer pays a specific fee to this pension fund, so you get it whether you want it or not. Right? And so this pension fund is closing in on—what was the last number I saw? I guess almost 800 billion Danish, I think. It was, like, huge. It's like, you know, so it's €100 billion or something like that. And since they manage monies for a lot of different funds, there were a lot of different solutions. Everything from paying out pension funds to paying out insurance to, you know, not unemployment, but injuries—workplace injury, things like that. We also have vacation funds here in Denmark, so I get paid during my vacation from a fund, things like that. So we did a lot of those solutions.

(Joel Beasley at 00:03:32) And where are you at today?

(Claus at 00:03:34) Well, now I've moved on from the—I stayed in the financial world for about 10 years. Had a lot of fun. Like I said, a lot of different solutions. And then through a couple of stops on the way, I sort of fell into, first, a chemical company and now Novozymes, which is a biotech company, global biotech company. And you may have heard of Novo Nordisk that does insulin mainly and a lot of other stuff over time. And Novozymes is sort of a—again, long story, but sort of a breakout from that. And we do enzyme development and microbiological products. So if you take a look at a lot of your detergents or things like that, if you look at those, they will list that they have about 5% enzymes, and there's a very big chance that we made that.

(Joel Beasley at 00:04:26) That's so cool. Why the enzymes? I don't understand enzymes. What do they do?

(Claus at 00:04:32) Well, at the risk of making myself look extremely stupid, basically what they do is they break down a variety of, you know, the stains and the dirt and the smells that you don't want, for instance, in your clothes in the case of detergents. So by developing those enzymes and adding those to detergent, instead of having—to put it in layman's terms, which is all I know, I've been doing this for two years, and I still don't understand half of this whole chemistry thing—but basically, the enzymes are a biological way to break down, like I mentioned, dirt and smells and things like that in clothes, instead of having, like, a chemical solution. So instead of having some sort of artificial chemical, we try to use natural ingredients for things like that. We also have, so we have, like, household care products. We have things like for baking, for instance, enzymes that can be added to flour. So, you know, bread made at a variety of scales—like bakers and also industrial bakeries—can have bread created with maybe a bit longer shelf life or, you know, a specific texture to it that enzymes help create. So it's a vast variety of things.

(Joel Beasley at 00:05:56) It's like Enzyme 101. You say at the risk of sounding stupid—you know so much more than I know about them. I've heard of them. I've heard of these things, but I'm curious about what they do. So you would be involved in, like, a wide array of products from laundry detergents to, you know, bread. I mean, that's food. That's—how big is the company?

(Claus at 00:06:17) The company is about, what are we, 6,000 people-ish? I think six to 7,000 people. And we have locations—since we were founded in Denmark, we have, let's see, three or four locations in Denmark with plants and offices and administration and things like that. And then we have a variety of offices and plants across the globe. In the US, we have one in Franklinton, and we have one in Brazil, and we have two locations, I believe, in China and India. We have both IT offices in India, and we also have a manufacturing plant in Mumbai.

(Joel Beasley at 00:06:55) Yeah. You guys are huge.

(Claus at 00:06:57) Yeah. We're pretty big. We're pretty big.

(Joel Beasley at 00:07:00) I was talking with Nick. I did an interview with him at BiZZdesign. And after I was talking with him, I was like, alright, I was trying to understand enterprise architecture and how their software and what their offering was. And I was really trying to understand it. And then I thought, alright, just give us, like, somebody who uses your product, and we'll talk with them too just to, like, get more experience with it. Because I happen to be kind of—I want to grow a large company. I would love to have a problem where I have 5,000 employees and I need to, like, really take enterprise architecture seriously. So I'm just curious, like, what is enterprise architecture to you?

(Claus at 00:07:38) There's a short and, you know, a hugely long answer. But the short answer is it's optimization. And historically, there's been a lot of problems with enterprise architecture. People have sort of seen it as, well, now we have all of this IT, and we need to get that under control. But in my mind, it's the interface between the line of business and IT in order to optimize and solve problems. And it just so happens that if you have a company with 6,000 employees across the globe, one of the main solution drivers will be IT. Right? It's hard to optimize without IT, but there are ways of doing that. I mean, you can look at a specific process and just consider not doing that. Right?

(Claus at 00:08:34) You could do it differently. I've been in cases where we did a business case for the pension fund, and we had the conversation of, well, if we want to automate this—we have this process, it's slow, let's automate it. And we did the business case and we figured out it would cost, I don't know, let's say, I'll just say a million dollars. It doesn't matter. And then we said, well, for a million dollars, how much time will we save? Well, we'll save, you know, X amount of hours. Okay. So for a million dollars, we can hire people to perform the same task, and we could do that for five years. And so the final agreement was, well, let's do that then. Let's hire people for five years for a million dollars. Because in five years' time, any IT solution that we build today will most likely be, if not exactly deprecated, it will be nearing the end of its lifespan and will need to be upgraded or sunsetted or remade. Right? So the interesting aspect of that was figuring out, does it make sense to do it smarter or does it make sense to do it differently or not do it at all? And that to me speaks a lot to what enterprise architecture does.

(Claus at 00:09:54) I spent a lot of time today, for instance, in meetings talking with people who work in our production facility. And like you said, you don't know enzymes, but I think you're a great enterprise architect if you are willing to keep asking questions about, well, why do you do that? How does that make sense? Because as soon as you see a specific process, it doesn't really matter whether it's paying out pensions or building cars or in our case, researching and growing enzymes as it were. If you understand the process, you can start to ask questions and have line of business then tell you, yeah, you're right. We could do that better, and we could probably do it better in this way. So that's where enterprise architecture really, really shines as a discipline, to me, anyway.

(Joel Beasley at 00:10:44) It's like a core competency of a founder. Or at least, that's how I feel myself because I sort of see my role or the things that I'm passionate about. Like, I'm really passionate about creating, you know, autonomous, scalable systems, right, that generate revenue. I like those. If you don't like autonomous, scalable systems that generate revenue, I don't know what you like out there. But it's interesting because you get to sort of, like, take this aspect, this, like, engineering mindset and aspect, and you get to live it all day with processes across the board. Is that fairly accurate?

(Claus at 00:11:22) Well, I mean, it's very, very wide. I mean, enterprise architecture as a discipline is to me—it's very, very wide. There is that part. The, you know, we have a process, we believe that process is somehow flawed, let's figure out what it is. So then, like you said, you were talking to Nick. What Nick's company BiZZdesign then does is they offer you a way of documenting and analyzing gap analysis and do as-is and to-be of that process and communicate that to line of business in a mutual understanding, mutual language. So there is that part, but there's also just the part of, well, we want to optimize something. We want to save 5% on this, or we want to save on fuel. And then they'll sometimes come to IT and say, can you help us? And if there's an enterprise architecture department, they will most likely pick up that part of it for the initial stages and say, you know what? You should probably look in this direction. And then you'd have someone run the actual solution. If it's something you develop internally or have externally developed, you'd have a project manager and a solution architect ensuring that the architecture for that particular solution matches the need. But you also have sort of what we like to call guardrails or guidelines for how to do IT in general. Good example. Let's say you have your new global company and you have your 6,000 employees. If you have employees in six different countries, what are the chances they will all agree on the same production system?

(Joel Beasley at 00:13:06) Negative?

(Claus at 00:13:07) Exactly. The same process control system for their machines, the same vendor for fuel, the same, you know, whatever. And then you have different regulations for if you do something in China or whatever. So sometimes you want to set up, like, an initial framework for your company saying, look, here are the guidelines for how you want to implement new solutions. Like, if you get a good idea in China, feel free to run with that idea, but do it within these guidelines. Security-wise, architecturally speaking, process-wise, et cetera, et cetera. Right? So there's a whole documentation of that of preemptively defining how do we do things IT-wise in a company. That's a very big part of what our enterprise architecture is as well. Right. Reference architectures, basically.

(Joel Beasley at 00:14:07) I've got so many questions.

(Claus at 00:14:10) Sorry if I keep talking.

(Joel Beasley at 00:14:12) No. I've got, like—I started taking notes real quick if you hear me typing because I'm just like, alright, you got me off on this thought pattern of, you know, why is it that people can't agree on these things across countries? And then I was thinking, well, you know, trust is what you know and trust is, like, localized. So your ability to create these frameworks allows for, uh, somewhat of a standard on execution, but allows the trust to be, you know, delegated locally to the brands and the companies that people know on the ground in those countries that they understand. So they can take that local trust and then process it through a framework so that there's some form of consistency within the organization, but they also have the freedom. It's interesting.

(Claus at 00:14:55) Yeah. That's a really good way of putting it. Exactly. Because what we see is if you talk to enterprise architects who've been working for a number of years by now, there are some phrases that will pop up. Something called the ivory tower. I don't know if you've ever heard of that.

(Joel Beasley at 00:15:14) Executive team.

(Claus at 00:15:15) Right.

(Joel Beasley at 00:15:15) They send commands down. Yeah.

(Claus at 00:15:18) Exactly. And that's what enterprise architecture for a lot of companies turned out to be because, you know, I, the enterprise architect, would sit in my ivory tower, and I would just decree, use Amazon Web Services, or use Microsoft Azure. And I wouldn't really—just, you know, because reasons. Right? But you'll also hear things like shadow IT, and you'll hear things like rogue IT. And to me, those are really, really interesting concepts because they speak to what you're talking about. Right? If you have an IT department, a centralized IT department, that's where, let's say, you—well, maybe that's where you run your main AWS account and you spin up your different environments. It's where you have your server, your data center, things like that. But all of a sudden you experience that someone in R&D has bought his own software as a service. Right? He uses Zoom instead of Teams. He uses Salesforce instead of SAP. What have you. And if you're not aware of that, that becomes shadow IT. And a lot of our organizations will suffer from that today, and more over time, because it becomes so much easier for what we these days call the citizen—the end user—you just, you know, you just swipe your credit card and you have an IT solution. Right? I mean, you can buy stuff that would previously require you to go to the IT service center and say, look, I need a server, and I need someone to install it, and I need someone to make sure that it doesn't go up in flames in a week. And the IT guy could then say, well, I won't do it for you. Or sure, I will do it for you. It's going to cost you, or however you wanted to do that. But these days, there are almost no limitations to what you can do in a browser. So controlling that, or—and I'm not meaning controlling as in a stranglehold, but being in control of what happens—becomes paramount. And that's where the guidelines come in. So people understand, well, you're welcome to buy your software as a service, but please understand that these are going to be the consequences. Like, maybe you have a specific set of rules regarding security or data that you can put on it, or maybe you can only pay for it in a certain way, or maybe you can't integrate with internal systems. It's one of the reasons why I don't have the Zoom application, but I'm running this through a browser because we don't install that on our machines. Right? It goes against our guidelines.

(Joel Beasley at 00:17:54) Oh. Harry will not be happy. I'm going to send him a little—I'm going to get an email from him and his little puppy the last time he brought his dog on the show. That's hilarious. Sorry.

(Joel Beasley at 00:18:06) Sorry. Off topic. I want to talk about how does this fit in, the things that you're talking about with Biz Design. Like, give me some concrete example of how you use Biz Design, how it's useful.

(Klaus at 00:18:18) Well, there are multitude of ways that you use a tool like Biz Design. We have decided, for instance, to start with modeling to a large degree our as-is landscape. Because coming back to, like, you have shadow IT. Now come back to your 6,000 employees in five different countries and realize that you probably don't know what software is out there. So you could buy some software that solves that problem that, you know, snoops the network, tells what's installed here and there.

(Klaus at 00:18:50) But now you know what you have, like a list of a thousand applications. But who uses them? What are they used for? Why do we have them? What purpose do they serve?

(Klaus at 00:19:00) And that's like one of the first steps that we use Biz Design for. There are many other ways that you can use it. But figuring out, okay, so we have these systems. Let's take them all and define a set of metadata that we can attach to these systems, like who's the system owner, who's the VP in charge, what's the criticality of that system, does it support a critical process, what type of data does it contain? Like here in Europe, we have the GDPR issue, for instance.

(Klaus at 00:19:28) Does this software contain personal information? Sort of gather that throughout the organization. That gives us an understanding of what it does. What's the purpose? Why did someone buy this?

(Klaus at 00:19:40) And sometimes you'll find stuff that someone bought and just didn't use. And then we model that. We start to model that in a variety of different ways. And that's where I think a software like Biz Design or some of the others in the market are really, really great because they basically do what PowerPoint and Visio does for a lot of people, but in a combined data stored system, which means that if I have, let's say I have all of the metadata for my Salesforce implementation, I know what account it runs on.

(Klaus at 00:20:14) I know who owns it and things like that. Then I can start to say, well, okay, what capabilities does this help me achieve? And now I can create a capability map. So I can have that separate to my list of systems, but now I can draw relations, right? So now I can say, well, these three systems help me drive these two capabilities. Like sales, for instance, would be a capability.

(Joel Beasley at 00:20:38) That's a good capability.

(Klaus at 00:20:42) Back to the revenue generation, right? So now you can map your systems to your capabilities, but you can also say, well, we have some initiatives in our organization. We want to upgrade our SAP. We want to develop a specific application for our AWS, something something.

(Klaus at 00:21:03) And so now you can map your systems to those efforts. And because you sort of start building this spider web throughout the database, then once you reach critical mass of this, what I like to call enterprise information, then you can start to mold it and model it semi-automatically in pretty much any way you can imagine. It's sort of like, you know, data analytics, but for modeling, if that makes sense. Right?

(Klaus at 00:21:33) So if in my system right now, if I want to know, well, I've got this particular process or, well, I'll give you an example actually. We had one model where we talked to our quality management team. And so we said, well, how are your systems connected? Well, they were connected like this. And so now we have this map that shows all of the systems that are relevant to perform quality management, and what information flows back and forth.

(Klaus at 00:21:59) And so now we can all of a sudden really quickly have an overview and say, okay, if we want to upgrade this from, I don't know, like I said, let's say we want to swap from AWS to Azure, or we want to swap from an Oracle database to a Microsoft SQL database. Well, what are the implications of that? Well, there are these five systems around it, which all receive or transmit information to this database. So are any of them dependent on that particular technological layer that we're trying to change? Well, yes, system A and B are okay.

(Klaus at 00:22:32) So what would it then take to change those? And so you sort of like rings and like throwing a stone into a pond, you start to see this influences this influences this. And then you can at the same time, when you then come to, let's say, C-level person like the CFO or whomever and say, look, it's going to cost us a million to fix this. He's going to say, well, why do I want to spend a million on that? And we can then tell him because this and this and this is critical.

(Klaus at 00:23:02) This one is end-of-life from the vendor, and they're all what enable you to do sales, right? So we can have a conversation based around what they're specifically achieving in the organization. Why they are important to us.

(Joel Beasley at 00:23:19) All right. So you buy their product. Is it something that they're helping you out in the onboarding experience? Do they give you some online videos and say, here, go do this? Do they act as consultants?

(Joel Beasley at 00:23:29) Like, what is that like? How are they more than a tool?

(Klaus at 00:23:34) In our case, specifically, what we've really benefited from using Biz Design is, oh god, there's so many things. And that sounds like I'm really in love with those guys. But there's such a thing as, you know, they have consultancy. They have an understanding of, like, if you run a consultant agency, you could come in and you can ask people, well, what do you do? What do you want to optimize? Where can we help you? You should probably look at this. What Biz Design is capable of doing is taking that, and then at the same time, sort of bringing the tool with them, if that makes sense.

(Klaus at 00:24:04) So you sort of buy the tool, but the tool then becomes the platform where you start to build your questions and answers with their assistance.

(Klaus at 00:24:30) So things like, well, what's important to you as a business? Like I said, what we did was we started modeling our as-is for systems. For another company, it might be let's say you work in finance. You're heavily regulated. Then maybe just understanding your business processes and having those documented is your prime concern.

(Klaus at 00:24:51) Or maybe you're trying to, I don't know, make some digital disruption in your business, right, to do digitalization of your entire processes and start selling your data or things like that. So what the individual company needs is much, much more important to your starting point of the tool itself. And having that consultancy assistant is really, really critical in getting a proper implementation of such a tool. So that was one of the things that we've benefited from over the past couple of years, is having those conversations about, well, what's important? Where do you want to go?

(Klaus at 00:25:29) What is it you're trying to achieve? And then just generally having, like I said, let's say I want to model things with ITIL, like we're just talking about. I can call on these experts and say, look, I know I have the tool, but what is best practice for doing this? What is best practices for documenting Amazon Web Services, DevOps roles, ITIL, processes, whatever. And we'll have a conversation regarding what is best practice.

(Klaus at 00:26:01) And so it's, yeah, it's basically having the consultancy that's sort of served on a specific platform of a tool. That's what I think is great.

(Joel Beasley at 00:26:13) That's pretty cool. And you like them, so I'm going to talk to some other people too. I like to whenever I have these guests on, and I like what sold me on them is so silly. I like their design. Like their branding, I was like, I like their branding.

(Joel Beasley at 00:26:27) And Nick was cool. And then, I don't know. This is life. You know, you would think before when I was less mature on how business worked, we have to spend time together. You know, like this is life.

(Joel Beasley at 00:26:38) We have to do life together. So it's really good to surround yourself with awesome people because that's the, for me, that's what makes all the difference. There could be 20 solutions, but I'm going to go with the solution that meets all my needs, but also has really great people behind it because I'm going to have to spend time with them. You know?

(Klaus at 00:26:54) Oh, definitely. Yeah. And I think the value proposition of that, I have, because I've considered this before, is I find it interesting that a lot of companies will buy, like, you know, an ERP solution, SAP or Dynamics or what have you. And they'll say, look, it's important that we understand our manufacturing, our purchasing, our sales, our transactional information, our master data.

(Klaus at 00:27:15) We need to understand all that. But what something like an EA tool like Biz Design, what that platform does for you, it allows you to have the same control over your information. Right? To me, that's hugely valuable. Like I said before, having knowledge of, well, what software do we have?

(Klaus at 00:27:37) What do we use it for? Where do we want to go? If I want to improve manufacturing, what systems support that specifically? If I want to improve sales, what systems and processes are lacking? Where can we improve those?

(Klaus at 00:27:50) And having a system like that enables you to, you know, run through that information at any given time and look through it. Same way you would look at, well, I wonder how we can increase our revenue or our bottom line by, you know, point zero three percent. Well, you look at your transaction data. You look at your manufacturing costs, right?

(Klaus at 00:28:10) So you need to analyze your data. And I like to call this information analysis instead, right? Because it's sort of the information that, you know, it's there. People know it. It's in their heads.

(Klaus at 00:28:20) But it's not documented.

(Joel Beasley at 00:28:23) Yeah. And that's what Biz Design does and helps you with. So how many people are in your Enterprise Architecture organization?

(Klaus at 00:28:32) We are specifically, let's see. There's my boss, and there's one, two, three, four. We're seven actually. Seven right now.

(Joel Beasley at 00:28:38) So people will come to you within the org when they, are they already working with you to help? Like, how does it work? How do you interface with people in the org?

(Klaus at 00:28:48) Right now, we mainly interface with people who come to us and say, we have an issue, or we have something we want to do. And that could be anything from, like I said, they want to say, look, we want to optimize this process, but in order to do that, we need to understand the process. Can you help us do that? And so we'll help them with that. Or they'll say things like, we found this patent management database or patent management solution.

(Klaus at 00:29:19) Is that a good fit for us? Does that fit within those guidelines that you've set out? And we'll help them with that. And so—

(Joel Beasley at 00:29:26) Sorry. I'm going to interrupt you a couple times. But what if they don't?

(Klaus at 00:29:28) If they don't what? Sorry.

(Joel Beasley at 00:29:29) Like, let's say, like, they know to come to you to check out, let's run with this patent one, right? They're going to buy this little patent management system. They could just, you know, take their credit cards, swipe it with the vendor, install it, enroll and, like, finish their problem, you know, be done with it. But what triggers them to be like, I need to go to these people and talk about it.

(Joel Beasley at 00:29:49) Like, how did they learn that they need to do that?

(Klaus at 00:29:54) Well, they're still learning, to be fair in our organization. But they learned it, I think, and this goes before my time. So this is more of a theoretical thing than it is specific for Novozymes where I'm employed right now. But when you had those, when you have those shadow IT, which I mentioned earlier, or you could have rogue IT, which is where, well, we know what the guidelines are. We just don't care.

(Klaus at 00:30:19) We're going to do it anyway. So when you have those things, what happens is, and that's interesting to me, is, let's say you decide to buy this patent software and you don't ask IT, then something happens. The vendor decides to stop supporting it or raise the pricing or maybe the service level isn't good enough for you. You need better support, better uptime, things like that. And then you contact IT, and IT will tell you, well, it's not mine.

(Klaus at 00:30:51) I haven't done it. I can't help you. And a fight most times will ensue, right? Well, you're IT. Yeah. I know I'm IT, but you've literally implemented something that I can't, I don't know it. I can't understand it, right? If you take the AWS versus Azure comparison, I might have five cloud engineers who know everything about Amazon, but none of them know anything about Azure.

(Klaus at 00:31:17) So if you've built something on Azure in your own free time, or let's say your coworker has and he's now left the company, I can't help you. And once that happens in a culture enough times, people start to think, well, let's just make sure that we're not doing anything. But that's just one example. There's also things like, let's say security is a massive issue. The patent database would be a prime example of that.

(Klaus at 00:31:42) If you take our patents and store them on a server that we don't know where that is in the world, you know, any of the hotspots in the world or anyone that has a reputation for stealing corporate secrets, then you run a massive risk on behalf of that company. And nobody really wants that risk. And people understand that, right? I mean, I understand that I don't want to risk my own livelihood by doing something silly to my computers.

(Klaus at 00:32:13) Right? I want to avoid phishing. I want to avoid storing my information where others can get a hold of it. So that's how they learn through that, and they learn through just, I was about to say being told, and that sounds like I treat people like small children, but you set up these guidelines and say, look, whenever you want to buy something, as a rule, you're welcome to it. But please come talk to us first so we can tell you what the consequences are.

(Klaus at 00:32:45) And that's a great method of involving people who want, because everyone just wants their life to be easier. They want their systems to be faster, their computers to be better. They don't buy stuff to, you know, be mean or to destroy something for someone. When our information security officer, when he says, look, I don't think it's a good idea to put that in that particular country, then someone can say, well, I really, really want to. And he says, well, then you just have to go get the CEO's approval of putting our patents on an unsecure server that's, you know, has straight access from the Internet.

(Klaus at 00:33:26) And so that conversation of consequences, coming back to the ivory tower, instead of saying, don't buy anything, just say, well, come to me, tell me what you want, and I'll tell you what the consequences are, then you can decide. Those are the type of guidelines that I think make a great EA solution.

(Joel Beasley at 00:33:44) This is so interesting. I'm learning so much about this enterprise. You know, the first couple times I heard about enterprise architecture, I was like, yeah. That's just probably, you know, how they lay out their servers in an enterprise. It's like their AWS configuration.

(Joel Beasley at 00:34:01) It's probably just their architecture because, you know, I was scoped to, like, building software and SaaS solutions. And so when I heard that, I was just like, oh, that's probably what that means. I never really looked into it. And then I started exploring and learning and I was like, this is much deeper than I thought. And actually, I'm learning even more now even after talking with Nick.

(Joel Beasley at 00:34:21) Like your example of how you can store this metadata on these, you know, this list of solutions that you have and connect them back to company, like, objectives or outcomes that you're looking for. That's actually really, that's like business intelligence. That's—

(Klaus at 00:34:36) It is.

(Joel Beasley at 00:34:36) Yeah. Does business intelligence fall under, it's like enterprise architecture is huge because, I guess, some security stuff would come under there. You've got business intelligence. You've got, like, vendor management. There's a lot of things happening that this department, what was this department before it was its own thing?

(Joel Beasley at 00:34:52) Like, when did enterprise architecture come about? I expect you to be a PhD historian on the topic. When did it come about? When did people realize it was a need to be its own thing?

(Klaus at 00:35:06)
Oh, actually, I think the first example is, what was his name? Zachman, I think? Wasn't he the first guy who started to write about enterprise architecture? And I think that was ages ago. You could look him up. I think his name was Zachman, Z-A-C-H-M-A-N, I believe. He had a model, one of the earliest enterprise architecture models, and I think it was like late eighties or nineties or something when he started talking about it because it's really, really old. But it's an interesting discipline because you have to be, or I believe you have to be, a jack of all trades, master of none. I could not configure any service on the cloud if you had a gun to my head.

(Klaus at 00:35:54)
I could not run a piece of heavy machinery in a plant. I couldn't drive a truck. I can't do any of those things. But I can understand, and I can talk to anyone from an operator of a machine to a chemist, a research developer, a business analyst, a data scientist, a cloud engineer, a data architect. I can talk to all of those people and tie that information together and say, okay, so here's what I think we should do. You believe this is good. You think this is good. So if we do this and match that up, I think we can solve our problem. Right?

(Klaus at 00:36:35)
So it's sort of, I was about to say, playing matchmaking of knowledge. That's what you do a lot of the time. But it's also a discipline that's hard to quantify. What's my worth? Right? I mean, what is it worth to an organization to have someone like me or seven people like me having that skill set, being able to document, well, what's our actual value chain? What's our value proposition in relation to our expenses for IT operations?

(Joel Beasley at 00:37:10)
It's hard because it's like, and I hope you have an answer for it, but it's like, what's the value of the smart friend that talks you out of doing something dumb? It's like, you know it's important and you need the smart people around you to bounce the ideas off of. But like, how do you put a dollar amount to it?

(Klaus at 00:37:28)
Exactly. And so when you say that, when did people start, you know, realizing that enterprise architecture was a thing or a necessary thing, they're still very much realizing that in a lot of organizations, I believe. I mean, enterprise architecture, as a case in point, in the vast majority of companies that I've ever seen or been in, enterprise architecture is a department within the IT department. And the IT department is under the purview of the CIO, typically. The CIO, in most cases, is underneath the CFO. And the CFO is the first member of the executive or the C-level team, as it were. Right? That's how it's been for every, I was about to say, friend I know who's in the business, with a very, very few exceptions. Maersk, the shipping company, recently changed their organization and put their CIO up at the top with the other C-level people—COO, CFO, et cetera, et cetera—because they now consider IT to be as important, as it were, as those other areas rather than just a cost center. So when you, or if you don't look at enterprise architecture as something that drives value, then it's hard to understand the value. And if it's hard to understand the value, it's hard to, you know, like you say, put a dollar amount on it and to say, that's worth it to us. Let's do that. I can see the idea on that.

(Joel Beasley at 00:39:03)
There are definitely things that I spend money on that I don't do like ROI, you know. There's some things in business you just know that you need it. Right? It's like, all right.

(Joel Beasley at 00:39:14)
The business, my team is telling me that this is a problem. We need to solve this solution. We need a solution. You know, somebody really bright told me once, I was very product-heavy in my upbringing. So building products, very product focused. And then I switched to be more of like founder type. And what I learned was that if you get sales right, if you get that right, then you have money to solve all the problems and improve your products. But if you start, like, my mistake I was making is I was obsessing too much over the product before I had a bunch of customers. And I was like, if you looked at the structure of my company, it was like I had, you know, maybe seven people building product, improving it, and like one salesperson. Right?

(Joel Beasley at 00:40:00)
And we ran out of money. So as we ran out of money, I said, I had to let people go. Right. And then I said, all right, well, let's hire like seven salespeople and have like two people that just focus on this. And we'll grow at the rate of like three sales, three revenue-generating roles to one non-revenue-generating role, and we'll do it that way. And wouldn't you know, we're profitable now?

(Klaus at 00:40:29)
Yeah, exactly.

(Joel Beasley at 00:40:30)
Yeah. But through that path, the thing that's clear to me is that there are problems that come up. So we have money now, and now we're like, we need to be better at delivery. Right? It's like, all right, well, I can go solve that problem easily because we have profit from the first quarter. We can just go hire somebody. And everyone's kind of saying, there's this problem, we're picking up on it. All right. Let's just go hire somebody that, and it's maybe half a role and let's figure out what we can give them to make it a full role. And but I didn't do an ROI study on that. Like, I know I probably could've. Right? I probably could've figured out, you know, customer happiness and NPS score and put a dollar amount to it.

(Joel Beasley at 00:41:07)
But I just feel like—

(Klaus at 00:41:08)
Here's an interesting thing. Imagine you are, you know, a couple years ago, you're a Blockbuster. You have plenty of money. Right? Now someone is disrupting your business. And what happened, I think what's interesting about that is, you probably know this, right? But Netflix came up and started doing stuff, and they actually went to Blockbuster and I believe tried to sell Netflix for $50 million, if I remember correctly. And Blockbuster said no. And everyone seems to highlight the fact that Blockbuster said no. What I like to know is why the hell was Netflix trying to sell? Right? Someone in that, I mean, someone there had to take a leap of faith that what they were doing would generate sales. Right? Tesla, someone has to believe they will make money. Amazon, someone has to believe they will eventually make money because there's, I mean, but you're getting your income, or as it were, you're getting your money in from investments, but it's still a leap of faith.

(Klaus at 00:42:18)
You're actually doing the opposite of what you're talking about. You're developing a product and crossing your fingers that you'll stay alive long enough to see it generate revenue. And sometimes you have to do that. Sometimes that's the best thing you can do. Was it Ray Bradbury said, sometimes you just gotta jump out a window and grow wings on the way down. And you have to do that in business sometimes. And sometimes, having an enterprise architect or a solution architect or some sort of architect, cloud architect, can help you do that in the best possible way.

(Joel Beasley at 00:42:53)
Yeah. It's like how do we jump out of the window while at the same time reducing the probability of failure?

(Klaus at 00:43:02)
Yeah. Preferably to a very, very, very low number. A negative number, please.

(Joel Beasley at 00:43:10)
You know, somebody asked me the other day, I was at an event. Can you believe that? We had an event, a physical event. It was a physical in-person event. It was an event. I saw other humans. I came out of my cage. I saw other humans. It was great. But somebody asked me, they said, do you think it's possible anymore to even make a company or build a product without investment? And I was like, yes. And they were like, they didn't, they kind of disagreed with me. They're like, I think you have to have investment. And I was trying to probe a little bit deeper to figure out what their context was. Because I'm sure you've done plenty of speaking. Everyone who raises their hand or has a question, like you gotta kind of dig down a little bit to their context. But there is definitely this field that you have to go raise money. And one of the things that I've learned myself is about market pressure. Right? So if you find a place where there's enough pressure, if you find a pain point that's big enough, you will get paid to solve it before you even have the product.

(Joel Beasley at 00:44:12)
Like if you have believability in the area and subject matter expertise, like you can go around and interview people and figure out what they're looking for, what their problems are, find a common thread, identify the market, find something that they're willing to pay you for. And then you can do presales and then develop the product. And I know this because I did this. And I did it after I read somebody telling me about it. And I was like, well, I made a bunch of things. I either got investors or I, you know, did all of this and then tried to sell it. Let me go try this inverse thing. You think about the inverse. Case in point, you're thinking about Blockbuster and Netflix. Right? You thought of the inverse. So I was like, you know, what's the inverse to this and let's go try to sell it before we have the product. And that ended up working.

(Joel Beasley at 00:45:00)
Because it was painful. It was painful enough. But if it's not painful enough, it doesn't work. I don't know. I'm sorry. I like product development. You got me excited talking about it.

(Klaus at 00:45:12)
Yeah. But you're absolutely right. And I think that's probably the takeaway from that is, like you said, well, you know, get sales right. Yeah. But how do you do that? And if there isn't, sometimes if you find the pain, good. But sometimes you also have to communicate the pain. And I think that's an interesting prospect. Right? You have to tell someone, you are in pain. Right? Instead of just going and asking them what's your problem, saying, this is your problem. This is what needs fixing.

(Joel Beasley at 00:45:45)
Sometimes you have to take a step back and even teach the people how to communicate.

(Klaus at 00:45:49)
Oh, yeah, yeah, yeah. That's a hard thing to talk.

(Joel Beasley at 00:45:53)
How do you teach people how to, I'm still working on it, man. I've given up on it being something you complete. It is a life's work. You always have to work at it.

(Klaus at 00:46:02)
I was, I still enjoy that I took a foundation certification in ITIL.

(Joel Beasley at 00:46:08)
What's this?

(Klaus at 00:46:08)
ITIL, Information Technology Information Library or something. I forget what it is. It's a standard way of communicating. It's a library of phrases and scenes and roles, and someone is probably gonna listen to this and tell me I'm an idiot. But to me, it's basically, when you say problem, this is what you mean. You put a problem manager to manage a problem. You put a situation manager to manage a situation. And when you look at it, it's almost degrading how simple it is, but it's necessary.

(Joel Beasley at 00:46:52)
I'm looking it up right now as you're talking.

(Klaus at 00:46:56)
I mean, but if you and I are talking and saying, look, we have a problem, and you say, no, we don't have a problem. It was a, you know, it was a unique event. It was, the problem, the thing that I just rebooted the server because it's Monday. That's not a problem. And I'm like, well, that is a problem. So, you know, if we can't even agree on what is a problem, how are we going to communicate? And you can do that for pretty much any phrase. I had a colleague, I worked briefly for the Danish Customs Agency, building a huge solution there. I didn't get to finish it because it was too massive, and I got a different job.

(Klaus at 00:47:35)
But we had a guy there who was our data architect. He was basically, and basically all he did was define phrases. What do we mean when we say building taxonomies and things like that? And it's just when, again, when you get to a certain size, if you say product, what do you mean? Do you mean what we develop? Do you mean what we sell? Do you mean it prepackaged or post packaging? Do you mean delivered product? Right? What is the product?

(Klaus at 00:48:07)
And if we talk, and I'm trying to help you optimize that as part of my architectural work, or you're trying to explain to me why our products have problems, then if I don't understand that you're talking about a physical product in a big bag, and I think you're talking about a conceptual product in a database, we're not gonna have a proper conversation, and we're not gonna be able to help each other.

(Joel Beasley at 00:48:33)
This is fascinating. So this is like a framework that will go across companies. I looked it up. It's the Information Technology Infrastructure Library. So if I learn this language, right, then I can communicate with anyone else who has this accreditation, and we're instantly on the same page.

(Klaus at 00:48:52)
Correct.

(Joel Beasley at 00:48:52)
Oh, that sounds like a badge I want for my LinkedIn profile. Right?

(Klaus at 00:48:56)
It's cool. And especially in an organization, like let's say you have a large organization and you have an incident, right, with anything, you know, maybe you had a physical break, maybe you had a server that went down, then you can all say, okay, look, here's our process. According to ITIL, who are we gonna sit down and talk with? What's our business continuity processes? Who has that role? Let's get that guy in this meeting room. Let's figure out what went wrong. Let's do a post-mortem. Things like that. And you have all of that. And like you said, you can take that to any company that uses that.

(Joel Beasley at 00:49:30)
That's fascinating. I'm learning so much. You're a smart guy.

(Klaus at 00:49:36)
No, no, no. I—

(Joel Beasley at 00:49:37)
You're a persistent guy.

(Klaus at 00:49:39)
And that's what I am.

(Joel Beasley at 00:49:40)
Yeah. I'm not very smart, but I'm one of those people, man. I do not give up. I just keep waking up every day and going after it. And it works. It only takes a lifetime, Klaus. It only takes a lifetime to achieve something that is, that you're proud of. So I got a weird question for you. So over the weekend, over the weekend, I like to think of, you know, just interesting things to talk about or ideas that just flow. Right? And so I have a hypothetical fun question for you. Is that cool?

(Klaus at 00:50:16)
Yep. Go for it.

(Joel Beasley at 00:50:17)
Okay. Let's imagine that right now, I snap my fingers and then you just wake up and the entire life you just lived to the moment, up until this past moment, was a game. So you just found out that you were in this really long game. Right?

(Klaus at 00:50:33)
Mm-hmm.

(Joel Beasley at 00:50:33)
And I'm sitting there next to you and I happen to be the creator of this game. And I ask you for some feedback on it. What would your thoughts be?

(Klaus at 00:50:43)
The tutorial is too damn long. Um, no. I mean, no. I don't know. I think, well, it's an interesting analogy because I game a lot as you can probably see in the background as well. Those are all board games. Um, but I'm almost certain I would say that, well, I think you nailed the game, but if everyone else is an NPC, you really need to work on the AI.

(Joel Beasley at 00:51:16)
That's hilarious. I love it. My random generation's too high. Getting some weird stuff out there.

(Klaus at 00:51:24)
Well, I mean, it's not that people are necessarily stupid or evil, but as a species, we're just, we, I don't think we're designed to last forever, you know? We have a self-destructive tendency. So I would say fix that. If those were, I mean, and if they are other players, then, you know, there's nothing left to fix.

(Joel Beasley at 00:51:46)
That's interesting. It's even more interesting that I thought you were really smart because those were really thick books behind you on your bookshelf. They're not really thick books. They're board games. I wanna hang out with you more now.

(Klaus at 00:51:58)
They're board games. Pretty much all of them, with a couple of exceptions. Yeah.

(Joel Beasley at 00:52:03)
Yeah. That's so cool. I've never seen that, by the way. I see every, I get to see everyone's background. Right?

(Joel Beasley at 00:52:09) Everyone always has books, the shelves and everything, but you've got board games. I think that says a lot about you. You're a fun, fun person.

(Klaus at 00:52:15) I think, you know, I try to have fun every day, and I try to communicate in a direct way similar to the conversation that we've been having. Right? I mean, I honestly believe that if we can speak directly and freely to each other... I like to say that if I can tell you everything when we're friends, it makes it a lot easier for me to tell you the truth when we disagree.

(Joel Beasley at 00:52:40) Yes.

(Klaus at 00:52:40) Right? If we can have fun and be direct, then I can call you stupid when you do stupid stuff or a jerk when we're just goofing around. But then when you actually do something stupid, I can look at you directly and say, "Look, that will not work." And that cuts through a whole lot of, "Well, I have to be careful how I phrase this with that person over there." And so that's what I do in almost all my interactions.

(Klaus at 00:53:05) I try to be as direct as I can, because it just simplifies things. It probably means I won't have a major career ahead of me in top management, but I'd rather have fun.

(Joel Beasley at 00:53:19) I disagree, actually. I think it's contributed to your success. I think it's part of the reason why you're where you are.

(Joel Beasley at 00:53:27) And because I've lived both ways. I've walked on eggshells and it's too frustrating. It's too much work. And if you're able to be direct and you can care about somebody and be direct with them, that's the hardest thing to do. Right?

(Joel Beasley at 00:53:43) It's not the easiest thing. The easiest thing to do is to dismiss it or let it go or not address it because it might hurt them or because it's painful. The hardest thing to do is genuinely care about somebody and pull them aside and help them understand, like, what your perspective is. Because, man, that's tough, but it's the right thing to do.

(Klaus at 00:54:05) Yeah. I think you're right.

(Joel Beasley at 00:54:07) People did it with me, you know?

(Klaus at 00:54:10) Yeah.

(Joel Beasley at 00:54:10) People being direct with me allowed me to shave time off of my experience. And I'm very grateful for it. And so, man, I love this conversation. We covered so much from gaming and the creation of life, to enterprise architecture. It was good.

(Joel Beasley at 00:54:30) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.