The well-architected way

Hi, everyone. Good afternoon. Thank you so much for joining us today. I'm Ilana Greenberg. I'm the senior product manager for Well Architected.

Hi, everyone. I'm Samir Kopal. I lead product and engineering for Well Architected.

Awesome. So before we go ahead and get started, how many of you are familiar with Well Architected or know what it is, show of hands?

Ok, love that. Great.

So um as some of you know, the Architected framework and tool is really helped to meant to help you ensure that you are building your systems and best practices in the cloud um in a way that makes sense and you're following best practices, right? And so as Werner says, everything fails all the time, so plan for the future and nothing fails. And that's really where Well Architected can come in.

So um when you think about how you build and manage your systems and applications in the cloud, you should be asking yourself, are you well architected? We hope that today we can provide some guidance on, you know how to actually implement Well Architected and scale it into your organization.

So back in 2012, there was an outage with one of our most popular services which impacted some of our customers. However, we realized that there were some customers who were actually not impacted at all. So we wanted to understand why and what we found was that those customers that were not impacted, actually were following a set of certain best practices consistently.

So we went out to understand, ok, how can we share some of these best practices that these customers were following as well as the insights and data that AWS had and share that more um broadly with our community and our customers. And that's really where Well Architected was born.

So as some of you know, Solutions Architects or SA's as we call them, then started providing AWS best practice guidance for architecting in the cloud across operational excellence, security, reliability, cost optimization and performance efficiency. This resulted in a collection of white papers which eventually became the first official AWS Well Architected framework.

So from there, SA's continued to help customers implement those best practices found in those white papers. And over the years, we launched with AWS partners to help provide customers with that more hands on guidance for actually implementing and understanding best practices.

And then in 2018, we actually created the Well-Architected tool. So the Well-Architected tool was created to give you a self-service way to actually learn, measure and improve your workloads using the Well Architected framework. I'll go into the framework and the tool in just a few minutes.

Since then, we've really focused on making sure that we're updating the Well Architected framework as well as the tool to meet the needs of our customers.

So in 2020 we launched a full set of API's which helps you integrate your Well Architected best practices into anything that was existing already, like your systems and dashboards.

Then we started implementing customization features, like being able to mark best practices and questions as not applicable. This really came from understanding that not all best practices or questions are applicable to every single workload. And so that was impacting what risk we were giving you after you did the Well Architected review.

Last year we implemented and launched the sixth pillar of the framework, the sustainability pillar as well as custom lenses, which actually allows you to bring in your own best practices into the tool to use as an overlay to the Well Architected framework.

Samir will go into details about custom lenses a little bit later on. Most recently, we also launched an integration with Trusted Advisor and Service Catalog App Registry and really that helps you provide context at a resource level to help you increase the speed of your workload reviews and help save you time when doing a Well Architected review.

Samir, we will also touch on that a bit later on.

So diving into the Well Architected framework a little bit more. So this framework has really been developed through years of feedback and insights from our customers. It includes a set of questions and best practices across six pillars, as well as design principles including operational excellence, security, reliability, performance efficiency, cost optimization. And as I mentioned, most recently, sustainability.

Within those questions, there are various best practices that should be implemented to help you evaluate and maintain the health of your workloads. The Well Architected framework is really that set of foundational best practices that will help you think about how you're actually architecting in the cloud.

And with the introduction of custom lenses, now you can really expand upon that foundation and make those best practices unique to your organization.

So custom lenses is meant to enhance the Well Architected framework and allow you to really focus on what's unique and important to your organization, things like governance requirements or operational needs, anything internal to your organization that you want to bring into the Well Architected tool to help you keep track of all of your architectural best practices in one place.

So speaking of the tool, this is really a self service way to help you actually review the Well Architected framework and those custom lenses that i was talking about. It's really intended to be a continuous and iterative process to help make sure sure that your teams are always improving upon your architectures.

You define your workload, you answer all of the questions and all of the best practices within each of the pillars. And there's risk identified based on what you've answered. Then we give you an improvement plan and step by step guidance on how you can actually remediate some of those risks.

