What is the path to becoming a cloud solutions architect?

Hello. Hello. Hello. So who here is aspiring to be a solutions architect, whether at AWS or at your own organization? Congratulations. You've come to the right session.

Who here is already a solutions architect? Ok, a couple of you - welcome.

Who here is building a solutions architect practice at your own organization? Congratulations. You too have come to the right session.

My name is Norman Wan and I'm a manager of solutions architecture at AWS. Today I have with my buddy John Walker and he is a principal solutions architect at AWS. Now, John here traveled the journey or dare I say walked the journey that you are about to embark on or already embarked on. So I asked him to come here and share with us his story and his journey.

John, that's a funny pun on the name Walker. I get that sometimes too. So thank you Norman. And I've learned so much working from you these last few years and it's a lot of great experience you have. And here I want to share a little bit of my experience that I had as a young architect myself.

So my first encounter with falling in love with doing the work of solutions architecture really came with a problem. So there was a problem with the flagship product and it was before I came over to AWS and it had some performance issues and we needed to on board some diverse data sources and the customers were complaining a bit and I went to the owner of the company and I said, hey, let me go ahead and rewrite this for you.

So that, that was my mistake. Number one, number two, it was a million dollar project right to go rewrite part of the flagship, the beating heart of the software system. It was gonna take nine months. I got to work and I fell in love. I just loved being an architect. I loved designing things and coming up with design patterns and solving the problem and coming up with novel ways to get around some of these, these issues customers had been facing.

But what had been happening at the same time is customers were living with the existing architecture and it had been changing. And what had happened was the lessons that I'd been picking up designing brand new solutions trying to do a rewrite. I had been feeding back into the support team and the architecture that was lived in now became product number one and my product became product number two.

So what happened was the customers were satisfied with the existing product. My product was canned and that's one of the ways that architects can fail and architectures can fail. But I think it wasn't a complete failure because I, I wasn't fired and I was actually promoted into being the chief architect.

Later at this company, move this product through a series of evolutionary changes to being a software as a service application. Architecture. That's my subs specialization as a solutions architect within AWS now moved over to AWS three years ago and that's my path to becoming a solutions architect. But I learned some things, architectures are living systems and they evolve, right? And they're intended for those who use and live in those architectures.

No man. What are we going to be learning on the path of a solutions architect today?

Yeah, before I get started there, thank you for that incredible story of resilience and also humility. So today we're gonna talk about who is a solutions architect and what do they do? What are the different paths to this role? What are the skills you need to be successful in this role? And lastly, we will leave you with tools to get started no matter where you are in your journey. So with that, what is solutions architecture and who is a solutions architect?

So the open group architecture framework defines architecture as the structure of components, their inner relationships and the principles and guidelines governing their design and evolution over time. Now this definition is based on IO I triple Eiec. But if you go consult your favorite source for all things, technology, you will get a different definition. But chances are that definition will encompass the three different parts of this definition. So let's take a look.

So the first part, the structure of components, this means that each component has a role and a responsibility and correct assembly is needed to make a whole their inner relationships. This means that each component has a web of relationships to other components and there may or may not be a direct dependency and the last piece, the principles and guidelines governing their design and evolution over time. This means that change is anticipated, evolution is expected and a foundational belief system is needed based upon which choices are made today and onwards.

But this is architecture in general. We're here to talk about solutions architects after all. That's what we promised. So John, you're a solutions architect. What do do solutions architect do?

So we're going to define solutions architect and we're starting with some foundational definitions and that really resonates with me. We talked about the evolution of architecture, right? And now let's talk about what a solutions architect is specifically here. We're talking about a cloud solutions architect and this can be a cloud solutions architect at at your company that deals with AWS may not deal with AWS, but let's talk or it may be someone who is a solutions architect within AWS.

So a solutions architect is, we'll define it as a person who designs and guides technical architectures to solve a business problem. So we talked about and architecture and that it's supposed to evolve. It's got components, right? You have to be able to solve the problem. The problem is defined by the business and it's solved with the technology and it's the job of the solutions architect to put those two things together.

