Architecting for the Unknown - Venkat Subramaniam

This talk addresses the complexities of architecting software systems in an unpredictable world. The speaker emphasizes the necessity of microservices architecture while discussing how teams often replicate others' choices, risking mediocre results. They encourage a focus on minimalism, suggesting that surviving as a company must take precedence over ambitious projects. Drawing parallels to real-world examples, such as failed startups and successful pivots, the speaker illustrates that good architecture should enable adaptability to change. Collaboration is highlighted as essential for effective architecture, urging listeners to engage teams and avoid relying solely on AI or trends. Overall, the session advocates for critical thinking and ongoing evaluation of architectural decisions.

So I want to talk about architecting for the unknown. Uh this probably is going to be the shortest keynote you ever heard. This is the easiest keynote. When Dillip said, "We want you to give this keynote." I was like, "Gosh, I can get this done very quickly, right? So, let's get it over with so we can enjoy the rest of the day." So, I'm going to say,

"No matter what your application is, the architecture has to be microervices." Thanks for coming for the talk. Enjoy the rest of the day. Thank you. Well, clearly some people would rather do that, right? feel pain. We've all been through that, isn't it? So, how many times have you worked in companies where no matter what you talk about, the answer is microservices, right? That's been the world we

live in, unfortunately. And this talk in a way has nothing to do with AI or has everything to do with AI because whether you use AI to a small extent or a lot. Can you guess who is responsible at the end of the day to deliver the products? Want to take a guess? It's us, right? So you cannot simply say AI did it and relinquish your responsibilities

and walk away. And one of the things that we need to really think about is how can we really go faster but without losing track of where we are going after all if you don't know where you're going it doesn't matter where you end up with. So essentially I want to really take us back to the fundamentals and we think about what can we do to create

better architectures and whether you're working with a team whether you're collaborating with AI or a combination thereof these fundamentals become really important as we go move forward and that's what I want to focus on for the next about you know 50 plus minutes. So if you mostly do what others do, you mostly will end up getting the results that others get. And that is as simple as

that. This is one of the problems we often deal with. How often do you hear people say what is other people doing? What are other people doing? What does your company do? So we are eager to really see what others do. We tend to really aim for what others do. Often times we feel it's a safe bet. Well, if they're doing it, we should be doing it

too. And we are in this pressure to really look at what others do and start adapting it. And if what others do is do is getting really good results, that's a good thing because if they're winning and if you do what they are doing, you might come out winning too. But if if others are not getting the results and if we try to really do what others

are doing, that's not going to be good for us because we end up really getting the same results they are getting. Why do this? And this is one of the problems we often face. Um I had an experience uh last year a manager reached out to me and said, "Hey, I came across uh you know your profile. We came to know about you. Uh I just wanted

to just talk." And I said, "I'll be glad to listen." And the manager said, "I've been in project management for 30 years." This is exactly her words. She said, "I've been a manager for 30 years and I've never been as unhappy and as unsuccessful as I've been the past few years." And I'm like, "Wow, you got a 30 years experience and you're struggling. Why?" And because she

says I have no control over where we are going because it's a complete chaos in terms of what people want to move us into the direction it doesn't seem to give us results. It doesn't make any sense. So once again what can we do to really get better at what we do is the question. So we all aspire to be architects if we're not already architects. I

was sitting in an airplane and as I was getting ready to buckle in, I turned to the person next to me and you know, we smiled at each other and a few minutes later the conversation rolled and I asked the person, "What do you do?" And and he said, "I'm an architect." And I was very curious. I looked at him and said, "Pardon me asking, but are

you an architect or are you a real architect?" And he looked at me and said,"Well, I cannot answer that question until you define what a real architect is." And I said, "Sure, that's fair. I'm a computer programmer." And he said, "Don't have to say anything more." "I'm a real architect," he said. And I was curious. I asked him, "So, you're a real architect? Tell me more. I'm

curious to know what do you do." and he said, "Well, we are building this hospital and we are into the fourth year of construction and my job as an architect is to work through this project to get it to completion." And I said, "Wow, I'm really surprised. You said you are into the fourth year of construction. Aren't you supposed to be an architect who comes in and

does cool things and leaves before any work gets done?" And he said, "Yeah, there are some architects who are like that, but I'm not one of them. I stay with the project from the start to finish." And then he paused and said, "Because he said, I'm the who I'm the one who delivers the bad news to the management." And I said, "Bad news to the management? Give

me an example of that." And he said, well, for example, the one we are building right now, we did all the studies you need to do and I need to go tell them that 200 ft below the ground, the soil is not what we expected it to be. And now we no longer can build what we planned to build and we need to rework the architecture to

deliver what we can deliver to them. So this is my job as an architect to keep reworking things along the way because we discover things as we go on. There is unknown in every aspect of life whether it's in construction of buildings or or building software we have to deal with it. So, I want to ask the question, what's architecture? Let's spend a minute. If you don't