Similarly, you can also upload your custom lenses into the tool and review in the exact same way, custom lenses allows you to create your own pillars, questions, best practices, helpful resources, as well as improvement plans.

And so really, there's major benefits to using the Well Architected tool first, identifying your risks early and often helps ensure that you're building your architectures correctly from the start. This will help you mitigate risks early. And often in your development process, being able to really document your workload decisions and tradeoffs that you may have to make over time will not only help you keep track of those, but also make sure that all of the stakeholders that are working on that workload are understanding why those decisions were made.

Lastly, the iterative process helps you understand how your workloads have been improving over time and you can see progress as you save milestones in the tool.

So when we think about Well Architected as a whole, there's really three components that work together the content, the tool and the data.

So the content is the framework, the help of resources, everything that we've talked about included in the Well Architected framework and now your custom lenses, then we have the tool. So the Well-Architected tool helps you carry out those framework reviews as well as your custom lens data and then you get the data.

So the data is all of that combined into what decisions you've made, what your risks are any, you know, notes that you've taken to really help you understand how the content and the tool are integrated into your organization.

So as you can see on the screen, there's many different ways that content tool and data overlap and that's really where you can scale Well Architected into your organization.

So i will pass it off to Samir to talk a little bit more about how you can actually integrate Well Architected at scale.

Thank you, Ilana.

Alright. So one of the things that we always hear and we speak about it a lot at Amazon is, you know, good intentions don't work, right? And a lot of us here have been in positions before where we all want workloads to be architected correctly. We want, you know, we take care of failure and we take care of incident management and all of those things and those are conversations, but they never really translate into actual mechanisms, right?

So here we are to talk about how we can go ahead and create a mechanism that works and that's called the Well Architected way. Just to quote, good intentions never work. You need good mechanisms to make anything happen. And that's what we're here to talk about.

So how can I implement Well Architected for my organization? That's a question I get very frequently. Like it's great. I can use the framework and can read about it. I can do it on a single workload works great. How do I implement this across?

And one of the key things is how do you use it? So there are three aspects to it. There is long measure and improve. Uh when you talk about learning, that's the first thing that you want to do. You want to learn what? Well architecture is why? Well, architect is important when to do the review, why you need to do the review, right? These are best practices that are learned through incidents that AWS has had uh through learnings that we have from our customers. And we've combined this into this framework.

So there's a good aspect of saying, you know, we've done this before we failed at it. We've learned and we've now provided guidance like Ilana was just pointing out the outage back in 2012 was what prompted. This is how did some of our customers not get impacted by an outage?

So the key thing is the teacher teams about that and get into a little bit of details there. Um so we're going back um measure now, what does measure give you by just show of hands here. How many people here are part of teams where each team in your organization does its own measurement of workload, health like everyone that works in a silo. Yes. All right. Some of you.

So there's no standard way to measure your workloads, right? A lot of times when you look at it, people be like, oh, i have, i run this audit, i have five high risks or four high risk, but there's no consistent way. What well architect gives you is this de facto standard, right? Where you can start measuring consistently across the organization and then it gives you improvement plans, it tells you how you can move from. You know, this is the current state of my workload to where i need it to be and it's an iterative process.

Well, architected is a point in state time, a point in time, state of your workload, right? What does that mean? That essentially means that today you can say i've done everything i can, i have no risks, you deploy another change and you went from being multi az to single a z and that no longer is sufficing your needs, right? Your operational goals are not being met, you don't have enough fail. There's a whole bunch that can go wrong.

So how does Well Architected come into all of this is by looking at those improvement plans, having a continuous improvement process where you're constantly evaluating any change that you make to your architecture to say, did this change the state?

Let's talk about what Well Architecture actually has. So we went from a very foundational structure of saying here are some of the, the high level overview of the best practices we've learned and those were organized in four pillars to begin with. And we added operational excellence and we added sustainability over a period of time, we've changed some of these best practices. We've talked about, you know, a lot about how you can optimize for cost. Right. There has been changes on reliability recently with a lot of like resiliency and reliability is a big topic. So we've added some best practices around that.

