Transcript
Gregor Hohpe: Being an architect can be challenging. One of the challenges we have is explaining to people what we do. The default approach would be, as an architect, I do architecture. Then you’re stuck with explaining architecture. Then you can pull on, “I make all the difficult-to-reverse and important decisions. It’s about the components and their relationship”. Quickly, you see people’s eyes glaze over. Then the other fallback would be to look at your business card. I don’t find that very useful because some of the best architects I know don’t actually have the title on the business card. There’s also a fair number of folks running around who do have the title on the business card, but I might not consider them the greatest architects I’ve ever met. That doesn’t work either.
For me, it’s much more about defining being an architect as a way of thinking, a way of looking at the world, a way of working with other teams. I think that way we get maybe a better and hopefully also a different view on, what does it actually mean to be an architect? What does it mean to think like an architect? To do away with the biggest weird stereotype that people have, it’s like, architects are the ones who make all these really important decisions. Somehow implying that they’re smarter, or wiser, or older, or more experienced, or something rather than the other people. I always find that a bit of a tall order. Because, A, how can we be so much smarter? B, shouldn’t the decisions be made by the people who are closer to the action? They come to me or they come to a chief architect of sorts, and say, please make the decision for us. I don’t think that actually leads to the best possible decision.
There’s one important thing that we can do, and that is help other teams come to better decisions, more informed decisions, and consider all the options, communicate and understand the ramifications of those decisions better. That is a way we make other people smarter. That is a very nice way to look at an architect. In a way, we’re like IQ boosters. We’re like an amplifier for other folks. That’s great, because we spread our knowledge or our way of working. We amplify our impact across the teams, who at the end are often closer to the action and the technical reality, and most of the time also have to live with the consequences of their decisions, which sometimes the architects don’t have. Making other people smarter, getting other folks to make better decisions is actually a great way of thinking about what an architect should do. Next time somebody asks you, what do you do as an architect? Say, I make everybody else smarter. They might think you’re a teacher, which is also good. You say, that’s what I do as an architect.
Architects Connect Levels
The next question is, how do you do this? I have six or seven items here that I have learned through my experience that work very well in making other people smarter. The first one is about connecting levels. We mentioned the architect elevator. That’s a little bit my spiel that I learned from going to Silicon Valley to a very large insurance company and understood that they work very differently. Funnily, they don’t work differently in the way that they think about each other. There’s a lot of misconceptions also. I realized that large organizations have many more levels. There’s much more disconnect. What I learned there, and I had the glorious title of chief architect, so it would have been easy to say, that’s the most valuable person.
The counterargument would easily be, if you’re the so-called chief architect and all you do is draw pictures and they have no impact on reality, then you’re actually not that valuable. You might be entertaining management and keeping them from interfering with actual work, which might be useful. It has some value, but by and large, that’s not what we’re hoping for. Vice versa, if you’re writing amazing code, but it doesn’t connect to the business strategy, it doesn’t line up with where we want to go, it doesn’t produce the value, then by definition that’s also a less valuable role. The second major statement I want to share with you guys is that it’s not about the title you have or the level that you’re at, it is really about how many different levels you can span. Can you dive into the technology when need be, like operational issues, helping debug things, help people write unit tests, help people refactor? Sometimes write code, make the system more scalable, whatever it might be.
My last role was I worked on serverless programming models at AWS. TypeScript type systems use type systems to better represent the runtime behavior of cloud services. That’s very engine room. That’s very hands-on. Then you need to also have the ability and pop back up and see this in context. Is this the most important thing that we should be doing? How does it relate to other efforts? Does it depend on other things? The ability to ride the elevator up and down and see things from different perspectives and communicate with people at different levels, that’s where the real value comes in. That’s easily explained. The metaphor I use for that is, if you look at an organization, the two ends of an organization, if the tunnels don’t meet, drilling faster doesn’t help.
As architects, we’re not there to make people drill faster. That’s like the project managers or micromanagers or project owners do that. Sometimes they’re like, move faster. No, as architects, we are there to make sure the tunnels actually meet. Because if there’s a disconnect there, everything else has no value. This is a very valuable activity because in reality, this risk is quite omnipresent. Most organizations have this to some extent where the strategy is set somewhere and then somewhere down, somebody writes some Helm charts. In between is relatively what I call loosely coupled. There’s like a disconnect and the disconnect is sometimes middle management.
Funnily, the respective layers can be quite happy with it, because management knows that we’re using GenAI and blockchain and Kubernetes, so they think IT is perfect. It’s like it checks all the boxes because they don’t really know. The developers know that nobody else knows really what they do, so they enjoy the freedom. Respectively, they’re happy, but this is not a great way to run an organization. As I said, this is an unhappy case of loose coupling. We want these things a bit more tightly connected, and that is exactly what the architect elevator does. If this is broken, basically nothing else will help you. That is the idea of the Architect Elevator, seeing things from different levels, being able to communicate and understand things from different levels, seeing things differently at different levels. That’s the basis.
Architects Use Metaphors
In order to communicate with a lot of different audiences isn’t easy. The basis that we have is highly technical. I just said, reflecting the runtime behavior of serverless services in a type system. How do you explain to a CEO how valuable or not valuable that is? That’s equally important and equally challenging as part of riding the architect elevator. One of the best tools you have is using metaphors. Metaphors are ways of explaining something, drawing onto a different domain. Ideally, the domain that the company leadership works in, like the business domain. If you work in manufacturing, you might use metaphors from supply chains. People will know queuing and flow optimization and lean manufacturing very well, so you can draw on a lot of knowledge.
If it’s a financial services company, you can draw on financial market analogies. We’ll see some of those later. If you can translate something into the domain that people come from, it’s much easier for them to understand. I’m a bit famous for using metaphors, and mostly I use car metaphors. Just happens to be I’m a bit of a car buff. You can see this is all outdated. This is all internal combustion engine, old architecture type of stuff. You can make a lot of points about it. I use the gas pedal as a metaphor for good or bad abstractions. Calling something a gas pedal is not good because electric cars, EVs, don’t have gas. Hopefully not. Using the word accelerator is a better abstraction. You can tell people easily that naming matters, naming tells you how you think about certain things. I use cars as metaphors for disruptions. Like how Japanese automakers came in, I use it to explain platforms.
Sometimes I make fun of some cloud services being like halo products. They’re these shiny cars that everybody wants, but in the end, actually, nobody buys. There are many ways you can make things easy to understand by using metaphors. This is my personal shtick. I use a lot of cars. If the cars don’t use it, I use the train wheels. I’d say, if you want to transform your organization, if you want to move faster, don’t burst the boiler. Don’t just put more pressure on people to deliver faster because that’ll give you a burst boiler. What you need to do is change from steam to an electric train. People immediately get the idea that this is not a try a little bit harder, push a little bit harder exercise, but it’s a work completely different exercise.
If you’re interested in platforms and guardrails, you should really have a look at train wheels. Train wheels don’t stay on track because of the guardrails, the flanges. They stay on track because they’re self-centering. You learn something about platforms and guardrails. I always say where there’s guardrails, you also need to have mechanisms that people don’t hit the guardrails. There’s a car metaphor for this. I always say where there’s guardrails, you need lane assist because nobody likes hitting the guardrail. Those are the metaphors you can use to immediately get people think with you.
This isn’t about just making it easier to understand. That’s the first half of it. The most important part is if the metaphor matches, people can think along with you. They can think in the metaphor and come to conclusions that sometimes you did not come to. You can think in parallel. That is not only a nice thing to do, it’s also a better utilization of the intellectual, the human intelligence resources you have in your organization. It’s not just rhetoric. It’s not just nice words. It is really a tool for folks to better understand the tradeoffs. People can say, the train wheels, but if a tight turn comes, does this still work, or do I still need guardrails if I have lane assist? Why do we still have guardrails? Those kinds of discussions you can have and you’re thinking together and you’re in a whole different dialogue.
The warning I always give to technical folks, if you go to management and you use all the great technical terms that we like so much. It’s containers and Kubernetes and Helm charts and observability and serverless and loose coupling, all these kinds of things. Then you say, I need 10 developers and a million dollars. What management really hears is, trust me. Because they didn’t really follow all the other parts. They may actually trust you, but in the end, you want the stronger foundation. You want more support than just, trust me. You want people to understand the decisions you’re making, the tradeoffs you’re making. You want them to think along with you. That way, you get much more support and buy-in from the leadership.
Architects See More Than Other People
That’s metaphors. That gets you to connect at different levels. First, you need to have something to talk about. One of my common sayings is that, as architects, we tend to see a little bit more than other people. I always use the example, we draw four boxes and three lines. A lot of people see four boxes and three lines. We might see layering. We might see loose coupling. We might see replaceability. We might see brittleness. If one of those four things fails, the other three cannot communicate. We see a lot of things when we look at a simple picture. That is extremely valuable. There’s a certain flavor of this, and that is seeing more dimensions in something. This is like this little sketch. People look at a problem from their point of view, and you can’t blame them. If you look straight on, this thing looks like a circle.
From the other side, it looks like a rectangle. They can debate until the cows come home. They’re like, “What are you talking about? It’s like rectangle, which planet do you live on? This is obviously a circle”. They go back and forth, and they will never come to a fruitful conclusion.
One of the most valuable architect maneuvers you can do is you can show them that they’re looking at the same thing, that there’s more dimensions to it. I have some concrete examples. One of my favorite topics at AWS was always lock-in. It was my favorite topic because it’s every vendor’s least favorite topic. Vendors don’t like to talk about lock-in. My proudest achievement at AWS was giving a talk with lock-in in the title at re:Invent. That was not easy to do because that’s not something that marketing normally likes to speak about, but customers do, so we should speak about it. The first thing you do, when you talk about lock-in, is you first realize it’s not binary. It’s not like the cell is closed or open. It’s not like going to jail. It is shades of gray. It’s really about switching cost. If I want to make a switch, and this can be a cloud provider or a different product or a SaaS service, this can be anything.
If I make a switch, it’s not free. How much switching cost do I have? Then the other dimension is, how much utility do I get? I broke the problem down into two dimensions, and now you can have a very different discussion. It’s no longer about we must avoid lock-in at all cost. No, now it’s an ROI discussion. How much switching cost am I willing to accept in return for faster delivery, better features, more operational resilience, and I can make an informed architecture decision? Showing more dimensions is the best way to get out of FUD. People have just this fear, uncertainty, and doubt arguments because they see things as one or the other. We’re locked in, that’s bad, so we should be not locked in. What you do is you show them more dimensions. I call this, you expand the solution space. You give people a bigger playing field along which to maneuver, and that makes them smarter because then they can come to a better answer themselves. You might have accepted lock-in, but yes, some switching cost is ok because I’m getting a return.
Talking about metaphors. The best metaphor I’ve heard is from an old friend of mine, Adrian Cockcroft, who would go to audiences and say, who here is worried about lock-in? All the hands go up, of course. Then he said, who here is married? Everybody looks at their hand and like, yes. No advice on that regard to be had today, but think about it. There’s some accepted lock-in that has good utility. You can play this further. This switching cost, so now it’s cost versus benefit. That’s the first multidimensional maneuver, but the switching cost doesn’t have a single dimension either. This is straight out of cloud strategy. You normally think about switching vendors, but switching products or even switching versions of products or switching architectures also is not free. All of this has a switching cost. My favorite example is I always joke that my least favorite service that AWS released was extended version support on EKS, the Managed Kubernetes Runtime. Why do you need to support old versions? Wouldn’t everybody always want to be on the latest version? The simple answer is that carries a cost.
If you have been with clients at the time, they have 200 clusters, are they all going to upgrade all the time with every release? No, because they have better things to do. They have a switching cost of a version of an open-source product. They’re locked into one version because the switching cost was so high that they did not switch. That doesn’t mean open source is bad. It doesn’t mean Kubernetes is bad. That means by seeing more dimensions, we look at the world differently. It’s not like open source makes all these problems go away. Even upgrading versions can be a form of lock-in because it has a non-zero switching cost. Last one I always like to highlight, mental lock-in is the one that really sneaks up on you.
The way I always said this, if a vendor gets you to think only in their services and their vocabulary, you’ve become mentally locked in. You look at the world from the same lens that the vendor does, and that is great for working with one product. If you look at other products, they will always seem a little bit odd or not as well-fitting. That is mental lock-in. That’s the one, actually, that I would be most worried about. As an architect, you need to have a neutral view of things. You need to have your own opinion. Don’t get mentally locked in into certain frameworks that people feed you. I always say, make sure the framework works for you, not the other way around. Maintain your independent thought and your independent thinking.
This is stuff I’m still working on. This is a very simple version where some of the maneuvers that I use most when we are trying to make architectural decisions, when we are looking to make people smarter is, break one problem down into smaller pieces. We need to decide on integration software. What does that mean? API management is separate from an ESB, is separate from traditional. Is MQ in the same box as Kafka because they’re both asynchronous, or is this sacrilege because one is supposed to be event-driven and the other one is supposed to be messaging? What’s the granularity? How big are the boxes? How many decisions do we get to make? Very powerful maneuver. I mentioned the dimensionality. People see left or right. People see, I can be fast or I can have good quality, quick and dirty, is these harmless slogans that represent a mindset of linearity, left or right.
I always find that very depressing because if your world is only left or right, you’ll never be happy. Either you’re slow or you have crappy software or a little bit of both. It’s not a great place to be in. If you show people that speed and quality can both be had, shift left, automated testing, source code analysis, rapid feedback, all the things we know, CI/CD, you can have both. You really change people’s worldview. You not only make them smarter, but you actually also make them happier. These are very powerful tools to change the way of thinking.
The biggest problem I see, and I alluded to this a little bit earlier, is where people have all the buzzwords. Here’s all the things we want, and then it gets very thin. There’s a little bit of hand-waving, a little bit of FUD, a little bit of FOMO. Everybody else is doing it. Why aren’t we? Then comes, I need this much money, and I need this much headcount. This is what drives executives nuts. This is the trust me. “All these great things, they all sound good. I don’t know exactly how we got from here to there, but I’m asking you for all these resources and all this money”. This is not a great way to get buy-in, but I see it all the time. I call this the hourglass shape. What works much better? I call this the architect boomerang. It’s like, take a brief step back, re-evaluate what we’re really after.
Too often we presuppose the solution before we’ve really understood the problem. There’s a smart Albert Einstein quote, if I had an hour to solve a problem, I would spend 50 minutes understanding the problem. Something along these lines, take a brief step back. What are we really after? Everything must be loosely coupled. Why does it have to be loosely coupled? Because we need to make rapid design changes. That is very good. That can be achieved with other ways. Automated deployments, automated tests also drive rapid change.
Suddenly, the playing field widens. You’re no longer looking at the solution before you understand the real objective. This is not an academic exercise. You back up briefly, that’s why it’s the boomerang, because it comes back with more force. In the end, you have a better view of what you’re after. You evaluated all the right options, and you understand why you chose a certain option, and the tradeoffs come with it. No solution is ever perfect. You can also communicate, we chose option B because we like those characteristics, but also option B has some downsides which we are either willing to accept or we do something else to mitigate, to minimize those downsides. I find this boomerang a very helpful technique. You do this quickly, other people will say you’re just making this more complicated. No, you back up in order to go forward with a better understanding and better decision discipline.
The one, and this plays both to the metaphors as well as making people smarter with decision models and seeing more dimensions, a lot of my ways of explaining these things come from the real world. People often say, to be a good photographer or to be a good painter, you first need to be a better seer. You need to see things from a different perspective. When you look at something, you take things away that other people may not do. I find that to be very suitable for architects. When you’re standing in line somewhere, and you don’t like standing in line, what occurs to me, I start thinking about asynchronous messaging systems and in-order delivery. Every architect says, my messages must be delivered in order. When I stand at the supermarket and the person in front is taking forever, the last thing I want is in-order delivery. I want to jump the line. A, you have a metaphor, but also, you’re thinking about systems architecture. In-order delivery is the ultimate throughput killer.
If one message takes a long time, everything else is stuck. I wrote an article many years ago about how Starbucks doesn’t use two-phase commit because they’re interested in throughput, they’re optimized for the happy path, and they’re willing to throw your drink away if you can’t pay or they made the wrong drink. I feel that you can learn a lot about big system architecture by looking at the real world. The real world is asynchronous, error-prone, loosely coupled, sometimes poorly coordinated, full of error scenarios. You can learn a lot of things about building complex systems just by walking around ordering a coffee or standing in line at the registration.
Architects Sell Options
Now I want to up the bar a little bit. I want to explain what we as architects do from a very different perspective. This is a metaphor because I used to work in financial services, insurance, and I was trying to explain what we do as architects. The explanation I made is that we are trading options. Options are points of flexibility. We might want the option to use different programming languages. We might like the option to move to another cloud. We might like the option to add or remove capacity, elastic scaling, elastic infrastructure. Those are options. These are things we can have but we don’t need to if we don’t exercise on them. The maneuver that we pull is we give up some options. We lock some things down.
For example, if I want different programming languages in my projects, you guys are architects, you guys all know the answer. What you do is you make microservices, you make common APIs, you make a common protocol, whether it’s HTTPS, OAuth, JSON, those kinds of things. You gave up some options. You gave up the option of having 20 different protocols and you gave up maybe a monolithic architecture option. In return, you gain more choice in your programming language. This is a fun maneuver because generally people think that if you standardize something, you take choice away. Here you standardize something but in return you get more choice. You achieve more innovation or more choice by harmonizing, which is the opposite of what people normally think. Not only do we use a metaphor here, we also move things from one dimension to two, because people always think, I either standardize or I have flexibility as one or the other. Here it’s like, we standardize to get more flexibility, two dimensions.
You can see how these different strategies, these different tactics come together. If you’re explaining this to financial services folks, there’s a very easy way to make that intuitive to them. That looks like this. I always say this is a great test because this is the same as us showing a complicated Kubernetes platform thing with all different forms of automation to management. What they see is the same as what we see when we look at this. To them, this is trivially obvious. This is the Black-Scholes formula of options pricing. They will all understand this. They got a Nobel Prize in economics for this. That is the metaphor at work. You’re using something, I’m selling options.
When you use that metaphor, every financial services person will know that options have value because options defer decisions into the future. You have the option to do something later on, but you don’t have to. You haven’t made the decision. You defer the decision. Besides listening to your architect, the other easiest way to become smarter is travel into the future. Just like, wait a year. In a year, you’re smarter. Most decisions, how much capacity do you need? After launch, you very much know, or maybe during performance testing, you know how much capacity you need. You got smarter by traveling time. Time travel is a little bit tougher. The best thing we do is having options. I have the option to add capacity when I need to. My sizing decision is deferred until I know how much capacity I actually need. I can make a better decision. I am smart about it.
Here comes the kicker. I use this metaphor with the financial services folks. I said, I like this notion, this option thing. Then they said, the value of options goes up with the level of volatility. This is the thinking along. I translated what I do into another domain, in this case financial services, and they’re thinking along in the metaphor because they know this stuff. They know that the more volatility you have, the more value the options have. Let’s say, if you architect are selling options, we live in a very volatile world, I should invest more in architecture. Home run. This is, we’re giving people a way to think along in their world, and come to conclusions back into your world. That is amazing. Intuitively, we can understand this. Let’s stay with our hardware sizing.
If I’m building an internal application for 50 users, is the option to add capacity later very valuable? Probably not, because there is very little uncertainty, very little volatility. I’m building a mobile app, might have 1000 users today, might have 100,000 users next week, the option is very valuable, so less I can predict, the more valuable is to defer the decision, so the more valuable the option. We can understand this, but in this case, the insight came from the business stakeholders using my metaphor and thinking along my metaphor, giving me new insights. That is the architect elevator home run. You can play this further. What did I just say? I said architecture selling options, options are more valuable the more uncertainty you have. The more uncertainty, the more architecture.
There’s another method that we commonly use that also thrives on uncertainty, but that’s often seen as at odds with architecture, and that is agile. You might have these conversations where somebody comes to you and says, dear architect, I really value what you do, but I’m agile, so thank you, no thank you. It’s like, yes, don’t need you. Now you have a completely different way of responding to that. Say, I like agile methods because agile methods help us deal with uncertainty. They say, yes, great, uncertainty. We do iterations and all these kinds of things. That’s how we deal with uncertainty. Now you can say, me too.
As an architect, I make sure that I can deal with high levels of uncertainty because if I know everything and everything is running and nothing ever changes, I don’t need a lot of architecture. Agile and architecture both thrive in the same environment. There’s absolutely no conflict here. If you want the car metaphor to also explain this, agile is the steering wheel and architecture is the gas pedal or the engine. It keeps you moving, and agile makes sure you’re moving in the right direction. There’s another car metaphor for this. What we learn is that both of them thrive on change and uncertainty. Here is the mathematical proof if anybody has any doubts about this, that both architecture and agility thrive on uncertainty. It was the sigma squared, in case you’re wondering.
Architects Make Better Decisions with Models
Next level down. Metaphors, great. Using analogies, discussing with people about uncertainty is great, but the biggest problem we face is complexity. We have to admit, the reason people here trust me when we explain things is because our stuff isn’t simple. We can do amazing things. These days, we build fully globally distributed applications, distributed transactional databases, autoscaling, auto-healing, multi-region, multi-AZ. We can build the coolest stuff, but we have to be honest to ourselves, it is not particularly simple. The stuff we do is complex. The best tool we have to tackle this complexity, metaphors work sometimes, but if you need to build more detail, that’s when we use models. Just like real architects make models, we also like models. Our models are slightly different though. Models are very powerful because we think in a certain model, we have a certain mental model, a certain mental view of the system.
Depending what that looks like, the world might look much simpler or much more complicated. This is like 600 years or so ago, when some people have the notion that obviously planet Earth should be in the center of the universe. If that model you believe, planets do some pretty cool things. They go around and then make these sharp U-turns. It’s like for an object the size of a planet, that’s pretty impressive. In the end, your world looks very complicated. If you understand that the sun is in the center of the solar system, suddenly everything falls into place. Using the wrong model for looking at something might make it seem very complicated, very difficult to reason about. The model is not just a cute picture, the model shows how you think about something. The famous quote is, all models are wrong. Yes, of course, these models are wrong on almost every possible category.
Planets are not little red dots that go in a single plane in a perfect circle, and the sun isn’t a little yellow dot and we’re not a little blue. This is completely wrong. I didn’t want to draw a one-to-one scale model of the solar system. The purpose is not to be accurate. The purpose is to sharpen our thinking, to make us collectively smarter. There are clever quotes about this, “All models are wrong”. The biggest fallacy I find architects do, or the biggest violation is, we always quote the title of something, we never read the second line. The Big Ball of Mud is a classic. I encourage everybody to actually read the Big Ball of Mud paper. There are so many gems in there, but everybody just says, big ball of mud is bad. Same thing here, all models are wrong.
The sentence you really need to read is the one that says, simple and evocative models, those are the ones that shine, not the overly complicated ones. Simple models, in a way, the ones that are more wrong, they’re more abstracted, those are actually more useful. One takeaway is, as architects, I should maybe make a section, architects are the ones who read the rest of the paper. You can also take that away as a learning.
Yes, this is exactly the fallacy. This is what we fall into, show me your architecture, and people roll out the scroll, like the banner, the poster on the wall, here’s our relational database schema. You’re like, this is really impressive, but it’s not making us a whole lot smarter, except maybe we understand why everything costs so much money, or takes so much time. Maybe it explains a little bit, but it doesn’t actually offer a lot of solutions. The simpler a model, the more power that it has to sharpen our thinking. The tapestries are impressive, but they’re the worst model to make us smarter. You can easily test this. The tapestries are a little bit like, “Go away, our stuff is very complicated, we understand it. You go back and sign the checks, and we go back and do relational database modeling”. That is the antithesis of the elevator. You want to invite people into the thinking, and the simple models do this much better.
This leads to a follow-on question, if a simple model is better, is there a single simple model that answers all questions? Likely not. You need different models. Models are not good or bad in the sense. Tapestries are mostly bad, but a simple model isn’t about being good or bad, it’s about suitable or not suitable. It’s about, does it make you smarter? Does it answer your question? Does it help you solve a problem? I always say, here’s four models of a system we know reasonably well. Planet Earth, last time I checked, everybody’s been there. Good. Here are four models.
First thing we realize, they’re all wrong. Last time I hiked, there wasn’t a contour line. We are in San Francisco, everything should be green outside. Not exactly the case. They’re all completely wrong, the highways are not orange. They help us answer questions, and they help us answer a surprising range of questions. Top left, topographical map. I want to go on a hike, and I don’t like steep hills. Great model. I want to build a ski resort, and I do want some black runs, also a great model. I want to build a house outside of the flood zone of that river, also a great model. I want to build a dam, and I’m trying to calculate how big the reservoir is, also a good model. These models can answer a lot of questions. In order to pick the right model, you first need to know which question you actually have. This is another interesting scenario that I see repeat all the time, and that is people say, show me your architecture. What they mean is, show me a model of the architecture, because the real architecture has bits and bytes, and CPU caches, and cables, and stuff.
You never see the real architecture, you only see a depiction. You only see a model. If somebody asks you, show me your architecture, a valid counter-question is, what question do you have, or, what problem are you looking to solve? What question are you looking to answer? Because depending on the question that you have, I might show you a different model. Next time somebody asks you for the architecture, you can ask back, what are you looking to answer? Because we’re not producing abstract modern art, we use models to help us make a decision. If you want to see my architecture, I suppose we’re looking to make a decision, so let me pick the model that best does that.
Last comment on this, sometimes we fall in love with complexity. When we use a good model, the answer often becomes obvious. It just falls out. It’s like in your face. Sometimes we have a tiny bit like introvertedly, inherently a little bit disappointed. I’m this big architect, this is such a complicated system. How can this be so simple? We feel a little bit like anticlimactic, but that’s exactly the right thing that can happen. If the answer becomes apparent, that means you used the right models, like the solar system. Suddenly it all makes sense. I’m a big fan of sketching and making custom models. One question I get, how about standard notations, UML, C4? Simon Brown, good friend of mine, they say, are those no good? It’s like, no, that’s not what we’re saying. We’re saying there’s two different ways of using model. The one is to sharpen your thinking and come to decisions and moderate. That’s where custom models and sketching is very powerful, because you have a certain problem you’re after.
Then there’s other models that are very good at communicating. A new developer joins your team: here is all the classes, here’s the structure of our code. You want to communicate decisions that already have been made. Standard notations are very good for that because everybody knows what the notation means. There’s two different use cases here. The one is using a tool to make a diagram. The other one is using diagram and sketching as a tool for you to come to decisions. As architects, we do much more of the latter. For us, it’s not about the drawing tool we use. It is about using drawing as a tool for us to moderate a discussion, to come to a decision, to make everybody a little bit smarter. Hence, one of my many clever slogans, I always say, architects don’t draw, we sketch. We make things on the fly to come to decisions, to make something that is very expressive.
Architects Become Stronger with Resistance
Last part I have, so I hopefully made everybody a little bit smarter. Now we have a room full of whippersnapper architects. You go and say, “Listen to me. I’m here to make everybody else smarter”. In large organizations, that’s not always how it works. There’s politics. There’s resistance. There’s long budget cycles. There’s consultants being brought in. There’s vendors trying to sell you one thing or the other. You hit the reality of all this stuff.
For closing, I want to give you a few hints how you can make some lemonade out of these organizational lemons that you will undoubtedly be served in your organization. Let’s again start with a failure mode, the thing that I see go wrong most of the time. That is, you’re talking to people and they don’t agree with you. We don’t like that. It’s like, we should release 100 times a day. They said, “No way”. It’s like, “Let me re-educate you. Let me explain this simpler about CI/CD and rapid releases, and Netflix does it, FOMO. Like they do it, we should do. If we don’t, we go out of business”. I call this buying a bigger shovel, because you got a bigger shovel to dig the deeper hole for you ever faster. This is not the way it goes. You can easily come across as condescending, narrow-minded, poor communicator. Like, let me smarten you up a little bit. This is not where you want to make people smarter. This is where you need to understand where they’re coming from.
This is another kind of boomerang, try to think about what must their beliefs and assumptions be to make their behavior rational. If somebody believes change is risk and they often have living proof, somebody put something in production, everybody stayed up all weekend to fix the thing. They have an inherent belief. They will never tell you this belief. They can’t say, show me all your beliefs. They’re like, what are you talking about? They will never articulate that. Sometimes these beliefs come out in little slogans like quick and dirty, never touch a running system. That gives you a hint.
By and large, you need to reverse engineer and you need to understand, if they don’t like frequent releases, there must be something in their head that makes them believe this is a bad idea. It’s not because they hate me, but they honestly think it’s a bad idea, so I can repeat this a million times, I’m not going to get anywhere. I need to understand and disassociate, for example, change from risk. I can explain why changes used to be risky and how I am making changes less risky. Once I have that conversation, then I can come again with more frequent releases, but not any sooner than that. Banging the head against the wall leads to nothing except headache. You need to back up and understand where people are coming from.
Another lemon that you likely get thrown is, you do the architect boomerang, and you said, “Let’s understand this a little bit better. Let’s look at the options. Let’s have some models”. People come, like, “This is too academic”. That was my favorite one in Germany, where everybody is a hair doctor or Frau Doktor. They’re all PhDs in insurance. Like, this is too academic. I’m like, that’s a funny argument. You guys all got here by getting PhDs. People who work in large organizations have seen this, “We just need to make a decision”. I have one recommendation. It’s a little bit pointed.
Next time somebody comes to you, “We just need to make a decision”. You say, “Aye sir/lady, perfect”. You take a coin out of your pocket and you say, “Heads or tails?” Then they look at you and they’re like, “Come on, heads or tail, easy. Like, you can’t do this”. I’m like, “Yes, I can”. Do you want the decision? Here it is. It’s a very clear decision. It’s a fair decision. It’s an easy to communicate decision. We just look at it. It’s the perfect decision. It doesn’t get any better. People are like, no. I’m like, exactly right. Maybe we should think a little bit. Yes, we do want to make a decision, but we want to make an informed decision. It’s a little bit pointed, but can work miracles.
The last one in the row is that what you find is the illusion of predictability. People say, “I don’t need all these options. I don’t need all this architecture. I have a perfect plan for everything”. I have this as a quote from my time in insurance. We always said, if reality didn’t match the plan, we blamed reality, because the plan was obviously perfect. You will find those people. The sad thing here is some of you guys surely studied logic, you can prove anything out of a false assumption. If you say, assume 1 equals 0, you can run any mathematical proof. This is what people are doing that you might be up against. They’re making a false based assumption, and then they’re incredibly logical and rational coming to all their conclusions. You cannot argue because all their conclusions are correct, except the starting point is wrong.
This is another boomerang. It will take time. You need to go back and understand the base assumption and change the base assumption. Say, the world is not that predictable. The levels of uncertainty are high. There’s the pandemics. I had an interesting conversation with folks who work in the pharmaceutical industry where they learned, it used to be all about scale. I make a certain medication. I have 10 years of research. The more of this medication I can sell, the more successful I am. That’s how the industry used to work until the pandemic.
Then, suddenly, it was about speed. Nobody cared about if you had the greatest thing 9 months or 12 months later, suddenly, it was all about economies of speed. How quickly can I get something? Those are interesting metaphors and stories, again, to help people, to show people that scale is good in a predictable world, but in an unpredictable world, speed counts for more. If I’m late to the game, I will never get the scale that makes my economics work, so I better be fast. Those are ways to go against this illusion of predictability.
Recap
Hopefully, I accomplished my metatask here. My metatask is to make you smarter so you can make other people smarter. It’s a double multiplier, so it’s squared. What we need to do is make sure the tunnels meet. Metaphors are not just a nice rhetoric tool. Metaphors help your audience think along and sometimes come to conclusions that you didn’t even come up with. Go through the world with the eyes wide open. Next time you get a coffee, you stand in line, think about distributed systems, selling options. Option to add capacity, option to migrate to another platform. Like Scholes’ formula, models are your best tool against the inherent complexity that we have. Yes, somebody wants a decision, you go and flip a coin. All the rest is some books and some ideas. I have a blog. Most of this content is on the website, architectelevator.com/book. I invite you to go have a look.
See more presentations with transcripts
