Creating Architectures with the Aid of AI - Venkat Subramaniam

This session explores the integration of AI into software architecture design, emphasizing the distinction between using AI for generating ideas rather than solutions. The speaker reflects on the evolution of programming tools over the last four decades, including the shift from deterministic programming to the non-deterministic nature of AI. He discusses the importance of understanding functional and non-functional requirements, highlighting that non-functional characteristics, such as scalability and reliability, are crucial in guiding architectural decisions. The talk advocates for a collaborative approach that combines human insight with AI capabilities to identify and prioritize architectural characteristics, ultimately leading to more robust software solutions.

[music] We're going to talk about two different things put together here. One is about creating architecture and the other is creating architecture with the with the aid of AI. So we'll bring those two things together here. uh so let's first focus on architecture and then we'll we'll talk about bringing in AI into it as well but before we go that route we are definitely in a time

where we are super excited about what AI can do for us how can we use AI uh to build things we do so I want to step back a little bit and there's a lot of noise there's a lot of excitement around using AI but this is changing pretty rapidly. Uh but the honest observation I have is collectively as an industry we truly don't know where this

is going to go. You can listen to people who are uh keen on marketing the products and they want you to believe something very different from where the reality is. But that's generally the way marketing is. They want us to always uh you know boast things about where things are which probably is not where things are quiet at any given time. But at the same time we

also need to be aware that the technologies are changing very rapidly. So the way I see it is there's a lot of potential but just because there's potential doesn't mean it will turn out to be the way it is. We just don't know honestly. And it is there are two different extremes you can think of. One extreme is AI becomes the next revolution in the in the

in the industry and completely transforms everything we do in software development. Is that possible? Absolutely that's possible. The other extreme is that AI becomes just another tool we use and we still need to work quite hard continuing to use the AI to develop applications. That's a possibility too. We don't know where this is going to end in the long run. But I can definitely tell you about

what it is today because that's something we are experiencing and we can see where it is and what it can do. Now one of the biggest challenges with AI compared to all the things we have done so far if you look back I've been writing code for about 40 years and when I started writing code uh to what we do today it's a very different world we

are in in terms of the tools we are using uh when I started programming you know a lot of times people are surprised when it started programming there was no idees uh there was no windows for example uh I remember as I was working uh we were you know looking at the first version of Windows uh you know 3.1 coming out and then the journey towards you

more graphical user interfaces and systems and we now have a lot of fancy tools and ids to program with they definitely are making us a lot more productive but in all the things we have seen before to what we are seeing Now there is a one clear distinction between those two. You probably have heard this a few times already this week and that is every single thing

we have used until this point has been deterministic. AI is fundamentally nondeterministic. This makes a huge difference in what we can do with it. So this is the dilemma we are in. uh we are dealing with tools that are that are deterministic but to a limited amount of power versus a tool that is enormously powerful but also very non-deterministic. So, so there is this tradeoff between the

two that we have to deal with. But I want to ask the question what is AI really good for and what is AI maybe not uh you know the most reliable for we should really ask. So my recommendation today is use AI for ideas uh and not for solutions. So this is one of the recommendations I often make these days is when you when you look at

ideas are uh uh a lot less risky. So when you work with a team what do you normally ask your team? You are asking your team you know hey what are your thoughts? Well how would you approach it? So a lot of times what you're interested in is really asking the team give me some ideas to work with and ideas have less risk. You want a lot

of ideas and then you want to start filtering these ideas and move towards a few that you want to explore further and take it towards a solution. To me, solutions have a very high degree of uh, you know, uh, rigor in it, if you will. If a solution doesn't work, uh, you're going to be dealing with the consequences of it. So, if I propose a solution and

if it doesn't stand up in production, I'm going to be in trouble with it. So, to pro provide a solution, I need to be able to verify it, be very rigorous about it. So I'm very comfortable using AI for ideas. I am not as comfortable using AI for solutions. Now maybe you know a year later, two years later, 3 years later, we will gain more confidence with

AI and maybe we'll shift towards using it for more for solutions. And and I always ask the question uh at the end of the day no matter what you do right you are responsible for what you deliver. You cannot simply say AI did it, right? You cannot simply do that and walk away. So you need to really take the responsibility for it. So I want to be

able to draw these ideas from AI. So my recommendation is use it for ideas and and not for solutions. But when you create architectures, so when do you normally create architecture? Um you create architecture often times in the beginning of your uh application development. Sometimes you even create architecture before even you do anything at all. Uh but the problem is this when you start on a new

