AWS re:Invent 2021 - The architect elevator: Connecting IT and the boardroom

(upbeat music) - This talk is about architects and architecture. You might wonder whether it's worth spending 45 minutes listening about roles and titles instead of hearing the latest product features. I certainly believe so because I am convinced that architects and architecture play a central role in the success of any complex IT project and especially cloud projects and if that isn't convincing enough, software and cloud architects are routinely ranked amongst the most sought after and highly compensated job roles.

So, let's look at what it means to be a successful architect. We talk a lot about modern applications and system architectures. In fact, most of re:Invent covers modern architectures, but I believe it's time to not just upgrade our architectures, we also need to upgrade our definition of what it means to be an architect and I can give you a hint, it's not about drawing YouMail diagrams or setting coding standards.

As always at Amazon, we like to work backwards. So we should think first about the values that the modern architect provides. So, which architect is most valuable?

I have carried the title of chief architect at a major financial services institution. Now did that make me the most valuable architect? Or perhaps it should be the architect who knows the most design patterns or the one who has the most certifications or the one who is hands-on with the development teams?

Well, I am convinced that in our modern world, the most valuable architects are not the ones who carry a specific title or have specific certifications. Instead, it's those who can connect the most levels of the organization. Large organizations, and many not so large ones, have many different layers and too often, they're disconnected.

So the organization is playing some sort of telephone game where the folks setting the business strategy up in the penthouse have little idea about the technology and vice versa. So, it's easy to see that that doesn't work terribly well. As an architect, if you're up in the penthouse, but all you do is, you know, spool at words like agile or cloud-native, your impact is actually very small.

I wouldn't even call that being an architect. I might call you a parrot if I want to be more poignant and I have met a lot of parrots in my career and I have to say, I prefer the ones who can fly. Likewise, if your world's foremost helm chart expert and have written dozens of Kubernetes operators, but you've never worked on a project that provided real business value, you're also not very valuable.

It's the connection that provides the most value. So, let me prove that to you with an architecture. Architects like diagrams, so here's an architecture diagram.

It shows one of the most fundamental architecture patterns, it's called layering. Layering divides the system into multiple parts, such that any part only depends on lower parts. I'm sure you've seen or drawn a diagram like this.

Now, why is this type of architecture so popular? Well, because it has a number of distinct advantages. Each layer does one thing, so it's a neat separation of concerns that abstracts away the details behind well-defined interfaces.

For example, a lower layer might deal with persistence, so that the upper layers don't depend on the type of data store that's being used. Also, dependencies flow nicely from top to bottom, meaning the application logic will depend on the persistence layer, but the persistence layer doesn't depend on the application. It can be reused for many other applications.

Now this also means that the data store can be replaced without impacting the remainder of the application. Well, that's pretty cool, you have to admit, right? Shouldn't we layer all applications then?

Well, not quite so fast. Architecture is in the business of trade-offs. So we should expect this architecture to also have downsides.

Dividing a system into layers can slow things down, perhaps, you know, the ideal database optimization that you wanna do isn't available in the shared layer beneath and connecting the layers also carries overhead, especially if you're using a text-based data format like JSON or perhaps XML and if you have many, many layers, managing all the layers can become tedious and lead to teams optimizing their own layer, but forgetting the end-to-end flow. Lastly, we have all seen how a simple change in the UI layer requires an update in the back and front-end layer, the application logic layer, the API layer, the persistence layer and in the data source schema. So such change propagation also slows you down.

Slowing down is not a good thing. Now you might wonder, what does this have to do with the value that architects bring to an organization? Well, actually quite a lot.

All the benefits and liabilities listed here don't just apply to technical systems, they also apply to organizations. Departments use well-defined interfaces, but are also prone to optimizing locally, right? They make you take a number and fill out endless forms or making a change requires you to coordinate across 20 different teams.

