Venkat Subramaniam on Architecture Patterns and Practices

Transcript

Introductions [00:24]

Srini Penchikala: Hi everybody, my name is Srini Penchikala. I am the lead editor at the InfoQ for AI/ML and the data engineering community. But today as part of this podcast, I'll be focusing on architecture and design topic. In today's podcast, I will be speaking with Venkat Superman, founder of Agile Developer Incorporated. We will discuss architecture patterns and practices and what should be the new role of architects in the agile software development organizations. We'll also cover some of the emerging technologies and, more importantly, when to use these different technology choices to get the most value out of each technology. So I have known Venkat for a long time, so it's great to chat with him on this topic today. Hi Venkat, thank you for joining me in this podcast. Can you introduce yourself to our listeners and tell us more about what areas or projects you have been working on recently?

Venkat Subramaniam: Hey Srini, thanks first of all for having me here. It's a great pleasure to be part of this podcast. I appreciate it. Thanks everyone for listening.  My name is Venkat Subramaniam. I'm the founder of Agile Developer. I also moonlight as an adjunct professor at University of Houston, even though I don't live in Houston for a long time, but I wear several hats. I write books, I speak in conferences. I teach a lot of courses in the industry, work with teams on enabling their teams to adapt to various technologies and practices. So I'm constantly traveling around the world, working with different companies and speaking to different teams. It's been an exciting opportunity to learn from, and then also turn around and help a lot of developers around the world. So that's pretty much what I've been doing, training, consulting, mentoring and practices around it.

Role of Software Architect [02:17]

Srini Penchikala: Thanks Venkat. So let's get started. So software architecture and the software architect have gone through a lot of changes in the last 10 to 20 years. So I want to start with the software architect side of the discussion, software architect as a person, as a team member, as a contributor, as a technology leader, as a people influencer, as I call them, can you talk about how do you see the role of a software architect in the new era of agile and lean software development processes and organizations as well as the technologies like microservices, serverless, DevOps, and cloud computing? There have been so many disruptive technologies happening in our industry almost all the time. So how do you see the new role of architect? How can they still enable the development teams to not only develop the software solutions on time, but also make sure that those software solutions will stand the long-term goals and objectives?

Venkat Subramaniam: I'll start with a quick story. I was on an airplane sitting next to a gentleman. We had a small talk. I asked him, "What do you do?" And he said, "I'm an architect." And tongue in cheek, I asked him, "Are you an architect or are you a real architect?" He laughed and said, "I can't answer that question until you define the terms." And then quickly he said, "I'm a real architect." Well, he's from civil engineering. Well, the architects in software development take obviously a very different role than architects in civil engineering, for example. But I would argue that it is an extremely important role for those who want to engage in focusing on contributing to that particular role, rather than focus on the title of that role. So that's why I want to emphasize the word role here than the title. An architect is a role which literally sits between on one side the business which wants the development of the software, and the technical folks on the other side.

And to be an effective architect requires a couple of different things. One is their ability to really articulate the details. They need to be able to articulate things to the business. They need to be able to articulate things to the technical people as well. So number one on top of the list is their communication skill. The second thing that, I know this is hard to accept when we hear this, but the job of an architect is to be both technically strong and, at the same time, strong on the domain as well. An architect cannot be effective if they don't understand anything about the domain. On the same token, an architect cannot be effective when their knowledge is not deep enough and wide enough on the technology scale. So if you take a programmer's job, we often emphasize how difficult a programmer's job is, and it is, but take that and turn up that several orders of magnitude, that's the job of an architect. So they got to be good in various different layers and, with the demand on systems we are developing today, that has only become a lot more essential in terms of how effective an architect can be and what are the skills they need to develop for that as well.

Effective Communication with Architecture Stakeholders [05:50]

Srini Penchikala: Thanks. So definitely you mentioned communication skills. So the architecture responsibility comes with an interesting challenge of communicating not only vertically in the organization all the way up to C-suite, down to the developers and other team members, but also it spans across the organizations like sometimes architects needs to work with the database administrators, sometimes with the security architects or the network engineers. So what do you recommend? How do they “know your audience” type of approach? So what are recommendations in terms of how much to communicate and how to effectively communicate with these different stakeholders?