application you often think you know what you need to do but in reality you don't know as much. We often are in denial about it more than anything else. So as you start developing the application is when you start really truly understand the requirements and and things become much more clearer. So we often have this urge to could define architecture very early on. I I remember one

client called me and said can you help us with architecture and I said oh I'll be delighted to and they said no no wait a minute we want to make sure you are really able to and and we're going to tell you what we really need. I said, "Okay, what do you really need? Maybe I can tell you whether I'm qualified to help you with it." And

they said, "Well, we really need an architecture and you need to be able to provide uh solutions on cloud and concurrency." I said, "Okay, great. You want cloud and concurrency? Got it. Can you please tell me what are you actually building?" And they said, "We don't know yet, but we need cloud and concurrency." Right? So that's one of the problems is we don't know what we're doing

but we know exactly how we're going to do it and and that is a risk in itself. So we need to really take the time to understand what we are actually building. So how do we actually create architecture? Well, we often create architecture uh you know based on essentially things we know already. So sometimes it begins uh with you know things just falling in place. Uh I

was working with a client and I had the opportunity to work with multiple teams in this company and I had worked with about six different teams and I went to the seventh team and I and don't get me wrong right I'm not trying to bash any technology or praise it here. I'm just making an observation. So I went to the seventh team and I sat down. I

looked at the team and said, "Let me guess your application runs using Java and uses Spring Boot." And they're like, "Yeah, how did you know that?" And I said, "Because that's what every other team has been doing in your company, right?" And then I said, "Why is it Java and why is it Spring Boot?" And they looked at me and said, "What do you mean? That's what

we are supposed to do, right?" Because we were given a reference implementation and they said, "Oh, so sometimes you don't really do architecture. you just follow architecture because it's been given to you. That happens also quite a bit unfortunately. So it's from based on the past experience or because other products have been built similar to it we end up doing such things. Uh or there could be

a lot of other ways architecture falls in place. But the problem really is in almost all of those approaches, you need to really ask the question, is that the right architecture? And if that's not the right architecture, you're going to feel the pain for it later on. And essentially what you're going to find out is a misalignment between the architecture and what it provides to what the

application needs are. And you're going to have this misalignment and you're going to have to deal with that over time. Not only that, if you create an architecture based on what you know, the world is not a static place. What you need today may not be what you need maybe 5 10 years later. So, as a result, you may have to modify your architecture as well. You

know, it's easy to think about this in more concrete things. Let's say you have a you're constructing a house. Well, in your house, let's say you have nice stairs and you can get into the house and and everything is great because you're healthy and young. Now, maybe you're living in this house for a long time. Maybe 30 years goes by. You're not the same young person you

are. And now you're like, gosh, I cannot go upstairs so easily. Would be nice if I can have an elevator to go up. Well, you cannot just, as you know, just throw an elevator into a house and say, "There you go." Well, it's an architectural concern and in all honesty, right, as as we are trying to build houses, one of the things we are asking the builder

is, we don't want an elevator now, but can you put a facility for an elevator later on? And honestly, the builder says, you know, I'm going to build a closet for you, but when you get older, you just open the closet, we convert that to an elevator. I'm like, good thinking, right? So but that is something you need to really think about and say how can you

really amend it and there are times when you try to make changes to what you have to be able to build things in a similar way in a software system your needs may not be the same over time you may think of a few things you need today maybe 5 years from now your needs are different how can you bring that into your architecture is a concern

you need to deal with in the software systems as well but why is it really so hard to create an architecture uh you know effectively but a lot of times the reason it's so hard is we are often either eager to create an architecture we often rush into it or even worse we are infatuated by what everyone else is doing and and because everyone else is doing

something we believe we should be building that too and as a result we end up building what others are doing rather than what we actually need to do. This is one of the problems we are fighting today is that people feel that they have to create architecture what others are doing what's popular because that's easier to get another job. uh so often times uh architecture is created

by what is called uh traditionally architecture is driven by what's called RDD which stands for rédriven development right so this is basically you are developing things based on what you can put on your resume that's not a good way to create an architecture but but that's driven by saying oh if I do this then I can put that on my resume it help me to get my

next up but unfortunately we're not doing a good service to the uh application we are developing so we need to rethink about it. So the question you want to ask is do you truly understand what you are actually building and and if we take the time to understand what we are building then we tend to really focus on the the relevant architecture rather than an architecture we

desire to build. We focus on building an architecture that's essential to build Excuse me. So when you look at applications, what are the things you normally look at? So when you look at an application, you often look at what are called the functional requirements. So what are the functional requirements? Functional requirements are the requirements that tell you what the application will do for you. So if I'm