So definitions out of the way foundations laid. What do solutions architects actually do Norman?

Oh wow, what time is it? Ok. 306, maybe your mind is already on dinner or perhaps an afternoon snack after the session. So bear with me.

So if i ask you the question, who made this dish? Your answer likely will be while the entire kitchen made this dish. But if I asked you the question, who created this dish, what would be your answer? It should be chef de cuisine or the head chef. A solutions architect is the hat chef of their own kitchen. Let me repeat that a solutions architect is the head chef of their own kitchen.

Now allow me to explain the head chef is the person who takes that business needs the customer needs and creates the first proof of concept. They draw upon their vast culinary experience and they envision they experiment and create a dish. The head chef is the person who is defining the structure of components, the sauce, the garnish the base, the focal points and they're also defining the interrelations through taste, texture, temperature plating and so forth.

Now, the head chef then explains the whole dish to all the other specialized chefs in the kitchen. The specialized chefs are the ones that perfect the technique. They are the ones that elevate the individual component. They do all of this while still staying true to the original vision and the foundational system put forward by the head chef.

And of course, lastly, the head chef oversees the preparation of that dish meal after meal service after service. Now, if you've worked in a kitchen yourself before or if you're a fan of the many reality cooking show, you know that a head chef does much more than this. They work with vendors suppliers, wine pairing, experts, management, health regulators and so forth.

So a head chef works with their kitchen team to deliver that dish. A solutions architect works with their technical team to deliver that solution, that product, that component that has an independent and stand alone value. So a solutions architect really is the head chef of their own kitchen, John.

I know we've been talking about head chefs for a while now. So it's obvious why a kitchen needs one, but why do companies truly need someone fulfilling a solutions architect role?

Great question. And it did make me a little bit hungry. I won't lie. So having a solutions architect is really there to be able to build and deploy faster so an architect needs to think through which pieces of the architecture are going to cause the deployment of systems to slow down.

So if you look at some of the statistics around what happens whenever you release to production faster and faster, the quality of the system actually goes up. Right. So if we're going to help build and deploy faster, we're going to experiment more often, more quickly, try out new things and release value to production more frequently.

Second, we're going to lower and mitigate the risks being able to look at and try new experiments to do proofs of concept, to make sure whether a concept will work before building it into the architecture is one of the core responsibilities of a solutions architect.

In addition, we take all of these learnings that we have and we build them into creating an informed decision so that the business and technology teams just like those other specialists in in the chef example, would need to be able to take that information and execute extremely well.

And last, we need to learn and to teach the best practices here at AWS. We have architecture, best practices based on the AWS well-architected framework. We have six pillars of the well-architected framework. We have a white paper and we also have a tool that you can use to go assess your architectures against the best practices that AWS has found out dealing with thousands and tens of thousands of our own customers.

But talking about the solutions architect and who we have to communicate with Norman. How does that communication actually occur?

Sure. All right. So data architects, network architects, security architects, that's you up on the screen, software engineers and developers. I saw you with your editors up already. That's you up on the screen dev ops engineers, testers and management. You too are also on the screen, business leaders and product management. You are sitting in that boardroom.

So who connects this boardroom to all the technologists on your right? It is the solutions architect. The solutions architect is the communication glue, but the rule is much more than just connecting the solutions architect is not just repeating the same information. The solutions architect is not just amplifying the same message from the boardroom to these technologists.

In fact, they are understanding the business need, then they are creating the technical architecture, the solution architect then communicates the technical architecture and the relevant business details to all these technologists. On the right. The solutions architect is communicating why you should care what you should care about and how you're gonna solve for the thing that you care about.

Now, why you should care about is likely going to be the same for these technologists. What you should care about is likely going to be different for these technologists and how you're going to solve for the thing that you care about is most definitely going to be different for all these technologists.

So the solution architect has to tailor their messaging to the recipient. They need to really speak the language or the dialect or the accent based on who they're talking to.

Now. Of course, conversely, the solutions architect is not just repeating every single technical decision or every single technical challenge back to the boardroom. They are translating those into business risks and business capabilities and communicating that to the board.