Venkat Subramaniam: Yes, that's an extremely important question to address to begin with. As a programmer, we often focus on the how. How do you implement this in Spring? How do you implement this in Micronaut? How do you implement this using Angular? The emphasis shifts quite a bit when it comes to an architect, and the “how” is often replaced by the “why”. Why do we make certain decisions? What are the reasons to make certain decisions that become extremely important. So I would say the role of an architect is to really focus on understanding the why, again, both in terms of the business and in terms of the technology. If they don't understand the “why”, the job of an architect is two-fold. One is for them to make decisions, but the other is for them to really be willing to engage in an act of compromise. The job of an architect is not just decision making, but the one of compromising.

The challenge we deal with as an architect is you have a multitude of expectations and requirements and characteristics, and your goal is not to fulfill all of them, because you cannot. So your goal is to prioritize what is the right set of choices. And the prioritization may come from understanding what the true business needs are, and then driving from there to understanding what the technology feasibilities are. And this is where they need to go back and forth talking to the business and talking to the technical people, and arriving at the middle ground that would make this possible for them to achieve. That's the challenge of an architect is, they really need to focus on the why, they need to focus on this compromise and trade-offs and be able to evaluate it, and then to be creative, but not as an individual. But in terms of how they are creative working as a team, they don't need to come up with answers.

I often say a good architect comes up with good questions rather than good answers. An architect who comes up with answers may be really limiting, but if they're able to come up with good questions, they open the door for various answers from various people that may have better technologies or better approaches that can help them to solve the problem. And that is the key to being an effective architect is to really understand the “why” and to be able to drive the discussion so that they can achieve a proper compromise on things so that they can achieve the business objectives within the feasibilities of the technologies that they have available to them, and maybe a few other constraints within the capabilities of the team that they're working with as well. That becomes a job of an architect to be able to provide that as well.

Srini Penchikala: It definitely makes sense asking the right questions and compared to coming up with the right answers. If you have the right answers, you can solve the problem the right way, but if you ask the right questions, you will solve the right problems. So sometimes solving the right problems is more important than solving the problems the right way. Also you talked about the depth and the width of the knowledge, not only business domain, you mentioned and also technology feasibility expertise. So how can the architects balance out? They can’t be experts in everything. How can they balance between jack of all trades and a master of all right, so in terms of breadth and depth?

Venkat Subramaniam: The first thing I recommend for an architect, and especially I'm focusing here on a system architect, is don't be a PowerPoint architect. That is the most dangerous architect to be, in my opinion. A PowerPoint architect can draw nice diagrams and pictures, maybe add some nice colors to it, but they're not effective in actually implementing the technology. I'll give you a couple of different experiences. One is a company that I was consulting and training with and their architect had no knowledge of how to actually effectively write any kind of automated test. Well, can you imagine an architect with no knowledge of implementing any automated test ever, but he's in charge of guiding a team of developers. And so the architect was actually actively working and discouraging people from writing automated tests. That is not going to serve. If the person takes the time to learn about the effectiveness of testing and know where they can walk in and show the ropes, that becomes very effective.

So the question really is it humanly possible for somebody to really cover the breadth and also cover the depth? And the answer here really comes to not if it is possible, the question is how can we achieve that? So I have a recommendation, actually a specific recommendation for architects to achieve this. One of the challenges with an architect is, you know I want architects to be technically capable. And I have worked with architects who are super good in technical levels, and when they're really good technically, they have the respect of the team, but they're also effective in what they do. But the question is how in the world can they do? Are these people super humans? And the answer is no, and there's a very effective way to actually achieve this. Now, as an architect, you need to be in meetings with the business. A business comes over and says, "We got a question. How does this handle?"

Well, you get taken away for maybe an hour and you need to really be in that meeting answering the questions. You might go up in the management category for you to be able to answer some questions as well. One of the challenges is, you and I know this and everybody knows this as a programmer, the minute you start writing code, you can't say exactly how long it's going to take to finish it. Sometimes it takes more time. My wife jokingly often says, "Venkat, when you say five minutes, that is seven hours in human time." Well, when you touch the code, it gets dragged in. So as an architect, the worst thing you can do is to pick a feature to implement, because if you take a feature to implement and you are in the middle of implementing it, something doesn't work. You are trying to figure out why this code wouldn't work. There's an incompatibility problem with the library, and in the meantime your job as an architect is still waiting and you get frustrated.

