How to use the AWS Well-Architected Framework
This is the final part 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 this part we will look at how to use the Well-Architected Framework and also some resources to help you further understand the framework and review process.
Firstly I think we should look at how not to use the framework and review as often I see people getting dishearten or resenting the review because it is used in the wrong way.
Often people/teams/organizations use the process as a checklist. They believe that validating against a set of standards and fixing any issues will resolve all their problems. The issue with this is that it becomes a focus on compliance and feels like an audit rather than a balanced review of a workload against business targets. It can then become frustrating for architects and engineers as it feels like they are having their homework checked. I also think there are better ways to run audits and compliance with tools such as AWS Config.
So how should you use the framework and review?
I think the best way to get benefit from the framework and review there are two ways to use them.
First is to use it more as a design strategy guide. Don't feel that every part of the framework has the same importance or even that every question on the review needs to be answered. Understand how it translates to your business and environments to be able to design and review designs against a set of principles. and architectural templates. This will then allow you to build more scalable and resilient solutions for your organization. It will also shift the focus from technical perfection to a focus on value creation.
The second way to implement the framework and review is by integration with the product lifecycle. Use both tools at every stage in the delivery to ensure your still pointing towards the end goal from a design and implementation perspective. This will ensure that the focus on benefit is measured constantly and solutions can be reviewed and improved. This also fits in with the "shift left" principle of DevOps where it is much easier to correct items early in the development cycle.
Which you choose will depend on both the maturity of your teams and also other processes in place. The integration into development cycles works better when a more agile and DevOps culture exists where as most organization seem able to implement the framework into design standards.
Further Resources
As well as the framework white papers there are several resources to help you understand the framework, review and principles discussed. Below are some of the ones I have found useful.
The Well-Architected Map breaks down the review questions into the pillars and categories. Clicking through links to further resources and best practices as well as explaining how to build out an improvement plan for that area.
The Well-Architected Labs site is packed with hands-on guides to teach you ways to meet best practices. It has guides for all of the 5 pillars and ranging from level 100 (Foundational) to level 300 (Advanced).
Well-Architected Team