On the upshot, replaceability can be a major benefit. We call this outsourcing. So what we are realizing is that, architectural thinking applies equally well to technical and organizational systems and that means that you as technical architects understand a lot more about organizational design than you might've realized, and that's perfect because you can't be a successful architect these days without also influencing the organization and because that's such a critical insight, let's dig a little deeper.

What do the properties on the left and on the right have in common when compared with each other? As you will see, architects are expected to see things that not everybody else sees. So if you look carefully, you will find the properties on the left are largely structural.

We talk about interfaces and abstraction. In contrast, the downsides on the right, they are largely behavioral. We talk about latency and change propagation.

So that gives us, as architects, a hint as to when layering is beneficial and when it can become a hindrance. If the rate of change is slow or changes are local, then layering works well. When the rate of change increases or we're dealing with systemic changes, then it becomes a hindrance.

Now, large organizations are divided into many layers, right, from strategic planning to finance, accounting, payroll, manufacturing and facility services and that used to work well for them when the business environment was stable. These days, we talk a lot about digital disruption and transformation, the environment keeps changing faster and all those layers are now becoming a hindrance, but it's not easy to take layers out. That's why you need folks to connect the layers and architects are best suited to do that.

I call this riding the architect elevator. Instead of walking from floor to floor, you provide a fast connection between the levels and in fact, I've written a whole book that teaches you how to ride this architect elevator from the engine room to the penthouse and back and this describes how architects provide value at the different layers and manage to connect them. Starting from the top, architects need to make sure that business and IT strategy are connected.

If the two tunnels don't meet, nothing else will really help you. Second, you'll never be in an ideal state. Architects are also expected to affect change.

Complexity is your biggest enemy, you will need to minimize and tackle it. You do that by explaining and de-mystifying. Don't make things more complicated than they already are.

Now down in the engine room, there's a ton of technical topics like building resilient and scalable systems, agile delivery, automation, and much, much more, but there's hundreds of other sessions on those topics, so I'll only focus on the top half. There's one question though, that I often do get from aspiring architects when I show the idea of the architect elevator, and that is, will the folks up in the penthouse welcome me? The answer is very simple, yes, they will.

People who can translate the technical details into meaningful insights for the penthouse, without dumbing things down, are extremely rare and highly sought after. If anything, your biggest problem might be that the folks in the penthouse don't want to let you get back down into the engine room. So, let's have a look at how you can ride this architect elevator.

To me, architect is not something that's written on your business card. Rather, it's really a way of thinking. The first thing that comes to mind when we consider what architects do are diagrams.

We could draw diagrams and that's good because diagrams are abstractions and they're the best tools we have to manage the complexity we inherently face. Now, when we think about the diagrams that architects draw, we usually think about boxes and lines, like the typical system kind of architectures. However, if we compare this with real-life architects, with famous architects who design buildings, they do not draw blueprints.

Rather, they make sketches. This is a sketch from Oscar Niemeyer, one of my favorite architects who designed these buildings in the city of Brasilia in Brazil. Now, this is not a blueprint, there's a lot of detail that's missing, but most importantly, it captures the essence.

It expresses what the essential structure and property of the system is going to be and it incorporates the major decisions and the context in which the system is going to be built and if you're wondering whether this napkin sketch matches reality, you can be assured that the real building matches the essence of this architecture. They are a lot of details to be filled in, a lot of blueprints to be drawn but the core decisions and the core system image, so to speak, follow this sketch of the architect. So first, learning about how architects think is that architects don't draw blueprints, they sketch.

The second part of being an architect is to see more dimensions. You've surely been in situations where people argue back and forth between, are you going to do X or are you going to do Y? Should our code run in a container?

Should we make it serverless? Do I need an API gateway? Do I need a service mesh?

Do I need a document database or do I need a graph database? And people can go back and forth for very, very long time because they both believe they are right and it's just like in this picture where one person is very, very sure that they see a circle while the other person is equally sure that they see a rectangle. Architects, our job is to see more dimensions, to see the problems from different points of view and show that both are right.