mind, why don't you turn to the person next to you, ask them. Go ahead, ask them what's architecture. Let's spend a minute. Go And let's hear some noise. Turn to the person next to you. Ask them what's architecture. I'll give you some time. I see people quiet. No. Talk to the There are two sides to most of you, right? Ask the person on both sides. I want

to hear more noise. I'll wait until you begin talking. Folks, let's get up. Let's warm up. Let's stand up for a minute. Talk to the person next to you. Ask them what's architecture. I'm not letting you go easy today. There you go. I can hear noise now. Let's speak. Yell out a definition if you find it. All right, let's settle down. Thank you. So, did you learn

what architecture is? Did you find out? So, here's what I found out. I've asked this question to countless people around the world. And this is one definition I hear over and over and over. And the definition is it's something we know but we cannot put that into words. Did you feel that way too? You're like everybody knows architecture but when you tell them to define it we

throw a blank isn't it? We're like gosh how do I define architecture and we seal it we do it we practice it but what is the definition of that? What can we give right is the Is it a blueprint from the definition of construction buildings? Right? Because civil engineering, there are architects, they construct stuff. So, it's got to be a blueprint. So, we could think of it

as It's a structure of how components inter are interconnected and how they communicate with each other. So, we tend to define architecture in terms of how we put things together. What are the different pieces? How do they communicate with each other? What are the boundaries? So we tend to define architecture based on the structure of what we built. But then you realize, wait a minute, so is

design. So then we are kind of confused back again. If that is design, then what's architecture? And that's okay to be confused about it, right? That's a natural thing because we are trying to really figure out what these things mean. As it turns out, there's a reason for that confusion. Because if you think about it, you could think about architecture and design as really two ends of

the spaceime spectrum. If you are far to this left, that could be more architectural. If you keep pushing it towards the right, maybe that's more of a design. And maybe there is this middle ground somewhere in between. And when you're in that middle right there, you're not really sure. Tilt a little bit, it feels like design. Tilt a little bit to the side, it feels like architecture.

And that's fine. We don't have to get too hung up on how we define it. But you can think about this in terms of what are these concerns? Why does one have to be architectural, one has to be design? For example, if I'm going to build a house or a building, office building, doesn't matter. One of the questions you get often asked is, "How many cars do

you want to fit in a garage?" That's a very simple question. Uh I've had a few opportunities build homes for my own over the past several decades, but one of the questions when I talk to the builders often time is how many how many cars do you want to park in your garage? That's a very simple question. Would you like to park two cars, three cars, four

cars or whatever that could be, right? So the decision as to number of cars you want to park in a garage is Why? Because you start constructing the house and 2 months into it, you go to the builder and say, "I've got an idea. I just realized I would rather be able to park two more cars in the garage. Can we make it bigger? The only response

is to laugh because that's so silly to ask them to change the architecture because it's expensive. You cannot imagine because the number of cars you can park in a garage goes all the way to the foundation. And you cannot just wake up one night and say, "Yeah, let's just make this bigger or smaller for that matter." Right? So you cannot just change these things so easily. But

on the other hand, what kind of style do I want for a garage door? Do I want a garage door where there are windows in it so I can get natural light in? Do I want a garage door which is a bit more stylistic? What do I want the color of the garage door to be? That's a design. You can change that. You can replace your door.

Sometimes you have to because sometimes I back into the door. That's how awesome a driver I am. So you need to replace the door maybe, right? So that's a design concern. So this kind of gives you an idea, right? These two are similar and yet they are very different. both related to garage but both with completely different consequences. In a similar way, you could ask the question

when it comes to software, what framework should I use? Don't take that question lightly, right? Because if you decide to use a different framework, you have to make a lot of changes that becomes cost prohibitive. So the decision as to what framework to use is very fundamental for you to decide that becomes an architectural decision. On the other hand, what library should I use to parse this

XML document or to access this JSON? That's a design concern. Why is that? Because you can decide to use a different library tomorrow if you want to. that doesn't cost you a lot as much as deciding to use a different framework or a programming language for that matter. So once again you can see the spectrum where the decisions have an impact. So how do you define architecture?

Well, as it turns out Martin Fowler gives a definition. He says arrite is a set of decisions that are hard to change. While I agree with this definition, I also don't like the definition. You know why? Because I am good at creating things that are hard to change. I cannot celebrate I've created architecture. It just means that I'm silly. I have not really done a good job.

So, not everything that is hard to change is Though what is architectural is often hard to change. It's not an if and only if. It's not vice versa. So I was struggling. Maybe I need a better definition for what an architecture is because a hard to change doesn't cut it for me because I can create stuff and say, "Yeah, that's hard to change, so that's architectural." Not