creating a banking application, my functional requirement could be I need to be able to transfer money from one account to another account. That's a functional requirements. Oops, I shouldn't go near the microphones. So essentially the idea behind a functional requirement is you're describing what the application should really do for you. But as it turns out in all honesty, when you look at a functional requirement, how do

I implement a functional requirement? And you can say it's not really that hard to do, is it? So you want to transfer money from one account to the another. Big deal, right? You basically know there is on one account, you see where the information is about the account. You have another account, you know where the information is. You do the the debit on one side, credit on

the other side. You're done. So usually I would argue dealing with functional requirements are not really that difficult. But then applications not only have a functional requirement, they also have what are called the nonfunctional requirements. Unfortunately though when we traditionally right when you're when you're learning about software development when you're learning about building applications unfortunately we tend to focus a lot on functional requirements and and the

word non in nonfunctional requirements is not helping us because when you hear the word nonfunctional you're like that's lower nowhere right that's not as important that's nonfunctional functional this is more important it's functional so we tend to really you know not give so much importance to nonfunctional requirements so so maybe rather than calling it as a nonfunctional requirement we could probably call it as characteristics this is

a term that Neil Ford and Mark Richard just use in their book on architecture I like this term characteristics but when you elevate this term to characteristics now we are not trying to diminish it as something less important But as it turns out, imagine again for a minute I'm building a banking application. My functional requirement says you need to be able to transfer account. I'm like, yeah,

I can do that. Not a big deal. Now, the characteristic says you must be able to support a 10,000 concurrent money transfers at the same time. And now you're going to say, "Oh boy, if I have to support a 10,000 concurrent requirements, I got to rethink about how I'm going to be able to do this because I need to think about the number of threads I need

to run for processing the request, the hardware resources I have, a lot of these things are going to make a difference. I have I have a client that I I worked with and they do a lot of math operations. Let me just putting it very, you know, uh nondescriptive. They do a lot of math operations on on data. And you say, gosh, what does it take to

do math operations on the data, right? Not a big deal. Well, then I found out that when you run the program, we perform 53 billion computations. Now, think about that for a minute. If I have to run 53 billion computations, I cannot run that on a machine like this. It's not going to be able to take it. I got to rethink about the hardware I need to

use. Well, it turns out we need to really run these computations in parallel and send a lot of data. And now we are thinking maybe we should use Spark and we should be able to use a network of computers. We need to bring in a map produce algorithm. And all of a sudden we're not talking about the functional requirements. We're asking how can we practically run this

code to provide that kind of you know performance or that kind of scale depending on what we are trying to do. So my my point here is that in general one of the things we need to really think about is these characteristics and I'm going to go out you know call it out and say uh you know it is uh you know so I'm going to say

more than uh the functional you could say right functional uh requirements uh the uh characteristics you could say uh you know have so characteristics uh have a greater uh impact uh on the architecture. So this is one of the reasons why characteristics are so important. So your architecture is not as much driven by functional requirements. Your architecture is driven by the characteristics and and characteristics make uh

the most difference if you will in terms of uh how we are going to build this application. Uh so essentially the problem is this if you don't really understand the characteristics you're going to be ending up building applications that don't have the architectural alignment. And if you don't have the architectural alignment, you're going to see issues in production when it has to behave very differently than what

you have planned for. And that's going to be really a huge problem. So what are these characteristics? Characteristics often are called as when it comes to applications. So the characteristics play a very vital role. Uh for example, reliability is a characteristics. Uh some applications require higher reliability. Some maybe not need that much. If I am building an application for medical uh you know related uh you know

uh uh processing uh if I'm monitoring a patient well it better be reliable because if it is not reliable and I am dealing with the patient that could result in potentially a major injury or a loss of life that has consequences. So reliability becomes very important in those cases. If my application is monitoring uh flights, uh reliability is very important otherwise you could be causing accidents if

you're not being very careful. So, so reliability is a big concern in certain applications may not be in others. Uh similarly, you may think about scalability. Uh scalability is important in some applications may not be important in other applications. This is one of the things we need to be careful about. Right? when I'm teaching courses often times I would ask people what are the important things for

architecture and design and somebody would say scalability I'm like not really right you cannot throw these terms and assume scalability is extremely important why why is it not always important uh you know let's think about this for a minute right if I'm creating um a bank application and if I have a if it's a very large bank and if I have uh you know millions of customers

for the bank. Well, scalability probably is very important. So, we can argue that scalability is something we should consider. Uh, if this is a credit union and my credit union has thousands of users, well, let's be honest. Is scalability your primary concern? If your application cannot handle a thousand people, we got a bigger problem to deal with, right? So, scalability is not a huge concern. I was