So this is one of the reasons a lot of times architects don't touch code, but my recommendation is actually pretty directed towards an architect who wants to be an hands-on architect. So take your calendar. If you don't have control over your calendar, you are not in a leadership position. I think we can agree that an architect is a leadership position. So take your calendar and on your calendar, for example, book 10:00 AM to 11:00 AM every Monday taken away, 10 to 11. Tuesday, 2 to 4 booked away every week. Thursday from let's say 9:00 AM to 11:00 AM. Well, you have booked away about five hours every week. When the clock ticks 10:00 AM on that Monday or 2:00 PM on Tuesday, step away from your desk, find one of the developers on your team, drag a chair, sit next to them, and pair with them for an hour or two.

There are two things you achieve by this active pairing session. One, as an architect, you are able to engage in conversation with that developer. You are able to direct their effort towards what they are working on. You are influencing the design. You are also receiving feedback on the effectiveness of the architecture and the design as well. So as a result, you are doing a more effective role of an architect by pairing with them. The second thing is for that hour or two that you are pairing with on the Monday or the Tuesday or the Thursday, you are getting exposed to very intricate details about a certain implementation technology. You are working with this Angular programmer, you are then working with this Spring developer or the Micronaut developer. You are gaining insight into the front end of the backend, for example and so on. And that can be an effective way for you to really stay hands on.

But at the end of the hour of pairing, you can walk away and the developer continues to work with the code they've been working with. And yet another thing that I think we can do effectively is when you are looking at a certain technology, when you are gaining that breadth of the knowledge, you realize there are three technologies that are interesting that we are not using on our product. Well, find three developers and say, "Hey, you do a prototype on one, the second person on the second one, and the third on the third one." Bring them together on a Friday afternoon, take a look at the code they have written for the prototype and then spend the time discussing with them. That is a great way to gain insight into the technology at the low levels of the detail. So you can be hands-on, but it doesn't mean you have to take ownership of implementing the features, and pairing is a very effective way, and guiding the prototyping is a very effective way to stay technical and stay hands on and at the same time fulfill your other obligations as well.

Architecture Deliverables [17:11]

Srini Penchikala: It definitely makes sense. So pair programming is usually done with the two programmers, but I like the idea of pairing the architect and the developer so the architect can see that the intricacies of implementing a particular idea or a design pattern, and also the architect can learn what is practical and what is, you know, the PowerPoint only type of solution, and they can adjust the architecture, and evolve the architecture based on that ongoing implementation of the solution. So instead of waiting for six months and realizing it's completely different. And also you mentioned about the different technologies working with different developers to do the prototypes, I think that's a great idea because instead of one architect slaving away doing these prototypes and not focusing on their core expertise and focus areas, if three different developers can work on three different prototypes and they can come together on a Friday afternoon, great time to collaborate and have the demos and talk about the pros and cons of each technology, and maybe decide on one of the technologies, but now they have one developer who is familiar with that and he can mentor or train the other two developers, or the rest of the team on the technology, instead of architect being the bottleneck in the POC effort.

So it makes a lot of sense. This leads to the next question that I wanted to ask you. So as you mentioned, sometimes architects become too PowerPoint focused and are Visio focused documenting the diagrams and solutions and become hands off over the time. But working with the developers hands on and collaborating on the POCs definitely helps them. But do you see any specific deliverables along the way during part of these efforts that they can contribute to not only at the project level, but also in a long-term organizational level?

Venkat Subramaniam: One of the most important documents that an architect should be involved in creating is the ADRs, the architectural decision records. I find this to be extremely important in organizations that have been doing it's been effective. In organizations that have not been using it, you can see the pain of not having such a record. One of the most important information that we continuously need is the why. I sit among developers and the architects and we are having a conversation, and somebody throws their hands up and says, we're using this technology, it makes no sense why we are using it. And my question to them is what was the reason we chose this technology? And in companies where they don't have ADRs, they throw a blank face, "Oh, Johnny said we should use this," or, "Sarah said we should use it, and we started using it."

