The Cloud Excellence Framework
AWS Well-Architected answers the infrastructure questions. It was never meant to answer the rest.
Cloud-native applications underperform for reasons that rarely show up on an architecture diagram. The infrastructure is sound and the AWS bill is reasonable, and yet the product is slow on a phone, the team can't ship on a Friday, nobody is quite sure what it costs per customer, and the business case has quietly drifted from the original pitch.
We run a Well-Architected review on every engagement. It is an excellent foundation, and it has relatively little to say about whether you are building the right thing, whether real users can actually use it, or whether your team can keep shipping it confidently after we've gone.
The Cloud Excellence Framework is our answer to that gap. It extends the conversation from the workload to the whole product. Two of its six pillars cover ground AWS does not; the other four build on the AWS pillars, with the lens shifted towards the realities of web and mobile delivery.
Each pillar is a statement, a set of design principles, and a list of questions we ask.
We ask them of ourselves and of you, at the start of an engagement and at checkpoints throughout. Sometimes the answers change the scope. Occasionally they suggest the work isn't ready to start.
-
01
Product & Outcomes
Build the right thing, for the right reasons, and know when you've built it. The most expensive software is software nobody needed.
Extends AWS Well-Architected -
02
User Experience
Build something people can actually use, on the devices and networks they actually have. Teams build on fast laptops and ship to mid-range phones.
Extends AWS Well-Architected -
03
Architecture & Reliability
Build it so it keeps working when things go wrong, because they will. Four nines costs meaningfully more than three, and not every workload needs four.
Builds on Reliability, Performance Efficiency -
04
Security & Trust
Build it so it deserves the data it holds. If the secure pattern is harder than the insecure one, developers will reliably choose the insecure one.
Builds on Security -
05
Delivery & Operations
Build it so the team can keep shipping, safely, long after launch. An application that ships well on day one and can't be changed on day three hundred has failed expensively.
Builds on Operational Excellence -
06
Value & Sustainability
Build it so it pays for itself, and keeps paying. Cloud gives you the freedom to spend as much as you like, which means the discipline has to come from you.
Builds on Cost Optimisation, Sustainability
One question from each pillar, so you know the shape of the conversation.
-
What happens if this project doesn't go ahead? What is the cost of doing nothing?
-
What devices, browsers and network conditions do your primary users have, and how do you know?
-
When did you last test a restore from backup, or a failover?
-
If you were breached tomorrow, what would you do in the first hour?
-
How long does it take to get a one-line change from a developer's laptop into production?
-
Do you know what this application costs per customer, or per transaction?
One page the next engineer can pick up and read
The framework gives us the questions. The Architecture Canvas is where the answers live. It borrows from a humble source: an electrician walking into a room half-wired by someone else, with no idea where the cables run or what the homeowner asked for. A sheet of paper with the room sketched on it would save hours. Software teams have the same problem and rarely solve it any better.
The boxes come pre-drawn, so nobody starts from a blank sheet. You fill it in, cross things out, annotate, add arrows. Anyone can pick it up and read it, including the support engineer at two in the morning.
The box at the bottom is the one most reference architectures leave out. A diagram tends to describe the system somebody intended. This one has somewhere to write down the manual deployment step, the cron job running on a developer's laptop, and the database nobody has the password for. Making them visible is the first step to fixing them.
-
Users
End users, admins, staff, third parties, integrations
-
Entry points
Domain, DNS, CloudFront, WAF, API Gateway, ALB
-
Web and app layer
Frontend, backend, admin app, public site, mobile API
-
Compute
ECS, Lambda, queues, workers, cron
-
Data
RDS, DynamoDB, OpenSearch, S3, cache
-
External services
Payments, email, source control, CRMs, analytics, APIs
-
Security
Auth, IAM, secrets, certificates, VPC, backups
-
Operations
Logs, alarms, alerts, deployments, environments
-
Notes and risks
Known weak points, manual processes, ownership, the things you'd warn the next person about
The Discovery Sketch
Hand-drawn, fast, deliberately rough. Its job is to surface assumptions, so empty boxes are as informative as full ones. If you can't fill in the data box, that's a finding. If operations is blank, that's a much bigger one.
The Support Map
A working diagram of what is actually there, kept current. It answers what talks to what, where it lives, and what breaks. This is the one we hand over, and often the most useful document we leave behind.
The Proposal Diagram
The clean version with the AWS icons, for proposals and case studies. Less detail, more polish. We draw it once the support map is reliable, which is why it comes last.
Four points in the life of an engagement.
-
01
At the start
A structured conversation with you. The review questions are the agenda, and the first version of the canvas is usually drawn while we talk.
-
02
During design
A checklist for architectural decisions. When we choose between options we say which pillars we are trading against, and you are in the room when we do.
-
03
At launch, then regularly
Every six to twelve months is a sensible cadence for a live product. The canvas gets updated to reflect what is actually there, including the gap between the diagram and reality.
-
04
At handover
A written record of where the product stands against each pillar, including the things we didn't get to and the things we think matter next.
It is a working tool rather than a certification, and it isn't a fixed methodology. The questions we ask a cultural analytics platform are not the questions we ask a field surveying app. The pillars are stable; the emphasis shifts. Every live system carries trade-offs and things the team knows could be better, and a good framework makes those deliberate.