So it's constantly evolving. But this is the foundational layer of what you should be talking about. Right? Then you move into what we call AWS Well, Architected lenses, what are lenses and this is where you're moving from this general foundational layer to be more specific to your workloads. These are lenses like we have lenses for compute uh analytics gaming and a whole bunch. And what that does is that adds another layer on top for you to get a little more specific.

How do you go from this general i should encrypt my data at rest to what do i do for a workload that's specific for gaming and that's where the Well Architecture lenses come into play.

And then what we recently introduced last year was called custom lenses. Now, a lot of us are part of organizations that have also learned your best practices, have a lot of cloud center of excellence teams that allow you to go ahead and learn and share those best practices in different ways. A lot of teams have their own tooling that they built, right?

So these are what you can now convert into custom lenses and bring it to the Well Architected tool. So you don't have five different places that you're tracking the health of your workload and that becomes critical because now once you start seeing everything in a single place, you can make optimal decisions on what you need to do.

So that's where you go from being more general to more specific as you become more specific, you can create custom lenses. You can take the Well Architected white papers to the lenses like analytics that you can convert into custom lenses as well. You can create your own flavor of it.

Here's what I call the Well Architected way. Uh what it needs is inputs, it needs a tool. How do you build adoption for the tool and the usage? How do you go track those improvements, update the tool and that cycle goes on and what are some of the outputs that you get? And we get into each one of these as we go. And this is essentially the mechanism.

I'm talking about a lot of times when you are looking to implement a Well Architected way in your organizations, you're looking at something that can scale, you're not looking at this applies to one workload and well it applies to three but fails when you try to apply to four, it seems like it shoved down to people, right? And you'll see a lot of this come up and, you know, some of our customers get on stage and talk to you about how they've implemented this, right?

So let's talk about inputs for a little bit. Why are inputs so important to this whole process? You need to understand why you're doing the review. Um, what is the priority? It's not a checklist, it's not an audit. The reason it is not an audit or a checklist is because what you want to do and going back to a few slides you want to learn, right? You don't want your teams making the same mistake over and over again. That's what happens when it's a checklist or an audit is your teams are not as aware of what they need to do because it's like i checked the box, they asked me to encrypt data. I did it great. You want this to be more about the learning process.

So that's why it's important to understand why you're doing the review and help your teams understand why you're doing a review. One of the reasons could be here, we had a recent security incident and we want to make sure that this doesn't happen again. So the focus on the security pillar is higher and your teams understand what they're doing and why they're doing that.

It could be. Well, we want to make sure that we follow a certain standard and that standard is, you know, going by the Well Architected um guidelines. That's another reason you could go ahead and do that.

The other thing you want to do is work backwards from your customer. So when you're doing the review, you're looking for a certain outcome, right? And that could be your internal teams, that could be your external customers.

So it could be about we want to increase our performance for the, you know, the tool that we have out there are the service that we are providing for our customers. That's a good way to think about saying that's why we want to do the Well Architecture review.

The other thing could be where we want to make sure our operational load is reduced, our internal teams that are constantly deploying, monitoring, alarming and things that is reduced. So you have to understand why and what those needs are from both your internal external customers.

Um i would also say reference the Well Architected white papers. The reason for that is there is a lot more detail that it goes into. It tells you a lot about the value, the why, how did we come up with this process? So those are really good tools as inputs for your teams to learn why? Well architected is such an important thing in order to maintain workload, health, going to the tool.

Now, when i say the tool immediately. The first thing comes to mind is the AWS management console, the Well Architected service. Yes, that's the first thing but there is a ps around there, right?

So let's talk about the console. So how can you use the console as something that your teams can use? So very simple. A lot of our customers use centralized accounts, create a central account because it's a free to use, completely free to use service, create a central account. You can go ahead and ask every other team that's doing a review to share with that account.

