Why use the AWS Well-Architected Framework

This is the second in a three part series on the AWS Well-Architected Framework. It is based on my presentation at the AWS Thames Valley user group "How to design well when there is no rule book". In the first part of this series I looked at what the Well-Architected Framework is. In this part we will look at why you should use the Well-Architected Framework.

I split the what of the framework into 3 categories; Cloud Roadmap, Design Principle; Cloud Assessment. For the reasons as to why use the framework I am also splitting it into 3 area; Promote discussion, Plan for Progress, and AWS best practices.

Promote Discussion

I think the main benefit of the AWS approach with the Well-Architected Framework, and the Cloud Adoption Framework, is that they promote discussion between technical and business teams.

In my experience many good engineers can often forget the purpose of of the systems they are building. This can lead to over technical solutions with no added value to the organization. By being more of a conversation process than an audit I believe that the framework and review promote the following 4 mindsets:

Question Based around the purpose of the solution to the business. This focuses on why decisions were made and can help to change the "I've / we've always done that" approach many engineers can carry with them. Questions around what has lead to a design, what challenges was the solution trying to overcome can all help to ensure that systems are fit for purpose rather than just built well.

Provoking discussion of the workload can help to highlight any misinterpretation or assumptions that have been made. Often the initial goal and final product can be vastly different. In many cases this is down to understanding what the expected purpose and value of the system is/was.

Discussing functional and non-functional requirements, and challenges, further helps to ensure all parties understand the logic behind decisions. In some cases it might be that systems have been over engineered due to a misunderstood requirement. In others I have seen functions requirements under estimated and simple statements turned out to be more complicated and require significant system redesign.

And finally, by encompassing business and technical perspectives the framework ensure that systems addresses all areas of an organization. Items

Inform Decision Making

Following on from the points around promoting discussion, I think this naturally leads to better decision making. If you have all the information needed to make a decision you can then make the best decision. For me this comes down to 3 items.

Firstly, the framework helps individuals understand workloads in relation to outcomes. This means that the both business and technical parties are able to correlate change to the system in terms of the expected outcomes of the system. As a result everyone involved should be clearer on the impact of their decision on the solution.

Secondly, I think the review can help people understand the benefits and risk of decisions that are made. Often it is easy to focus purely on the benefits whilst placing less focus on the risks. The Well-Architected review puts focus on both, not with a goal of placing blame, but to highlight that they are not two isolated outcomes. Changing any component can produce benefits but also reduce or increase risk. By talking about risks in an open way will ultimately produce better solutions for the organization.

Finally, I think the framework and review do a good job of explaining the relationship between various component. As a result of understanding how to balance between pillars to meet business needs engineers and project personal should be able to understand the impact any single decision has. To often demands are made that have an effect on other areas so balancing various requirements have to happen. For example, increasing resiliency might be a technically simple item but the resulting impact to cost might not be sufficient for the benefit to be realized.

AWS best practices.

One of the biggest benefit for me of the framework and review, that often gets overlooked, is that it is based on over 15 years of building in the cloud. Amazon has implemented and supported millions of workloads and deployments on the AWS cloud. While most areas can be applied to any solution the framework and review also incorporates items that are part of the AWS Best Practice Checklist. This ensure you are using AWS tools and services in the best possible way. No matter how good an engineer or architect you are AWS have been supporting solutions , both internally and for clients, as well as building the solutions. As such they have seen both good and bad practices, and also how these related to decisions.#

If you've not read the Best Practice Checklist I urge you to check it out.