once working with a with an application and don't get me wrong, right? I I I respect applications I work in. This application is very noble. This application was helping children with learning disabilities to cope with their learning. So very very useful application. I have the deepest respect. I I like to really be part of such application development. But we were developing this application and one of my

fellow developers was very unhappy and said why we got to make this really really uh you know better in its in its behavior. We got to cut down all these calls and I and I said hang on we are developing the code right now. we are trying to bring in the functionality but why are you so you know apprehensive about modifying this call and why are you

so keen on reducing this call and he said oh you should never make these multiple calls because if you do it'll affect your scalability and I said hang on hang on let's talk about this for a minute you said it will affect scalability with all respect can you tell me how many children use your application on a given day and he said, "Oh, our entire center has

about 200 children, but on any given day about a dozen of them use the system." And I said, "If you have a problem with scalability when a dozen people use your system, we got to really understand what we are dealing with, right?" So, so a lot of times we read in the books. This is something that Dave Thomas told me one day. He said, "The worst book

you should to read, you should never read." He said is the book on is the en the medical encyclopedia. I said medical encyclopedia why shouldn't I read it? He said because as you start reading the medical encyclop encyclopedia you start thinking you have every disease that you read about right and then you spend the time thinking about it. That's one of the problems we have. You read

about scalability in a book and suddenly scalability is your concern. But the question is is that really your concern? You need to understand if it's such a characteristics. Similarly, you need to ask the question is performance important for my application. Similarly, things like observability, traceability, usability, upgradability, a lot of these things uh could be a concern. And if you start searching for these, you probably will end

up with about 4 dozen of these its. So just Google for this and say what are the it or characteristics of applications. You will fill up three pages of these characteristics. Now once you look at these characteristics what is the worst thing you can hear from people you go to your team and say can you tell me which characteristics are important and the worst answer is everything.

Right? Because if they say everything is important, you know, this is not going to go anywhere. Why? Because characteristics come with tradeoff. You're not going to be able to provide something and just walk away. You cannot do that. For example, um if the room temperature is very cold, I'm not comfortable. So, I want to keep the room warmer. Well, that's great. But if I make the room

warmer, I'm going to spend more on utility bill. And the utility bill, when you get it at the end of the month, you look at it and you're like, "Oh my gosh, that's $300 in electricity bill. I I don't want to spend $300 a month. I want to lower my electricity bill." Well, guess what happens when you lower the electricity bill? The temperature lowers in the room

as well. And now there's a tradeoff here. So, I can put a few more layers of shirts uh and and clothing and I can keep myself a little warm. I can keep the temperature a little lower and my bill is lower. So, now I'm dealing with tradeoffs here. In a similar way, if I want more scalability, how do I attain more scalability? You can attain more scalability

by creating multiple instances. You can get more scalability by replicating your uh shorting your database. Well, when you create multiple instances, when you short your database, now you have to make calls across the network, your performance will go down just a little bit. So, increase scalability, you decrease performance. You increase performance, you may have to decrease scalability. So, you have these tradeoffs that you have to deal

with. So you cannot simply get one thing raised up and walk away not affecting any other thing. So when you look at these characteristics, you can group these characteristics into multiple categories. Uh some characteristics are intertwined or dependent on each other. So when you modify one characteristics, another may get affected uh alongside. But then there could be another group where if you modify something in this group,

it doesn't affect anything in this other group. So we need to understand what these consequences are and what affects what as well. And this is where prioritization becomes very important because if you prioritize something, you say, "Oh, scalability is more important than performance for this part of the application." Whereas here performance is more important than scalability. Oh. over here availability is extremely important. Reliability is more important

than anything else. You need to be able to prioritize what's important at each of these stages for you to be able to decide on architecture. So once you prioritize them and like I said characteristics has the greater influence on architecture. So you need to identify the relevant characteristics and and be able to uh say here are the characteristics here are the priorities. So then the question is

how do you identify these characteristics? So the first thing to keep in mind is you don't as a developer, as an architect, as a programmer, as a technical person, the worst thing you can do is get into a room, sit down with your programming team and try to identify the characteristics. That is a terrible idea. Why? because we are the people who are implementing these systems. So

what's on our mind? On our mind, we are so eager to figure out how to implement things. So if you ask me, right, I'm a programmer. If you ask me what are the characteristics I should think about, I'm going to start throwing things at you based on what I think is important to implement. This is one of the things I often tell my developers. You should never