Well, we need to be able to reason for an adoption of a certain technology and that's got to be business driven. So ADRs are extremely important. So it's the job of an architect to really create an ADR and to maintain the ADR. And you may have a difference in technology as time goes on, but the reasons may stay stable much longer. Or when the reasons were to change, we need to re-question if technologies that we chose once are still valid. So that is partly one of the responsibilities of an architect. A second responsibility of an architect is, here's a way to think about it. Let's say you are driving a car you don't want to drive, so to say, in the dark. You want to know how much fuel you have, because if you don't know how much fuel you have, you could be stuck in a place with low battery, or low gasoline depending on what you have, and that could be dangerous.

Similarly, on your application that you're developing as an architect, you want to know how effective your solutions are. If your solutions are going to take you in the wrong direction, you want to know that sooner than later. And so as a result, a job of an architect, again, this is not something they have to do alone. An architect's job is proper governance more than anything else. You don't have to do everything by yourself, but you need to be able to manage the things to be done effectively. So as an architect you say, "Hey, look at these characteristics. My application has a demand on scale for this area of the application. That other area of the application has a higher demand on performance, for example. Oh, this one here requires high availability. Well, you architected for scale, performance and availability in different areas, but is it really working?

And the day you don't want to hear this is when something goes up in flames in production and they knock on your door. Or worse, they call you at 2:00 AM and say, "You got to come here because things are failing." So the question really is how can you be effective in monitoring and making sure that the solutions you are creating really are working. And so this is where when you are architecting, don't just design solutions. In addition to designing solutions, also design, monitorability and observability for those characteristics to run in production. On day number one, even when we are doing development and testing during development, I want observability and monitorability to be in place. If we designed and architected for scale, I want to see what kind of scale it's providing. If we architected for performance, I want to know what performance it's providing.

And so, as an architect, the job is not just to create solutions, but it's also to create the feedback loop to know if those solutions are effective. And we're able to do that as an architect. We also then influence our developers not to do silly optimizations. How many times have we seen developers come and ask this question, "What about performance? If I write this code this way, will it have poor performance?" And if I were to make money every time somebody asks the question, my bank will be full of money right now. But the point is we tend to put focus on the wrong areas in tying them to the business needs and characteristics. So if we can tie those to say, performance is not important in this area, but we care about scalability. Scalability is not important to this area, but we care about performance of these kinds of operations.

If we can observe and monitor those things, then, as an architect, you are able to get feedback saying, "Here's a solution we are implementing. And look, it is working." I was working on something a few weeks ago. I had a good desire for a certain behavior in the code, I designed for it, and when I started implementing and observing it was nowhere near providing that particular behavior. So the immediate question is, "Where did I go wrong? What did I miss?" And it was an influence of a different characteristic that was causing the degradation, but knowing that soon enough helped us to go back and re-implement a different solution to get the results we wanted. So that is, again, part of the job of an architect is to be able to not just think of a solution but also think about the feedback loop and being able to guide your development based on knowing that the solutions are working in areas where it is and making adjustments where it is not delivering the results that you might expect.

Srini Penchikala: Observability is definitely one of those new “ilities” that is more powerful than anything else because it can make other nonfunctional requirements like scalability, performance, and they're all more effective. Like you said, not every application needs to be super fast so the observability can help implement the appropriate solutions to the right requirements. You also mentioned ADRs, architecture decision records, definitely a lot of the companies have been using this and they have seen a lot of value in using those. And at InfoQ, we have published some articles on this in the transcript of this podcast, we will add those links for our listeners. So definitely I've been looking at that as well recently, and it makes a lot of sense how to document the snapshot status of architecture and track the evolution over the time, and also justify why a particular addition was made, whether it was right or wrong, but it was right at the time, based on what the team knew at the time. So it definitely makes a lot of sense.