They just need to look at things from their respective point of view. Once you show them the cylinder, they can have a much more meaningful conversation. For example, people might argue that we need to speed up software delivery while others argue that we need to improve quality.

They each see one dimension and consider these properties opposites of each other, but modern architects know that test and build automation speed up delivery while actually increasing quality. So, we see these as independent dimensions and know how to achieve both. Now, this is the second major part of thinking like an architect, we do stand to see more dimensions and not only do we see more dimensions, we're also good at zooming in and zooming out of the system and this isn't like a camera lens where you zoom in and you see the same thing just a little bit bigger.

It's much more like this Mandelbrot set where if you zoom in, you will see very different things. Our world is also fractal. It covers things from business architecture and business strategy to high level architecture and then you go deep down into the engine room to make sure you have the right number of spaces in your YAML file and all of those different levels of zooming in and zooming out look very, very different.

So, when we talk about what it means to be an architect, you can see that it's a way of thinking. It's about sketching to express the essence of something, that is about seeing more dimensions to allow folks to have more meaningful discussions and it's about zooming in and zooming out to see different things. Now that we understand what goes on in an architect's head, how do we articulate the value that an architect and architecture bring?

Most people, including myself, would say that if your system is still running, if it's still running well after several years and continues to absorb change, then it likely has a good architecture and perhaps a good architect behind it. But there should be a better metric for the value of architecture than hindsight, we would say. Now I have found that you can express the value of architects with this simple formula.

Well, actually, you don't need to understand the formula, the gentlemen, Fischer Black and Myron Scholes, you know, got a Nobel Prize in Economics for this one, which is known as the Black-Scholes formula of options pricing. What you do need to understand though, is how architects provide options and why these options are valuable. Options are a way to defer decisions.

In financial markets, these options usually entitle you to purchase a share of stock at a given date, for example, in one year, for a set price, let's say $100. Now, the great thing about having such an option is that in one year, the decision whether to use that option becomes trivial, right? If the stock trades at more than $100, you use your option to buy at 100 and you have money in the bank.

If the stock trades at below 100, well, you don't use the option, it's optional after all. So, options defer a decision into the future. So almost like time travel, in the future, you'll be smarter than today and you can make better decisions.

So, it's not surprising that these options have a value and Black and Scholes have calculated that value. That's what this formula is actually about. Now, as architects, we can also create options to defer decisions and that's how we provide value.

Let's look at a simple example of how this works in modern architectures. In classic IT, hardware sizing is one of the most depressing activities, right? You have an application and you need to estimate how much hardware is needed to run this application well.

Now, the reason it's depressing is because it leads to only one of two possible outcomes. You either end up with too much hardware and waste money or too little hardware and you end up with a poorly performing application. Now as cloud architects, we know a great option that we can provide, it's called a scale-out architecture, coupled with an elastic infrastructure.

Now, you have the option to add compute resources once you see the actual application performance and you can easily see that this option has made the decision much simpler and allows you to make a better decision. Well, you can further increase the value of this option if you break your application into even smaller pieces, so you can scale individual components, right? That'll be an even better option.

Of course, that's exactly what a serverless architecture allows you to do. Now, those are fantastic options to have. They defer a decision about hardware sizing until you have more information, like the load of the application and as a result, you can make a much better decision.

Now, you might've noticed that I said architects sell options, I didn't say they're giving them away. Sometimes architects believe that teams should use all their great ideas, meaning their options, but they forget that those options also have a cost and that cost comes in three main forms. First, implementing the option requires some work, right?

For example, you need to decompose the application, wrap it into container, automate deployment to spool up new instances. You know, second, the options tend to make your architecture slightly more complex, right? Scaling out requires you to have a load balancer and you have to manage and replicate state as well.