John, this is how a solutions architect communicates and with whom they communicate. But where exactly do they sit within an organizational structure?

This is really true for me and the dealing with customers and how we need to take the business problems and be able to communicate this into the technical jargon of individual specialists. It really resonates with me. And if you have a chance, I'd highly recommend you attend uh gregor hopes session. He is the author of the book architect elevator. He's here at AWS and he's talked about how a solutions architect, whenever they're a really great architect, are able to talk the language of the folks in the board room all the way to the folks in the engine room. And this is really what we're talking about here.

But whenever we're talking about how architects work within projects, what actually happens whenever i have to go execute a project nomen. So let's talk about team blue and yellow and team pink here and we've got our team of orange architects that's in uh this, this box here on the left. And we've got a separate architecture or a separate organizational structure on the right. There are many ways to solve this problem. These are the two structures i most often see whenever i see architects organized inside of project teams.

So first, whenever a company starts out having a solutions architect to solve four project problems, usually there's already multiple projects going on and they'll bring one person into the role of the solutions architect. They may not even have that title yet, but they're doing that job

And often this person is, is shared as a pooled resource and that's highly efficient to start out. And these architectures are going to be coherent because it's going to be the same set of folks working within the same team as architects that will be shared amongst multiple projects. This is pretty efficient until it isn't because you end up context, switching the more and more projects you add the problems of scale begin to add up.

And as you have about, you know, 60 to 80% of your time being spent as an architect on one of these teams, it may be time to start thinking about a different organizational structure to put your architect into. And another one of the drawbacks that we sometimes see is if you're an architect that is in a single architecture group, you may suffer the anti pattern of being an ivory tower architect, who here has heard of the term ivory tower architect before nobody wants to be the ivory tower architect.

So i'll tell you the antidote to the ivory tower architect. What you do as the architect is, you must live with the consequences of the decisions you make. Therefore, the architect needs to be involved with some aspect of the delivery of that project. Whether it's a proof of concept, building a minimum viable service, whether it's creating a new design pattern in a library, they should have to dive deep and really get into some of the details in order to live with the consequences of their decisions.

But this isn't the only way neman tell us a little bit about the organizational structure on the right. Yeah. So the organizational structure on the right is usually and i use that word usually the answer to scale. You see that in this model, the solutions architect is directly embedded into the delivery focused teams. These teams are laser focused on delivering that product or that component that has stand alone and independent value.

Typically in this model, we see cohesive architecture. So movement to microservices, strong interfaces, api driven interfaces and so forth. Now these delivery teams, they can make local decisions, they can make local decisions on what libraries to use, what frameworks, what platforms to adopt, they can make local decisions on risks and they can make local decisions on tradeoffs. So velocity really picks up here.

I know john said earlier, one of the reasons why we should have the solutions architect is to build and deploy faster. So the solutions architect is facilitating those that high velocity decision making within these teams. Now, of course, there is always a not so positive attribute to this model and that is increased coordinations outside of these teams. It's not natural for reuse or um to go discover something that another team has already built.

So a strong discipline for documentation for discovery and reuse is absolutely needed in this model. So we talked about how and with whom a solutions architect communicates, we talked about where they might sit within an organizational structure. And we talked about that a solutions architect creates technical architecture. But how do you actually do that job?

So the the job of doing a solutions architect, solutions architecture, you actually have to work inside of these teams. So when i'm in one of these teams, what do i actually do? That's what we'll cover next.

So we saw the communication diagram and those folks who are going to communicate the business problem that they want solved with a technology solution will tell you exactly what they want. Not everything is doable. Some of it you have to communicate and iterate and come up with that vision for what you want to achieve together. This is the goal, this is the shining goal to go try to achieve in order to do that though. You need to make sure that you agree on the direction and that you set a strong technical direction.

Second, that direction may include things that i don't know how to do yet. Maybe i don't yet know how to use redshift ml in order to plug in an llm, which was just released on sunday, right? So i have to go learn this, this is a research spike. I have to go pull up how to do the innovation. I'd start an innovation spike. I'd do a proof of concept. I asked the question that needs to be answered technologically and i on board that new technical capability in order to do this work, i have the capabilities that i already had.

