All three leading Cloud Providers (AWS, Azure, GCP) have produced well-architected frameworks and guidance for teams and organisations. They have designed them to guide engineering and architecture approaches within their platforms. In this article we show you how we integrate Well-Architected into our ways of working through a Process that supports regular facilitation and collaborative coaching techniques. We call the process SCORP.
What is the well-architected framework?
AWS Well-Architected helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for their applications and workloads. It has based its framework on five pillars — operational excellence, security, reliability, performance efficiency, and cost optimisation . AWS Well-Architected provides a consistent approach for customers and partners to evaluate architectures. And to implement designs that can scale over time.
The AWS Well-Architected Framework started as a single white paper. However, it has expanded to include domain-specific lenses, hands-on labs, and the AWS Well-Architected Tool. The AWS WA Tool is free in the AWS Management Console. It provides a mechanism for regularly evaluating workloads, identifying high-risk issues, and recording improvements
How do organisations embrace well-architected?
How organisations embrace this guidance fascinates us as Architects. Encouraging teams to adopt the Well-Architected Framework in their architecture and engineering practices is a significant step forward. When an organisation applies it at scale, it can achieve economies of scale. And create healthier development environments for their teams.
We use Well-Architected, and experience its benefits. We drive it at an individual team and workload level. And we have become more productive with it through supporting dedicated facilitation, by using it as a basis for achieving broader economies of scale to drive continuous improvement for our teams. We started with the thought/hypothesis that:
‘If the organisation invested in facilitating Well-Architected-Framework into their core ways of working then we would quantifiably see organisational improvements in the quality of our team execution and the quality of our outcomes.’
What is behind my hypothesis on organisational well-architected facilitation?
We are Architects for a large engineering organisation with multiple development teams, not necessarily on the same engagements. As a result, there are many aspects of our operation that we are responsible for and need to consider, such as
- Reducing the distance between our most effective teams and the least effective (emerging) — More commonly measured in the DORA Metrics.
- Defining and supporting the architectural enabling constraints to guide all teams? Consistency and benchmarking of engineering standards.
- Creating Efficacy (Efficiency and Effectiveness) by preventing duplication of problem-solving and creating situational awareness between teams. Reuse.
- Highlight and Celebrate good engineering rigour and expose shortcutting and technical debt.
- General engineering proficiencies and development of those proficiencies.
Inspired by recently reading the book Atomic Habits, we realised good psychology in slow, deliberate and sustainable incremental improvement. In meeting the responsibilities, slow, continuous and gradual improvement is the approach we take. We needed a framework to base our plan on supporting this incremental improvement. A direction to steer individuals and teams towards AWS Well-Architected Framework gave us solid fundamentals to work from.
Why does the well-architected framework tick the boxes of organisational scale?
The Well Architected Framework is a commoditised set of opinionated standards. It means that we, or other architects, don’t have to invest much time crafting and agreeing standards. The subject matter experts from cloud providers have already done that and will continue to evolve them with their platforms.
As architects, we focus on the principles and guidance that apply. And we get right into how we can implement or meet the standard. The well-architected lenses are an essential subset of the well-architected framework tailored for specialised domains. (Serverless, FinTech, Machine Learning, IoT etc.).
The power of portability
The framework gives us the power of portability. When developers move from one team or organisation to another, their experiences and expectations are consistent. Their skills and experience have become very transferable. Our challenge is to create a process that brings well-architected reviews, collaboration, enterprise direction, and integration with the team backlog. The process allows us to meet the teams where they were at (experience and capability-wise). And bring them together in the spirit of learning and collaboration.
It allows us to make and celebrate small wins through deliberate, incremental improvement with a process that is ultimately be sustainable and manageable on the development process.
We integrate Well-Architected into our ways of working through a Process that supports regular facilitation and collaborative coaching techniques.
Building on
Before introducing the SCORP process cycle, we facilitated around 15 Well-Architected Reviews with different teams. The process itself (when performed correctly) was quite enjoyable for the architects and the engineers participating. The review provides an entry point to meet the team. It allows us to understand the nuts and bolts of the architectural implementation of their workload. As well as being able to advise and share thoughts and direction, the team can escalate and discuss challenges.
Successes and experiences are invaluable in facilitating reviews with other teams. You are effectively a conduit for well-architected practice across teams. The well-architected reviews typically end up with updating the AWS Well-Architected Tool and creating a milestone. We follow up to see what the team had added to their backlogs after a few days.
Our observations were the same three months later. Teams were progressing, but was it enough? We were okay with the lack of progress but knew we could improve. We should be covering more ground. And we were missing tons of low-hanging fruit-type improvements. A typical review lasts between 2 and 10 hours, depending on the lens used. It can be tiring if the team hasn’t made much progress. And it can create a sense of frustration if continued.
Build Trap:
We were observing that the teams were falling into a sort of build trap. By being able to move fast, teams typically were more focused on shipping to production. And maybe not as invested in engineering excellence around the Five Pillars as they could be. The focus was not on continuous improvement (proactivity) but on reactive corrections and rapid delivery.
Sometimes, teams start with small workloads, and the dev-ops overhead is negligible. With time, the team scales out the workload, and the dev-ops overhead increases significantly. In these cases, the teams always end up with epics to resolve tech debt or reliability issues.
In our experience, these trends are not ones you can correct by directing technical leads at books. Or by meeting once a quarter for a technical review. The teams typically succumb to the everyday pressures of delivery. In our experience, these trends require leadership to engage in the delivery process. It requires clarity of direction and a way for the teams to introspect themselves continuously with performance and capacity to act. It also needs to be consistent for all teams regardless of how they are engaged.
We set about this by introducing the SCORP Process Cycle of the well-architected review. We explore this in part 2 of this blog series.