really. So architecture is a set of decisions that have high impact and greater consequences. I would like to say because if I have to make this change, it's going to cost me a lot more. it's got a greater impact. It has greater influence on what I do. And if I do it wrong, it's going to hurt me more. So these can be really problematic in general. But

the problem really is we don't know what we don't know. And when we don't know things, what we don't know can hurt us a lot. So the question is, how do you deal with things that you don't know when those spring up and bite your back and you're like, "Ouch, I did not see this coming." So what can we do to minimize those things that we going

to have surprises on that we don't know? Now you might say, "Oh, wet, it's very easy. Spend the time knowing everything, then you don't have to worry about it." But the reality is you don't know what the future is going to be. It's even worse. You might plan for something, but what springs up on you is not what you planned for, but something completely different from what

you anticipated. And I'm hoping today I can convince you about this by looking at some examples from world we live in. So we can be more realistic in terms of what we can do. So, how many car manufacturers were there in 1890? I want you to yell out a number. Don't worry about being wrong. Don't worry about being right. You're not in an exam. You're not in

an interview. Anyone wants to take a stab? How many car manufacturers were there in 1890s? >> What was that? >> Five a year. Anyone? More than five. Okay. Oh, by the way, more than five goes in the other direction. One is there. Look what a has done to us. More than five meaning six, seven that direction. What do you think? >> A thousand. That's a That's a

lot. Let's come back here. Can it be steam cars? >> Steam powered car. >> Uh steam powered cars. Anything that has four wheels on it. That's what I look >> Any one more number? >> 10. How about a 100? So it turns out depending on which year you're looking at, we had anywhere from 50 to 100 car manufacturers in 1890s. Kind of scary, right? Now the year

is 1910. Any any guess? What? What was that? You said 10 is what you said. Did you say 10? How grim and how right you are. So yeah, it dwindled down to around 10. Think about that for a minute. Within a span of 15 years, a good number of hundred manufacturers got bought over, got absorbed into other companies, were sold off, or went bankrupt. Where are we

going with this? Most startups fail. That's a reality. Excuse me. Whether you like it or not, most You say, "Well, I heard about this successful company." That's the problem. You don't You only hear from survivors. We don't spend time talking to people who didn't make it. It's the companies that survived that you hear about. So, most startups actually fail. So imagine if you are part of a

startup and somebody tells you you need to create an architecture that would absolutely solve the world's problem. What are you looking at? Spending a lot of money when you have no clarity on the future if you would even exist. I had a business partner. I'm I'm not a business guy. I'm a programmer. I like to tinker with the code. That's what I love doing. And I had

a business partner. And one day he called me and said, "Congratulations." I'm like, for what?" And he said, "You we have been in business for 5 years." I said, "Hang on a second. You didn't bother to call me at the end of first year or the second or the third year. Why are you calling me today at the end of five years?" And he said, "Oh, winket,

maybe you don't know." I'm said, I don't know what's going on. And he said, most companies don't survive for 5 years. If you survive for 5 years, that's time to celebrate. I'm like, really? I didn't even know this. And apparently 5 years is a good mark because if companies survive for 5 years, maybe they will live a little longer. So most fail unfortunately. Take an example, just

not startups, products within companies. This is just one example. You can always look at your own organizations. Google has about nine core products and we look at it as a great company and it is but they have about 250 failed applications. You can search on the web people talk about graveyards of failed applications and then what has been built on top of that. So the point is

the chances of you working on a successful product is fantastic if it survives because you need to see if it's going to last. So the number one lesson we have to survive before we can succeed. That's a reality. I can be ambitious. This is what I want to build and that's great. But if I'm not going to survive first, imagine this for a minute. You're sitting in

front of the people who have the money and you are asking them, I need money to fund this project for the next year. The conversation you have with them is very different, fundamentally different if you have a product that's not seen the light of the day and you have a product that's already making the revenue. If your product is making revenue, your conversation is very different compared

to when your product has not seen a dime in reality. And this is one of the things to think about, right? And we could say we need to really build this amazing product with respect. Yes, but not yet. You need to survive first before you can succeed in reality, So architecting requires minimalism. So time and again I'm going to be that person on your team constantly asking

you do we need to do that? Is that necessary? Can we just avoid that right now? Can we postpone it so we can focus on doing something that will help us to get this to the market? So minimalism is extremely important. So when you hear this chatter about all the beautiful things we can do, I'm going to be the person in your team asking, can we please

not get there right now? Can we just focus on minimally what we can do to get it out? Because if I don't survive, it doesn't matter what my ambitions were, unfortunately. So focus on minimalism to begin with. This is especially so important today. The problem is just forget about today for a minute. Go past five five years in in you know in time. So let's say 5

years ago what did we do? We created massive amount of complex applications it only makes it faster to create a mess. This is the danger we are living in right now because the cost of creating code is so cheap. We might create more of it which can lead to bigger trouble for us. So minimalism is even more important today. Now that we can create more garbage, we