No one is ever looking for more complexity, so this is an important cost to consider and last, options can lead to under utilization. For example, if you want to have the option to run your application in many different environments, you might hesitate to use all the services provided by one environment and that might lead to an application that doesn't perform as well or one that takes longer to build. In either case, that's a very real cost.

So, architects are in the business of trade-offs. So we consider both the value of an option and its cost. So when is it worth getting this horizontal scaling options?

You will find that the higher the degree of uncertainty, the more valuable deferring a decision becomes. That's intuitive because if nothing ever changes, making the decision today is just as good as making it tomorrow. But if you're building a mobile application that might have 100 users or 100,000 users, this scaling option becomes highly valuable.

So, we find that architecture provides more value in uncertain times, and we live in uncertain times, so architecture becomes more valuable. Now, we know another popular method that also starts with A and that's called agile methods and oddly, architecture is sometimes seen as in conflict with being agile. You might've heard people say, oh, we don't need much architecture because we're agile.

Now, interestingly, agile methods also thrive on uncertainty. If you know everything upfront, you don't need to be agile, right? We just write it all down and you code it out.

So when you, as an architect, meet somebody who prefers agile methods, you can say, since you're agile, I'm guessing that you have to deal with uncertainty and that's exactly what architecture options do too. So when being agile, you should invest in more architecture. Now that we understand how architects think and how they provide value with options, it's time to get on the elevator, right?

After all, we have some connections to make, we need to connect the levels. We start on the top in the corporate penthouse and up in the penthouse is usually a CIO, a chief information officer. In most organizations, IT staff report to the CIO and the CIO is responsible for the overall IT budget, but who does a CIO report to, right?

That's actually a very good question. When you're up in the organization's penthouse, you need to understand what IT is measured by and you'll find that the CIO's reporting line has a direct correlation to this. I blogged about this many years ago after visiting many different organizations.

For example, the CIO reporting into a CFO, the chief financial officer, as we see on the far left, then implies that IT is seen as a single number, it's seen as a cost figure. You know, trying to pitch agility to such an organization is going to be difficult. An organization further on the right that sees IT as a critical business enabler, they will be much more interested in agility and speed as topics.

Now, you will observe that many organizations actually change their CIO reporting line over time and luckily, almost always to the right. I just spoke to a CIO recently who said that her biggest success so far was changing the reporting line away from the chief financial officer. So again, we see that organizational structures have a lot to do with architecture.

Understanding the organization allows you to translate technical capabilities into the specific business priorities. Now, let me give you a concrete example. You know, as an engine room architect, you often build systems that have automated deployments, they enable software delivery velocity and they increase observability.

Now, you'd think that every IT executive must be excited to have such a system. However, you find out that up in the corporate penthouse, IT executives have very different priorities given by the CIO or by the CEO or by the business. You know, it's gotta be secure, right?

They don't wanna be in the news for a data breach, right? The IT must be up and running, it must be available. Nobody likes to pay for something that's not running and of course, it's better to spend less money.

So you might find yourself pitching something that you find exciting, but that's perceived as of limited value by the folks that you're speaking to. Now sure, you could just now say, I just pitch cost and availability, but you can do something much more valuable. You can ride the architect elevator by showing how the items on the left actually enable the items on the right.

Observability, velocity and automation are critical elements of security because they allow rapid detection, served containment and maintaining off patch levels. Likewise, observability allows you to detect or even predict system issues to increase availability. Automation allows you rapid fail over or scaling up and high velocity allows you to roll out application fixers and reduce downtime.

So again, all three elements on the left work together to increase availability and last, elastic scaling enabled by automation reduces costs and increased observability allows you to optimize sizing. So, this is a perfect elevator example where you show how the items from the engine room connect to the concerns of the organizational penthouse. It's like zooming in and zooming out in action.

What you notice on the previous slide is that, we are not throwing out new buzzwords. Folks in the penthouse might be a lot less interested in the latest open source project names than you are. Instead, you're focusing on forging connections.