So your central team can look at a portfolio view of all the risks that you have across the board and not just a single workload.

A great example of that is when you're looking at a security risk that goes across 17 different workloads. You realize this is one service, this is authentication and authorization service that we built, which we fix it, fixes all the high risk issues that all these other workloads have. So you're starting to see a portfolio view, right? That's a great way to do it where the tool allows you to go in and share this workload that you've created with other accounts or the central account. A lot of our customers do that with central accounts.

Um the second thing that you can use the console for is it generates reports. So you can use reporting like you could use that for your S meetings that you happen to have weekly, monthly or quarterly. A lot of our customers use that as for budgeting. So they go in and take a look at it and say here's the risk that we have, here's the cost that it is going to take us to fix this risk. So they've gone ahead and actually used this for funding as well. So you can use a lot of these features out of the console.

Now, as I understand, a lot of us also have tooling that we've built, right. So we already have our own management and governance processes. We have third party systems that we use, that we're tracking our risks in the APS are a great way to integrate your well architected findings into those tools or the findings from those tools can help answer some of the questions or update the answers of those questions in well architected as well. So that gives you the ability to customize, build those features on top.

An example that I'll share around AP usage is there are some customers that we work with who have this thing where they say, what do you call a medium risk is actually a high risk in our business context. So we are going to use your API and every time you return that as a medium risk, we're going to change it to a high risk. So when they show it in their dashboard, it's shown as a high risk. So you can go ahead and tailor and customize the experience to your, to your users workload definition.

Um why is workload definition so critical today? When you ask somebody what a workload is, you get a vague answer and three people in your same team can tell you three different answers for what they, what they think a workload is. Well, AR it gives you a structured way to define that workload. It'll ask you things like what's the name of the workload? Which accounts does it span? What regions does it sit in? Right? Um it has a very important feel actually, I think it's super important. It's called review owner. A lot of times you have people in the organization who go, I don't know who to talk to about this workload, right? I don't know who to reach out to when you look at the review that has a review owner, that's a point of contact. That's where you can start talking about these things. You can look at who did the review, right? A lot of times when you go back and you look at why trade offs were made or why those decisions were made, you realize, you have no idea because you don't know who did it. So those things are those that metadata is extremely important to capture when you're talking about workload information.

And the director told us that for you um documentary decisions, how many of you here have been in meetings where you don't know why a decision was made and by whom it was made, how many times you see in architectural reviews and go, I have no idea why we did this. Right. I've done that a million times and I'm like, why did we do this? Right. And looking back and I'm pretty sure people who look back at the code I've written go the same way. It's like, why would somebody do that? Right. And back then, that was my only option. That was a trade off that I made. There is no documentation around it. What? Well it gives you is the ability to make sure that you add that documentation in there, right? So you can say we're trading off cost for high performance, we're trading off cost for high reliability, right? So you can say this risk in cost is something that we are ready to accept and acknowledge because of these reasons. So when somebody else is looking at it and say, I don't know why we provision so many servers, right? They know now. So that's a byproduct's this historical decision making that happened that nobody knows of.

And then I talked about the consistency, it gives you right. So now you're measuring everyone across the same scale. So now you know where those risks are, what those risks look like.

Now adoption, um how do you actually have these teams adopt? Right? One way, shove it down their throats like a top level mandate, just go do it doesn't work, right? So I always tell people you should try a phased approach. A phased approach means pick a few critical workloads that you think are gonna benefit from doing the review where you're starting to see a lot more issues come up where you see operational issues or you see security issues happening, go pick those, start using those, start doing reviews for that and you start seeing the value that they bring. And once that value brings, you said that we are spinning where you have a lot of other teams saying I want to do this too because there is value and those strategic workloads are key because you can immediately see those impacts. So that's what I'd say is determine a phased approach to scale those reviews, tailor the guidance using custom lenses.

