 Thanks for joining me for the next 45 minutes to talk a little bit about enterprise architecture and the role it plays in large organizations. As you can see from the slides, I now work for Google as a technical director in what we call the office of the CTO. So my job is largely to work with large organizations at the CIO or CTO level or enterprise architect level and help them draw the right frame around cloud adoption, which includes architectural changes, organizational changes, cultural changes. So a lot of the things I'm going to talk about are based on those conversations, as well as my experience at Allianz. Before I read you on Google, I've worked five years at Allianz, a very large insurance company. And I was the chief architect there. And I actually originally joined as head of enterprise architecture. And when I did so, I didn't really even know what enterprise architecture is or what a head of enterprise architecture does. But over the years, I really got a very thorough appreciation of what architecture is really meant to be doing and also find a lot of ways in which it doesn't quite do what it's meant to be doing. And let me start with this part. When we talk about enterprise architecture, there's two key problems we tend to see. The first problem is the clicker is on the wrong window. I'll fix that. There we go. The first problem we see is usually the enterprise architects are seen as the people who live high up in the ivory tower. They just draw pictures. They talk about stuff. But they don't actually solve the real problems. They leave this to the other folks. And the reason for that is often that the organizations allow people to do this. And at the end of the day, it is much easier to draw pictures than to get actually software running. So if your organization allows somebody to call that a success, people will always do that. Unfortunately, it doesn't really bring the value to the organization. And that's why I don't really count this as enterprise architecture. Basically, I count this as a hiding place where people are no longer technical and can no longer deliver software. So this is not what it's meant to be. Problem number two is when people talk about the enterprise architect, they generally think of this guy. It's like the architect from The Matrix, some wise man who just knows everything and decides everything. And of course, that model is equally broken because nobody is smart enough to know everything and make all the decisions. And in fact, in the movie, it's not a person. It's a computer program. So if you want to play the analogy, this is not a human being. But again, there's a reason this happens. Because for many folks in the organization, it's actually convenient to find somebody who makes all the important decisions because making those big decisions isn't an easy task. So invariably, something will go wrong. You will make a wrong decision. Now, if you have somebody else who makes all these important decisions, it's very convenient. Because it's not your problem. It's the other person's problem. And again, this is not what our enterprise architecture is meant to be at all. So let's talk a little bit about what I think the role of enterprise architecture is. And then I'll also talk a little bit about what is a good way to think like an enterprise architect. So how do you actually do the job? So the most important thing is, I believe, just to understand how enterprise architecture fits within IT architecture. Most of the time when you meet an architect at an event like this or an organization, they will be an IT architect. You're a software architect, infrastructure architect, cloud architect. You will have those kind of things. And you're kind of curious that on the business side, you have fewer folks being called architect, which should make you slightly suspicious because a large part of IT is to support the business. So you wonder where the people who actually architect the business, because what that looks like really drives what the IT looks like to a large extent. And you will find that recently there's a bit more of a movement called business architecture that formalizes that, similarly to IT architecture. But largely, the business architects will be the business leaders. They will be chief operating officers, vice presidents, department heads. They usually don't have the title architect. But if you see in what they do and how they think about their work, like the designing business units and divisions and product plans, et cetera, they actually very much behave like architects. So in the end, they are the architects of the business. Now, the two need to have a connection. And that is the key role of the enterprise architecture, to make sure that the IT architecture matches the business architecture. Because if that is out of whack for some reason, all the fancy stuff we do in IT is pointless. Then it becomes hobby because we're doing stuff. We're building fancy docker container, Kubernetes, whatever stuff. If it doesn't match what the business actually needs, that is about the worst case scenario you can have. So there's a corollary to this. And that means if enterprise architecture is sort of the connecting element between the business and IT architecture, you will quickly realize that the more these two are apart, the more enterprise architecture you will need. And this is one of the reasons that in digital companies, like inside Google, you will find relatively little enterprise architecture. That doesn't mean they don't do enterprise architecture, but it means that business and IT are very closely interlinked that they don't need the crutches, if you will. They don't need the enterprise architecture as a helper. They fulfill the enterprise architecture function, what needs to be done without having a separate department for it. Now, in a vast majority of large traditional organizations, that is not yet the case. They have separate IT divisions. They have shared IT service providers, all these kind of things. So the two are a little bit further apart, and that means enterprise architecture plays a critically important role. Now, there isn't an easy sort of three step process how enterprise architecture works. There's no one, two, three framework, unfortunately. But I think what can help to really appreciate and understand enterprise architecture is to look at what I call the enterprise architecture value chain. You're working for a business, so you need to create value. If you're creating value, this value doesn't come out of the blue sky. That value is created somehow. That's what's a value chain. So just like the business has a value chain where they buy raw materials, and then they assemble product, they ship product, they have a value chain, how they provide value to the end user, enterprise architecture also has a value chain. And what we'll do in the first part of my talk, we'll run through this value chain. Now the other thing that's important here, the reason it's called a chain, is because a chain is made out of those links. And that has the additional property that if one link is broken, the chain is broken. So that means if as an enterprise architect, you skip or miss somehow one of these items, the value chain is not there. You're not providing value. You can understand the business strategy better than the CEO, but you're not delivering the value because you're not making it to the end. The other part that we'll find is, these steps are not rocket science, right? If you can have a look, you can kind of have a feel what this is. So the steps are not somehow black magic, but doing this in the complexity and scope of a large organization is actually quite difficult. So what we'll find that is to a large extent the challenge of enterprise architecture. So let's start at the top and we'll run down the enterprise architecture value chain. As trivial as it sounds, the first thing you need to do is you need to understand the business. And the business in this context has really two parts, right? There's what the business does in the market, right? What does it sell? And then there's also the business as an organization, right? How is the business structured? So I worked five years for our insurance company and many people think insurance is relatively boring, right? In Germany, we have this image of the middle-aged guy in a suit and a little suitcase who comes to your house and sells you some car insurance or life insurance, kind of very, very boring. And he does this for like 30 years and it never changes. It is actually not quite true. In Alianza's case, it's a very large global insurance company, so you can buy travel insurance when you buy your airline ticket and it has sort of the next pop button. It says, oh, do you also want to be insured? For five more dollars, they do that. But they also ensure the aircraft you're gonna fly in and the oil drilling platform that pumps the oil that ultimately produces the kerosene and probably they ensure the refinery in between as well that makes a kerosene for the aircraft you're gonna go into. So if you see something bad happening on the news, like some large scale, large insurance companies like Alianza involved, right? And these are all real examples, right? From the Hindenburg on, this is all claims for Alianza insurance, right? A fairly old organization. But that also means that sort of just paying out a claim isn't the key role of an insurance company at this scale, right? If something like this happens, they need crisis management, right? People can have, need to protect their brand or they need to rescue people, right? Or they need to restore operations. So the business is often much more interesting than it seems, right? It's really false arrogance. If we think, oh, our IT is so interesting because we have all the cool Dr. Kubernetes TensorFlow AI quantum computing stuff and the business all they're selling is like insurance policies, that is actually a very, very dangerous attitude. A business generally, once you look at it, is interesting. So that's kind of seeing what the business does. And of course the next thing that's very important to understand is where do they make the money? And the money can mean revenue, but revenue doesn't mean margin, right? Where do they have growth areas? Where do they expand? Are they maybe gonna sell off some units? Are they acquiring a lot of new companies, right? You might think, hey, I'm just an IT architect, right? Why do I have to deal with this? That's the CEO's problem. But as you can quickly see, all this have an impact on the IT architecture, right? If you do a lot of acquisitions, you need a lot of integration, right? Things like that. The translation is much more apparent or much more real than it's apparent. So I did this, for example, Alianz, once I traveled through Asia and then understood what is actually going on. Asia of Alianz is largely a life insurance market. Malaysia is the most biggest property and casual market. They sold their business in Korea. They started business in Hong Kong, right? You start to get a feel for how the dynamic of this business works. And as I said, the second part to this is you also understand, okay? I'll just keep going. We lost the screen there. We also understand how the organization is structured, right? Business organizations have to deal with different dimensions, right? They have different geographies. They have different product lines. They have different functions, right? You could be in Asia doing life insurance and being in sales. Or you could be in Europe doing property and casualty and working in claims. So that's business architecture, right? They have three different dimensions. Somehow they need to make an organization out of this. So usually they're organized by country and then by product and then by function, right? This is all quite interesting to know because if you, as an enterprise architect, want to really make the connection between the business architecture and the IT architecture, this is the business architecture to a large extent. So you need to understand that. Who are the right people and how is the business as an organization structured to work the markets that they're in? Like all this, basically reverse engineering in the organization. And generally as architects, we're pretty good at this, right? We can do stuff like this. We can understand the structure of systems. In this case it's just not a technical system. It's an organizational system. So it might seem very far away from our daily job, but actually your brain is actually pretty well equipped to follow this kind of logic. And the last important thing you need to do at the very top of the value chain is you need to understand how the IT is embedded into the rest of the organization. And usually the IT ends at the CIO, right? It's at the chief information officer, right? That's the person he or she who has all the IT budget and most people in IT will ultimately report to a CIO to a chief information officer, right? That is actually a pretty tough job. So a lot of people joke that CIO stands for career is over. And that's one of the bad jokes because it's really a tough job, especially these days. You need to keep the cost down. You need to innovate, right? You need to have cloud stuff. I mean, cybersecurity can make you instantly unemployed, right? Usually CIO takes the hit if that happens. So interesting job. So what's important is how does the business look at this CIO and his or her organization? What do they expect? And traditionally the IT in most organizations grew large because it automated what the business did. It was a cost saver, right? I do things by manually today and that costs a lot of money because it's labor intensive. If I have a computer, I can do this on the screen. I can automate this cost me less money. It's a good thing. And that's basic for about half a century how IT grew as big as it is today. The catch is it's very much cost driven, right? It's all about cost reduction. And we talked about reverse engineering the organization. So one way to get a hint that the organization believes IT's main purpose is to reduce cost is if the CIO reports to the chief financial officer. CFO, chief financial officer is the person who writes the checks, right? So if it's all about money spent, reducing money spent, that's where the reporting line is. And that's very important because let's say as an architect you come out with a fantastic hybrid cloud strategy, right? And I always use Docker Kubernetes as an example, right? It's all this hybrid cloud containers, container orchestration. You can move in and out. You have a CI, CD pipeline, right? You can push so for any time. CIO is not gonna be interested because his boss is not gonna be interested or her boss, right? Because it's all about cost reduction and all you just talked about is about gaining speed and flexibility, right? You're sold speed and flexibility to somebody who only cares about cost and that sale is not gonna go through. And this usually results in IT people being frustrated and saying nobody wants to fund my project. These people are stupid. They don't understand why containers are so important for us, right? But in the end, you just totally communicating at the wrong line. So these things are important and you will see that a lot of organizations are changing these reporting lines as their mindset is changing. So a lot of organizations moving the CIO reporting lines over to the chief operating officer. And that's a big step ahead because now they're talking about return on investment. They're willing to put money in if they get more money out. So at least money flows. On the left side, no money flows in the first place. At least here money flows if something comes back. So you can start arguing but generally they're driven by optimizations, right? Economies of scale. These are large companies. They do something in IT and then they get the return of investment because they roll this out across the whole organization. So this is all about harmonization, standardization, right? These are the people where like, we try to get everything on the same Linux version, right? Very important stuff but usually not the stuff that excites us all as much as architects. But as enterprise architecture still needs to be done. Where it gets really interesting is you move further to the right. This is where people see that IT is not a support function but IT is really part of the business, right? I often say the compact disk wasn't an end user requirement, right? This was technology driving a latent need for music on demand and the tapes couldn't really do that and the CD could do that. This was technology enablement that unlocked a latent need. It wasn't the user saying, oh, I need a spinning thing with little holes in it that a laser can read, right? This is not the user's game. And this also can easily tell you why the CD went away so quickly because the need for instant access to music just flipped the streaming, right? It solved the same need boom, end of CD, right? Went very quickly. So this is where it's quite interesting. Now what I haven't talked about is in these kind of models, there is a logical conclusion about what you should do with the IT. If it's a pure cost, you should outsource it because somebody can do it more cheaply than you can, right? Many of us don't like that as much, but it's the logical thing to do, right? If you're looking to unlock business value, if you're trying to really make IT a part of the business, it is actually the opposite, right? Because the driver is no longer cost, the driver's agility. You know, and I remind people, agility is the ability to steer, right? Agility is being able to maneuver and if your IT is in-house, you don't have contracts in the way, you have shorter communication paths, right? You have shared goals. It is easier to get into this agile model. So it's exactly the opposite and you can see from organizations, right? Organizations that are making a big outsourcing push still, they're probably still in the model on the left-hand side versus organizations that bring the IT back in, they probably move further to the right-hand side. And what you'll find is that in addition to the CIO or in a reporting line, you usually have a CDOS chief digital officer, right? Those people have understood that the digital world has different rules of the game and ultimately the CIO should just report to the CEO, the CIO, the IT should be equally important to all the other functions like finance and operations and marketing and sales, right? This should all be equally important and that is ultimately what you see where really IT equals business, right? The distinction no longer exists. And I call this the economies of speed. People have realized that in the digital world, it's not about how big you are, but about how fast you are, right? And they work very differently in their IT. So quite a lot of work to do up there to understand the business strategy, the business environment, now you need to translate that business strategy into an IT strategy. And the key thing I remind folks of that the most important thing about a strategy is it's not reality, it's a direction you want to go. So I once had an IT strategy where I said, I'm gonna package my applications in containers. And some of the studies I saw, my application can't be containerized. That does not invalidate the strategy, right? It's a direction, a vision, it's a goal you drive towards. It's not something that's supposed to be 100% reality today and immediately. The other important part, and there's some very smart people who coined that quote, which is strategy is what you're not doing. Faster, better, cheaper is wishful thinking. That is not a strategy, right? Strategy is focus and focus includes excluding stuff, right? And the last one that happens in large enterprises, they're very much influenced by the vendors, right? Because large enterprises are generally buy over build type organization. That's a good thing, right? Why should you buy software that you can buy? Because ultimately you should build the stuff that differentiates them during the market and you shouldn't build your own persistence framework. So you buy this kind of stuff and you buy the server. But what can easily happen is that sort of the product vendor's roadmap starts acting as a proxy to your IT strategy. And that is very dangerous because that is the strategy for the vendor, not for your business, right? And they might have good things in mind, but still they don't know what's best for you, right? And they have a very specific view on your business from the product that they sell. They don't have the complete view. And that's what you need to do is you need to have a complete strategy, know where you're driving, know what's important to you. Maybe automation is important, right? So you go to the vendor who comes and says, well, how do you install your software? And if it's anything more than a push of a button and something fully automated, they say, sorry guys, doesn't match my strategy, right? And maybe the vendor can fix it, right? But those are the kind of conversations you wanna have with a vendor. You wanna know what's important to you. Does it run in a cloud? Can it go in a container? Does it run fully automated, right? And then you see whether the vendor's product matches that, doing it the other way around is extremely dangerous. So the very first book that there was around about enterprise architecture is called Enterprise Architecture Strategy. And as so often with the first book, it's an important book, but it's not always the best book, right? Because it's the very beginning of the collective understanding. So I would say it's fair to say that this book has one most important diagram and it's this two by two matrix. The good news with two by two matrices is that management has been sufficiently inundated with two by two matrices by McKinsey and Coe. So they always understand everything that's in a two by two matrix. So if you're trying to make something easy to understand, this is a good strategy. This one does require some explanation though. So what's going on here, there's two axes on this matrix and it shows how much the business processes are standardized versus how much they integrated. And in the bottom left, you will find businesses that are neither standardized nor integrated. This could be like Siemens or GE or some companies that make everything under the planet, from a locomotive to a power station, to a train, to a refrigerator. I mean, it's basically they make everything, it's not standardized and it's not integrated. On the bottom right hand side, you will, and let me see, you can actually then see what you do. If they really that diverse, the best you can do is basically try to get some economies of scale, by at least getting them on the same infrastructure. But they won't have the same applications because they do so many diverse things. So all you can do is basically kind of give them Linux servers or something like that. If you're in a replication environment, this is like a franchise, McDonald's. Every business is the same. So you can give them a whole application suite. In modern software architecture terms, there would be software as a service. You can make this as a SaaS model. All the new McDonald's branch has to do is log on to your cloud. And boom, they have all the sales inventory, payment, everything they need. Could be easily done because it's highly replicated. Every McDonald's is like the next McDonald's. That is the strength of the franchise model. On the other hand, one McDonald's has very little to do with another McDonald's. They operate very independently. The only thing that rolls up in the end is the financials. So here, common applications, standardizations on the application is interesting, but integration is less valuable versus you have a business that is diverse but highly integrated. Then integration and data standardization, data warehouse, data lakes, all these kind of things are much more valuable. And those are examples where you can see that the nature of the business, we call this the operating model of the business, how that makes certain IT strategies more valuable or less valuable. If you're highly integrated, stuff around data, enterprise service bus integration, data warehouse will have a high value. It will have less value for a McDonald's type operation. There, you wanna make sure you have the application replication. Right, and there's companies that have the combination of two. So that's the critical translation step between business strategy and IT strategy. Third one was, you need transparency. It sounds much more trivial than it actually is because if you don't have transparency, you can't do anything, you can't really steer the organization. Unfortunately, usually reality looks like this. And I always joke that this is a fantastic architecture because this is extremely scalable architecture if you haven't thought about it. And the simple reason why it's so scalable is, I mean to me it's blatantly obvious, the reason it's so scalable is because look, the database is down here and nothing connects to it. So it must be 100% stateless and it's great scalable. Joke aside, creating transparency in a large organization is a huge undertaking. And you need, we'll come to this, you need to also not just document reality but you need to find a model to represent reality that allows you to reason about it, that allows you to chart a roadmap. And that is the next step in the value chain. So we have the business strategy, IT strategy, we have reality and you will always find a gap. You're never where you wanna be. So now you make a roadmap. I was at a conference in Australia where somebody said very nicely, he said, management are suckers for plans. They love a plan, right? As an architect, we always like to show the target picture and often to management that's confusing, right? It's like the Dr. Kubernetes, whatever, right? So they're like, what is this all? But management loves a roadmap, management loves. So first you do this, then you do this, right? You make it nice and easy. So this is a real example, right? What does one of these roadmaps look like? One of the biggest problems we have in this enterprise is that all of the applications are completely separate. They're not well integrated, they're silos and they use a tiny bit of common infrastructure. Ultimately, they all run on an x86 server if you're lucky, right? But it's a huge duplication, right? Data silos, no integration. They all have their own tool chain, their own testing framework, their own runtime automation, their own deployment automation, right? All that is duplicated. So what do we need to do? We need to solve two problems. We need to get some sort of API or some sort of integration layer on these things and we need to grow a common platform out of the bottom. An application have in its own tool chain, its own testing and deployment framework probably doesn't sell your business a single dollar, right? So that is non-differentiating that stuff you should harmonize, right? Because it's non-differentiating. And once you have done that, you can also start breaking down these applications into smaller services because if you don't have a really well-greased, harmonized runtime, it's gonna be very difficult to do this with smaller services, right? You can sort of get away with it if you have three huge applications that all have their own tool chain and runtime and automation and monitoring. But even if 100 services, you won't be able to deal with that, right? So this is a classic sort of IT roadmap. We grow the common platform, then we break down into smaller services, microservices, if you wish. And you can see here, the next thing you do is also because you have this common runtime, you abstracted the applications and services away from the infrastructure. So now you gain some flexibility to move things from on-premise into the cloud. Classic IT strategy, right? Translated into a roadmap that is relatively management compatible, right? Upper management will understand this, right? But the next thing you need to do, so people buy into your roadmap, so now you need a lever, right? You need to somehow make sure that the stuff that you have actually gets onto this roadmap, right? They often say an architect is more like a gardener, right? The weeds grow, well, the plants grow by themselves and the weeds grow the fastest, right? And IT is the same, right? The weeds grow everywhere. So you need to start pruning. And here's another real example where we try to make very clear and very simple. What is the IT strategy here? What is the roadmap and where do we harmonize, right? And in this case, the left-hand side was a big problem for this IT because the applications were relatively rigid. So they were prescriptive at the top where the business actually wanted some flexibility, right? The business might have a great idea or this market might be different than this market or this product different than this product. So the applications couldn't deliver the flexibility that the business needed, but at the same time, at the bottom, they had a huge diversity, right? Then every possible hardware and software, mainframe AIX, you know, Linux, Windows, X86, I mean everything you could imagine they had, right? So it's a worst case scenario because you have a lot of diversity that you pay for at the infrastructure level which is not providing a differentiator for your business. But an insurance company has not sold a single policy because it's on X86 processors versus other ones, right? They sell insurance policy because they have systems that support the business and engage the customer. So a key part of the harmonization strategy was harmonize at the bottom, right? Get this diversity out of the infrastructure. Get things on Linux, get it in the docking container, automate the deployment and runtime and really shrink that. And you see the platform again there, right? James Lewis just gave a very nice talk about the role that platforms play. And then on top, you don't want to harmonize, right? You want to give the business the ability to experiment flexibility, right? It would be foolish to harmonize too strictly there because that's what drives the business, right? So it's very important in this harmonization and governance that you understand where you want to tighten the screw and where you maybe intentionally want to loosen the screw, right? And those are the important considerations of an enterprise architecture. You will have people running around and say, oh, we need to harmonize everything, right? They caught a word somewhere and say, harmonizing is good, it saves money, but then harmonizing can also kill your business, right? If you harmonize, the wrong things. Now, this all sounds fantastically easy, right? But the reality is, you know, you have a nice plan, but the reality looks a lot different than your plan, right? And there's a little you can do about it. I often joke that in Germany, right? I work for a large German company, when the reality doesn't match your plan, you blame the reality because your plan, you worked so hard, your plan must be good, right? So if it's not working, something is wrong in reality. Sadly, it's hard to argue with reality. Yeah, a little bit. Reality can be a bit stubborn on this, right? So what do you need to do? Again, no magic recipe is you need to course correct. And the important thing is when you're in course correct, two things you need, right? You need agility, right? You need the ability to steer, but you also need a clear target, right? Because if you keep course correct and you don't have a compass or a target, you just keep going in circles, right? So it sounds nice to course correct, but you can only do this if you have a clear direction that you're going into. And a lot of stuff that you'll find is stuff that you won't like, but what are you gonna do, right? It's better to find out than not to find out. And that brings us to the end of the value chain to the very last one. And that's an important one is, enterprise architecture is not just about doing architecture. It is also about growing the awareness and the skill in the organization for architecture, right? You will never have enough people to work with. You won't have the skillset that you can communicate in a high band with model, right? So there's a true motivation to just do this, but on the other hand, this is also the right thing to do, right? If you made it to become an enterprise architect, right? Your role is also to help other people make that journey, right? It's not the game of like who gets to the top first, but it's the game whoever gets to the top helps lift the other people up, right? And that is the coaching and the mentoring part. And that's important not to forget because that's what in the end fuels the cycle, right? You will need other architects to help you. You will need more understanding and broader support. So if you don't do this, you will lose your basis, right? Linda Rising also earlier made this very clear, right? You think like, oh, I have all the great ideas. I don't need anybody's help, right? That is the quickest path, right? Right into the dead end. So that's the value chain. So now let's talk about what goes on in the head of an enterprise architect. And we'll find that it's three key things an enterprise architect needs to do to solve these kind of problems, to make this value chain work. But before they do this, I want to share one of my favorite definitions of architecture. And that is when I talk, yeah, it's very simple, yeah? So now everybody knows how architecture works. This is actually the Black-Scholes formula. Those guys got a Nobel Prize for this, right? So pretty clever guys. When you talk to the business and you're trying to explain what architecture does, most business people actually understand this stuff, especially in a financial organization. You tell them I sell options, right? What does architecture do? Architecture gives you flexibility. Architecture gives you the ability to make changes in the future, right? Those are options. Am I gonna move to the cloud or am I not gonna move to the cloud? Do I wanna have this option or do I not need this option? Do I need to be able to dynamically scale my application? I can buy this option. This option is called stateless architecture, horizontally-scaling architecture. The option is not free, just like in a financial market. So what this formula does, it calculates the value of an option. So options are not free because it lets you buy flexibility in the future and that has a value, right? Because I don't know yet which way it's gonna go. So buying myself the ability to go left or right clearly has value, right? You can draw the decision trees and do the math very easily, right? So that's what architecture does and the key conversation between architecture and the business is, here's the list of options that I think you might find useful. Let's talk about which options are worth buying. And there's a small follow-up to this and this is actually buried in this interesting formula is that in a volatile environment, the value of the option increases, right? You can easily imagine. If you know exactly what's gonna happen, if you build an application for 10 users and it will always be 10 users, the option to scale dynamically isn't that valuable. But if you're building an internet-scale application, right, where you could have 10 users a day and 10 million users tomorrow, the option is highly valuable. So now we live in a very volatile world, like so many changes going on in the business environment, in the technical environment that the value of these options goes up. So this is a very nice pitch. You're most welcome to borrow to your business. That's why they should invest more money in architecture because the value they get from the option that you as an architect are selling is increasing. And business people will understand that logic. So you're welcome to borrow that model. Three things architects do, connections. So there's one ugly truth in architecture and that is no one actually cares about the architecture. And sadly, this message comes straight from me, you know, former chief architect, it's kind of, you might say, well, that's a little bit depressing, right? Nobody cares about the architecture because the customers don't see your architecture. Your customers see how the systems behave. Like, are they performing? Do they run 24-7, right? Or are they broken all the time? Are they able to accommodate rapid changes? Now if you look at the system, right, left and right has the same pieces, right? ABCD, but what's the difference? The difference is they're put together differently. The connections are different. And, you know, if I ask any architect, do these two systems have different properties? They will give me a list of like 10 things immediately, right? And the left, it's easier to replace something, but latency might be longer. And if one component fails on the left-hand side, everything falls apart, versus the right-hand side has shorter path, but more coupling is harder to replace something. Boom, boom, boom, boom, boom, boom, right? That's what we do as architecture. They're basically the complete opposite of each other, even though they're built from the same ingredients. So the way I explain this, right, we like simple metaphor, you know, this is the bill of materials, right? This is ABCD, so when you build a software, this is the application server, your database, your firewall, but the catch is out of this stuff you can cook very different things. You can make a amazingly tasty pizza, or you can make this horrible I don't know, melted cheese sandwich here, right? And that is in the connection. So being a good chef, right? An architect needs to be a good chef, but a good chef is about how you put the ingredients together. Going to the market and buying tasty tomatoes doesn't guarantee a good meal, right? And the same is in IT. Buying high-quality ingredients is a good start, but making the tasty meal, making the good architecture, is something that lives in the connections. It's all about how it's put together. Which leads me to another famous saying that I have, as somebody shows me an architecture picture that has no lines, I basically tell them this is not an architecture, right? Because of all the behavior, of all the important parties in the connections, if somebody doesn't show me any connections, I'm like, well, this is not very useful. People think it's a little bit mean, but I actually mean it, right? If there's no connections, this architecture picture is probably not helpful. Now the interesting thing about the architecture job is, you will find that the connections live in many different universes. So the one is connections between layers, right? Layers of abstraction from business strategy to application-state infrastructure, and getting this aligned is a very important architecture function, right? And that's the value chain largely we talked about. But there's also things like connections between systems. How is stuff integrated, right? Are they integrated at all? Are there silos as a point-to-point? Is the service bus has a big impact on the way your system behaves? And lastly, we don't live just in a technical world. We also live in the organizational side, right? There are connections between the different functions in the enterprise, and then also has a huge impact. When James Lewis talked about platforms, he talked a lot about this, right? If you need to go to another department and wait two months for a server, moving to a cloud platform does not help you, right? Because you're still waiting two months for the approval, right? So connections play the central role, and the connections live in different universes, right? In different dimensions. Second important thing is the ability to abstract, right? We saw the funny picture earlier, right? That is the reality. You cannot use the reality to make intelligent decisions. You use a model, right? The model is our most important tool to make decisions as architects, because reality is too complex. Now the important thing is to understand is a model is not reality. It shouldn't be reality because the whole purpose of the model is to simplify reality so you can answer a question or make a decision. But then also means in order to find a good model, you need to know what question you're trying to answer. So here's a classic example of four different maps. They're very different. They show the same system, the system planet Earth, right? But they look very differently. And the reason they look so different is because they answer different questions. You know, how do I hike from A to B, or how do I drive from here to there? Different questions. So that means if you make an architecture diagram, which is a model, in order to make a good diagram, you first need to know what question you're answering or what decision you're trying to make. So somebody says, please show me your architecture. It's a valid question to say what question you'd like to have answered with my architecture, right? I don't draw architecture pictures as artwork that need to be driven by a question or decision. And you can turn this around if somebody shows you an architecture picture. It is a valid question to ask, what decision does this help me make? And if they're like, what do you mean? Then you're like, well, this is a model, the purpose of the model is to help me make a decision, right? So if you show me a model, you must have some decision in mind, right? And if that is not there, the architecture picture is probably not very, very useful. So here's one example of an architecture model, right? And this is what a lot of the enterprise architecture tools try to do. And you can see a little bit, it's trying to make the connections, right? We talked about the connections are so important. It's trying to make the connection between business processes. So I think I have a laser beamer here, maybe a door. Ah, there we go. Between the business objects and processes to the data and applications down to the infrastructure, right? So it's trying to make these connections and that's what a lot of enterprise architecture tools do. And that is actually a very useful thing. The catch is that a lot of people get lost in the complexity of the tool, right? And we'll come to that, right? It's not about putting everything into the tool, it's what get you, what you get out from the tool, right? The tool needs to help you make decisions. If it doesn't do that, right? It just waste the time and money to put stuff into the tool. And the last one that's important in this abstraction is as an architect, you need to have a clear view of how this system fits together, like how does this system function? And there's actually a classic anecdote to this and actually it comes out of India here and it's called the Cobra effect, right? So in the old days, there's a lot of cobras around and cobras are not very friendly animals, right? So in the British folks, they're like, what do we do, right? And they're like, well, we put a reward out for a dead cobra, right? So like people will kill the cobras, right? So we make an incentive, right? Now of course what happens, people start breeding cobras because it's a source of income. It's easy money, right? You just make sure the little cobra is all happy and safe, right? So now of course, ultimately people get wind of this, right? Suddenly there's a lot more cobras than you wanted to buy so they stop paying for these cobras. Now what of course happens, the cobras now suddenly became worthless. So you just release them. So in the end what started like a good idea ends up actually having the negative effect. That's what we call systems think and complex systems theory. And a lot about making changes in these architectural organizational systems can have this same challenge. So when you talk about the connections it's very important to understand those kind of effects. You might have a good idea. It's like, hey, we give a reward for people to get rid of something we don't like. It can lead to the exact opposite. So this is also a very, very important aspect for an architect. Last one I already hinted at this, right? The point of a model is to help you make a decision, and the example I often use is I ask people whether this is architecture. And in the classic definition of architecture it probably passes the test. The classic definition of architecture, it's the components, the constraints, how it's put together and this is perfect. The windows are there, the door goes to the floor, the windows are in the wall, the roof is on the top. So it has all the definitions of classic architecture but for me it fails the test because it doesn't represent any decisions. Well, I have a very similar example. Oh, I actually have a good test for this. The question is not, is this architecture? But the question you should really ask is would you have paid an architect for this? And the answer then very most likely is no, right? Because there's no decision here. This is cookie cutter. I have a slightly different variation for a house that has a funny pointed roof and the roof is so pointed because it's in a cold climate where it snows a lot and snow is heavy so it can crush your structure so they made a very pointed roof so the snow gets off the roof. Now here is a decision and suddenly I would say that makes an architecture, right? There's a decision made, somebody put some thought in it and for this you might have actually paid an architect. Bringing this back to IT, making decisions what I find my worst pet peeve in the 90s is that people really get lost in the complexity of the system and lose the decision discipline. Making decisions is relatively easy thing. You have some options. You need to choose one of the options. You have a clear guideline on what options you prefer. Like I said, right? You want things that are automated, things that can run into the cloud, things that are open source, right? Those are your clear strategy and principles. You look at the options, you decide based on these options, right? The problem is in all this complexity people forget this, right? So you need to go back to the basics and be a disciplined decision maker. The one thing I like to remind people and I borrowed this from George Fairbank's book Just Enough Architecture is a decision that doesn't have a trade off is usually not a very useful decision, right? And you will find this in IT where people make a decision between something meaningful and something completely idiotic, right? And then show a score chart and say, well, the meaningful decision, look, it's much more meaningful than the stupid thing. It's like, those are not useful decisions. Useful decisions have a trade off. We can make the point roof pointy, so the snow falls off, but there's a trade off. You're not gonna find any furniture at IKEA to furnish you up a floor because your walls are gonna be like this, right? There is a trade off in a decision. If there's no trade off, probably you haven't made a very meaningful decision. And what I'd like to do is what I'd like to add to George's, the last sentence is mine, if your decision has a downside that we accept, you should still have a strategy how you minimize that downside, right? So that's your role as architect as well, to say like, yes, we understand, right? That making things, you know, hybrid cloud compatible can increase the complexity and here's what we're doing to minimize that. So that brings us near the end of my talk, right? The last, most important advice here is that all this sounds rather logical, right? We have the eight steps in the value chain, we have the key ingredients that you need to do, right? You need to consider the connections, you know, you need to look at abstractions and you need to make decisions. The problem is it's never that easy because this is a vast sea of fuzziness and I think that's where most enterprise architects sort of get derailed. They have the right intentions but because it's so fuzzy, they don't know where to really start. So dividing and conquering and having a measured impact is probably the most important thing enterprise architects can do because that keeps them out of the ivory tower, right? If you don't have measurable outcomes, you will live in the ivory tower and you will feel really good about it because life is nice and convenient but you're not producing any value for the enterprise. Now that is a very, very bad thing. So in the end, I would say the takeaway is it's not black magic, right? A lot of it is common sense. It's understanding the relationships between things. It is prioritizing. It is about understanding how business and IT connects. It is about making disciplined decisions, making sure these decisions are driven by common principles and common strategies, right? This is all stuff we do in daily life all the time. We know how to do this. The key thing here is not to get lost in the complexity of the domain or in the complexity of the tools and frameworks. That can also happen, right? The tool is the tool for you to achieve your goal. The tool is not the goal, right? That is probably the most important advice here. And with that, I'll end on a little bit more personal note. For me, really, if you look at my career, I've seen quite a few different viewpoints of IT. I was a co-founder of a startup. I've worked a lot in consulting. Then I worked in Google as a software engineer. Then I was a chief architect. So in the end, just as much as good architecture is about combining different viewpoints, I think being successful in IT is also about combining different viewpoints, right? Understanding the organizational aspects, understanding the technical aspects, understanding the business aspects, right? The more of these viewpoints you can combine, the stronger and the more successful you will be in bringing this together and producing value for the enterprise. And you will find that the demand for those people is enormously high. That is because the supply is so slim. You will find very, very few people who have seen the different viewpoints on IT and organizations and can bring them together in a meaningful way. So I highly encourage you to think about that and stretch your own horizon. Hopefully I was able to give you a broader view of what architecture is really all about. And really, I mean it seriously here, right? If you can do that, if you can get the broad view and translate that into measurable results, companies will love you, right? You will be really one of the few people who can fill this kind of spot. So if you enjoyed this talk and some of the ideas, the book is not about enterprise architecture, but this is a book I wrote very much about the role of architects in a large organization, mostly with a point of view of driving a transformation scenario. It is really a lot of little anecdotes, right? Little stories, but they have a sort of very serious content, a very serious underpinning. So if there's an architect, you'd like to engage at the higher levels of your organization at most strategic architects. I recommend you have a look. A lot of the content is on the website and if you like it, you can have an e-book or a paper book of this version. So with that, I apologize for being five minutes over time, but I thank you very much. I'll be around today and tomorrow. So if you have questions, just find me. I think that's the easiest way we can have a chat. Thank you very much.