It's like learning a new language. There's way too much vocabulary, well, especially in IT there is, but if you learn the grammar, you can make connections and express meaning. So when up in the penthouse, focus on the grammar of IT, not all the buzzwords.

Now riding the elevator is about connecting levels. Now, that's why the mid-levels are very important. They tell you how to connect the engine room with the corporate penthouse.

Your biggest challenge in the mid-levels is complexity. Systems we build today, they are amazingly powerful, but let's face it, they're also complex. At the same time, these systems have a great relevance for the business and IT strategy.

The role of IT has dramatically changed thanks to these systems, so we can't just ignore them. So one more time, let's borrow from real architects and see how we deal with the complexity. Real architects build models.

Models are great because they're cheaper and easier to build than the real thing, allowing architects to iterate until they reach a final design that they can implement. For us IT architects, models are also extremely useful and models allow us to predict a system's essential properties. For example, will the system scale?

We saw a simple model for that just a few slides ago when we discussed options. Models filter out the noise. For example, our model for layering just showed the essence and allowed us to think clearly and because we can think more clearly, we can make better decisions and last, models should appeal to a broader audience, so that stakeholders can understand the implications of the decisions and the trade-offs we make in the engine room.

There's one important property that all models have in common though and that is models aren't reality. They are simplifications to help our thinking. They're by definition wrong, so at least let's make sure they're useful and as George Box eloquently pointed out, it's the simple models that do this best.

Most models I have used in this talk, so far, they're very, very simple. They were designed to get a specific point across. So, let's try two more very simple models.

So here are two very, very simple system models. In fact, they use the same components, A, B, C and D. However, they are wired together differently.

Do you think the systems represented by these models have different essential properties? Well, I think so. In fact, they're almost the exact opposite of each other.

The system on the left is, correct, a layered architecture, right? This means a clean structure, easy replaceability, but also longer latency and possibly single points of failure. All right if C fails, A can no longer talk to D.

The model on the right is the exact opposite. It has many more dependencies, but shorter paths and more resilience, right? A can talk to D directly when needed.

So two things we learned here, less is really more. You can express more with simple models. All the irrelevant aspects like programming languages and data times and whatnot are omitted, so we can focus on the essence and second, architectural models without lines are mostly meaningless.

All the properties we just discussed are a result of the lines. After all, we use the same boxes and that's how architects see more dimensions and use models as their best allies in the mid-level of the elevator. So, models aren't making things superficial or trivial.

They place important abstractions to sharpen and deepen our thinking. Many IT architects draw these giant tapestries. Those are not useful models.

They lack abstraction and they lack emphasis and they also don't widen your audience. As George Box would say, they're the mark of mediocrity. So how do we pick the best model?

The best model is the one that helps you answer your questions and helps you make better decisions. Now, that means before you draw a model, you must be clear about which question you're trying to answer. All the models here depict a very well-known system, planet Earth, which of these models is the best?

Well, that's a trick question because it depends on which question you're trying to answer. If you're going for a hike or you're trying to build a ski resort or avoid building in the flood zone, a topographic map is an excellent model. Political maps are great to understanding elections.

Highway maps tell you how shortest drive from one town to another and where there's a good place to take a rest and lastly, if you happen to be in the business of building distribution centers, a population density map is the best map for you. So, the next time you're being asked to draw an architecture diagram, a model, you should first ask which question are you looking to answer because that will tell me which model I should be drawing. Now, we saw that simple models are better, but careful.

George said simple, but evocative. Now, how is a model evocative? Well, here is one that isn't.

You might say, oh, that's a nice architecture, has a front-end, oh, has a back-end and the database and look, the front-end talks to the back-end. No kidding, right? This model doesn't evoke much in me besides maybe boredom.

So, why is this model not useful? Because it doesn't convey meaningful decisions. It's like saying my car has four wheels.