What I mean by that is, you know, if I give you 60 questions to answer on the super high level, right? It's not going to be as valuable, right? It's great when you're starting off on a new workload. If it's a legacy workload, which has a whole lot of complexity to it, you want to tailor it, you want to make it as prescriptive as you can. So you can go ahead and say, you know, I'm gonna skip three questions across the VOC framework, but I'm gonna introduce seven questions on a custom lens which are a lot more specific to what we are building and what we are doing, it could be industry specific, it could be technology specific. Uh it could be that particular workload specific, right? So you can build out those custom lenses, uh collaborate across teams. Uh that helps because what happens if you have one person sitting and doing the entire review, you're going to struggle, that person has to know everything across your six pillars and they most likely don't so collaborate, build teams out that can take, hey, there's a security team that will do the security review. There's a team that will do sustainability. There's a team that will do performance and a team could be one or two people, they could change, but you're collaborating and there are a lot of features in the tool that you can use to collaborate.

Um going to organizations in a bit. Um I talked about custom lenses. Um now organizations, so we integrate with AWS organizations. What that does is so all these things I was talking about before is share the review, uh share those lenses, right? Uh you can share it with an organization. So now you can create those organizations, those or use within your departments and then start sharing them, right? So everyone can collaborate, the central teams can start seeing those dashboard portfolio views that I was talking about and now they're seeing a broader picture, all right. So use that integration that we have it helps you prioritize where to invest.

So think level up and think about when I'm looking across a portfolio, I'm gonna start thinking of, oh, wait, we have massive cost issues across the board. What can we do? Can we have a team look at how we are spending across AWS? Right. What are some of the quick changes that we can make? What are some of the changes that we can make over time? So those are things that are going to be important in terms of what you prioritize.

Um, labs. A lot of us are scared to go in and try something new in, you know, in the production environment. And I think that's a good thing, right? Labs are a great way. We have Well Connected labs that you can go in and test it out, you can try it, you realize what the effort to value ratio is in terms of, if I was to do this, how much time will it take? Because a lot of times that I get a question is great. I know what I need to do, but I don't know how much time or effort it's going to take me to do that. Right. I probably understand the value. I'm gonna get out of it. But how do I know labs are a great way to go test those things out. It's like a sandbox, build it out, test it now, you know what that effort is gonna look like, um I just put an example here in terms of, you know, value to effort.

All right, and then the improvement piece of it. Um as you build these improvement plans, it's very critical. So the first part is we learned what we needed to do, then we scale that out, we measured where our problems are. And the important part is to actually go improve it. And as I mentioned earlier, the improvement doesn't come from, you know, it's not an overnight thing. It's like here are all the issues that you have. I cut your tickets for all of this. Let's get this resolved by the end of the month and we're all good doesn't work, right? So you need to start prioritizing, you should integrate with your ticketing systems, cut the priority tickets first, have people go address that then give them a nice set of priorities. So it's continuously improving the health of your workload in the order of priority that works for you, right? And then look at the reports that you're generating that help you track where you are in that journey, right? So you are trying to see it's like your credit score, right? Can you go from 300 to 800? Now it builds over time. It's exactly what you want to do, right? You want to slowly improve to point where it is 800 not everything is going to be 800 you're going to have workloads that will have certain things that you have compromised or certain things that you have traded off for one or the other. So you'll have risks there, but at least you know of those risks, you're aware of those risks and you're tracking those risks.

Um what are some of the outputs that you get out of it? A de facto standard? Um as I mentioned earlier, consistency across the board, a central place to look at those reviews, cost optimization in today's economy and world. We, we need to look at how we can optimize for that cost. Right? When I say cost optimization, it's not just the spend that you have on your resources in AWS. It's also how you manage your teams. Once you start looking at those risks, you can start looking at how and where the resources can be applied within your organization to address these risks, right? And that will give you a good sense of optimizing your workforce.