Maybe i already knew how to use sql server databases, right? Maybe i already knew how to use those in the cloud with reserved instances. Maybe i already knew how to use web design and to create websites. What we end up creating though is a combination of our set of capabilities and we create a design. The design work is so fun. You take those problems that are big and you break them down into their component parts. This is called decomposition and you solve the individual problems, then you recombine those solutions and that's called rec composition.

And how you choose these architectures to go back together, ends up being your in-state design. But that design is not the whole story. Of your architecture. The architecture is a living system. Yes. So that living system is going to be that combination of your design and that system architecture that gets implemented. This is the dev system test system production system that's actually running and people are using creating operating living with the consequences of and by the way, this is a great ex uh a great opportunity for the architect to get in there, create something and build along with the team inside of that project, get your hands dirty, roll up your sleeves and do a little bit of the work so that you can live with some of that.

And how do you know that your architecture that you designed was successful, norman, you don't know unless you measure it right. So you need to build into your design, build into your architecture methods of inspection. So go ahead and put in kpis, maybe make sure that your logs are going to create metrics that go out to cloud watch, roll those up into dashboards. And what kind of metrics do you need to care about? You need to care about the things that you're trying to solve for with the business problems.

So build out a dashboard that shows the kpis, the key performance indicators of what business problem is trying to be solved. Sew it all together. You will have created a wonderful design that people are actually going to see whether you're getting the business value out of the system that you created and you get to live with a little bit of the consequences of your decisions and people begin to create and you c uh close this loop as a continuous cycle.

So after inspecting the system by measurement, we've done our job. So we've talked about the definitions of a solutions architect laid the foundation. We talked about how that's a little like being a head chef of your own kitchen. We talked about methods of communication and we talked about organizational structures and now how that job is actually done inside of the project.

Now, i want to move on to the core theme, which is the path to becoming a solution architect. And as we talk about the paths to becoming a solution architect, we're gonna cover four main ones, but these are not all as many architects as there are that i've met at our customers that i've met at aws and other places. There are that many stories and that many paths to becoming a solution architect. So we're just going to cover four archetypes, norman, why don't you kick us off?

Yeah. So every aspiring solutions architect, as we go through this uh four types, ask yourself the question, am i this persona or am i a little bit of each of these personas? I know there's executives and leaders out here who's building a solutions architecture practice? Ask yourself the question, what kind of solutions architects are we going to bring into our organization.

So the first uh persona is the inventor essay, an inventor essay. Let's talk about the origin story of an inventor essay. So these may be folks who get their start tinkering right in a uh garage, you know, like our own aws origins uh being able to get into uh research, right, laboratory work. Um this is uh someone that is going to start up in their career, perhaps in start ups or incubators or at universities.

And then this is where they first encounter. Like i first encountered my approach with architecture, their responsibilities to grow into doing architecture work. So they'll tinker, they'll uh get into the lab and that's gonna give them great energy. But the superpower of an inventor solution architect is that they're actually pushing the envelope and creating the things that do not exist yet. You'll hear about a lot of those today at re invent.

No man. How do we recognize these inventor essays when we see them in the wild? Yeah. So the inventor essay, they have this tremendous curiosity and they have an idea whether it's a pie in the sky idea or a simple idea or anything in between. And they have this desire for this idea to be born from their mind into this world as something real and as something tangible, the best place to see some of the inventions that came from the minds of these inventor essays through the work of their hands is at the builder fair.

So everyone in this room, this is a full house. I need you all to go check out the builder fair at the expo hall at the venetian. That's the inventor essay.

So the next uh essay type is the entrepreneur essay. So these folks started out their career perhaps as a uh business subject matter expert, perhaps they have a business degree as a subject matter expert or as a business development expert, they get into greater and greater detail to get the subject, right? These folks draw their energy from draining about the impossible scale of what the solution can do.