got to be more careful at what we are creating as well. So to go back to that fundamental, aim for minimalism. That's the first thing I would say. So what is a good design? What is a good architecture? I would say a good design is not the one that correctly predicts the future. It is the one that makes adapting to the future affordable. So you can say

I can sit here and plan for everything that could happen in the future. The best way to fail is to predict the future. If you want to know what will not work in the future, ask me. I'll tell you everything possible. So the point really is I can plan for this future or I can say how can I plan so that when the future arrives I can

make the changes towards it in a most cost effective manner and again one of the ways to get there is minimalism that can get us to that particular place. But how many of you have heard about Zoom? Oh, sorry. I forgot to say back in 2020, not not any hands, one one person in the room, maybe two or three, right? Most of us have not heard about

Zoom in 2020, right? And all of a sudden, everybody works from home. We need to communicate with each other. And we were rushing towards software that can help us to communicate remotely. and and suddenly this tool that's been around for a while became very prominent and they had to rush to handle problems they never had to deal with before security scalability and all of that. So how

do you know all this is going to happen? There was in your road map it doesn't say do all of this and there's pandemic you need to do this right. Nobody thought of this becoming such a massive change in the way we do things. How many of us have heard about ODO? Uh a very few hairs. This was a company that was focused on building a tool

for podcasting. Very nice ambition. They were building the software for podcasting. And guess what? this company called Apple decided they're going to be in the same business and they're like, "Oops, we can't compete anymore." So, they lost their business pretty much overnight. And they were sitting and scratching their head. What do we do now? And they were going to fold the shop, go home, and you know

how programmers are, right? Programmers are the most hopeful people I ever know. When everything is dim, everything is giving, you're like, "Wait, wait, but one more thing maybe we can do with this. And a bunch of guys got together and they said, "Hey, we got this code. Maybe we can salvage this code and do something. Maybe we can take this in a different direction." Oh, by the

way, we live in this beautiful world. We use nice words, pleasant words for when things go terrible, right? That's the beauty of humans. We can use good words. We love euphemism. You don't say people, "Oh, life is terrible." Right? You say, "I've got challenges." That sounds a lot better than life is terrible, right? So, you don't say, "We failed." You say, "We pivoted." That's a beautiful word.

What does pivoted mean? We have no clue what we're doing. We're going to find something else to do. So, this team said, "We got to pivot." And so, they said, "Wait, here's an idea. What if we take the software moving in a direction different direction the let's start putting together an application where people can say useless things to other people like I'm having a cup of coffee

I'm going to go to bed now I'm watching Scott sit there anything that you think which is things you see nobody imagined the world will be excited to say useless things to each other. You know what this company is? You just didn't know it. We're talking about Twitter. So, Twitter really came out of a failed project, a failed company. And now, think about it. How many of

you were using Twitter back in 2007, 2008 time frame? A few of us. What did you notice when you used Twitter back in time? One thing that Abler stood out. That's right. It's the whale, right? What happened? Why did the whale show up? Because when many people start tweeting, it couldn't handle the load. And you would see this whale pop up and say, "Sorry, we are experiencing

high load. Please try again later." Now, people in this room know this. The words, "Please try again later." translates to what in English? Hit the refresh button. That's right. Refresh. Poor whale gets summoned over and over and over. So overnight, Twitter had to sit there and say, "Darn it. We never thought people would get excited about saying stupid things. We got to fix this." And they had

to rearchitect. Now, it turns out, don't get me wrong, I'm a big fan of a lot of technologies. Twirl was written using Ruby on Rails. It's a great framework, great language, just doesn't scale. And they figured out rather than throwing everything out, they found out the problem really was in the messaging layer. So, they reimplemented only that layer using Scala. At that time I was listening to

a Twitter engineer back in time and he was saying had we had J Ruby mature at that time we would have just used J Ruby to run this on the JVM but they couldn't. So the key here is they did not anticipate this. Why? Because they were pivoting. They were not even sure if they would even survive because they were already failing as a company. And what's

the last thing you do when you're failing as a company? You don't go to your team and say, "I've got a great idea. We got to make this scalable." They're like, "Are you an idiot? We don't even have a business. What kind of scale are you talking about?" Right? This may not have survived. But when it did, they had to change very quickly in order to turn

around. Maybe that's the only good news I can talk about better given what we know today. But the point really is a good architecture is evolvable. And if you cannot evolve your architecture, it doesn't matter what you build because the minute you turn around, it's going to fall apart and you're not going to be able to support it. So it's a question is what do you want

it to do tomorrow when you get to know what it should do because you cannot anticipate all of that. Zoom needing to deal with security, Twitter dealing to deal with scalability when the products didn't even have any success in the market. How can you really justify those things? And what else would you be planning for? One of the principles I love the most is the Yagy principle.