And then I want to talk lastly about this integration that we just launched earlier this month. Uh it's with two services, Trusted Advisor and Service Catalog. Um it's App Registry. So Trusted Advisor is uh for people who are not aware, Trusted Advisor is a service that allows you to check your resources for best practices. So it tells you what best practices are across your resources. What we've done is map those best practices back into Well Architected. So now when you go into the tool, you can see what checks are failing. It's a good start. It's a good baseline for your, for, especially when you're looking to say, what resources should i look at? Where do I start? It gives you those checks get you right there to say these are your resources. These are accounts, go start here, right? So you start looking into those to begin with.

And then the Service Catalog integration is with App Registry. App Registry is a good way to start looking at workloads or apps as one unit. Right? Today we talk in terms of accounts and and resources. What we want to do is start thinking in terms of workloads. So when I tell you an EC2 outage, you're not running across to say where all is EC2 use. You have an application or workload that you can look at and say, oh, these are five systems that are impacted because that's critical for you from a customer standpoint. What you need to know is to say what applications are impacted, not what services or resources are impacted, right? Because what your customers are using is applications. So that's very critical.

Uh what this integration does is it maps your Well AR review to an application in App Registry. So you can always reference the review and with that, I'll bring Matthew and Alison to talk about Liberty Mutual Insurance and how they were able to use Well Architected.

Thank you. That's loud. Hello everyone. My name is Matthew Dorian and I am a senior solutions architect at Liberty Mutual Insurance. And for those who have not heard of Liberty Mutual, we are a global property and casualty insurer, protecting everything from cars to homes, to businesses. And for those who do know us, you've maybe seen our adverts of our Liberty Emu and are quite lovely jingle. And last year in at Re:Invent 2021 we spoke about how we have created a culture of innovation and experimentation, all aimed at supporting our evolutionary architectural strategy. How do we rapidly deliver business value in a well architected way? And with that in mind, we do have 4000 plus technology employees. So ensuring that Well Architected is well adopted across the organization becomes very important.

So with that, we're going to tell our story today from two lenses, we're going to talk about Well Architected at the enterprise level and Well Architected at the team level. So for any initiative to work at this scale, we wanted to ensure that we gathered momentum across all leaders and all employees. And we wanted to ensure that we had an enterprise wide initiative that focused on the Well Architected enablement, but most importantly, the adoption. So we made sure we had representation, representatives throughout the organization. So we scarred, went through every corner of Liberty, Mutual Insurance. And sure we had representatives from every area and we wanted to ensure that we give them dedicated time and effort and the capacity to ensure that this is, you know, a success.

So with 4000 employees, uh technology employees who wanted to ensure that we knew how to engage the audience. So we knew from our previous experience of Well Architected core constructs from our Well Architected pattern starter kits that education is key. So we wanted to ensure that we had centralized guidance and support and this was all focused on easy on boarding, discoverability and finding of all of the resources really targeting that barrier of entry to lower that down. We wanted again to take the excellent resources that AWS have and supplement it with our own enterprise. LM context. A great example of this is the WA Well Architect of lab that Samir just touched upon. We've also created our own supplemented education course that takes into account our own ecosystem and how to, to accelerate that even faster. And we now have a definition of our own engineering excellence. You know, we look at things like door metrics, you know, our our product lens, our customer and we have woven in Well Architected as one of the core pillars to how we build in Liberty, Mutual Insurance with the audience in mind.

We now wanted to ensure that we are measuring our process, our progress towards our best practices. So of course, captured our maturity metrics, we wanted visibility into our lenses, the usage across them all of our risks uh and ensure it's really being used and justifying that value we're looking for. And we wanted to take everything that we've learned and use that, use those learnings to create tailored education and enrich that enterprise resource suite that we have our knowledge base. And of course it iteration and learning is is key. So we went through uh incremental pillar by pillar, roll out. So we went through base guidance, what is review, preview, guidance, post review guidance and went through our pillar by pillar starting with operational excellence security and went through that way and that and allowed us to have faster feedback cycles through each stage and that influence our own Well Architected road map.