ever ever go to your business people and ask one dreadful question. Right? Never do this. You go to your users uh business analysts or business people and if you ever ask them is consistency important. You doomed your life forever. Because if you ask them is consistency important, guess what they're going to say? They're going to say absolutely important because they don't know what they just said. Now,

from that day on, they see you walking down the corridor. You're rushing to the bathroom. Doesn't matter. They will block you on the way and say, "I just want to make sure you're dealing with consistency, right?" Because you just seeded in their mind a little problem there to worry about. They wake up in sweat at 3:00 a.m. thinking about consistency from next day. Right? So the most

important thing about characteristics is we should listen and not talk. So we need to first go to the business and say not in words like what are your characteristics but to say tell me about the application and start really listening to what the business is saying. This is one of the challenges. The most important skill of a programmer when it comes to implementing the application is to

listen to what the business needs and not to try to convey what we want to implement. So if we take the time to listen to them, we then begin to really form the ideas of what the characteristics are that's relevant for the application. Then we work with the business to prioritize Now, here is one of the challenges we're going to be dealing with when we work with

programmers. If you ask what are the characteristics, we're going to have people throw a lot of things and they are not relevant. They may not be relevant. But you want to sit with your business and the programmers and start really talking about the application needs and requirements and as they are talking silently start writing things down and say oh they are talking about doing these kinds of

requests that translate to these characteristics we need to really think about. Now when you one of the things to keep in mind is the is the following. So the question is how can we identify so how can we identify uh you could say right identify the uh characteristics. So the first is I would say uh you know uh uh bring your business uh I would say business

and uh tech folks uh together uh and [clears throat] uh discuss the application needs and along the way identify the characteristics. So this is the very first step I would say that we should do. Now you say but wait a minute there is AI why don't I just use AI and be done with it. So I often want to take human first AI next approach and I'll

tell you why I do this. I I'll give you an example of this. One of the things I often do these days is I I review books and I and I love reviewing books because when you review a book uh which is being written, you get to be the early reader of a book which means you get to learn from the book before anyone else even sees

the light of that book. Right? Because you're reading the book while it's being written by the author. So that's one reason. The second reason is uh you are able to actually help the author write a better book. I have greatly benefited from people who have reviewed my book when I was writing it. So I understand the benefit of having reviewers review the book. I benefited from it

personally. So now I give it back by reviewing books others are writing so I can help them to write a better book as well. Now having said that the when I when I look for reviewers when I when I seek out people review my book the people who are the most useful for me are the people who give me feedback on how I can improve the book.

The worst reviewers are the ones that say it looks good. I'm sorry I didn't ask you to give me a book to say it looks good. I want you to tell me how to improve it. Right? So the quality of the review is very important. So here's the problem. I'm working with a few publishers. They would send me books to review and say, "Can you review this

book for us? We want to improve the book." I'm like, "Sure." And then you get a link to a, you know, to a repository, a book, a a page, and the book is literally on that page. And when I click on the link and I go there, you know, maybe they reached out to me a few days later or they reach out to me a week like

this, I'm extremely tied up. I'm not going to be looking at anything until when I'm returning back on, you know, I'm on the flight is when I'm going to be reviewing things. So, by the time I get there to the link, guess what happens? There is comment from other reviewers. Well, I get really mad when I see it. Why? Because the minute I see reviews from others,

I've completely lost my ability to be original. And so I tell my publishers, I would love to review the books you want me to review, but on one condition. You're going to send me a separate PDF with no markings on it. So when I start reading it, I form my original ideas and I will then convey my feedback. You don't have to take them. These are just

ideas, right? But I don't want my mind to be corrupted by the feedback others have provided. So this is one of the things I want you to think about when you sit with your team and you're asking your team what are the you want to make sure your team spends enough time thinking deeply about the application you are building. If you rush through this, then you may

miss out on essential characteristics. And if you miss out on essential characteristics, eventually you're going to discover them. And that's going to be a problem problem later on. So this is why I want to spend time with the humans. I will sit with my team of developers and also my business and take the time to understand what are the characteristics. Write them down. Now that you have

written them down, the next step here is to go to AI and say describe the application to AI and ask for uh it to identify the characteristics. So first notice what I did not do. I did not go to AI and say hey here's the application give me the architecture right that would be a terrible approach because you shortcircuited so much that needs to be done to

get a better architecture so don't rush to AI first and don't go to AI and say here's the problem give me the architecture I want to go home so what you produce will only be as quality as the effort you put into it to create it. So what happens on step number two when you go to AI and say here is the application what are the characteristics