Entrepreneur essays, they communicate with conviction, they communicate with vigor. These are the folks that make others see the vision. So the best example of an entrepreneur essay is infrastructure as a service. That was a concept in early 2000. And it became the solution of aws that is the core mindset of an entrepreneur essay. Anything else, john?

Yeah. So entrepreneur essays, i love running into these entrepreneur essays in the wild. And uh for me, i deal with uh small and medium business customers as a solutions architect. And i'll meet these folks and they're usually owner, founder types or they're people who've come up with a wonderful idea. And to them, it's something that is stuck in their mind's eye and must be created. They can't really rest until it comes to fruit and so we heard about the inventor essay who creates something that's brand new that's never existed before.

That entrepreneur essay will take that and make sure that it's in everyone's pocket and they're not going to stop until they get there. So the entrepreneur essay really has to solve those problems of greater and greater detail and scalability and how is it actually practical to take that invention and to get it out to the masses? And so i want to see a show of hands who knows one of these entrepreneur essays in their life right now.

So i see a couple back here. So no man, what are uh what are some things that we're looking at in um in the path of a composer essay? I'd say the first things. So number three for our composer essay is that they have the the background, the origin story of getting in with computing or engineering, they um start their career sometimes as a developer or an engineer type. And as the session was starting, i talked with a few folks here in the crowd and, and some of you are in this kind of a mode already.

You're in the developer, engineer type and you're thinking about what happens next in your career. I wanna assure you're in, you're in the right place to figure this out. So as you get into solving some of those architecture puzzles, this is what gives the composer essay energy, right getting into a puzzle, laying it out and figuring out where, where every single piece will go and what superpower these folks bring is taking an idea and making it repeatable, taking a design and deriving a pattern, creating a library or api that everyone can use, making something that's going to be repeatable and scalable and usable by everyone.

So norman, these uh composer essays, what is it that you often hear them asking from the composer essays? They usually ask the question, how does it work? And then they asked the question. Yeah, but how does that work? These are the folks that look underneath the hood as to see how the system was put together and why it works that way for composer essays. For many of you in this room, the entire world is made out of beautiful patterns for you to discover unfold, repackage and reuse.

So aws on the aws solutions library, there's over 1300 solutions already published there. Some of the composer essays are the authors to those solutions. So go check it out. Aws solutions library.

All right. So the the last uh persona is the advocate essay. So an advocate essay, they start their um origin or their origin is in information systems. Perhaps they have a foundation in humanities or liberal arts. Their entry point is customer facing roles. So sales marketing q a and they get to hear from the customers what the customer needed in the first place to get their job done. And what was the friction in the first place?

An advocate essay? They get their energy from thinking about elegant systems and elegant solutions where the customer is at the center of that architecture of that solution. The superpower of these advocate essays is they have an extremely high bar and they will not stop until there is an elegant solution. A simple solution that is easy to use for the customer.

So the the composer essays, you will bump into these folks and they will ask, how would the user want that to work? I think you meant the advocate, essay, advocate, essay, advocate, essays. Thank you very much norman.

So the advocate essay will ask, why doesn't it work that way yet? Right. So they'll ask, you know, how would the user like it to work and why doesn't it work that way yet? And so uh i find advocate essays working to bridge that design gap between that business problem and the technical solution

And I'll say that a lot of SAs come from this origin story and really do try to build perfection out of the designs that need to be used, need to be lived in. And so here you can take a look at some of our AWS customer success stories that we have out on our website and really dig into how the customer was served by the architecture and what some of those success stories look like and maybe you'll recognize the profile of that advocate. SA.

So we've talked about our four different paths. These are just archetypes and we want to ask a question now, who here sees themselves in one of these paths? One of these types? Good, good. I, I see a lot of hands going up. All right. So now you know what to look for. And even though you have different reasons for taking this path towards solution architecture, you have the same destination, the same role, the same job to perform what we want to get into. Next is some of the skills and tools that you can use. You can take away from reinventing today in order to fill out that job, that role of becoming a solutions architect.

So the first thing we want to go to, first of three is the tech skills, then we'll go to business skills and then some soft skills. Ok.