Yagnney stands for you aren't going to need it. This is a mantra that I follow a lot. You don't need that. You don't need this. You don't need to really do that. But at the same time, Yagney is also risky because Yagnney could force you towards being blindsided and then when the reality occurs, you might be really in trouble to meet it. The other extreme of this

is extensibility and extensibility is where you want to really not only plan for now but plan for the future. So how do you really make something extensible and at the same time also worry about focus on what is essential? And what I like about this is the balance it can help you to strike right in the middle. not to go in one or the other direction too

much but to stay in the middle so we can achieve a balance between those two. But those of us who have experience probably will remember this quite well though we find it hard often time to accept. We often focus on extensibility. Raise your hand if you have been told you need to make your code extensible. Has that happened before? Right. All of us. Right. Absolutely. This is

the world we live in. We are driven towards it. Oh, how would this work if what if? What if? What if? How can you make this extensible? But I'm going to say that extensibility unfortunately is a slippery slope. We are in trouble when we focus on accessibility a lot. I've seen this over and over and over in applications because people build this massive amount of code and

you look at them and say, "My gosh, look at all this complexity. Why do you need it?" Then they say, "Because the code is extensible." I remember this experience. I was in Ohio years ago. I was sitting down and having lunch with the team and the manager said every day my team would tell me remind me they're building software that's extensible. Anytime I ask them anything they

would say oh don't worry the software is extensible and he said we got we received a change request from a client. When we received the change request I went to my team and said we got to fix this so this can work. And my team said, "Oh, we need about 2 months to get it working." And he looked at me and said, "I don't understand this. Why

does it take two months to make a change when they keep telling me the software is extensible?" And I told the manager, I know where the problem is. The problem is with you. And he said, "What did I do wrong?" And I said, "The problem is you ask the software to be extended. If you never ask it to be extended, it'll still be extensible." Right? So extensibility

is this myth we work towards and it's extensible until you ask it to be extended and when you ask it to be extended we're like oops we can't do that why because the change that often comes your way is not the one you are planning towards why does that happen well more complexity has been built into products for the sake of perceived and I see all this

complexity and you're like god Gosh, that's a lot of stuff going on. Why do you do this? Oh, don't worry about it. It'll handle the future. It's extensible. But as it turns out, how can we really build for extensibility? Right? I'm not saying we shouldn't, but how do we do that? So, ability to anticipate is has a direct impact on our capability to address extensibility. If you

can anticipate really well, you can be planned for extensibility. But the question is who can anticipate really well? That's the question. And I would say every team has three kinds of people. Just look at your own teams. Hopefully you will agree with this, right? Every team has three kinds of people. Who are these? Those with more software skills than domain knowledge know anyone like that. Yeah. Have

you looked at the mirror this morning? Raise your hand if that's true. Anybody here knows more software than domain? Most of us, right? Most of us. I know software more than the domain. I'm not saying I'm great in software, but I'm definitely not great in domains. So we tend to really have people who are really good at software design skills don't know enough about the domain. The

second type of people those with more domain knowledge than software skills. Seen anybody like that before? You're business analyst right? They probably took a four trend course in the in the school and they think they are good software experts. Now you're like thank you for your advice on software. Let's focus on the domain. Right? We're trying to understand the domain and they're really really good at it.

those very few people who have both fantastic domain knowledge and software skills. There are a few like that. I'm sure you have come across them at your work. I know what you're thinking. No, we'll politely ignore the fourth category now. So when you have these three groups of people in here, who do you think is going to be really good at anticipation? Any guess? The third category

is in it because they understand the domain well and they also understand the software design constraints really well. I was that person on teams who would think about oo I've got to design this. I'd go to my engineers and say, "I'm going to design it this way. These are the most patient people in the world." They will listen to me and say, "I'm so glad you ran

that by us. Hydrocarbons will never behave like that, so don't do it." I'm like, "I'm so glad I asked because I can make systems extensible for no good." And all I ended up was building complexity into applications for no good reason. Right? So to anticipate well we need both domain knowledge and the software skills but the problem is we either have one or the other but never

the both almost. So this requires extensive amount of collaboration. So architecting is a collaborative effort. I was in a in a conference and a gentleman who works for a fairly big bank came to me and said, "Oh, we are building this software and everything possibly could go wrong is going wrong." And I and I looked at him and said, "You said we are building the software. Could

you please expand on what the word we is?" And I looked a little surprised and said, "You know, I worked for this bank. We in the bank are building this." I said, "No, no, I get it. But tell me what the word we means, please. What does it mean? He said, 'Well, I'm an architect. I've got programmers on my team. We are building the software. I said,

that's your problem. Because you don't have the business involved in what you do. And when your business is not involved in the decisions you make, how do you expect to get good results? So you cannot just build a software without really collaboration. That becomes extremely important especially when you can go faster. You got to slow down to make sure you understand where you are going faster because