Venkat Subramaniam: If I can tie this back to one of your earlier questions because what you just said just now prompted me to make that connection. Earlier, your question was the role of an architect when it comes to agile development or in terms of lean development. And observability fits really nicely with it because what is observability? Well, it's a feedback loop, but what is agile development? Agile development is feedback driven development. This is why observability makes a lot of sense is because observability gives us this ability to get that feedback loop that we are heading in the right direction, or not, and make adjustments, which really comes down to the spirit of agile development, is that feedback loop, and observability is one way to enable that feedback loop. So I think that when you made that observation about it's one of the “ilities”, I think it really nicely ties to that notion of agile development as well.

Architecture Testing Tools

Srini Penchikala: Definitely. It makes a lot of sense. The other comment you made earlier is the effectiveness of automated testing. We all know testing is very important. Automated testing can make a big difference in terms of reproducing the tests and the results, and everything. So in terms of the spirit of testing and the validation and quality assurance, so how can the architects measure their contributions to the overall software development efforts? What deliverables, in addition to ADRs and the observability integration you mentioned, are there any other metrics? I know we've been hearing about a minimum viable architecture as a compliment to minimum viable product type of deliverables. And we've been hearing about architecture as code where you define your architecture in a textual format and use some tools like MermaidJS, or PlantUML, to generate the design diagrams. So any comments on those areas?

Venkat Subramaniam: I would say two things that can be really useful. One is, I'm of the firm belief that the best way to know about our solutions is to start actually using the solutions. One of the things that I'm beginning to believe, is when we developers can use the applications we built, we are able to provide better feedback on what the application should be really doing. And sometimes it's not possible for developers to be active users because we may not understand entirely all the integrities of a domain. So my recommendation is start deploying the application very early on, and evolve it incrementally. So one of the worst ways to architect a system is to wait for it to mature enough before we have people starting to use it. So get it into the hands of people to use it soon enough, then you are able to drive better feedback loops from it.

And another thing you can do is you want to be able to get feedback again, whether your ideas that you have created in combination with developers are actually effective. The worst situation that we can be in is when you took the time to architect and then you eventually realize that the programmers found out that won't work effectively and they took a roundabout and they found a workaround and they're implementing something completely different from the goals you have set. And when an architect discovers this eventually, it can be really expensive to make changes and realize that the decisions programmers made were okay for that moment, but may not support the long-term goals for things. This is where the pairing that I talked about can help as well, because when you pair with the developer, you are like, "Whoa, wait a minute, why are we doing it this way?"

Because our intention was something different that removes that communication gap. A lot of times I might have a vision of how some things should be done, but the developer doesn't quite see it that way and they've gone on to implement it differently. That pairing can remove some of those gaps. Another way we can get to that point is to use things like ArchUnit. Tools like ArchUnit can give us a way for us to express our architectural expectations. I want to use things like ArchUnit more as a guardrail than as a stick. And I think that's important distinction to make. If developers feel that this is used as a stick, they won't like it. They'll find ways to get around it. But if they realize that this is being used as a guardrail, then if they are deviating from the intention of the architecture, this creates an automatic point where they can approach the architect and say, "Your intention was to guide us this way, but here's the reason it wouldn't work. Can we talk about it?" So it becomes more intentional rather than hidden in terms of the alternatives that are being explored as well. So we can use a combination of these techniques to get that feedback loop and make adjustments as we move forward as well.

Srini Penchikala: Yes, I agree with you. One way enforcement is never going to work. The teams have to embrace the ideas. They have to adopt the ideas and maybe even feel ownership of those ideas, so then only they can fully adopt and start using the solutions.

Emerging Architectures [33:39]

Srini Penchikala: So that's a great discussion about the architect as a role or responsibility. So I would like to also discuss some of the architecture side of the topics.

So companies typically need to adopt hybrid architectures using technologies like microservices where it makes sense, or serverless architectures where they add value based on the requirements. And also there are a lot of other emerging technologies like cloud computing and DevOps. So can you discuss these architectures in more detail and how the architects can ensure correct solutions are being implemented for the business requirements? Like you said earlier, one size fits nothing. So microservices are not the solution for everything, just like the scalability is not needed for every application. So based on your experience, can you comment on this?

