For teams using the cloud today, the vast number of services and the break-neck pace of change can be overwhelming. In this constantly evolving environment, teams need reassurance that what they are building aligns with industry best practice.
The AWS Well-Architected Framework is a great resource to help teams understand whether their architectures are secure, cost effective, reliable and more. The review itself is a large set of questions across a range of topics, so can be quite daunting.
Here are seven steps we've found to be useful to get the most out of your reviews.
The 58 questions that make up a review can give the impression of quite a formal process. Indeed, the word 'review' can conjure images of a grilling by experts over what you've done and a demand to justify yourself, perhaps aligned with old fashioned Waterfall milestones. In reality, a good review is much more conversational and takes a spirit of curiosity.
With this in mind, we don't need to align reviews to formal milestones. Instead we can use the review as a tool whenever we want to kick off a project, plan some new features, or explore major changes to architecture/usage or in response to specific issues. Ideally, reviews should be a regular process where the team and the reviewers get to know each other and the system so they can work together to resolve any issues or discuss the results of experiments that the review identifies.
A Well-Architected Review doesn't have to be a rigid process. Amazon provides a set of though provoking questions across six pillars (Operational Excellence, Security, Reliability, Performance, Efficiency and Sustainability). We can choose to cover all of these equally or dive into detail in specific areas.
A good place to start is to cover all the questions at a high level to get an understanding of the overall state of the application. You could agree with the team that you want to cover all of the topics within a few hours the first time around to build a common understanding. Agreeing this up front helps you avoid being dragged into long tangents and make the most of the team you've assembled. If you identify some concerns around specific areas you can always come back later and perform a more targeted review.
You can then bring in experts from across your community and industry on those topics to focus on untangling the knottiest of problems. Focussing on what you want to get out of your review, be it an overview or a deep dive on a specific area, is a crucial step to making the most of your review.
Once you've decided what you want to get out of your review, it's time to bring together a diverse group of stakeholders. Reviews work best when they're made up of: developers that understand how the application currently works and could work in the future; cloud experts to paint the art of the possible; business leaders that understand the domain; and empowered decision makers to quickly enact change.
We want to create an environment where we can identify the current situation, discuss possible futures and be empowered to make decisions to move forwards again and again in a tight loop. As discussed in Step 2, be mindful about what you want to achieve and think about what talent you need to include to unlock that.
A review shouldn't be a tick box exercise or a stressful exam. Instead it should be more of an open conversation. As facilitators, it is our job to be curious and ask questions, to understand rather than to judge. There are no right or wrong answers. Instead a well-run review will aim to deliver a range of options with different trade-offs to weigh up.
It's also important not to feel pressured into always having an answer or thinking all recommendations will be clear cut. Instead, some takeaways might be to gather more information to help make decisions, such as by gathering application metrics or collecting user feedback. This can also be a great opportunity to craft an experiment to explore cloud options. For example, by running a comparison exercise between two AWS services taking all six pillars into account.
Again, try to keep your goal in mind at all times to make the most of the team you've assembled. If you drift into topics where you don't quite have the right mix of people, focus on what you can achieve and return to these topics in the future.
A review shouldn't be an isolated exercise. Instead it should produce a list of 'issues' for the team to work through. Part of assembling the right team is including decision makers that are able to prioritise these issues and add them to product roadmaps within the meeting. This avoids the common trap of convening a workshop to elaborate on a set of issues that end up at the bottom of a backlog, never to be seen again.
If there are issues around business buy in, it's an indicator that either the review hasn't quite assembled the right team, or there is more work to do around walking business leaders through the opportunities that cloud can unlock. One good approach to prioritising tickets is to map them onto two axis: difficulty of change versus impact. The team can then start on those that deliver the biggest business impact for the least investment.
Once you've documented and prioritised your improvements you can shift into implementing them. Whether you decide to drip feed improvement tasks alongside existing work or surge through all of them in a sprint, it's important to keep your plans SMART.
The review process can set up the team for success by matching improvements to Amazon's wide catalogue of reference architecture diagrams and prescriptive guidance. In addition to leveraging this general best practice, our Solutions Architects can help to embed experience from working on similar solutions and align your products to your company's strategic technology plans.
As we discussed in Step 1, there are many triggers to starting a new review. Once we break down the preconception that they have to be long and stressful experiences, we unlock the power to bring our group of empowered experts together to continually review the product. This could be triggered by the completion of experiments from previous reviews or new issues. It can also be a healthy part of a project's iterative cycle.
For example, evaluating if AWS' latest releases will bring value to the project, whether emerging best practices would be useful, whether the growth of an application needs a new architecture to react to its scale, and even to react to changes in business direction. Keeping the process conversational and encouraging that spirit of curiosity across all of your stakeholders means we can use the Well-Architected Framework to improve again and again.
Here at BAE Systems Digital Intelligence, we work in partnership as an AWS Partner to deliver cloud-native capabilities. If you're interested in learning more, take a look at our other blogs on cloud migrations challenges and tips for cloud migration success, or get in touch with our cloud experts today.
About the author
James Whitehead is a System Designer at BAE Systems Digital Intelligence
james.whitehead2@baesystems.com
A member of our regional teams can help you today. Email: learn@baesystems.com
Americas: +1 720 696 9830 | UK & Europe: +44 (0) 330 158 3627 | Malaysia: +60 327 309 390
Australia: +61 290 539 330 | Middle East: +971 4 568 6776 | Singapore: +65 6951 2440
Stay up to date our with expert's perspectives on the latest trends, issues and technologies sent directly to your inbox.