what's the point in going really fast in the wrong direction. That is something to really think about. So it's a collaborative Well, this brings up one more thing that I learned in a very interesting way. a house I used to live in the basement. Well, in Colorado we have basements and so in the basement usually you have stuff you put in storage things you don't do use

too often and I've been in that house for a while. I really never bothered to go to the basement until this year 2020 when the world shut down, no travel and I found myself teaching courses and consulting on projects remotely. What that meant was that I had to spend hours and hours talking to my clients using this window on my computer. So I took over the beautiful

place called basement and I spent a a good year or more in the basement. Well, unfortunately the house I lived in the basement as you can imagine right is under the ground and we had this well window which is surrounded by a well. The fire code requires that you need to have windows in the basement in case there's a fire that breaks out. You are in the

in the basement you got to escape. So typically the houses are required to have this window well and what you don't see is there's a ladder that will get you up. So in case of fire you can open the window, jump or crawl onto the well and use the ladder to come out. The problem is, as you can see, the well is covered by mud, surrounded by

mud, and all you see is this little bit of light on the top. So, you can imagine when you're stuck in the basement for 10 hours a day, and all you see is a light you could be seeing, but you can't. And so, I had a new hate for window wells. And we decided to go construct another house. And as I was beginning to construct this house,

I was talking to the builder. What I didn't realize was I had the world's best builder ever. And nobody tells you. Everybody says we're the best, but you don't trust them. But this person didn't say he's the best, but he turned out to be. And as I was talking to him, I remember telling him one day, you know what? Whatever it is, I hate window wells. I

kept telling this to him. So when we started building the house, we had an architect and the architect made a nice plan and I told the architect I hate window wells and he came to me and said I'm really sorry Wanket in some part of the basement you can have a nice window you can look out but in this part of the house very sorry based on

the elevation based on the position of the house we cannot remove the you know well but I'll give you a half window Well, I mean, what is a half window? Well, that's a consolation price. You can, you know, I'm a short guy. You can do this and you can see the light on the top. I've been talking to the architect. Can we please remove this window? Well,

no, you cannot. And he's teaching me on architecture. I'm like, okay, fine. You can put this half window. I'll live with it. Well, my wife and I go to this construction site and the builder said, "We laid the foundation." So, I was curious. I go there to look at the foundation as they were building and I'm looking at my wife and she's looking at me. We both

are a little puzzled because we had the diagram of the foundation and I'm looking at it. I'm looking at the wall and everything and suddenly I noticed that you know the builder as I mentioned to you was this person right who has been listening to us and as we were looking at it we noticed there was this wall right there in the middle of nowhere and I'm

puzzled what is this wall doing here and I'm asking my wife you think you made a mistake and she's like do you think you'll make such a mistake? And how do you go to the builder and say, "Dude, you made a mistake. You have a wall where you're not supposed to have a wall, right?" So, we both are kind of looking at each other very quietly and

the builder comes over and how do you tell the builder, "We got some bad news for you. You your guys put a wall where it doesn't belong." So, as we were kind of looking at him and he comes around and says, "So, what do you think?" And we said, "Yeah, it's kind of interesting. We've been looking at the, you know, foundation and all that." And then he

said, "What do you think of that wall?" And we said, "Yeah, that's what we were curious about. What's that wall doing?" And he said, "I'm really sorry. I didn't have time to ask you, but I I I know you hate window wells. Do you?" I'm like, "Oh, yeah. I hate window wells. Thank goodness." And we were just laying the foundation when one of my colleagues came to

me and said, "Didn't you say your customer hates hates window wells?" I said, "Yeah, then why the heck are you having window well here?" And I said, "What do you think we should do?" And he said, "Raise a wall, push all the soil on the other side, excavate this area, and off you go. You don't need a window." Well, and he said, "Brilliant. Let's do it." And

in a split second, they completely changed the architecture of the building to include a window in its place rather than a window well. And it just blew my mind. And I asked Dave, the construction builder, and I said, "Dave, why do you do this?" And he said something that absolutely amazed me. He said, "When I'm going to build this once, but you're going to live there for

a long time. I need to build it for you, not for my convenience." I said, "Can you please come and talk to my programmers?" Because they say, "Oh my gosh, I wrote this code. I want don't want to change it." And here is a person who was changing the architecture of a building. So the lesson I learned is the following. with that view that every day I

appreciate the lesson I learned was that architecting requires will to change if you don't have the will to change it doesn't matter it is to really ask the question you know what it doesn't matter what we decided what do we have to change now based on what we know right now and that's the lesson I learned from him is to be able to accommodate the change because

that's going to make this a lot better for the users in the case of a building or a software what have you there are no absolutes we often think of absolutes but it's important to realize there are no absolutes this we think of this as switch I want this I don't want that I want this I want I want scalability I want performance I want security I