So just looking at some insights and metrics so far, we've had 700 reviews since 2020 in 2022 alone, we are running at about 10 to 20 per month. Speaking about the lens breakdown, we have 50% of those 700 all focused on service lens. I think that speaks volumes to how much we value service architecture within Liberty Mutual Insurance. We have now started to delve into our data privacy by design and this is our first customer or custom lens that we'll be looking at. And then it also gave us a bit of insight into our pillar gravity. You know, we can see here that operational excell operational excellence is quite a popular pillar. followed by security, reliability and things like that. And we are able to look in bit further, look at our risks, the categories of risks, and we can take all that information and keep that flywheel effect better in our resources so that i'm going to pass over to Alison to talk about the team.

Thanks Matthew. So I'm Allison Bridge

I'm a solutions architect at Liberty Mutual.

Matthew was just talking about rolling out Well-Architected reviews across the organization. I'm going to focus a little deeper on Well Architected for the team.

When I started working with the architecture team building out some of these supplemental documents and working on the rollout, it was really important to us that this wasn't just another mandate coming down from architects and managers saying you must do these reviews. There's a huge amount of value in doing these reviews for the engineers and the teams themselves. We really wanted to make sure that we focused on that as part of our rollout.

That's part of why we built out this Liberty Mutual context documentation that Matthew was talking about. Anyway, I've participated - most of the teams I work with are not only new to Well Architected but new to cloud development. So this also adds another twist to the process.

I've participated now in I think four or five facilitated reviews and participated in a bunch, observed a bunch and we've got a few findings I just wanted to share with you that helps streamline the process.

First is the documentation itself - ahead of all the reviews we shared not only the AWS pillar guidance, the white papers that Samir was talking about and the Liberty Mutual documentation, we also encouraged the team to go in and create a workload in the sandbox and play around and read up on the questions.

So prior to the review, folks had an idea of what questions were gonna be on there and had maybe given some thought already to how our workload matched up and where we have opportunity areas.

My second bullet here is conversation over check boxes. I think Samir said exactly the same thing. We really wanted to emphasize that this isn't just about checking a box on the form. There's also - we didn't want it to be discouraging for some of our newer teams where there's not some sections don't have any boxes checked. This is meant to be - we need to look at it as an opportunity for how we can improve our code and our applications, not as an indictment of "oh no, this is so bad, you didn't check any boxes."

Really the value of these reviews is in those conversations where the engineers come in and they can help identify where do we have risks, maybe risks that we haven't thought about by getting everyone's perspective and involvement and engagement. You really are going to do a better job and it's gonna end up being more well architected at the end of the day.

We also really use the tool in our reviews there to document our findings carefully and then go back and look at the findings and the notes. We had to create stories and backlog items for improvement.

The last two bullets I have here, engineer participation and inclusion of non-engineers, are really about inclusivity. Some squads I've talked to have limited their reviews to just a principal engineer and an architect. We felt that for a newer team, we really want again to have these conversations with all the engineers - everyone contributes, everyone participates, everyone helps to improve the software.

So we included all our engineers and that really has led to this being less like a mandate coming from above and more of a grassroots type of review. I facilitated one review and the second part of the review, the team said "We want to facilitate the next part. We're gonna take over," which was really great. The team broke into pairs and each pair took one of the best practices to delve into and then report back. I think you can't really ask for a better outcome than that.

The last bullet is inclusion of non-engineers. We included managers, product designers, product owners, and scrum masters in these reviews because again everyone has skin in the game here, everyone has a stake in improving the software. For example, with operational excellence, the product owners really have a big part to play in those best practices. Also, product owners are helping make decisions about prioritization and a lot of what you're doing with these Well Architected reviews is trying to figure out - we know we have risks here, how do we weigh the risks we have against the time it will take to fix it against the features we want to implement?

You can implement all the features you want, but if your app isn't reliable or it's not performing and it falls over as soon as you have a heavy load, then it doesn't really matter - those features are never going to see the light of day. So the product owners being included in these conversations is really helpful to get these stories that we have in the backlog prioritized and improve the software.

Anyway, that's my four points - documentation and preparation, conversations over check boxes, and then inclusivity. That's all I have.