Tech skills, learn, build and teach foundational. What you need to do as a solutions architect is to learn how to learn, teach yourself first, whether it's through blog posts, it's going to see talks at conferences. Thank you. You're in the right place. You are doing a good job of learning, whether it's watching videos, listening to podcasts, reading, actually getting hands on doing workshops and labs yourself, do yourself a favor, teach yourself first and prioritize your time to make sure that you get to learn because much like the practice of being a doctor or being a lawyer. You don't get better by doing the job in the moment. You get better by teaching yourself how to do this job before you even have to be faced with a problem to solve. And a lot of that work is teaching yourself next though.

Second built, we don't want to become that ivory tower architect. So roll up your sleeves, go out and get into some workshops, get into some proofs of concept or POCs go out and create a minimum viable product. MVP, a minimum viable service MVS go build. There is so much delightful complexity that exists beneath each layer of the things that you are creating that you're designing that you're asking other people to go do much like the metaphor of the head chef. You need to taste the dish before you serve it to people before you ask others to go create it. And before you try to scale that up, next is to teach. Teaching. No. And I, I guess we're doing that right now right up on the stage teaching, but you don't have to go talk to a crowd of 100 or hundreds of people. You can teach through individual things that you take and maybe make a design on a white board. Don't do it alone. You have to cosign together, cote together, right? Write a blog post, build a proof of concept or a sample make sure that you share your knowledge. You're not going to be able to metaphorically plate every single plate of food. You need an entire team working with you and you have to teach that team what your concept is for your architecture vision that you wish to achieve and make sure that you can get it inside of the heads of other folks who are actually going to execute in order to bring that vision to fruit, right, learn build and teach

Next business skills. All right. So solutions architects, you absolutely need to have business skills. You are in fact the executive, the executive persona. So number one, the head chef needs to know how their business makes money. The head chef needs to know who's their top client target clientele, what's on the menu? What's not on the menu? How does seasonality come into um revenue generation? Very similarly, a solutions architect needs to know how their business makes money. As a solutions architect, you need to know who is your customer? What is your product? How does the customer consume your product? What are the constraints in your business and outside of your business? What are the laws and regulations governing your product and your industry? These are all the things that you need to know as a solutions architect to deliver that technical architecture. A head chef is keenly aware of the organizational structure of the kitchen, of the wait staff of the management. Similarly, the solutions architect needs to know the organizational structure of your own organizations. John mentioned earlier. One of the key reasons to have solutions architects is to increase velocity. If solutions archi architect can only do that if they can efficiently and effectively navigate an organizational structure, so they can remove roadblocks so they can mitigate risks and so forth. And lastly, corporate finance, a head chef needs to know the financials of the kitchen. They need to know what is fixed overhead. They need to know cost of goods sold, they need to know what levers do i have as a head chef. Very similarly, solutions architect. You need to know how the software purchases and hardware purchases affect revenue. You need to know how cloud computing pay as you go model affect revenue. These are just some of the examples you need to know as a solutions architect to deliver on the technical architecture we've been talking about for the last 40 minutes. So business skills solutions architects, you are the executive.

All right. So this uh I I think this makes a lot of sense to me. No, and thank you for walking us through this one and being able to take corporate finance and weaving that back into your design would say a cost and usage report is going to make a lot of sense for knowing which of your services, which of your features, which of your systems and environments are costing you the most money and how you need to take this information back to communicate to those folks in business, in that boardroom, in the language that they want to be spoken to in. It also helps you explain to perhaps a database architect, why you need to choose one database over another. So these business skills are indispensable.

Lastly, we want to get into our soft skills, curiosity. So curiosity is going to ask you, uh it will lead you to ask why, ask why five times is the old saying? Right? So be relentlessly curious about how systems are put together, go out to some of our solutions library and look at other architectures that have been put together by other architects and learn just like those tech skills of learning. But as you dive into the task of trying to design a specific cloud solution, ask why ask why of the technologists and ask why of the business folks next is going to be courage, have courage in order to get unstuck. This is the secret to uns sticking norman. I never have perfect information. If I wait until I collect perfect information about the architecture or about the business constraints or about the technologies that exist now or may exist in the future, I'd never create anything. So have courage to say we have enough information to make a move right now, stick a fork into the ground, make a decision and move.