want I want I want but you can't just pick things that's not the way it works because there are consequences it's a tradeoff for example I live in a place where it's very cold. So, it's nice to turn up the heat. And if I turn up the heat really high, my electricity bill goes through the roof. I got to pay a lot more. And I'm like, gosh,

I don't want to pay that much. Well, what can I do? Lower the temperature. The bill goes down. Now, there's a trade-off. What is a reasonable amount to pay and a reasonable temperature to keep? So, it's a dial. And there are several things that are influenced by this lack of absolutes. For example, if you want scalability, you often cannot get scal scalability without compromising on performance. If

you want performance, you got to compromise on scalability. And it turns out there is an influence back and forth. You cannot say I want this and that. Sorry, it's not possible. You need to determine what that range can be for you to accommodate. Similarly, if you have availability and consistency, there could be a trade-off. Which one do you want more? It may be hard to provide both

at the same time. So, what is the balance we can strike? So, a lot of decisions you make. Architecting is really figuring out what that nice comfortable compromise is. You don't have the luxury to say I want all of this. I want to go home. So evaluating tradeoff becomes a part of what we do. We are constantly evaluating these trade-offs. How do I accommodate these two things

in so we can be within reasonable range? That becomes an issue. We often talk about functional requirements. We focus on functional requirements. But as it turns out, there are nonfunctional requirements as well. And I don't like the word nonfunctional because we tend to really de-emphasize it's non functional is more important as it turns out it's quite the opposite. So maybe we can call them as characteristics as

Neil Ford and Mark Riders call in their book. So we can think of characteristics but what about characteristics? I was a few weeks ago in the Oslo airport. I had landed in the airport. I'm sitting in the train station to take the train into the city. My mind is corrupt. I always think of programming. So I sitting in the in the train for the train to depart

and I looked out the window and I saw this little sign, you know, Oslo Lethavan airport and I was kind of staring at this sign and it occurred to me, hey, wait a minute, it's interesting. We can think of functional and nonfunctional requirements. I I apologize. That's all could come to my mind looking at the sign and I realized that's a functional requirement. Why? You want to

tell people where what where you are when the train arrives into the station, right? And the font size has to be big enough for people to see and and other things. But then I realized there is a nonfunctional requirement. You don't want the bird to sit on the display and color the display. So you notice there is a nonfunctional requirement on it as well. That's why you

have the bird spikes on top of this display. So you can see how you have to think about not just the functional requirements but the nonfunctional requirements as well when it comes to what you design and what you create. And as it turns out that functional requirements like transfer money but where whereas characteristics could be handle large number of concurrent request. Now in all honesty if all

I had to do was functional requirement transfer money I can do that very easily. But when you say I have to support you know large number of concurrent users I'm like gosh how do I handle that? So the lesson to take home is that characteristics have a bigger impact on architecture. So if you don't fully understand the characteristics, you're in trouble. But this only gets worse, right?

We need to identify and prioritize the characteristics and architecting is priorit prioritizing characteristics. But characteristics change and requirements evolve and we have to keep up with these as time goes on. Which means every decision we make needs an expression in date. You cannot say we decided this and we're going to do this forever. Every few months, 3 months, 6 months, whatever the time frame, you have to

re-evaluate it. So architecting is re-evaluating decisions and you have to constantly keep asking is this still a good idea? Should we change anything we need to change? But avoid DUI. No, this is not driving under influence. This is deciding under infatuation. How do we make decisions? How do you decide what to use? Oh, somebody else told me to do this. We're going to do that. Or I

I have to put this on my resume. So, this is called the rumdriven design, right? So, we do things because it looks good on the resume. We often exhibit this herd mentality. Why are you doing this? Because everybody else is doing it. So we got to do this too. And we have seen this wave through the world. For example, how many of you have been programming for

more than 15 years in the room? A few of us. You know what I'm talking about. When I started programming 35, 40 years ago, the rage at the time was object-oriented programming. Everybody there was a fight. Oh is great. Oh, it is nonsense. Don't do it. And then suddenly it is was all about oh and we started doing object-oriented programming a lot. Then what happened? Some of

you may remember the scary days. We did comm and corba and every application was common and corba. Anybody was gone through that journey before a few of us right? Want to go back again? Then raise the hand. You can see that then what happened? Oh, the 2,000 years was great because we did this beautiful thing called serviceoriented architecture. Life was wonderful, right? We created so much complexity

into applications. And you thought things cannot get any worse until somebody yelled out microervices. And there's a dragon out there as you can see that is about to topple the entire world. And we have gone through this journey. And why did this all I was in a conference and I said in the talk 80% of those who claim to build microservices actually are not building microservices. Somebody