you're going to notice a three different things right now right now the first thing you want to notice is your team has identified some characteristics and AI identified the same characteristics so what does that tell you hey that's great we found some characteristics and AI also gave us the same character istics. That's awesome. That's the first thing you want to find out. The second thing you want

to find out is that your team identified some characteristics but AI did not because AI is not perfect. AI is not deterministic. Your team has sometimes better context. What happens in general? You might have a team member who is a veteran developer who or or a veteran business person. This person has been in the financial industry for 20 years. When you're sitting and talking to this person,

they might be able to tell you about characteristics that come deeply rooted from their experience in the domain or they may have been with the company for the past 10 years. They may tell you about things that are done in a certain way in that company. Those are important characteristics for you to carry forward. So what you're going to notice are the characteristics your team is going

to identify that AI doesn't. Then the third thing you're going to identify is characteristics that AI is going to identify but your team did not. So those are the three things you're going to be able to look at. Now when AI is telling you characteristics your team is going to say aha uh we did not talk about it. Is that really relevant? And your team can then

say, "Oh, yeah, that's really relevant. Gosh, we missed it, but good catch and let's talk about it. Let's put this as important." Or they say, "No, no, no, no. AI is saying it because it's seen those things in other places, but that's not relevant to what we do because of these reasons." But this really gives you an opportunity for you to discuss further. So what you do

in this case is that you you know create a union uh I would say of all the characteristics uh from humans and the AI and then uh prioritize right so the uh uh the characteristics. So here is one more reason if you bypass the human uh aspect what's going to happen when AI tells you the characteristics you have not taken the chance to think through the application.

So you don't have the ability at this point to evaluate the quality of what AI is suggesting. So as a result by spending time on the problem before you go to AI you have provided yourself the opportunity to have enough knowledge to discern between sensible ideas and things that are not relevant and if you don't take the time to do it you don't have the ability to

evaluate this is one of the things I often uh tell my developers is the most important skill you need to have is the ability to evaluate what's being presented in front of you. Whether that's being presented by humans or whether that's being presented by AI, it doesn't matter. But you need to be able to look at it and say that is sensible, that is useful or that

one is of no use. Let's not worry about it. But the only way you're able to do that is if you have spent enough time on the problem before you start looking at these different uh you know uh characteristics that can be coming from humans and and AI and you have that captured at that point. So it's a very highly collaborative effort and you then collaborate with

the business and with excuse me. So start by collaborating with humans first then collaborate with AI and and bring it together. So let's think about this for a minute and see how we would we would approach it and and this is where we can have a bit of a richness of what we are creating as well in in terms of uh the effort and how we proceed

with it. So let's take a look at an example here just for a for our purpose and and see uh how we could we could create it. Right? So so here is a is a pro problem. So let's take um a problem and and I'm going to say here's a tax software I'm going to describe and and see what we can do. So so look at this

uh application. It's you know big enough to read right? So so just spend a couple of minutes reading it. It's describing a software that's going to help people file uh taxes. So, it's talking about you should be able to collect the tax information and you should be able to file federal taxes, you should be able to file state taxes. Now, unfortunately, uh in the US, uh we

not only have to file federal tax, depending on where you live, you may have to file state taxes. It can even be worse. Some of us live in one state, work in another state. Now we got to file tax not only federally but in two states as well. So this can be quite a bit of things to work on. Not only that, I always there are a

few people in the world I don't ever envy because their life is much more horrible than my life will ever be. If you want to ask me to list people I don't envy at the top of the list I would say is people who work on tax software because imagine you work on a talk soft tax uh tax software uh the amount of complexity in it is

unbelievable not only that if you write a tax software you got to keep it updated I can't tell you how many times this happens in the past years you or I buy the tax software and I start it. The first thing it says is you need to update it. I'm like dude I just bought it. But why do I have to update it? Because the rules have

been modified. Then you enter the tax data and then suddenly it says we got to update it. Why? Oh, because they just change the rules and we got to update it. So almost every year the tax software keeps updating so many times. I say almost every year. This year is not a problem because we don't have a congress in the US this year as you know. So

as a result there's nothing happening. So it's been pretty stable overall. But the point really is that this software needs to be you know constantly updated because the rules change even you know as you get nearer to filing they got a new rule and it's got to change these rules and apply it. So that's kind of the software that it's describing in terms of what it should

do. So I want you to think about this for a few minutes. Right now, one of the things I mentioned earlier and and we cannot really meet that expectation is I said don't bring a bunch of programmers into a room and ask them what the characteristics are. What did we just do? We brought a bunch of programmers into this room and we asking what the characters are,