Venkat Subramaniam: The worst way to choose an architecture is based on emotion. The worst way to choose an architecture would be based on infatuation. I was giving a talk in a conference and I blurted out saying 80% of the teams that are using microservices are really not building microservices. And somebody posted on Twitter and said “Venkat is wrong. That number is 90%, not 80%.” Well, the point is, I worked with clients in the past year, or so, where they have used microservices architecture, but when we sit down to ask the question why, they don't have a good answer. And they sometimes appear surprised like, "Everybody is doing it, why wouldn't we be building it?" So the very first thing to start out with is don't be infatuated by solutions you want to use. When I was building a house a couple of years ago, and my builder said, "What kind of house do you want?"

And I said, "Gosh, I think that I need the one where I can live." And he laughed and said, "Yeah, that's what a house is for, but what kind of house do you want?” And honestly, Srini, I didn't know what to answer. And the reason I didn't know what to answer is I did not know. There are maybe a dozen different architectures for a house and I now can understand how a business feels like because when you go to your business and you tell them we need to build a microservice architecture, the business looks at you and says, "What does that even mean?" Like my builder comes to me and says, "Do you want this kind of architecture?" I'm like, "I don't even know what that means." So this is a bunch of jargon that we face and we all use jargons, but when we are on the other side of the jargon, when they use it from another industry, we feel the pain.

But that's the life of business people who work with us every day. The first job of a team, and this includes the architect's effort, is to really understand the characteristics of the application first. This is where it takes a lot of effort to remove the emotion. If I walk into a company thinking this is the solution I want to implement, that is not a professional behavior, because that's like the builder walking and saying, "This is the type of house I'm going to build. It doesn't matter what Venkat wants." So essentially, the first job is to understand the characteristics of the application and its scope within the domain. And in that regard, the worst discussion we can have with the business is about architecture. The worst discussion we can have with a team is about architecture because that doesn't even come into picture until we have understood the characteristics.

So we need to really focus on what are the non-functional requirements first. So let's say you tell me that you are a startup and you need to release this product very quickly. If your product begins to make money, you might get more funding, you may start making revenue, you can come back and expand on your business. The worst discussion I should be having with you is about microservices right now, because your goal as a startup is simplicity. Your goal as a startup is time to market. Your goal as a startup is low cost. A monolith is a fantastic option for this because I can get you quickly to market. Once we are able to make revenue, we find this,  90% of startups don't survive. Why would we want to put more money into a startup until we know that it's going to be one of those 10% that's going to actually survive?

On the other hand, if my company says they are having a really hard time making changes to a certain part of an application, that's a volatile industry. And if you imagine, if you take a plane for example, imagine on the plane, there are some areas that are very actively changing and the other areas are not changing as much. If we group them all together into one application, we cannot provide agility to the application because everything is going to drag you down in terms of the coupling. This is a case for business to consider using microservices. By splitting this around the bounded context, you can build one part that can change and evolve at a different pace than other parts. That is one reason to consider microservices. Another reason probably to consider microservices is that you really have different characteristics for different parts of a system or based on the users.

You say we have free users who don't need high performance, but they need some basic functionality. We have premium users, they're paying subscription and licenses, but we need to provide a certain performance and scale for them. That's a reason to divide them across. It's not a division over bounded context in this case, it's a division over the characteristics so it can provide a different behavior for different regions. But that information is not known to us until we understand the characteristics of the application. So architecture is important, but that doesn't come as the first thing to consider. That's probably the seventh thing we need to evaluate. Before that, we need to spend our time really engaging with the business and understanding the characteristics and then to understand what if there are any separations, and the overall business goal. After all, an architecture is to serve the business, not the other way around, where it's self-serving and we want to build this architecture, let's go find a problem is a fool's errand.

I think that's the key to really drive, is the architectures we choose should be based on the business needs, and we need to take time to truly understand what those needs are by way of involving the business. I was in Dallas last year and an architect came to me and said, "We are building microservices. It doesn't work." And I seriously asked him, "Can you explain the word we?" He said, "What do you mean?" And he was working for a fairly large corporation. And I said, "What does the word we mean?" He said, "I'm an architect. I've got a team of programmers who work with me. We are implementing microservices." I said, "That's a problem because your we does not include the business. And if your business is not involved in your development actively, how could you decide microservice is the right technology to use?" And I think that's the key that we need to be driving towards.