Next is going to be conviction so a stanford professor paul saffo says an architect and technologist should have strong opinions loosely held. This means that you need to have conviction that whenever something good comes along and you're paying attention because you're teaching yourself constantly, you recognize it, you're able to capitalize on it, you're able to take the opportunity and build it into your architecture. Know when you need to make a change, know what your architecture is to begin with because you're not going to architect just at the beginning and let it go and let momentum, take the wheel. That's not what we do. You have to be involved every step of the way and make sure that your conviction is going to guide your architecture's evolution.

Fourth is going to be communication, communication is not just speaking, it's not just writing or designing. It's all of those things. Make sure that as you develop your mode of communicating, that it's going to be clear in writing. It's going to be clear in communicating verbally, it's going to be clear in communicating your designs, your design documents. And it's got to be in some of the language that your specialists need to understand. So take your mode of communication and tie your organization together.

And last architectures are meant to be lived in. I want this lesson to come through today. Have compassion for the people who will use your architecture every day. How will it affect them? What happens to a user. What happens to a user when she or he has to use your application every single day for their day job? What points of friction do you have? Do you create a design that's beautiful, easy to use and elegant or do you create a design that does its job quietly and gets out of the way? Those are two of my favorite and most beautiful design approaches.

Next though, we want to have some tools to take away norman, it wouldn't be reinvented without takeaways. So get your cameras ready. There are some QR codes here and feel free to snap photos and take these away.

All right. So one of three, the first one is learned, we have over 500 courses and learning paths on a w skills builder in over 16 different languages. So go ahead and learn, take a curated learning path that fits your need, learn at your own pace or learn just in time, then go ahead and reinforce that learning and validate that learning by getting certified. Every aspiring solutions architect in this room. Go ahead and take the solutions architect, associate certification. Now, if you've been doing this for a while, go ahead and take the solutions architect professional exam. Of course, if you have both, go challenge yourself and take a specialty certification in machine learning or security and networking and so forth. So who here is planning on getting a certification this week while you're out. I know I heard some of the folks here. Yes, I heard a couple of you that were looking at getting a, a certification.

So next, so we had learn, you know, we're going to build. So as you build, we talked about the aws solutions use the solutions library. There's 1300 of these, you can go out and deploy these already, you uh can study what other people's architectures are. And so this is going to help you flex that muscle to become a stronger architect in your skills and go use our best practices. AWS provides you with the AWS Well-Architected white paper and the AWS Well Architected tool. Whenever you're creating your designs or you're assessing one that existed before you got there, let's face it. We've all had to get into some of those, a little bit of a mess. This will help you sort things out. So the AWS Well Architected tool is there to guide you with the best practices that have come from thousands and thousands of AWS customers being able to build on the cloud and build successfully.

Next three of three is teach. So what good is knowledge if you lock it and keep it away. So go ahead and share your wisdom. The easiest way to start sharing your wisdom is answering questions on AWS repost if a question is already answered. But you know, the first question, the answer is never the right answer. Go ahead and respond uh post your alternate answer, share your wisdom and john heroes, heroes. So every hero has an origin story. We had a little bit of the origin story discussions today about our path to becoming a solution. Architect AWS heroes are enthusiastic experts in the community who really take a passion for teaching. And we recognize those folks you too can become an aws hero. But regardless of what happens, uh you have learned what it takes to become a hero yourself. Perhaps this is your origin story.

So I want to encourage each and every one of you to take a little bit of the lessons that you've learned here today and go on and become the solutions architect that you want to be or to build this role out within your organization, using these tools, using these skills and using some of the structures and communications that you've learned about today. And I want to encourage every single one of you, please. It means so much to me. If you could fill out that um survey in the mobile application, it would mean the world to me. I want to thank you very much for the time that you've spent with myself and with no man here and no man. Any parting words.

Thank you everyone for coming and being inspired at a w at re invent john and i will be hanging right over there if you want to come and chat with us. Thank you, everyone.