right? But in reality, you want to be with your business. You want to be with your domain experts and you want to be able to ask these questions uh you know and and not not saying list me the characteristics but to talk about it to be able to extract. Now when it comes to there are a few things that we need to be a bit careful about.

The first is there are implicit characteristics and there are explicit characteristics. What are explicit characteristics? explicit characteristics are characteristics that might be just stated in your in your you know documentation someplace. For example, one of the explicit uh you know um um characteristics may be that the uh ATM uh should be able to dispense money uh even when the network connectivity is lost. But in such situation

limit the amount dispensed to this particular amount. So you are still making money available to your customers but at the same time you're not going to empty the machine when the network connectivity is not there. So that might be a you know requirement stated right but that's a characteristics very specifically stated. It says what your application should do in terms of a network failure and how does

it deal with availability. But uh unwritten implicit characteristics could be uh things that are kind of obvious in the domain but unless you know the domain you may not really know it or even worse because you know the domain so well you tend to really forget it because it's so obvious and you don't write it down. Both of those situations are pretty dangerous. So for example you

could have certain privacy requirements. You may have a certain uh security requirements. There could be other things that require for example uh a filing rules and requirements based on your domain and SEC may have a requirement to file a certain things and and in in certain businesses they work with there is a requirement about traceability and they should be able to come and pinpoint and say who

modified this at what time did they modify which computer they were in. all the slew of data that you need to collect could be something that's very you know well known but you have forgotten to really list it down. So you need to really take the time to identify these in general. So given this you can go through this and identify some characteristics. So let's spend a

minute on this to see if we can identify a few characteristics in here. Yell out a few things that come to your mind knowing this problem now. What was that? >> PIA handling. What does PIA handling >> Oh, personally identifiable information. So, so uh you know personal uh so is are you talking about privacy? >> Yeah, part of privacy then say privacy. It's easier to just say

simple terms. Thank you. So privacy, right? Good. Awesome. What else? Can we get a mic writer up there? >> Thank you. Any anybody else? >> Yeah, there there's few hands up there. Awesome. Thank you. >> Raise your hands if you'd like to ask a >> Availability. You said availability, right? Yeah. So, availability. Thank you. Especially uh if you are trying to file a tax and it's not

available. And when do people file tax? At the very last minute. Why? Because this is not a pleasant experience. Why do you want to do it any sooner? Right? I normally wait until the very last day. There's a reason for it. If I want to die that day, why do I want to spend my time filing taxes? Right? So, there's a really good reason. And you just

want to postpone it until you no longer can postpone it. Somebody else had a comment. Security. All right. Security is is good. Cool. Uh what was that? Scal scalability. Um okay. Usability. Love it. >> Consistency. >> Oh, was that >> consistency? >> Oo, I'm going to say correctness. Thank you. Uh correctness. uh consistency. Uh so I'm going to say correctness more than consistency in this case. It

better be correct, right? >> Yeah, same here. I was also talking about adaptability. >> Uh uh you said adaptability. I'm going to put upgradability, right? You must be able to upgrade constantly along the way. relaxibility. Um I I this one is making more noise than you can. So I'm sorry. What was your comment? >> Um it's adaptability in terms of >> in terms of the editing the

business center because that's uh ability to archive. Uh Ruth uh cool you need better record keeping right. Okay. What was that? All I hear is a it. Sorry. >> Flexibility. >> Accessibility. >> Thank you. Thank you. >> Modifiability. Right. >> Accessibility. Lovely. >> Uh modifiability. Upgradability as well. In terms of that, I'm going to do one more here. I'm going to say interoperability, right? because you need

to be able to communicate with a lot of systems. So let's kind of put a cap on that. Thank you. I really appreciate that. Good group. Yeah. One more. >> Partition and fault tolerance. >> Uh fault tolerance. Absolutely. Right. So recoverability is important too. Right. So fault tolerance uh and then upon failure. Um so awesome. So u so >> traceability. >> Thank you. So what I'm going

to uh do here is we can list these and you can start prioritizing these right and once you do take the time with your team right with the business and again don't ask your business list them you want to really have these conversations and as you're having conversations you want to start listing them rather than just telling them give me a list. That's not a very effective

way. Well, now that we did that, let's take this problem for a minute and let's go to any AI tool, right? Doesn't matter what the tool is. And you can say list the uh described let's say below, right? So I'm asking list the characteristics for the application described below and I'm going to paste that in there and you can ask AI to come up with that particular