Like, all right, now some cars have only three or six, but highlighting that you have four doesn't actually convey very much and that's why good models not only answer questions, they also convey meaningful decisions 'cause otherwise, it's not really worth drawing up a picture. Okay, it's time to apply this to a real architecture diagram, not a building one, but a cloud one and we have a whole website full of them, so I found this great architecture diagram. Actually, I think Corey Quinn had already picked on this one before, but to the author's defense, I have to highlight that this is third architecture diagram in a paper showing the high end option of hosting WordPress, the most scalable and resilient option.

Now, there are probably a lot of questions that this diagram answers, but it also seems to struggle a bit to be simple and evocative, right? The nine footnotes in the picture might give you a hint. So how would I simplify this and emphasize the key decisions without losing meaning?

I can see three major decisions in this model. The first important decisions I see is the split between static and dynamic content, right, that's a very sensible choice and one that we should make very apparent in our model. The second fundamental decision is to split the dynamic part across two availability zones.

Also, a very sensible choice for high availability and last, we extract the state into a replicated database and a shared file system, so that we can auto scale our compute instances because they're stateless. Now, not having spelled out the questions that this model is looking to answer, it's a safe bet that we're interested in system availability and scalability, right? And scalability is really just a special case of availability under load.

Now, one part is missing from this picture though. It doesn't show the AWS services being used. Your product selection is important, but it should follow your critical architecture decisions.

So, let's add them in. Now, admittedly, this is probably not the best architecture diagram I have ever drawn, but it does bring out the key decisions around scaling, plus the AWS services that it use and I can imagine sharing this model with a much wider audience than the original one. It's much easier to understand what's going on here.

Now, once we have answered the core questions in a simpler way, we have freed up mental capacity to address additional concerns that the audience is likely to have. Now, I'm not gonna dive into all of those, but there's a good chance that you get one or more of the following questions. People might wonder, how can you maximize the percentage of traffic that is served statically and how much costs this would save?

They might also wonder how the solution not only scales up, but how it scales down, right? What is your minimum run cost per month when you have very little or no traffic? You show auto scaling for the stateless compute nodes but what about Amazon Aurora?

Do you use a cluster for that to also auto scale? You know, could the compute nodes rather than EC2 be containers and run in EKS or ECS? Would that be better?

Would it have an impact on the other aspects of availability or cost? Users might wonder whether hosting static content separately right, in S3, requires them to use specific URLs and lastly, folks might want to calculate the overall system availability based on the architecture and the stated service after this. The real list is likely much longer.

What we learn here is that reducing your models to the essence gives you room to dig deeper and answer more questions. I'd like to sum this up with one important message. As cloud architects, we often over index on the services we select.

The services are, of course, important, just like good ingredients are important to making a tasty meal, but first and foremost, you need a good chef. So, every once in a while, remind yourself that as an architect, you are the chef, you are not just shopping for groceries. Now remember, a good model describes a system's essential properties.

So, how about this model? Pretty nice one. So, the essential properties that will come to your mind are gonna be pretty awesome, yeah.

This solution is serverless, meaning it's lightweight, without the need to manage any infrastructure. It's event driven and it uses Amazon EventBridge as serverless event bus which makes the solution loosely coupled. Almost without saying, the solution is distributed, is highly scalable and of course, automated.

So, you deserve to be pretty stoked about your architecture, but remember that the mid-levels of the architect elevator also need to anticipate questions from the organizational penthouse. Here, you might find interest in a very different set of essential properties. What's the business value of this solution and of this particular architecture?

Do I have cost predictability? How do I budget my run cost with a solution that scales up and down? Do I have the right people and skillset to build and operate such a solution?

And event driven systems are known to have highly dynamic runtime to behaviors. How do I manage those? And if I need to take my system to another platform, how high will the switching cost be?

Once again, the questions you get at different levels will be different. Tying these aspects together is where the power of the architect elevator lies. But how far do you have to go when translating benefits?