Srini Penchikala: Yes, the architects and the teams need to translate the solutions and make sure they align with the requirements. And also I can add a couple of comments here. Sometimes architects and developers, we have this fear of missing out (FOMO). Hey, everybody else is using it. I want to use the same technology. And also we sometimes get into the situation where we create solutions looking for problems. So, "Hey, I just learned Kubernetes, so where can I use it?" Or, "I just learned Serverless, where can I use it?" So like you mentioned, the job of an architect is not to use all the latest technologies, but it is to use the right technology for the right requirements, start with the business requirements, and then also the non-functional requirements. And also like anything else, you can be successful in one thing only when you intentionally decide not to focus on other things. So I think the architect's job can be the same thing. We need to intentionally decide what not to use so we can use the right solution effectively.

Venkat Subramaniam: And this is exactly driving the point of the compromise I was talking about earlier, not just about technology alone, but also characteristics. To give you an example, I cannot tell you how many times I talked to developers who are so hung up on providing strict consistency. Well, if you are so adamant about strict consistency and if your business truly doesn't really need it, that's where the compromise comes in. You are not able to provide high availability because you favored strict consistency, which truly was not important for the business. But we had a discussion with the business. I always say the worst question you can ever ask a business, please never do this, is you go to them and say, "Is consistency important?" You messed with their mind for life. That's a wrong question to ask. If you engage in a conversation, ask, "How do these interactions work?"

They may explain to you how it works. You can then determine if strict consistency is essential, or if eventual consistency is adequate. If eventual consistency is adequate, you can then understand if they have a need for high availability or [inaudible 00:45:08] intolerance for example, and you can provide the solutions to bring that in. But oftentimes, the technical people think that they have to provide the strict consistency. They also feel they have to implement distributed transactions. I call this the self-inflicted wound. By putting these solutions ahead of us, we are actually making it harder for us to solve the real problems for the business. And so this is why I think the key is to give ourselves the freedom to compromise and say, "Yes, my little mind says this will be useful to have, but if the business doesn't benefit from it, I got to let go of that and rework the constraints so I can meet the demands of the business, then my desires as to what to implement."

Generative AI and Architecture [46:06]

Srini Penchikala: And also not only by picking these solutions, putting the solutions ahead of the characteristics, not only we are not solving the business team's needs, but also potentially we would be creating new problems, distributed transactions bring their own challenges. So we don't want our systems to go down because of these overly engineered solutions. Quickly last a couple of questions here. So we have seen the Generative AI technologies like ChatGPT and the GitHub Copilot have taken the industry by storm. So there is a lot of value to these tools. I know developers are using it almost every day to create sample code snippets, automatically generate documentation, and so many other use cases. So how can architects get the best of these tools, to not only accelerate their contributions, but also like you said, automate some of some mundane tasks that these tools can help with?

Venkat Subramaniam: Let me start by saying my gist of where I think AI fits really well, and my slogan for that is use AI to look for ideas not for solutions. I think there's an important distinction here we need to draw. If I look for ideas, ideas are great because it gives me when used to dig into and even consider things I may not have thought about. If I look for solutions, that's dangerous because that prompts me to say, "Gosh, I found the solution, let me use it." And especially for an architect, they need to be able to analyze ideas and pick solutions from them rather than converge too quickly to a solution. Having said that, there are certain areas where generative AI can be phenomenally useful. For example, you can ask generative AI, "What are the characteristics for this kind of application?" One of the challenges with figuring out characteristics is not just explicitly stated characteristics, but those that are implicit.

You may be working in the medical domain, there could be requirements of auditing and rules that could be regional. To give you an example, I was working for an insurance company and very quickly I found out that different states have different laws related to how the insurance business can be done. And for me to discover this by way of discussion with my business analyst and my testers, imagine as an architect, I can get this information by saying, "Hey, here's the domain. Here are the states in which I do business. Tell me what are the characteristics I should focus on." And they say, "Do you know that state of Illinois has these requirements that don't exist in the neighboring state?" That's a valuable information for me to consider. So that's one area where I think we can benefit. The second is you have an architecture. You can feed that architecture and say, "What are the vulnerabilities in this architecture? Are there concerns we need to think about in this architecture?"