list. So it says architectural characteristics for the tax filing security is a top priority. It says did we identify security? Yeah, we did. Right. Then it says legal and regulatory compliance. I don't think anyone said that but that's one that we can think about and say oh yeah we should probably think about it interoperability did anyone say that >> yeah so that's that's very important localization and

internationalization it depends right uh it depends on where you build this software for in most civilized world we care about it in US we don't give a damn about it so it depends on where you hard right so unfortunately so that could be an issue may not be but that's where the discussion has to come from and say yeah that's very important or yeah no we don't

care about it or yeah maybe eventually but not right now that's not our priority uh scalability somebody said that uh reliability and availability we covered that too hey we've been doing good right so uh and then workflow and state management modulating configurability the gentleman over here said configurability Right? So that's very important. Auditability, somebody said that too. And observability, payment processing, we got to take the money

from the users. Right? And then notification and messaging, usability, accessibility, somebody said that. So it covered a few things. Now, real quick, there is one more thing you need to do as well. And that is in addition to what you said what we did I want you to think about one more thing when it comes to describe this to AI and ask for the characteristics. Now very

important uh make sure to ask at least three different AI models for this. So why do you think I should ask three different models? any ideas because they are not consistent. Because they're not consistent, if you rerun that, you may get a different list the next time. So by running this on three different models, you get much richer set of things to evaluate. So, so this is

essentially the route you can go to gather more information. So what is the next thing we should do after this particular stage? Your next step is now you got this comprehensive set of characteristics that was created by your humans and by AI and you have a union all of this and then you start prioritizing it. How do you prioritize it? A ask your humans to prioritize it.

B take it and go back to AI and say given this problem given this set of characteristics remember that characteristics is from humans and multiple AI models you say given this problem given these characteristics can you prioritize it for me now compare the prioritization by AI sorry by humans and the prioritization by AI and see how close we are but what does this help how Does this

help us? You can go back to your team and say, "Hey, you said this is low priority, but this one here are the reasons why it may be higher priority. Can we talk about it?" So, you're able to reiterate over it a few times. Once you do that, what you have on your hand now is a prioritized list of characteristics. Once you have a priority list of

characteristics, what's the next step? Now you go to your because the business often doesn't know about architecture right so you go to your programmers you go to your leads you go to your architects and say given what should be the architecture once you are humans debate about it think about it argue about it and we say given these characteristics here are the architecture or architectures that we

want to create and once they do then go back to AI and say given this problem given this prioritized what do you think the architecture should be and your humans have selected a certain architectures AI has certed a few architectures and now you ask the question which of those makes more sense And now you have more things to discuss, more things to think about. Notice in this

process what we are doing and what we are not doing. What we are doing is we are using humans and AI to really improve the richness of the effort to create the architecture to identify the architecture. What we are not doing is simply delegating it to AR AI and saying here's a problem tell me the architecture but I'm going to ask you one question and see if

you're able to answer it if you take a problem and throw it to AI and say hey AI given this problem what should the architecture be can anyone guess most likely what that architecture is going to be there you go microervices standard is a beautiful word. That's a industry mess. Not a standard. That's a industry mess because that's what every fool has done. So essentially, it does

what it's seen the most. That's the unfortunate thing, right? So it doesn't tell you what's right for you. AI is an inference engine. It's going to infer based on what it has seen. So if you bypass these steps and take the problem and say AI what should be the architecture microservices and you're like see I told you right and you can follow the crowd and you get

the same results as the crowd did. So is microser the right solution? Sure, in some cases it's the right solution, but in a lot of cases it may not be. And so by going through the steps, by creating a more detailed set of characteristics, by prioritizing it and then evaluating it and then asking AI, you have done two things. One, you have really taken this step by

step. So you're providing a lot more details and the context and the process for it to give you the approach. Secondly, because you went through this with the humans, when you see humans recommending certain architecture and AI recommending some architecture, you have enough now to compare and discuss and to be able to discern between what's right versus what's wrong. and and as a result your journey through

this can be a lot better. And and so my recommendation is yes AI is powerful but it's not powerful in the way we think it is where we simply feel like we can just rush through and throw things at AI and get the results. To me the power of AI is to give you these so many different ideas. The power of AI is not to give you

the correct answer. That's not what AI is really capable of. AI is very capable of giving you ideas. It's not as capable of giving you correct solutions. So by using AI for these ideas, you are able to benefit from those different ideas and concepts. And when you do arrive at a solution, you have used a lot of these information and help and you are driving something that's

a lot very richer and useful as well. So take that approach in incrementally and iterate through it but also spend the time with humans to be able to really arrive at that. That becomes very critical. Hope that was useful. Thank you. Heat.