Let's take one popular buzzword and try it out. Now, I wrote a whole book about loose coupling many years ago, so it's one of my favorite buzzwords. It's also widely considered to be a good thing, but don't assume all floors in the elevator will take that at face value.

So you have some explaining to do. Coupling is a measure of the dependency between components. The more dependencies, the tighter the coupling.

Loose coupling allows systems to vary independently without propagating the changes throughout the whole system. It's not an all or nothing affair, but a gradation with multiple dimensions. So for example, temporal decoupling can be achieved with asynchronous communication such as Amazon SQS.

Programming language decoupling can be achieved with common data formats like JSON. Next, coupling doesn't come for free. So you'll need sort of a tooling and you should also expect some overhead like we've seen with other architectures and I'm sure you could add much, much more about this and I want that you could write a whole book about loose coupling.

So how do you make this digestible for the penthouse? Just spooling out the buzzword, waving your arms and claiming it's important certainly doesn't do the trick. So you need to focus on a few key properties.

I pick a limited change radius and a limited error radius as the most important properties. But you need to realize that these are still proxies for benefits that the folks in the penthouse really care about. You're gonna need to do one more translation.

The limited change radius affords you a higher rate of change and the limited error radius makes this system more tolerant of failure. Meaning, it degrades more gracefully. It's like a limp home mode on some cars.

Now, if you had more slide space, you could offset those benefits against the increased complexity and overhead and then you can have a very fruitful and an intelligent discussion whether the system's anticipated rate of change is high enough to justify those trade-offs. We have seen that by translating the buzzword, you can get into a much deeper discussion with the audience. Most importantly, you made your audience part of the thought process.

Spooling out buzzwords not only makes you look dumb, it also makes your audience dislike you because it shuts them out from taking part in the thought process. Don't do that to the folks in the penthouse. All right, now you're armed with the best models and the best metaphors to bring architecture thinking to the penthouse.

But unfortunately, that's not quite enough. It cannot be boring. Luckily, you're not the first person to try to persuade an audience, so you can fall back on one more model and this time, one that's about 2,400 years old from Aristotle.

Your audience will view your presentation or any talk you give from three different lenses. They will hear your logical arguments, that's logos, they will consider your authority and trustworthiness, that's your ethos, and they will consider the emotions you invoke, we call that pathos. Now, the problem with most technical presentations is that the logos bubble is way too big and that's understandable, we come from the engine room, but it cannot be 90% logos and 5% ethos and pathos.

Your audience isn't a compiler. Luckily there are several simple techniques to improve the balance. Stating your experience and affiliation boosts your ethos, your credibility.

So does citing external sources. Gregor said that loose coupling has a cost. Now you have help in making your argument.

When it comes to emotions, my main advice is don't fall back to fear all the time. If we aren't serverless by tomorrow, we will be extinct. Now, that might be somewhat true, but as humans, we have many more fruitful emotions like anticipation, surprise, joy, pride.

So anecdotes and metaphors and great ways to stir such positive emotions. I have one last piece of advice that I used to become a better presenter and this time, it's not about building architects. Instead it's about DJs.

No one captures their audience like a good DJ and you know what? Most of the time, you know the content already but you're still mesmerized by the live performance, but you wanna see the smooth transitions, the buildups and the secret to success is that, a DJ reads the audience. A DJ works off prepared segments, but a DJ will improvise and fine tune based on how the audience reacts.

Now, if you're able to work this into your technical presentations, the penthouse is yours. Now I hope you enjoyed this short ride in the architect elevator. Now you understand how architects think, you have a clever way of articulating the value of architecture, you know how to read org charts, build evocative models, translate technical properties into benefits and deliver it like a DJ.

Now, there's a ton more to say, so I invite you to check out my book and the website, or to connect with me online. For now, it's time for me to yield the stage to all you architect superstars. I already pushed the button to the top floor for you.

Thank you very much.