And AI can provide ideas for you to look at. It might say, "Ooh, have you looked at this area? People have used a similar solution, have reported maybe these kinds of concerns." It can help us to look through certain concerns we may not be able to know by ourselves, but it can prompt us. Again, that is a nice feedback loop to have from AI where we can look for vulnerabilities to begin with. Another area where it can help is if I can take a set of characteristics and say, "Here is the architecture I'm considering. What do you think?" It can do a critique of it for you and say, "Have you considered these other issues? Your architecture is not sufficient to handle these concerns. Here are the characteristics you have not paid attention to."

That can be extremely valuable. So essentially, rather than using AI to provide solutions, I like to use AI as the tool that can give me [ideas]. I go to the destination, but the GPS helps me to get there in finding the right route. I see the AI as the GPS for my development. So it's not replacing what I do, but it's augmenting what I do. So I want us to start thinking about AI as an augmenting technology rather than a replacement technology. If you don't want AI to replace your job, don't replace what you do with AI. Instead, let AI augment what you do. I think you can use your skills, your capabilities, and the power of AI to deliver better results than to simply delegate your work to AI and call it done. Because if you can do it, your boss can do it too. So that is the key. Find a way to augment you rather than replace you. I think we are going to be more effective doing so and not less effective in the long run.

Architecture Resources

Srini Penchikala: Yes, you can leverage the AI's vast knowledge based on the information out there. That definitely is a preferred option. So as humans, we don't have that much knowledge. So we can definitely use it for ideas and make solutions based on your own decisions. So thanks Venkat, that's a really good discussion. So last question, do you have any recommendations or any resources for our listeners who are either architects, or wanting to be architects, or just working on the architecture tasks? So where can they learn more about this?

Venkat Subramaniam: A couple of things I will mention that would be useful. One of course is InfoQ. So you have a wealth of information on InfoQ. One of the things I really like about it is constantly updated information and a very diverse set of opinions and ideas and knowledge. So obviously, InfoQ is a great place to go. O'Reilly and other publishers have some really good books. My good friends Neil Ford and Mark Richards have written some phenomenal books on the topic of architecture. So please check out the books by Neil Ford and Mark Richards. Their most recent book was the Headfirst Architecture book, they wrote with my good friend Raji Gandhi. They also have Architecture of the Hard Parts, The Evolutionary Architecture, so it's a series of books they have. Mark Richards also has a wonderful site, which is the developer to architect. And if it's not uncanny for me to do a little plug, I am organizing a conference which has got a substantial architectural component to it. It's called dev2next.

Srini Penchikala: Thank you Venkat. We'll definitely add links to all of these references, and thank you for all your contributions to the community. I have known you for a long time and I have seen how much the community has gained from your expertise. So thanks for hosting this conference. The community will get a lot of value out of it.

Venkat Subramaniam: Thank you so much again for having me, Srini. I appreciate it. Thanks to the listeners for being part of it. It's been an exciting journey, but as you said, it's the community that I love the most. One of the most brilliant opportunities we have is to learn with the community. That's what I enjoy the most. I'll leave with the phrase that I often like to use, and that is knowledge is the only wealth you gain as you give. So when you share your knowledge, you only become richer. Thanks for this opportunity to share a little bit of what I know and to also learn from others as well. Thank you again for having me.

Srini Penchikala: Thanks, Venkat. As you mentioned, knowledge is wealth. I think to me, that's the only wealth that matters. Everything else is not that important. Thank you very much for joining this podcast. It's been great to discuss with you one of the very important and timely topics of software architecture because I think it's more relevant now, and more critical now than ever, to contribute to the software architecture in an agile and lean fashion. So just enough architecture is what we need. Nothing more, nothing less.

Also, to our listeners, thank you for listening to this podcast. If you would like to learn more about architecture topics, check out the architecture and design community on infoq.com. Venkat had mentioned it briefly earlier, and also definitely check out the resources that we had mentioned, and also check out all the articles and news items we publish. Like Venkat mentioned earlier, we try to keep up with the emerging technologies and we also want to provide the best value out of what's happening in the community. And we do all of this for you, the developers and architects and the community members. Thank you. Thanks for a great podcast. Thank you.