🦄 Making great presentations more accessible.
This project aims to enhances multilingual accessibility and discoverability while maintaining the integrity of original content. Detailed transcriptions and keyframes preserve the nuances and technical insights that make each session compelling.
Overview
📖 AWS re:Invent 2025 - Navigating the future: Solutions architecture in the age of AI (ARC203)
In this video, John Walker and Dina Hussein explore how Solutions Architects must evolve in the AI era, drawing parallels to Gary Kasparov's "Centaur Chess" where humans partnered with AI consistently outperformed both supercomputers and grandmasters alone. They discuss fundamental shifts: architecture advice now originates from LLMs as an "opening gambit," velocity has increased dramatically (turning months-long projects into hours), and commoditization enables focus on strategic rather than routine decisions. The speakers introduce four SA personas—Inventor, Entrepreneur, Composer, and Advocate—each with unique strengths for different situations. They emphasize architects must transition from reactive to predictive, from planning to simulation, from periodic reviews to constant sentinel monitoring, and become "tech debt liquidators." Practical strategies include querying architectures with AI, generating POC simulations, and automating compliance checks using tools like Amazon Q and Kiro.
; This article is entirely auto-generated while preserving the original presentation content as much as possible. Please note that there may be typos or inaccuracies.
Main Part
Introduction: The Evolving Role of Solutions Architects
Hello everyone and welcome. So who here is at their first re:Invent? All right, first session of re:Invent? That's everybody's hands. All right, we're all awake. That's good. Hey, I'm John Walker. I'm a Principal Solutions Architect here at AWS. I've got 25 years of industry experience and I've got five years here at AWS.
And my name is Dina Hussein. I'm a Solutions Architect Manager with AWS, working with Greenfield customers. My team and I work with some of our most innovative customers, those who are building new businesses on AWS or those who are rethinking entire industries from the ground up. Today, John and I will be talking about where the Solutions Architect role is heading to and how to succeed in this era.
Let me walk you through what we're going to be covering today. First, we're starting with what's changing, and then we will move on to a new game with new set of rules. And then we'll talk about how to evolve our craft as Solutions Architects. And then we will move to strategies to get you started no matter where you are.
The Kasparov Lesson: Humans and AI as Centaur Teams
So let me take you back before we get started. A little story about something that happened more than 25 years ago. This is Gary Kasparov sitting across from IBM's Deep Blue, a supercomputer that can do 200 million positions per second, right? 1997, New York City, Chess Grand Master, first time an expert, a human expert in the field was defeated by an AI. Who remembers this? I was a kid at the time. I remember this one. And so that was the scuttlebutt at the time. Oh, AI is going to take our jobs. It's going to replace us all. It's smarter than the smartest among us. And this really didn't happen.
So game six, Kasparov resigns after just 19 moves, and he said he felt like the ground was shifting beneath his feet. But he didn't stop there. There's more to the story. After this, Gary developed a tournament style called Centaur Chess. So a centaur, it's a mythical beast. It's half man, half beast, right? And here he designed a chess tournament that would take supercomputers, it would take these Chess Grand Masters, and it would pit them against these centaur teams.
And a centaur team was a laptop with an AI chess machine on it, not the supercomputer, but smart enough AI, 1997 to 2005 circa, and humans that would work with this chess AI. And what happened? It's no surprise. The human and the chess AI together, the centaur teams, consistently won, beating a supercomputer that can calculate that many positions per second and beating the Grand Masters. This is our hypothesis today. I don't want to leave you in suspense for 60 minutes. Can we play this new game with AI? Yes, we can.
And I want to take this a little bit further because the game has really been changing. What we've seen in the last 18 months, it's not AI will be useful one day. It's useful right now. And some of the things that are changing, the primitives. We used to think in terms of servers and databases, containers and serverless, and now we're thinking about brand new things. Agents, did that exist? No. MCPs, did that exist? No. A2A, agent to agent communication, did that exist? No. But we have to go build with that. We have to design with it, right?
So the tools have changed. Who's building with brand new tools right now? Not new takes on old tools, but brand new kinds of tools. And then the patterns are changing. How do you put something that is non-deterministic into your program and have it work today? Brand new kinds of patterns you've got to solve for. But then all of that together, there's new problems, problems that you can take off the shelf that have been on the shelf forever in your industry, with your company, with your internal users and customers, things that you were unable to do before this age. So that's what we're exploring today.
What Value Do Solutions Architects Provide?
But first, let's lay some ground rules. Dina, what is it that architects actually do for customers and businesses? Thank you so much, John. So the question is, what value do Solutions Architects provide? This is a simple question, right? But to answer this question, the answer isn't simple at all. To answer this, you need to make many decisions. For instance, what data to store, how to process it, how to organize, how to secure it, and so many decisions, and even some of the decisions branch out into even more with some trade-offs.
So cost versus performance, speed versus reliability, flexibility versus stability, and so on. So you go on from one decision to hundreds of decisions. And here's what psychology tells us about many choices, many decisions.
So when humans face many choices, we freeze, or we make poor decisions, or we tend to pick the first available alternative and we miss better choices. Imagine standing at the supermarket at the cereal aisle with hundreds of brands. You just wanted breakfast and you are overwhelmed with so many boxes. So what do you do? You either pick the first familiar box, or you stand there paralyzed trying to analyze and optimize for a decision that shouldn't take that much time at all.
So imagine that decision isn't about cereal. It's a multimillion dollar architecture which will be the foundation of your business. And here is why organizations need Solutions Architects, because we do three things. First, we explore the universe of choices. Second, we curate the most viable choices. And lastly, we help make a decision by challenging the status quo by asking questions like why, why not, what if, and what about.
Now, some of you might be asking me, hey Dina, but can't AI do this right now? And in fact, yes, the answer is AI can actually give lots of architectural alternatives and it's getting really good at this. But here's what AI can't do. AI wouldn't understand your organizational politics and your organizational context. It doesn't know that your team tried microservices years ago and it was catastrophic, not because of tech, because of culture. It doesn't know which stakeholder's relationship is fragile. It doesn't know that your CEO is risk averse while your CTO is a risk taker.
So AI gives you possibilities while Solutions Architects give you choices, and there's a world of difference between those two. Now let's move on to where the architectural advice comes from, John.
The Opening Gambit: How AI Changes Where Architecture Advice Comes From
Thank you, Dina. And I think it's about those questions, right? Because you can put a question into an AI and it's really good at providing answers, maybe too confident sometimes, right? Hallucinations. But you have to keep asking questions. You're asking questions with a reason. It's because of your team and your organization, so let me tell you about a move.
So there is a thing in chess called a gambit. It's that opening move where you take that first chess piece out and you put it in front, and you know that chess piece is going to get sacrificed. That's the opening gambit, right? We are experiencing the same thing in architecture. So it used to be that you'd sit down with a blank page and you would design things out. It wasn't really a blank page. You'd go to Stack Overflow, you'd Google it, you're not without help. But now what's happening? I have customers coming to me and starting with that opening move. They're giving us the first opening gambit. It's no longer us. The first move belongs to the LLM. It belongs to that agentic system that is pulling out that first pass at a design, and it belongs to the customer.
So whenever we have this shift happening, it's a little bit challenging, but this is changing in our favor. And I'll tell you why. Here's what we've gained. We've gained the ability to explore maybe hundreds of options if you wanted to. So what we can do today is take this architecture goal, the thing we want to do with the architecture, and put it into an LLM and get not just one option. Get dozens of choices, hundreds if you want to, and begin to explore those in depth. How should you do it?
So I can say, give me ten different architectural approaches to a real-time event processing system. It can give me those ten, but then I start asking questions. I trade them off with one another. What is going to be most important for me, for my organization, for the goals that I have, and for what I understand about the rest of the systems that it has to interface with? So I'll take Kiro, simulate a POC, and really the POC is to answer those questions. What's going to happen with this component when it interacts with the other? What happens for security? What happens for scale? Whenever you create a proof of concept, it should be answering a question you don't know the answer to.
And so what's my role now? Am I just using AI to do the work? Am I sitting beside the sidelines and answering questions that customers bring to me, and they already have the first pass at the architecture? No, you're doing something very important. This is not something that's happening to you. You ask the LLM for options. You run the simulations, you generate the POCs, and you exercise the judgment because it's your judgment at the end of the day that counts. And understanding the difference in those architectures that were offered as options and turning them into choices, right?
So what we have at the first pass is you have to become the warden of thought. You are making decisions and judgment at scale. And this is the first thing that we have to choose as a strategy in this game, is losing the opening gambit and winning with knowing a lot of the other moves that we can actually decide from among each other.
Velocity and Commoditization: From Months to Hours
But next, we also have a velocity of change that is increasing. Because we can go grab all of those capabilities, the speed is increasing. So Dina, take us through the speed that's changing with architects.
Thank you so much, John. And the first shift is about where architecture advice comes from. The second shift is equally as important. Think about this example. If customers would have asked us to include intelligent search capabilities to an application years ago, this used to be a few months job, right? So first, what would you do? First, you would start by building the architecture design, review architecture alternatives. You would build a custom machine learning model, and you would integrate everything. So a few months. Now it's a Tuesday afternoon job, right? So you need to spin up Amazon Bedrock with Knowledge Bases, you configure RAG, you point it to your documents, and your job is done.
So from a few months to a few hours, this is not an incremental improvement. This is a fundamental change in velocity. And this is what's happening. When things move that fast, parts of the architecture are becoming commoditized. And by commoditized, I mean architectural decisions are easier now to make and to reverse with less cost and less time. So part of the architecture is becoming commoditized. And what does it mean to us? It means that the commodity decisions, those decisions with a clear right answer, those decisions get super fast and they get perhaps entirely automated.
But the strategic decisions, the ones that are relying on your organizational politics, organizational context, those are still there. And they still need a Solutions Architect more than ever before. Because here is what happens. When velocity increases, organizations tend to do ten things instead of one or two. And those things are not the easy things. They are the hardest, the things that require more innovation. So commoditization is happening, velocity is increasing. But this doesn't diminish our role as Solutions Architects. This focuses it.
Now we need to focus less on commodity decisions. Think about it. Those decisions are getting more like primitives for us to use. We need to focus more on strategic decisions with no clear answer yet. And that's the first shift. Moving on, we speak about the second.
Addressing the Impossible: New Building Blocks and Problem Classes
All right, and so we are going to begin to address a new class of problems on top of this velocity. Because that velocity did increase, and you've got more difficult decisions landing on your desk because of the commoditization of the architecture. So what Dina and I have done is we've really kind of felt that same ground shifting beneath our feet whenever we consider this talk. And so we got into making a discussion about this and thinking through what happens three months, six months, eighteen months down the line when you begin to apply these strategies as an architect. You end up having this as a logical conclusion.
Because you are now addressing more strategic problems, what you begin to be able to do is to address the impossible problems. And not that's impossible right now, but things that were impossible twenty-four, eighteen months ago. Why was it impossible? Because the technology literally didn't exist. It's just been created this year and last year. So think about something that is non-deterministic in nature and dropping it into your architecture. Something that can actually explain, understand, and take action on human language. Those unstructured data that you had to pull out metadata about and then do your best guesses on before, now you can actually understand what's in that document and make real decisions.
So whenever you have, let me give an example first. Whenever you have something like a marketing focus program where you're going to go out and target customers by sitting down a group of folks and asking them questions and getting their feedback, this used to be a really tedious process, still kind of is sometimes. So you get a market focus group, and you're going to ask individuals what they want and what they need. You're going to have to get folks from different market sub-segments and go reach out and develop those groups and go back and forth with your go-to-market strategy, with your marketing campaigns.
What if you can then create pseudo personas in an AI and be able to ask those pseudo personas how this marketing campaign is going to shake out, instead of taking that precious time of human beings and going after that for just one to ten different campaign ideas and getting the feedback of the folks in the focus group? What if you had your AI personas? What if you took those AI personas and used those to get the initial winnowing list? And then you go to the focus group with something that's much more likely to work for your campaigns. Maybe then you're able to get to more focus groups with more diverse sets of customers. Maybe you're able to go to market faster. Maybe you're able to understand your customer better.
So understanding things that have a lot of context, heavy logic, or being able to put in something that can work in persona, like in the mode that a human being would normally operate in, that's brand new. This is something we weren't able to do before.
So increase the scope of your research, your insight, your critiques, whether this is data that's coming back from support talks that you're having with your customers. Maybe it's chats you're having with your customers in a sales situation, but all of that information is now rich enough and available enough to actually take action on it.
Second, I'd say you've got your new building blocks. We talked about this a little bit. You're going to have to take that intelligence and determine where it goes in your system. Let me explain how to identify exactly the kinds of pieces in your architectures that are going to be prone to this sort of change.
An architecture is made of many components. What you want to recognize are those components that have a lot of logic that are baked in, that are a constant source of churn. New rules come in from regulations, new requirements come in from your customers, and you're changing something that is that high complexity piece of code. It's called McCabe Cyclomatic Complexity, and you can actually use your IDE to study your code and find out where this is.
But it's the thing with a whole bunch of if blocks. You know it, you've got this in your code. You may have created it in the past, and I secretly have shame for those pieces of code that I've created myself. But those things where you have a business rule engine, perhaps today, some of those pieces that are trying to understand but don't actually understand, that's where you want to go use some of those brand new building blocks.
And a third kind to recognize, whenever you have a system that is trying to do something, but you're telling it how to do it, maybe you've got five different paths, ten different paths in order to achieve that logic, what you're doing is you're telling it how to do something, but there's a lot of different ways it could do it. Instead, think of using an agentic system where you can use an agent and give it a goal and make it autonomous.
Don't tell it how to do it, tell it what to do, give it a goal and step back and see how it's going to perform. Then make another agent that's going to watch that agent and make sure that its quality stays high. So the second agent to watch its quality is extremely important. So context heavy logic, the new building blocks, and use those goal oriented systems. Think about those things when you're looking at your architecture for the kinds of components that should be changed with these AI based systems.
Living in the First Derivative: Architects Thrive in Change
All right, Dina, we've talked about a lot of things and it feels very overwhelming. I know I felt overwhelmed and I know that a lot of our peers have felt overwhelmed. So what do we do to process this?
Let me make a pause here for a moment. We've thrown a lot at you. So commoditization is happening, velocity is increasing, architecture advice coming from AI, and lots of those things makes you perhaps feel unsettled, like the role that you've signed up for is changing to something that you're not sure about.
Here is something that a very wise architect taught us. Gregor Hohpe, if you know his work from the Enterprise Integration Patterns, "The Architect Elevator," he said something that changed how we perceive our role as Solutions Architect. He said that architects live in the first derivative.
Now, if you remember calculus, and I'm sure some of you are trying not to remember calculus, the first derivative measures the rate of change, not the position. It's not where we are, it's how fast we're changing. And Gregor's point is that Solutions Architects don't live where things are stable and unchanged. We live where transformation is happening.
For instance, organizations don't call Solutions Architects when systems are humming along in peace and everything is stable. They call us when there is a migration to the cloud, when there is an AI adoption project, when there is a novel proof of concept that we need to build, when we need to figure out value out of Gen AI, for instance, and so on and so forth.
So architects live where there is change. We are needed and this is our natural habitat. This is where we have always lived. And by saying that, where there is change, we're needed, we're not trying to be nice. This is not a nice sentiment. This is naturally what the Solutions Architect role is about and this is naturally who we are as Solutions Architects.
John, let's speak about strategies, how to execute in this environment.
Working Backwards: Five Customer Questions and AI-Enhanced Iteration
So I love that talk from Gregor Hohpe. If you haven't read "The Architect Elevator," it's an absolute treat and I think it's extremely pertinent to the time we're going through right now. And that is actually how I assess what my customers need is looking at their change, and whether I'm needed or not at that time. Maybe they're steady state, things are in production, they're humming along, they're not making changes. But where there is change, you're needed.
How do we actually do the change though? This is the question.
Who's heard of working backwards from Amazon? Okay, a couple of us. So I want to talk through five customer questions we apply to every problem that we do. This is actually how Amazon has operated since we were a bookstore, since Jeff Bezos's days in the late nineties. So going through this, we're going to ask five questions. They're not five business questions, they're not five technical questions, they're five customer questions. Every project I've been a part of that hasn't worked right has fundamentally missed one of these five questions. I didn't know it at the time, but now Amazon kind of puts it really clear. This has been used at AWS as well. It's been used the entire time the company's been around. Let me walk you through it.
So first, question one: who is your customer? You do have a customer for every piece of software, technology, or system that you create. That customer is likely someone internal or external. But there's a person, it's a someone, it's not an organization. There's someone who's going to say yes or no. That's your customer, right? Know your customer, know things about them, know what they want, know what's going to actually help them out in their day, which comes to defining the problem. What's actually the problem they're facing? Go define the problem and set down a problem statement. You did this when you did science fair in school, right? You're going to set down that problem statement, and then you're going to have a hypothesis.
So this is really just the scientific method when you boil it down. You go invent that solution. But it's never the first solution, and it may not be what they say they want. It may be what they need and they don't yet know that. That's a possibility. So go break that down a little bit and really see if your problem statement matches what your solution is. Then once you invent that solution, go refine the solution because no solution is perfect on the first pass. Go try it out and see what's going to happen with that solution and test it, iterate, learn what's going on with that solution, and actually define those things before you get started.
Answer those five customer questions. How are you going to measure it? How are you going to test and iterate? What are the metrics that you're looking for? What kinds of customer stories are you going to pull out in order to refine this and go back through these five customer questions? But we don't stop here. This is as an architect what I do. Then I go break down the architecture, I decompose that into different components, and then I put those components back together. It's what I've always done.
With AI, we're going to be able to understand more about our customers. Remember that unstructured data we're able to go ask questions about? Different kinds of data sources, we're going to be able to get this information to listen to them more. We'll be able to define the problem better by iterating on that problem statement against all that information we understand about the customers. Throw this against an agentic system. Maybe use Amazon Quick Suite to go after this. This is a new technology where you can actually go in with a chat system and tie this to your data and go back and forth on trying to refine that problem.
Next, invent the solution. Here I'd go with an agentic IDE. So grab an agentic IDE. I use Kiro as my daily driver. It's Amazon Kiro. It's great, it's an agentic system where you can actually point it at your problem statement, all your definitions inside of a repository, and actually go invent, iterate on this piece. This is where you're going to develop those proofs of concepts and things like that. Fourth, refine that solution. As you learn from those proofs of concepts, iterate, refine it, go ahead and make those changes. Make them rapidly and get them out to production quickly.
And with all that data that's coming back, test and iterate on it and don't just sit on it. Make sure that whenever that data comes back in, you're paying attention to everything. You can pay attention to nearly all of the signals, that telemetry from production, the telemetry from test and dev. Pull it all back in, really understand the system. Okay, but now we're going to move into understanding shifts. So these are fundamental shifts that are changing how we behave. How can we move from behavior A to behavior B? The first one we want to talk about is our former reactive nature and what's going to happen in the future.
Four Critical Shifts: From Reactive to Predictive, Planning to Simulation
So here's the first shift, and I will start it with a question. Can we shift from reactive to predictive solutions architect? Before getting there, let me paint a picture. Think about migratory birds. Migratory birds, they don't wait for winter to come or for food to be scarce. What happens is that they sense micro trends in wind patterns, in temperature before deciding to migrate. They notice this even before the rest of the entire ecosystem notices this. So their main strength lies in anticipation and not speed.
And back to the reactive or predictive architects, reactive architects, and I used to be this architect, they get called in when there is a problem. Systems down, cost spikes, systems are having issues, architecture is getting into a snag.
And then you get called in, you do everything, you troubleshoot, you fix, you make everything go back to normal, and then you're the hero who saved the day. This feels good because we feel wanted, we feel needed, we feel that we've delivered, we've saved the day. But here is how a reactive architect looks like from 30,000 feet away. We're always behind. Why? Because we're learning from failures, from mistakes instead of preventing them.
Now the predictive architect, that's a totally new game. Predictive architects would analyze patterns and relationships between patterns, and then they would use tools like Kiro to query, here is my architecture, based on patterns that you've seen before, where are the risks to take care of? How can I be ready for the next milestone, for instance, when I hit 10,000 users, when we hit another milestone in our project, how to make sure we are avoiding risks? So they're always using AI. And that's actually possible now to become a predictive architect, thanks to AI, because AI can help you analyze those patterns. It can help you actually detect also some problems, mistakes, failures, or technical debt accumulating before this becomes an incident.
So reactive to predictive, that's possible because of AI. And think about it, instead of firefighting, you're fireproofing buildings. So this is the first shift and the second shift, John.
So it does come back to those questions, Dina. If you paid attention to what Dina was just saying, it is those questions to be able to become part of that operational excellence in your team while being an architect at the same time. The time of the ivory tower solution architect is gone. You're going to have to build and you're going to have to get hands on. Let me tell you a little bit about moving from tech planning to tech simulation.
You're not an architect sitting at a drafting desk and developing de novo, coming from a blank sheet of paper and developing that architecture anymore. You're going to have to go a lot further and a lot faster. I've got a confession to make, we're all friends here. I've come up with a cost estimation that has been egregiously wrong in the past. Who else here has made some assumptions that have had the wrong cost estimation by the time it got into production? And the hands that are down, I know you have too. I see you all, I feel you. This is a safe space.
But those things were based on assumptions. It's not because you were doing a bad job as an architect, it's just because you didn't know. Why didn't you know? Because you weren't able to run the simulation to actually see how this was going to compare at scale, right? So there's a lot of these things that you can actually go do at architecture time. I talk about different times in your SDLC, your AI DLC, and if you do get a chance, go listen to the AI DLC talk later this week. Fabulous.
So the AI DLC, you're actually going to have at architecture time, at design time, at development time, at dev and test time, and run time. There's different times you can make different decisions, and a lot of those decisions come forward into architecting time. You can now go, instead of planning that architecture, writing the documents and estimating the cost and coming up with something that's wrong, you can actually go down the path of simulating the architecture before a single line of code is written.
Those two components that you're going to make work together that have never worked together before, develop a POC that's going to test out their interactions, go deploy it in your dev environment and just go have that run at scale. What happens to that when it goes from a thousand users to 10,000, and then plot that linear scale, understand it, bring that data back, and instead of having a long assumption section in your architecture description document, put down the appendix, that's the result of those POCs and all of the things that happen.
And this isn't just cost, this is everything in the well-architected framework. This is security, this is reliability, this is operational excellence. Make sure that everything that you're doing is actually tested, that you have the data and you're bringing it back and you're baking it into your design and your development phase. So this is what's going to happen. We're going to be able to simulate that and really run those POCs, run it at the time that you're doing the architecture design, run it at the time that you're choosing the architecture.
This is going to help you go from options to choices because it's going to winnow down that list from the 10 or 15 that you chose to run POCs in down to five. This is actually where the rubber meets the road, pardon the pun. I got the car on the screen. This is where the rubber meets the road with your architecture decision-making process in order to become that warden of thought. So two more shifts, here's the third one. How do we move to just paying attention to architecture review time? That's a point in time, right Dina?
Constant Sentinel and Tech Debt Liquidation
Yes, absolutely. So this shift from architecture review to constant sentinel is regarding how we maintain architecture quality over time.
The third shift. Now the architects here in the room will understand what I'm talking about when I'm asking how did we do architecture governance in the past? Actually, it's still happening now. We used to do quarterly architecture reviews, monthly meetings or quarterly meetings where all teams would come together, and we'd see work, we'd then approve or we'd send back some work for change. In between those months, in between those days between the architecture reviews, code gets written.
Change happens. Change happens when we're not there in the room, right? It's as if we're working as checkpoint inspectors when the convoy is miles away. So instead of that, think about becoming the constant sentinel who's always guarding, always protecting. How does this look like in practice? Think about it. Imagine every pull request gets evaluated against the principles, the architectural principles which the architect set up. Imagine that every change gets evaluated, or every service deployment gets checked against the Well-Architected guidelines.
This is possible because of AI again. You cannot be in every pull request, you cannot be in every team standup, but AI can. Once configured against your architectural principles, the architectural patterns that a Solutions Architect has approved, and the anti-patterns to flag, it's there. It's reviewing and making sure that every change is in line with your architecture principles and guidelines. So this is the third shift from constant architecture review to a sentinel who's always watching and always guarding.
Taking the noise and turning it into signal is what you need to do. Tie it into your CloudWatch dashboards. Tie it into all of the things that you should be paying attention to as an architect. You can't read every log, right? So next we're going to go to tech debt. Who here's heard of tech debt before? Who here has tech debt? All right. So tech debt weighs you down, right?
Tech debt was supposed to be a good thing, like a mortgage. You're going to take out a loan and you're going to pay yourself and you're going to ship things to production faster. But that's not what happened with tech debt. What happens with tech debt is these are the support requests, these issues that keep coming in and keep burdening your team. This is that system that is in the corner, in that yellowing workstation box that everyone's afraid to touch. And the last person who knew that code has moved on, right? They've taken that 401k and they're writing you stories about their vacations in Mexico. That's what tech debt is today.
You've got to take that old Java framework, that old .NET Full Framework and be able to migrate that to be able to turn it into something else. I've often likened this to canyon jumping. You're on a motorbike and you're jumping a canyon, and you're not going to make it to the other side. Something changed though. We're able to now take AI systems and point them to old code bases and convert them into new code bases. You don't have to sit with the old albatross around your neck.
Go take your tech debt and apply it to a single component. Take Amazon Q, take an agentic IDE, point it at a component and see what it does to update that component in your architecture. Update a library at a time. And then there are some tools that we have. We have AWS Q Transform, right? So you can take that and go transform some of your technology from the old .NET Full Framework into a modern .NET Core. And then maybe you're able to take it off of a more expensive operating system and put it onto Linux.
Then you're able to scale a little bit faster, a little bit better. And so you don't have to have those security bugs that are going to nag you because you fear them in those old frameworks that are no longer maintained. So turn that revolving credit, that old debt into something where it's no longer the monkey on your back. Get rid of it, all right. So this is something that I think that all of us can do. Take that time and turn it into something strategic. Go take one of those problems that were impossible to solve before and begin to solve for them.
The Centaur Moment: Amplifying Architect Superpowers with AI
So this is where we're at with that collective wisdom of AIs and Solutions Architects together. This is our centaur moment. This is where we adopt a new strategy and what we're doing with our role. And I'll tell you, it's not just the architect role. You're going to have to do this first for yourself and you're going to have to take this back to your organizations and teach everyone how to do this. Because if someone is a knowledge worker, they need to become a centaur and you'll help them get there first.
So what you're going to do is to take that machine learning superpower, that AI superpower. And it's not just about automation, it's about amplifying yourself. So prediction, constantly look for patterns in customer behavior.
In simulation, go try things out before it gets into production, before it gets into a dev test pre-production environment where it's more expensive. The further and closer it gets to production, the more expensive it is to change. The cheapest change happens on the architect's desk. Be the agent of change and make that change happen.
Don't pay attention just at architecture review time or whenever something gets to your test because the buck stops here on the architect's desk. This is the last moment of change. Instead, become a constant sentinel. Pay attention to all the CloudWatch dashboards, all of the things that are happening in production, all of the code that's going into your version control system, and then be a tech debt liquidator.
But we're not done. What we want to do is talk about different architect personas. We are all different. We're all going to do things in a different way. So let's talk about different architecture profiles of architects and how they're actually going to address this in a new way.
Four Architect Personas: Inventor, Entrepreneur, Composer, and Advocate
Thank you so much, John. So the different personas comes from the notion that different situations require a different kind of architect, and it requires different kinds of strength. So every architect could be wearing this hat as a sole hat or could be changing between hats depending on the situation. Now when we're speaking about personas, you may find yourself in one of those personas, or perhaps different personas, different pieces of each persona.
The first persona is an Inventor SA. You know this person, right? Perhaps you are this person. An Inventor SA has always got a side project. They are always diving deep, and they like technical capabilities. So think about it. Your colleague, or perhaps yourself, who tries beta versions of software. For instance, if there is a new software released or a service release, they are the first to have spun it up before the keynote is over. So they are the technical people who like to explore what AI can provide. What are the possibilities that AI can provide?
Now what is the main strength of an Inventor SA? It's actually exploration. They like to explore what AI can provide and applying the centaur method. So having a partnership with AI, they can be actually amplified. AI can help an inventor explore more, simulate more situations, and amplify their strengths even more.
When do we need an Inventor Solutions Architect? When there is no validity, when there's a new proof of concept to build. When there is a new technology that we need to test out, when we need to understand what would be the return on investment on this generative AI proof of concept, for instance. Now everyone has their challenging point. What are the main challenges for an Inventor SA? Sometimes they like to explore, sometimes they are in the lab for so long that they forget to sail the ship. So sometimes they need someone to remind them, hey, are we just exploring or are we delivering the value? So this is the Inventor SA, moving on to my favorite SA.
Alright, so who here feels like they're the inventor at this point? You love to tinker, you get in the lab, and sometimes you just get lost in the subject. Alright, so next is the Entrepreneur SA. Maybe this is the SA that's the pal of the inventor that's going to help them actually say, hey, we can ship right now.
So the Entrepreneur, they're going to make bold bets. In every game strategy, there are going to be some people who are aggressive players on the board, and the Entrepreneur SA is that. They're going to find something new, interesting. It's going to light up the back of their mind, and they're going to be the ones that say at 80%, we're ready. This is the one, let's go. They're going to make the bold bets and move.
You know this architect. They'll say, I've seen enough. And so they don't just experiment, they commit, right? So this is the person who's going to take something, and they're going to just evangelize it to everyone. And so critically, they know how to scale what works. They know how to get it into production, they know how to build, and they know how to ship, and they do it often. And they get excited about something, you're going to get everyone else excited about it. I feel like this architect from time to time.
So what is the Entrepreneur's centaur strength? They're going to be able to scale through velocity. So they're going to be able to use AI to actually explore more of that AI space and actually find out the thing that is the idea. They'll have that aha moment and they'll go. And so when do you need that Entrepreneur? You need them whenever time is of the essence. Whenever your market window's closing, when you see your competitors doing some of the things that you wish you had done, that you had that idea, that you wrote it down and you didn't actually go for it yet, that's when you need the SA to behave in this way.
So what's the Entrepreneur's challenge? Sometimes they move too fast, right? They will get up and run, and they are three, five moves ahead of everyone else in the organization.
They will be going right up to shipping, and they need to get everyone else in line with them. Because in order to support a system, you need that whole team. You need everyone in the village around you. So that entrepreneur really needs someone to be their buddy, to be able to say, "Hey, let's bring everyone along. Let's go teach everyone what you've just learned. Let's go make that operational team really sing whenever they ship this thing into production. And let's go bring everyone along for the journey." So that's the entrepreneur. They're playing offense. These are the people who are going to accelerate you through this next set of changes.
Okay, show of hands. Who feels like the entrepreneur SA at times? You've got something that you're just so excited about, and you want to be able to bring that through to folks. Okay, next we have the composer SA, really bringing the synergy to everything. Definitely. So while the inventor SA is the explorer, the entrepreneur is someone who likes to charge ahead and just implement things, execute things. The composer SA is different. They see patterns in chaos. So while the inventor SA would dream about the possibilities, what can AI provide, and they like exploration, they are always in the lab, while the entrepreneur would charge ahead and just execute and implement, the composer SA would take a step back and ask, "How can this architecture work together?" So they like to make sure that every component, every architectural component, is actually working very well with the others, so there is harmony and there is order in the architecture.
What are the main strengths of the composer SA? It's actually this structure. So the harmony that they bring helps them actually be structured in the structure that they bring. And as a centaur solutions architect, the composer SA uses AI a lot because it helps them simulate, it helps them imagine, it helps them visualize faster. So it helps them bring this architecture, this structure, to their minds faster. When do you need a composer SA? When systems are complex, when architectures are sprawling, when there are some mobile services that you need to actually put in order, and you need to create this structure and this harmony in your architecture.
What are the composer's main challenges? They tend to over-engineer sometimes, and they need someone to remind them, "Are we really solving for the business, or are we over-engineering things that should be simple?" And then we move on to the final persona. All right, who feels like they've really got that systems thinking? They're that composer architect at this point? All right, a couple of us. So let's look at the advocate SA.
I have so enjoyed my time working with advocate SAs. I tend not to be this person from time to time, but I enjoy my time whenever I get to share ideas with this person. The advocate SA is really that person who is going to understand the people that are impacted by the architecture. A little analogy. So whenever you have someone who is the architect of a house, you have someone who is the construction lead for a house. Who lives in that house? Is it the architect? No. Is it the homeowner? Yes, you do that too. As an architect, you're going to go build something for someone else to live in, and it better be good. It better fulfill the needs that those people want.
There are two kinds of architectures that I like. There's one that is simple, elegant, beautiful, fun, and easy to use, and there's one that's quiet, sits in the corner, and gets its job done. Those are the only two architectures I believe should ever exist. Yet we create so many that are horrible for the people who live in those architectures. This advocate SA often comes from a business architect background and will convert over into the tech just because they get fascinated. But they really understand the market subsegment that you're in. They understand your niche, they understand your customers. They may understand the industry to a degree that others don't.
They're going to take that level of understanding and really make that architecture hum for the people who live in it. And so what is their centaur strength? What is their strategy when it comes to combining their powers with AI? They're going to be able to amplify that empathy by taking all of that data and really understanding it. Take that information that comes from disparate systems, take it that comes from those unstructured systems, chat transcripts, all the information that comes back in, and then really compose something that really understands who those end users are and what they really, really want. So when do you need that advocate SA? When alignment is missing. Whenever it's just something's not clicking, and people are not picking up what you're deploying. They're not really understanding it and getting it.
You need someone who's going to behave in this way. And the Advocate's challenge? Too much empathy. They're going to try to please everybody. So who's been that person that's tried to please everybody and really not gotten away with it? This is one of those things that I have been really guilty of. Whenever I get into one of those, the trade-off with the tech team, the trade-off with the business team, trade-off with the customers, and then sometimes you get the wrong person that gets their piece of the pie.
So they're going to have to have someone that tells them, hey, this is good enough, we can move with this, and then we can make adjustments after we ship. They try to over-engineer again. They try to get things too perfect, but they over-engineer from the perspective of all of the different stakeholders that are inside of that system. All right, so now let's talk about what happens next. This Monday is different than next Monday. You're going to learn a lot of things here at re:Invent, and what I want you to do is to do these three things to become that centaur SA.
Taking Action: Three Steps to Become a Centaur Solutions Architect
Number one, and these are, you know, you can listen to me, these are the kind of prompts that you can take back. Query your architecture. Take a repo, take some of those design documents that you have and say, here is the problem we had six months ago. I want you to do an assessment. Here's why we chose option A. What other options should we consider now? And what would be the trade-offs? Give me a three-year cost profile. Put that into the prompt and see what happens.
You're going to need some things to make this happen. You're going to need some MCPs. So grab a Model Context Protocol server for AWS knowledge if you're going to build this in AWS. Go grab the cost MCP so that it can actually go query the real cost of these systems, and it'll be able to tell you things that will surprise you. Second, generate a simulation for this POC. So tell an agentic IDE to go generate a POC based on something you don't understand about your architecture. Include some code mockups, give it some resource estimates, and go ahead and get those performance benchmarks. You'll be surprised at what it creates.
Run that, and then you're going to have real data, real information to bring back to inform your architecture and also to showcase what you know, something different than you had before. Third, you have paper cuts. There's a whole lot of stuff that you can automate that you just have not gotten around to. Automate one thing. Create an automated script that analyzes this data for my architecture. Give me the top 10 compliance rules from Well-Architected that need to be addressed, and then shoot this out to me as an email every Monday.
So you can create something in Amazon Quick Suite, it's called Flows. Be able to do something like this and be able to get that email back out to you to understand your architecture on a regular basis. Something that you should be reporting on anyway, have something report to you. That way you really get that deep understanding on a more periodic basis. So you can generate a health score, right? But don't stop there. Oh, I did it, so pat yourself on the back. No, next you've got to do something.
So go take one insight from this. For your most junior teammate, go pull them in and actually start them on their journey. You're here and you're learning this right now, but everyone back home, everyone back at the office does not get to hear this. And you do take those people and start their journey as well. And last, reframe your value. Because someone says, oh, AI is doing all of this work, that is not true. You've just heard this. It's a compatible strategy where you're actually collaborating with the AI in order to produce more value for yourself. So you have to reframe that value.
What's the architect worth? So if you did that POC and say, we evaluated 38 different options for system B, and we were able to de-risk it by simulating a $2 million cost overrun in this POC. Before, it would have taken two weeks, but it took us two hours. Write that down and send that email to your boss, to your peers, to your team that actually helped execute this. This is going to be something where you can cheer for your teammates, you can cheer for yourself, and you actually reframe your value as an architect.
Lastly, summary takeaways. You have new behaviors. Understand that you are now the warden of thought. Your decisions have to be judicious, and they have to go at high velocity in order to really understand what's happening. You have to judge those things that are happening and try to go pull off the shelf those new classes of problems. You're going to change your role, but you're also going to be changing other people's roles at the same time because they'll come ask you how you are doing that and how can we do that for this key teammate.
That responsibility shift, make sure that you're going to be able to take from a reactive architecture mindset to predictive architecture. Simulate the changes, take the components, put them together, and actually be informed. Not educated guesses that you're going to learn from in production, but instead really understand your architecture. Go liquidate that tech debt and really pay attention to your architecture all the time. Your personas for your architects, understanding who they are is very important and how they operate. So you may have to be one of these different kinds of architects from time to time.
Take all of those four different types, take them back and really understand them. And Dina and I want to ask you one favor at the end of this. Enjoy your re:Invent. Thank you for coming to see this talk as your first talk of re:Invent, and we'd love it if you could fill out the survey for us. Please go become that new centaur come Monday. Thank you and enjoy your re:Invent. We'll take questions outside in the hallway so we can switch out. Thank you. Appreciate you.
; This article is entirely auto-generated using Amazon Bedrock.
Top comments (0)