listening to my talk posted on social media, hey Venet is saying 80% of the people building microservices are not building microservices. And somebody replied to that post and said, well tell Wenet he is wrong. That number is not 80%, that's 90%. They said that's one of the problems, right? Everybody chanting that's what we built. What could possibly go wrong is the question. So I posted this on

social media a few weeks ago. I see this in my future one day. I believe it's going to happen. My grandchild is going to come to me and say, "Grandpa, I heard you traveled the world. What did you do? What did you do before you retired?" And I'm going to sit there and say, you know, grandchild, I traveled the world, but I sat there watching as the

industry drank different flavors of Kool-Aid over and over and over. And this is the problem we have seen is we get gravitated towards these new fangle things, but are we asking is this the right thing to do? And so architecting is critical thinking. This is especially more important today with the AI world we live in. If AI removes the thinking from us, we are in dangerous situation,

dangerous territory. So critical thinking is is important already. It only became more important and we need to really ask the question why are we doing it? What what is the reason for doing it? Should we be doing this? is a question that can save us a lot of time and effort. When I go to the doctor's office, they often ask for very different vitals. They ask the

question, right? They ask the question, hey, what is your temperature? What is your blood pressure? They take these vitals. So, the question to ask is, what are the vitals for a software system? Neil and uh uh Mark talk about fitness functions in the revolutionary architecture book. This is something that's drawn me towards asking the question what are the fitness functions we can create to be able to

assess the software in a way that it's meeting the characteristics when the characteristics change we need to really evolve the fitness functions so we get feedback that our code is actually doing what it's supposed to do as well. So when it comes to architecting it is not something that we can take lightly especially in the world where we are going faster and faster and faster. How can

we really step back and make sure we are actually going faster in the right direction? How can we make sure that we're creating more complexity? How can we make sure that we are creating some not creating something that could completely fail under its weight? So, it's time for us to really go back to the basics to rethink about and be that person on that team that can

take the team in the right direction, not just run behind these tools. And we end up actually costing more effort, more time and failures. And this is something that you're going to learn about a lot of tools and techniques today. They are great though. Those are important. and you want to really learn these tools. You want to learn these techniques, but don't forget that the tools are

great, but you still need to use your judgment. You still need to use your wisdom. I often say this, knowledge is important, no doubt about it. But knowledge in the absence of wisdom is dangerous. You can see a lot of knowledgeable But don't forget, knowledge without wisdom is not going to get you where you need to get to. Knowledge will show you what you can do. Wisdom

will ask you to decide if that should be done or not. And and exercise your wisdom as you gain your knowledge because that makes a big difference in towards whether we succeed or we create yet another mess for organizations to deal with. Don't be that person on the team who says things have never been out of control as it is today because people are rushing towards doing

things something to do. So let's revisit what we talked about. Architecting requires minimalism and this is something I would be fighting for constantly. Do we need it? Can we do it with less? Why? Because with less I can change faster. With a bigger mess it's harder for me to make changes later on. So minimalism is something I would drive towards. Good. A good architecture is evolvable. So

how can I focus on the ability to evolve as time goes on and minimalism is one way to contribute towards it. But other ways too you can think about architecting is a collaborative effort. Make sure to bring the team together. Don't just delegate this to AI and say I took the problem it fed into AI. It said this and I did it. Well, you can imagine what

the result is going to be if you do that. But instead, involve the team. Ask the question to your team. Ask them what do you think? How should we approach doing it? And and use AI after that, not ahead of it. So that way you can evaluate what AI provides. So you can make more sense out of it rather than saying, I don't have a clue what

I'm doing, but I just did what AI told me to do. Um, architecture requires a will to change. This is honestly I I remember I had taken a 20-hour flight and and at the end of the long flight I was working on some code implementing features and I checked into my hotel literally at 2:00 a.m. And after I checking in I realized this was a complete mess

I had created in the design. And honestly I took a deep breath and deleted the entire code and started rewriting it. But the second right was much better. It's as if a burden was lifted out of my shoulder. But it's the will to delete it. The will to change is important lesson I took took for for for from experiences is to say hey if there's a better

way to do it let's do it right. Don't hesitate to have the will to change. Uh architecting is evaluating tradeoffs. So don't assume you can pick things and walk away. Take the effort to say if I do this what else I have to compromise and figure out what that right balance is between the things you do. Architecting is prioritizing characteristics. So take the time to understand the

characteristics. As time goes on your environment changes, your world around you changes. You got to repp prioritize and work on what's relevant now than holding on to what you have done once and re-evaluate the decisions you made constantly. And this is something we have to re-evaluate on a timely basis. And architecting is all about exercising critical thinking. You cannot just delegate that to a machine and say

I don't have to think anymore. It's all the more important we spend the time thinking now than we ever did. And finally, it's about evolving the fitness function so we can get the feedback loops that our system is doing what it's supposed to do as well. I hope that was useful. Thank you and have a good time. [music]