Becoming an AWS Well-Architected Partner is a series of steps to prove your competency in delivering Well-Architected Reviews to clients. But before you are approved to run the review, you reach a step where you are required to run one on your own business. We went into ours expecting a box-ticking exercise and came out with a fresh set of questions about how we operate that we had not considered asking ourselves.

The answers came down to who sat in the room. We could have handed the review to the engineers and waited for the report. Instead, we brought in exco, operations, delivery, sales, support and our solution designers. The questions changed character the moment people outside the technical team started answering them, because the same question means something different to the person selling the work, the person delivering it and the person supporting it 18 months later.

For anyone who has not come across it, the Well-Architected Review is a set of questions AWS publishes at no cost. Answer them against a system that matters to you and you get back a ranked list of risks with a plan attached. It covers six areas: operational excellence, security, reliability, performance efficiency, cost optimisation and sustainability. Most organisations run it once, against one application, and file the report.

That leaves most of the value on the table.

Read the six pillars with your organisation in mind rather than a single piece of software and they hold up well. Operational excellence, on paper, asks whether a system is documented and observable. Applied to a company, it asks whether the way you work exists anywhere outside the heads of the people doing it. Security, in most conversations, means the perimeter. The pillar pushes further: who has access, who granted it, and when was it last reviewed. Reliability reads as a server question. Asked of a business, it becomes a question about concentration — which small group of people carry knowledge nobody else holds.

Operational excellence

The review gave us the most to work with in operational excellence. It pointed to a strong operational practice and a thinner paper trail than that practice deserved. A good deal of how we run sat in experience rather than in writing, which is efficient at one size and limiting at the next. Fast-growing companies across the Middle East and Africa meet that same point, usually when hiring starts outpacing the transfer of knowledge.

The second theme was internal communication. We were building capability quicker than we were telling our own people about it. Useful things existed and were underused, because we had not yet built the rhythm of showing the wider business what was available and how to get at it. Easy to fix once visible, and almost invisible while you are busy.

Cost optimisation is the pillar business leaders should read first. It does not ask whether your cloud bill is too high. It asks how you arrived at the number.

In most organisations, next year’s technology budget is this year’s number with a percentage added, and the original figure is rarely revisited. Then add currency. Cloud is priced in dollars while budgets are approved in rands, dirhams, naira or shillings, so a move in the exchange rate produces an overspend that has nothing to do with how anything was designed.

Asking where the money goes, who approves it and what would break if you removed 15% of it is a finance conversation prompted by a cloud framework.

Sustainability behaves the same way. Many organisations across the region now carry a public commitment on emissions with no practical way to measure progress against it. The pillar gives you a place to start, and the logic runs past the cloud footprint into buildings, travel and hardware refresh cycles.

For anyone operating in more than one market, the review earns its keep twice. The questions stay identical and the answers change by jurisdiction. Data residency rules differ. Regulators differ. A control that satisfies one country’s supervisor does not always satisfy the next. Running the same structured review across markets gives you one language for comparing risk, instead of several country reports that cannot be read side by side.

Most businesses are now spending on AI, and the question used to be whether it would add value. That is no longer sufficient on its own.

The question worth adding is whether people were given what they need to use it: training, context and a clear reason to bother. We ask this of every solution we hand to a client. Delivering a working system is the first half of the job. Value shows up when the people on the other side can use it without us in the room.

Which is operational excellence again in different clothing. Adoption is an operations problem.

Why it works

The framework works because it reads as a conversation with a checklist behind it rather than an inspection. People answer honestly, and honest answers reach places a formal internal review does not. The output arrives as risks in priority order, so the argument about what to fix first is settled before the meeting starts.

Run it against one application if that is where your appetite sits. But read the six pillars against the whole organisation first, and bring more than the technical team when you do.

If you think your company could benefit from a Well-Architected Review, get in touch at lsdopen.io and we will set up a session.