Transcript
Hohpe: I think architecture has actually a lot of different lenses and different dimensions. I felt that this is a great opportunity to reflect a little bit on what does it actually mean to be an architect. My view on this is really, it's not anything on your business card. I've met great architects whose title is an architect. I met people who have the word on the business card where I would say, in my view, they're not such great architects. It happens. It's really a way of thinking, a lifestyle almost.
I've been in many different organizations that also had different views of what architects are. I used to be a chief architect, which sounds very ominous, whatever that is. I've also been in organizations that proudly proclaim, they have no architects, but they still had an architecture. It's interesting to be an architect, and to really get to the essence of what that really means. Here's my attempt. I don't have a single definition, but I have different lenses that I think help you reflect on how you can be effective and valuable as an architect. Here's my first important statement about this. Often, architects are seen as these people who should make all the decisions. They're a little bit older than everybody else, maybe get paid a little bit more.
They're a little bit wiser, or at least they look wiser. They should be making all the decisions for everybody else, so everything goes well. A, I think being that smart and that wise is really hard. I wouldn't definitely claim that of myself. B, why should one person make all the decisions? How can one person be smarter than everybody else? Especially if they don't work on the project, or they don't code day to day, how come that these people would be better equipped to make the decisions? I'm very adamant about saying is, you shall not be the smartest person in the room, or the smartest person in the team who tells everybody else what to do. Your job is really to make the other people a little bit smarter, to help them come to better decisions, to look at their problems through different lenses, understand impacts, tradeoffs. That is really your role as an architect. You're an IQ amplifier for everyone else.
Architects Connect Levels
That I think is a great way to start looking at what architects actually do. These are the different lenses that I talked about, of what I think if you find yourself assuming the role of an architect, knowing that you're an IQ amplifier, those are the things that you can do to accomplish that. Let's start with the levels. I wrote a book called, "The Architect Elevator," that's a little bit my pitch, and that is about connecting different levels of the organization. The opening question for that is really, which architect is the most valuable one? It's a trick question.
You can get people pretty riled up. Some people say, the chief architect, obviously. As the chief, they must be the most valuable and most important architect. Then you can easily make the counterargument to say, no, it's like the ivory tower people, all they do is draw pictures. It's the folks who are most hands-on, make decisions, implement things, get the software to work reliably, scalably. They are more valuable. In my view, it's asking the slightly wrong question, or it's thinking about the question from a wrong perspective. I find the most valuable person neither the one at the top, nor the one only at the bottom, but the people who can connect these different levels.
Maybe chief architect, or somebody who does draw pictures, might just draw a lot of pictures, if these pictures trickle down and help you make better decisions, that is very valuable. If they don't, if they just sit in the penthouse, probably not, and vice versa. If you're really good at systems engineering, you might be a great developer, but none of that ever connects to the success of the organization or the application as a whole, then also your value might not be as large. It's not about which level you sit at, but it's about how many different floors you can cover. That is what the architect elevator is all about. I encourage folks to ride the elevator and not get stuck at a single level.
Why is this so important? Because organizations tend to have many different levels. It's division of labor. Sometimes it's legal considerations. An organization isn't all one team. There's leadership. There are CEOs. There's boards. There's development teams. Sometimes things are outsourced. There's all these different layers. That can lead to some issues. A very common situation you have is the penthouse up there, the leadership lives in the illusion that in IT everything is fantastic. It's like, we have blockchain and GenAI, how much better could it be? Down at the bottom, the developers feel a lot of freedom, because management has no idea anyhow what they're doing.
It's like, great, we told them we're working on blockchain but we're actually writing this open source project. Life is really good. The reason this can work is because there's this isolation layer in the middle, and that's called middle management. This is an interesting architecture. This is a loosely coupled architecture. However, it's not the kind of loose coupling that the organization would normally wish for. Obviously, something is wrong here. This is a dangerous disconnect. If the people build things that don't contribute to the strategy, and the folks who make the strategy are not connected to the reality, that doesn't go well. That is the problem we try to fix when we say the valuable architects are the ones who can make that kind of connection.
As architects, we like models, and that was one of the items on the list. If you want to drill deeper into why this going across layers is so important, we can use a model. This is an architecture pattern. It's one of the most basic architecture patterns. Everybody knows layering. You divide things in layers. Why do we divide things in layers? Because it has some obvious advantages. I already mentioned, you have separation of concerns. You can hide and abstract details in one layer.
You have nice dependencies and interfaces, and that affords you things like replaceability. It's easy to take one layer out and put another one in. Architecture is the business of tradeoffs, so where there's a plus there's also a minus. We also know that too many layers can bring overhead. This can be runtime overhead. If all these layers are connected by an XML protocol, you end up doing a lot of parsing, and marshaling, and garbage collection. You might have latency.
You might have things like change propagation. People know this. If you have an application that is structured in the frontend, the Backend for Frontend, the API layer, the business logic layer, and the database layer, and you want to add one field to your screen, what do you end up doing? You end it to the user interface layer, the Backend for Frontend layer, the API layer, the business logic layer, the database layer. That's what's called change propagation. The changes tend to run vertically through these kinds of things. If you have too many layers, you're not sure what goes into which layer actually, and that has its own complexity.
Two things we learn here. The first thing, the way I just described this, I didn't say whether this is a technical system or an organizational system, so the frontend example aside. All these things apply to organizations as well as to technical system. Replaceability, what is that called? Outsourcing. You take one layer out of the organization and put it somewhere else. These effects apply to both technical systems and organizational systems. What you learn here, as a technical architect, you actually understand a lot more about how organizations work than you might have thought, because all these considerations apply to organizations as well.
If you have a lot of change in the organization, all this layering is going to be in the way. The second one, if you look very hard, the things on the left-hand side and the things on the right-hand side are slightly different. They come out of a different bucket. You have to squint pretty hard. The left-hand side, those are more structural considerations, like interfaces, and dependencies, abstractions, that describes the structure of the system. The benefits are largely structural. The right-hand side uses slightly different words, like changes, optimization, latency, overhead, those are more runtime-y, they're more like performance, operational words on the right-hand side. This is how the system behaves.
What you realize here, and this is the second major insight we have, is that this layering works well if something is slow moving, because the structural things on the left, you benefit from them. Versus if things become fast moving, the things on the right-hand side who are more dynamic, operational in nature, they will weigh more heavily. This explains why organizations became this way because they're made for an environment that is not fast changing, but we all know that is not the environment we are in today. It's not like this model was wrong, it was made for a different context, it was made for a world with a low rate of change. We don't live in a world with a low rate of change. As architects, we can start having a lot of insight by using these models, and actually realize that the organizational system and the technical system actually have a lot of similarity. Basically, as software and IT architects, you are also already organizational architects.
This is what I pitch, riding the elevator. Many of the topics relate back to this, where you make this connection, organization and technology, one cannot exist without the other. Careful, riding the elevator up doesn't mean dumbing things down. You're talking to some of the smartest people in the organization. They run the whole company. They didn't get there by not knowing anything. They might not know what a Helm chart is. That's totally fine, because that's not their job. Don't dumb things down, but convey meaningful details that help them make better decisions.
The architect elevator is not about telling completely different stories to different people, but it's about making the connection between the different levels. The story has to be connected. Here's a simple example that I've been using for a long time. Let's say you come out of the engine room, and you talk about high levels automation. You're in the cloud, speed, velocity, feedback cycles, DevOps, agile. That's the stuff that we get excited about. Then you go tell this to a CIO, or the head of IT.
They say, "This is really nice, but what my boss wants, which might be the CEO, is, they don't want to be in the newspaper. Security is number one. We don't want to have a breach. Nobody pays for IT that's not running, so availability is high on the agenda. Please, don't spend too much money." You can have an odd discussion about which one is better between the two. The maneuver you want to do, the architect elevator maneuver is to show that the things on the left actually get you the things on the right. The stuff out of the engine room that you're excited about, actually gives the CIO exactly the things that they're excited about.
How are you going to get security? If you have lack of automation and you do manual patching, I guarantee you, that stuff is not going to be up to the latest versions. It's going to have some exploits. Automation is critically important. Doing this quickly, having feedback and observability, and knowing when you have anomalies, detection, those are key mechanisms. Same thing, availability. Classically, you get availability with standbys. Standbys are expensive.
You spend double the hardware to get like 1% more of uptime or half a percent. How can you be cost effective and highly available through high levels of automation and elasticity, and the faster you can spool up new resources, the tighter you can run, basically. When the spikes hit, then you can scale up faster, so that means you can run closer to the limit. That's what the architect elevator is about. It's not repeating the stuff on the left 12 times until the guys on the right finally give up. It's about making this connection and explaining why this stuff is actually getting you the stuff from the right-hand side.
A couple of takeaways from the first part here is, it's really important. What I like to do to make these connections, I like to use a lot of metaphors. I'm somewhat famous for using car metaphors for everything. Pick whatever you like. Ideally, you pick a metaphor from the business that you're in. I have an example later. I used to work in financial services. If you can use metaphors and language from your business, you will win immensely with the upper levels of the elevator. What you're doing by using metaphors is you're inviting your audience into the thought process.
When we talk about our techno mumbo jumbo with leadership, the real translation is, trust me. You say, we need to be like EKS, Fargate, this automation, container orchestration, loosely coupled, event driven, please give me $5 million. Really what you told them is, trust me, because they have no idea. Then they might trust you then good for you, but if they don't, they feel a little bit uneasy. Using metaphors invites them into the decision process, allows them to think with you.
There are people who don't want the leadership to think too much. Would it be just nice if they just put the stamp on the purchase order and off you go? Wouldn't that be convenient? Maybe yes. That is not in the purpose of the organization. You're underutilizing your organization's mental resources. You have smart people sitting there, and you're not inviting them into this thinking process, that is waste. That is not a good thing to do for the organization. Metaphors, example is using clear language. Those are the things that forge that connection.
Architects Sketch
Pictures, I joked in the beginning, if the architects do nothing but draw pictures, they might have a fancy title, but they might not be as valuable. Correct myself tiny bit, drawing pictures is actually valuable, as long as they connect to something. If you search for IT architecture diagram, this stuff comes up, boxes and lines. Some of you guys know my preference for lines. I'm happy that some of these actually have lines. I often said architecture without lines is not architecture.
Fundamentally, they're these boxes and lines kind of things. All the analogies are always a little risky. Let's say, what do real building architects draw? They draw sketches. They don't draw the blueprints. I'm talking the famous guys, like Frank Gehry here. The famous guys, they sketch. Why do they sketch? Because they want to capture the essence, they're abstracting things away. They're looking at the big picture. You might think like, I could have drawn that. The short answer is, no, you could not have.
There's much more behind here. You can maybe copy here. There's much more behind this than it seems. That's the power of abstraction, the power of emphasis. They emphasize certain elements. They also incorporated the context. This thing is a little bit horizontal, and that has a reason because this is the Guggenheim Museum in Bilbao, Spain. This is by the waterfront. If my Photoshop skills were a little bit better, I can probably get this to match up.
These are not ivory tower things that are detached from reality, but they actually make the core decision, the gestalt like we like to say, of the thing that is going to be built, and some of the key tradeoffs that need to be made. Think about it, there's many folks who can draw the blueprints. As an architect, give yourself the liberty to sketch to something that makes a certain emphasis that uses a certain lens. A sketch has a very specific lens to it. That's our topic. That is most nicely done with a sketch. Architects draw pictures, but not necessarily boxes and lines. Architects can sketch.
Architects See More Dimension
One of my favorite maneuvers for architects is that we also see more dimensions, and that really changes discussions that people have. Remember IQ amplifier? You make everybody else a little bit smarter. I don't mean they were dumber before, but smarter in the way they look at the problem. The fancy word, I say this, you open up the problem and solution space, in a way, for them. That's how they get smarter at tackling the problem. Because you will have situations like this, two people look at a problem from one dimension, and they can argue until the cows come home.
One person will say, this is so cool. The other person is like, where do you live? It's like you have no idea, this is a rectangle. You say, no, this is circle/rectangle. If this is at the pub, it might be entertaining. If it's at the workplace, this isn't very productive. They will go back and forth. You will have these things. People say, we need to accelerate the delivery schedule. The other people say, but we need testing, we can't compromise the quality.
They want to schedule testing, schedule testing. They go back and forth. This is basically just a different flavor of circle versus rectangle. As an architect, you can put the third dimension on this. Speed versus quality is a perfect example. Why don't you automate your tests? Why don't you test earlier and incrementally? Those are the things that come from seeing more dimensions, so it's no longer left or right. Seeing more dimensions is a very powerful maneuver to amplify the collective IQ.
I do this quite a lot. We talk about lock-in, switching cost. It's not my favorite topic, because it's every cloud vendor's unfavorite topic, so I always like to tackle the special thing. We talked about, how difficult is it to move workloads from one cloud to another? Generally, people have this idea of a single dimension. They say, if I want to use serverless and all the great cloud stuff and all the managed services, that's really great from an architecture perspective, but it's really bad from a lock-in perspective.
As long as you think about this on one dimension, there is never a happy place. People argue, should I be here? Can I use this? Basically, as long as it's left or right, and you have some evils on the left and some evils on the right, you have never a happy place. One of the key maneuvers, I do this, think about this in more dimensions. Again, there's multiple lenses of more dimensions here to make it more interesting. The one is lock-in or switching cost is a liability. It's like a possible future cost that you carry. If I use a certain platform, and switching to the other side costs me 100,000 pounds to do that, and maybe I have a 5% chance that I need to do this, you carry a 5000-pound liability. That's math. At the same time, you might get benefit. You get serverless architectures.
You get managed services, less operational toil, so you have a benefit against this. You can talk about two dimensions. How much do I get out of having the switching cost and how high is the switching cost? Of course, ideal is, if I get all the utility but low switching cost, but I might also consider that this is actually not a bad tradeoff. If I carry this 5000-pound liability, I gain much more than 5000 pounds in the short term. The nice thing about these decision models, and this is one of my fundamentals when I talk with customers, is I rarely tell people what to do. Oddly, that is initially unpopular, because people come to you to get an answer. Says, give me the answer. I'm like, how can I give you an answer? Because I don't know your situation as well, your constraints, what you really want to do.
It is your company, not mine. Many people like to do this, "Just do x, y, z." I'm like, life is not that simple, or at least the life of an IT architect is not that simple. What I do instead is give people a model to think about the problem in a better way, IQ booster here. Then you decide based on this model. That is something I much more like to do, because at the end of the day, they know better, but I can give them a better model to come to a better decision. Rather than just giving them a quick and easy answer. Our world is too complicated for quick and easy answer. That's why these models are very nice.
I have this in one of my other books, "Cloud Strategy," where, again, I play this dimension maneuver, where I say the switching cost story is not a single thing. People say, I'm locked in. That sounds like binary, like the lock is closed or it's open. It sounds like it's a single thing. Both are wrong. It's not binary. It's a cost. That cost can be higher or lower. It has many different dimensions. Changing anything has a cost, not just a vendor, also changing a product, changing a version has a cost.
My favorite example, from AWS perspective, my favorite/least favorite feature is extended version support on EKS, so the managed Kubernetes. We now recently launched that you can have older versions. Why as an architect do I not like that feature? Because you should be on the latest version. Why do you need to be running on an old version? You don't get the features. You might have other issues. Why are you not on the latest version? The answer is very easy, version upgrades also have a switching cost. Now you're working on a managed open source project. There's no vendor lock-in.
This is managed for you. Still going from one version to another isn't free, obviously, because a lot of customers use this. There you have a switching cost. Breaking this down makes you think about these things very differently. Some people will come to you, it's like, don't worry about switching cost. That's of course BS. You should think about it, but you should think about it in a multi-dimensional model, so that your problem and solution space is much more nuanced. Maybe I want to make my version upgrades cheaper, so that I can be on the latest version. Maybe that's in the near term more important for me, than needing to go from vendor A to B, or product or architecture A to B. Again, nobody says what you should be doing, but you get a better view on what your options are.
Here's this left versus right, this one-dimensional thinking. This is a little bit out of the penthouse, like IT strategy, where every CIO, every IT leader I talk to pretty much lives in this, I call it between a rock and a hard place. They live on this scale of unhappiness. Where on the one hand side, they're supposed to harmonize, get complexity down, get cost down. That's why as a developer, when you say, I want to have database X, some evil person that's usually called enterprise architect comes and says, no, in our environment, we don't use database x, we standardize on database y.
You're like, why is that? That's harmonization, complexity reduction, cost reduction, economies of scale, because maybe when the y gives us a discount, if you only use vendor y database, but you like vendor x database better, the whole thing isn't very happy. Then the business comes and say, competitive field, fast moving, agility, innovation, we need to drive and go to market. The problem is, I can do innovation with database x, but you just told me I can't have. Again, if this is one dimension, if this is a linear scale, there is no happy place. People can argue about where they want to be, but they're never happy.
The thing you can do as an architect, if you see more dimensions, you can bust through this stuff. In this case, I've actually written a whole book. In this case, it was a topic where really a whole book and a whole industry in a way came out of, platforms do this. Platforms harmonize and standardize, but don't stifle innovation, they actually boost innovation. We know this, not just from IT, I mentioned car metaphors. Car manufacturers in the '70s started using a platform model. They started realizing that all the heavy duty engineering they're doing they should put that in a common car platform, Volkswagen, many others did this.
Then they can put different models on top. The interesting thing is, by standardizing on the platform, they didn't reduce the variety and the innovation, they increased the innovation. They made many more models. They could have more diversity by standardizing. That thought relies on seeing this as not a single dimension. BMW is a great example. Like in the '70s, they used to have three car models, 3, 5, 7 series, and now I didn't count it's like 25 or 30 models. There's a 1, 2, 3, 4, 5, 6, 7, 8. Then there's an X for everything, and then the electrics, and the performance models, the minis.
That's BMW. They have like 30 models, that would be impossible without busting through this one-dimensional thinking. They wouldn't be able to have that product diversity. If people can do that for cars that are made from metal and put together, we can definitely also do that for software. It should be easier for us to solve that than for them. This idea of turning one dimension into two, and having the combination actually applies to many things. I mentioned quality and speed. Automated testing gives this to us. Platforms give us standardization harmonization but still innovation.
Customization and cost. Say you have an e-commerce marketplace, with AI you can give every customer a customized experience. It doesn't cost you hardly anything. I work on serverless. It used to be, you make a prototype, and then you throw it away. In serverless your prototype will actually scale to like 1000 TPS. Openness and monetization, how can you make money if something is shared? Look at all the open source IPOs. There are many ways that these things that were perceived you can only have one or the other, you can have both, and that is a very powerful architect maneuver. That comes from seeing that this is not one dimension, left or right, that these are different dimensions.
Architects Sell Options
Next one, I mentioned metaphors. Options is one of those metaphors. We used to work in insurance. It's a metaphor that comes out of the financial space. I want to explain what I mean by that, because I think it's a very powerful way to understand how, as an architect, you make decisions. Let's stay with this on an innovation versus standardization topic for a little bit, the platform story. Let's say here you want to have some diversity. Harmonization and diversity are at the opposite ends, some people think. We don't think so. Here's some diversity.
You have some developers who prefer the stuff on the left and some other developers who prefer the stuff on the right. You can make all sorts of jokes about who is here, who is there. The idea is, how do you get this to work? We're IT architects, software architects, the answer is very easy. You make standard APIs, interfaces, you connect them with protocols like OAuth, JSON. That's how you get over this problem. Microservices architecture, very clear. We do this all the time. What is the maneuver you have done here? The maneuver you have done, you place some harmonization.
The interfaces are common, you lock those down. You gave up some options. This is not protobuf, or maybe you pick protobuf. You pick an authorization protocol, you pick a transport, you pick a data representation. You lock some things down in order to gain other options. You have more options now. You can code in Java, C#, Python, whatever you have. This is a very interesting maneuver. It goes back to the platforms. You standardize some things and give up the options there, so you don't have all possible protocols. Because you do that, you enable diversity somewhere else. That's like buying and selling options. You give away some but you gain other options. These options are valuable. The option to use another language is valuable. The option to move your workload to another provider is also valuable. Having the option to scale up your system, the option to add hardware capacity, all these options are highly valuable. That's been mathematically proven.
The quiz comes later. One thing we learn here, for people in the financial world, this is as obvious as Kubernetes and Helm charts. Reflect a little bit when you talk about your IT mumbo jumbo, this is what they are seeing. Now you're feeling the pain from the other perspective. To them, this is totally obvious. This is options pricing. Black-Scholes, they got a Nobel Prize in Economics for it. A little bit more advanced. This basically shows that having an option is always valuable. Because if you can do something later on, if you can defer a decision, that has value. I just talked about capacity.
In the cloud, you have elastic infrastructure and scale-out architecture, so that buys you the option to add capacity later. That is a valuable option to have. Now there comes a very interesting insight, which derives immediately from this formula, is the little sigma over there, and that is the volatility. These options are more valuable the more unpredictable things are. Let's stick with this capacity management example. If I build something for five users, and it's always five users unless one calls in sick, and then it's four.
Do I need this scale-out elastic hardware thing? Probably not, because I just have one VM and life is good. If I build a mobile app, or launch an e-commerce store or something, I don't know if I have 100 users, 1000 users, or 100,000 users, then that option becomes very valuable. The more uncertainty there is, the more volatility there is, the more valuable these options become.
That's the power of using these metaphors, because now you're not just making the intellectual argument, it's actually mathematically proven. It's like right in there. Every financial person will tell you that that is true. That's the power of metaphor. If you tell people like architecture is like options, and you say, uncertainty increases the price of the options, they will say, bingo. I have that very experience in financial services. Other industries pick a different metaphor.
Something else, volatility: if architecture sells options, and the options are valuable the higher the level of uncertainty is. There's another approach that starts with A that we use frequently, which is also good at dealing with uncertainty, and that is agile. If you know everything and nothing ever changes, you don't need to be very agile. You write it down, you build it, you're done. Agile fuels off uncertainty, off change, off volatility, and so does architecture, we just realized. When anybody comes to you in the future, and says, "The architect, that's really nice, you're doing this thing.
I'm over here, I'm agile. I don't need so much of this." You can say, "Interesting you should say that, because I deal with uncertainty and so do you." Architecture and agility actually live in the same universe, they have the same benefit. Car metaphor, agile is the steering wheel and architecture is the gas pedal, the engine. Architecture makes sure you keep moving, and agile makes sure you're moving in the right direction. It's the perfect combination.
There's absolutely no contradiction here. Both live off uncertainty. If you know everything and nothing changes, you don't need a great architecture, because you get it to work somehow. Fine, you're done, and you don't need agile. Not the world we live in. That's why you actually need both. Very different view on agile and architecture. They're friends, not foe.
Architects Zoom In and Out
Zooming in and zooming out. Seeing things, ride the elevator, things from the top look a little bit different than from the bottom. It's not just a zoom on the camera, it's really our world looks very different at different levels. It's like a fractal world that we have. An understanding that it's very valuable to ride this elevator. An example I often give, like some years ago there was this statistic about, if you get x, y, z cloud provider certification, here's the salary you can command. Here's how much this thing is worth.
Then all the folks sort of at the zoomed in level in the engine room is like, I should get the certification of vendor x, because that pays the most, so I should run over there. If you go a few levels up, if you zoom out a little bit, you come to very different conclusions. If an IT leader looks at this and say, "This skill set is most expensive, that means it's hardest to get, that means that technology choice is probably not the one I want to make because I paint myself in a corner because I can't get the people. If I can get them, I need to pay them a lot more money." They come to opposite conclusions based on the same information. Not one is wrong, one is right, but you need to understand that thinking about these topics from different levels leads you to very different conclusions. That's the fractal nature. It's not like grouping three boxes into one box kind of thing. It is really, you see different things and you come to different conclusions.
Here are some boxes and some lines. This is also an exercise of zooming out. Too many people look at each box in a system individually. By zooming out, you look at the system as a whole. I can at least tell from my experience, 9 times out of 10, the problems are not in A, B, C, or D, the problems are always in between. Assumptions that somebody made dynamic behavior. One system overloads the other one, all this kind of stuff. The lines are actually a lot more cause of trouble than the boxes, and that you get by zooming out.
Also, by zooming out, you realize that how a system is put together defines the essential properties. Do you think the left and the right has different characteristics? It was made from the same components, just wired together a little differently. The answer is, of course, they have almost exactly the opposite characteristics. The left-hand side, layering, we already learned, easy to take one out and replace it with another clean system structure but maybe higher latency, maybe brittle.
If C goes out, B no longer talks to D. The right-hand side is the exact opposite, shorter paths, shorter latency, more resilience, but harder to make a change. Interestingly, you have the same pieces put together differently, and you get the exact opposite characteristics. That's part of zooming out, seeing this thing not as a bill of materials. I often say is like, the menu when you go to the restaurant, it doesn't say tomato, cheese, and wheat, it says pizza. It calls you what that thing as a totality is.
Think about the system as a whole, and how the system as a whole behaves, not just A, B, C, D. Your job as an architect is not to manage a bill of materials, your job as an architect is to understand how all the pieces come together. I often say that you're the chef, not the guy or the girl getting the groceries. You're not the one with a shopping list, you're the chef. You do the cooking. You put these things together, because that gives it the important characteristics. You do that by zooming out, by seeing things in its entirety.
This is a classic example of seeing things zoomed in versus seeing things zoomed out. You can optimize globally. You talk about integration, you can look about how teams spend. Why is Dev and Ops being separate, so poor? Each team is actually quite happy because developers only need to build software, and operations does only operations. Locally, it seems fine, but one level zoomed out, it's horrible, because you have this whole throwing over the wall, slow feedback cycles.
These things that look good in the microcosm, don't look good as soon as you zoom one level out. Remember our elevator, with the illusion in the middle layer. Each layer is happy, but the whole picture is not happy. That's what the power of zooming in and zooming out is, to see the overall structure and see the issues that derive from them. That leads us to another architect insight, local optimization is natural. Each team will do a good job at what it's responsible for because they can control that, they can measure that, they will optimize that. The sum of local optima is rarely or never a global optimum. As an architect, you need to have this ability to zoom in and zoom out and see locally, but also see globally.
Architects Make Better Decisions with Models
The world we're in is not simple. There's a lot of complexity. I always remind people, the kind of applications we can build today, it's disturbed, event driven, asynchronous, scale-out, self-healing, autoscaling. We can build pretty amazing stuff, but it isn't exactly simple. There's a lot of complexity. The best weapon you have against the complexity is models. I hinted at this with the sketches. I said a sketch is like a model. Models are very powerful, because they shape your thinking. It's a graph I borrowed Dave Farley, he found this somewhere.
A long time in history, some folks said the earth must be in the center of everything, so the earth should be in the center of the universe, because obviously we are there, we're very important. It's called the geocentric, maybe self-centric should be another word. It's like, we believe we're in the center of everything. If you believe in that model, the planets move in pretty strange patterns, and make these rapid turns and go back and forth. The sun is still ok, but all the other planets, they're completely messed up. It's like, how can this be? The question here is not figuring out how the planets can make these sharp turns, the question is, are you using the right model for your thinking? It turns out, the sun is actually in the center of our solar system, that's why it's called solar system.
That model now clears up your thinking. It's like, yes, totally, they go around the sun. They're ellipses not circles. It's an abstraction. Suddenly, your world makes total sense. What we often do as architects, where we fail, we try to explain things in our model to people who have a different model. That always goes wrong. Then the conclusion is, they don't get it, they're not quite so smart. All these funny arguments come. The reason is, they use a different model. Unless you get the models to align, you have no argument.
I have many examples of this. Let's come back to our favorite, so our CI/CD, continuous delivery. If you believe speed is valuable, and you talk to a person who is very much cost driven, and sees the world in a static cost optimization, you can talk about speed all day long, they will not find any value. It might go opposite, because when you say fast, they might believe, error prone, sloppy, quick and dirty. If you're quick, you're also dirty. If that is their mental model, and you say, we can release 100 times a day. They're like, that's like worse than now. You're all excited, and for them, this goes exactly the opposite direction.
That's what happens if you have different mental models. It's very important to get the models to align, and only then can you make your argument. Let's pick this example. If you can articulate cost of delay, for example, that if it takes us 6 months to put software in production, how much development effort we do? This can cost us millions that we haven't released. Then you've translated time into money.
Then you start transcending these mental models. Most of the time when people don't get what you're talking about is because they have a different model, and repeating your stuff five times over will not help. You need to understand the model they use and either express your things, make a translation, or convince them to use a different model.
There are many nice quotes about models. One, that people use a lot, is, all models are wrong, because they're not reality, but some are useful. George Box, clever gentleman. Not many people read the second part of that quote, where he also said that the simple and evocative models, those are the good ones, because they have the most abstraction. Our architecture diagrams, they are models. We like to draw these pictures with many boxes, these big tapestries, our database schema, our system architecture, those are actually not the most powerful models, because they don't abstract away so much.
The good models are simple. This is a common fallacy. I see people say, this is too simple. It's like, no, a good model is actually simple because it abstracts the most away and brings you clarity. Then you have, Data and Reality, a fairly old book, where people say, the highways are not painted red. The last time I went on a hike, I couldn't find the topographical lines. These are models. They are abstractions. When somebody says, but this model isn't reality. It's like, it isn't supposed to be, it's supposed to be a model. It clarifies our thinking. It makes us smarter.
It allows us to make better decisions. It raises our IQ. These are not good models. Too many times when we draw an IT model, we try to draw reality. Every system should be on there. That seems nice, but it's not the most powerful model. The simpler models are more powerful.
How do you make a simpler model? There's a little bit of a catch here. Here we made this easy because we use a system we all know well, it's called Planet Earth. The system here is Planet Earth, and here's four different models of Planet Earth. Which one is the best model? Trick question. They're all good, it depends on the question that you're trying to answer. A model has only value if it helps you to answer a question. Otherwise, it's artwork that is nice, but not an architect's work. The question here might be, I want to go for a hike, or I want to build a ski resort, or I don't want to build my house outside a flood zone, topographical map. Political map, elections. Driving, shortest distance between A and B. This one is a population density map.
That's great for folks who build distribution centers, or railroads, or transport networks. Very different questions, very different maps. When somebody says, show me your architecture, or draw me your architecture, which is obviously a model of the real architecture because the architecture isn't a picture, it's a valid question to say, what question are you looking to answer? If you're asking me to draw a model of my architecture, it should answer a question. It's valid for you to ask, which question do you have in mind, because I have a different architecture model, a different lens to show you, depending on the question that you have? No tapestries, models should abstract. Some people say, we can't model this, it's because it's too uncertain. That's exactly the opposite. The more uncertainty you have, the more actually the models help you. Yes, without a question, you cannot pick the right model.
Architects See Shades of Gray
We come to the last one here, shades of gray. Our machines are binary, our world of architecture is not binary. It's all tradeoffs. I posted about this. I'm on LinkedIn a lot. One of my most popular post here says, you spot the poor architects by speaking in extreme, "Everything must be in a container. No, everything should be on this technology. Always do serverless. Always loosely coupled. Everything must be event driven." These always, never kind of people, those are not the good architects. It's not as easy.
You don't need to memorize and regurgitate one buzzword, that doesn't make you an architect. You need to understand the tradeoffs and the sliding scale that you have. Again, I use this in my talk about lock-in and switching cost, where I say, really, this is not on or off. It's not like the lock opens and closes. This is a sliding scale. How much is this liability you carry: your switching cost times the likelihood that you have to switch? How much do you invest now to bring this down? What is the sum of the two? It's the total cost.
Somewhere on the spectrum here, it's like being naive, risky business, doing nothing. Here is being over-insured. I invest 100,000 pounds to reduce my 5000-pound liability to a 2000-pound liability. In the middle is the sweet spot. This is a range. Money makes good ranges, but it's not the only range. This is a range that you can use. Getting out of this, I must be here because my switching cost must be lows. Getting into a range allows you to have a much better discussion. A little bit like the dimensions. In this case, you get out of the binary, it must be on or off. You get into, this is a sliding scale, so your solution space expands. That, again, raises the collective IQ.
See more presentations with transcripts
