The process of obtaining AWS Well-Architected Partner status requires companies to demonstrate competence in conducting Well-Architected principle Reviews for clients. However, before receiving approval, the company must conduct such a review for its own business. Initially, the team expected this to be a formality, but instead received a new set of questions about its own operations that it had not previously considered.
The answers to these questions depended on the composition of the participants. Instead of assigning the review solely to engineers and waiting for a report, the company involved senior executives (exco), employees from operations, delivery, sales, support, and solution development departments. The nature of the questions changed once people outside the technical team started answering, as the same question has a different meaning for a salesperson, an implementer, and a support specialist eighteen months later.
For those unfamiliar with this tool, a Well-Architected Review is a free set of questions from AWS. By answering them regarding a system critical to the organization, a ranked list of risks with an accompanying action plan is generated. It covers six pillars: operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability.
Most organizations conduct this review only once, targeting a single application, and then archive the report. This results in most of the potential value remaining untapped. When considering the six pillars across the entire organization, rather than just one piece of software, they demonstrate high relevance.
Operational Excellence
In theory, this principle asks whether a system is documented and observable. Applying this principle to the company itself transforms it into a question of whether there is a workflow existing outside the memory of the people performing the work. Security questions usually focus on the perimeter, but this pillar goes deeper: who has access, who granted it, and when was the last access check performed.
The reliability question, which sounds like a technical query about a server, becomes a question of concentration when applied to the business—which small group of people holds knowledge that no one else knows.
Operational Excellence
The review yielded the most material for work in terms of operational excellence. It identified strong operational practices but found that the documentation of these practices was less extensive than it should have been. A significant part of how the company functions was based on experience rather than written instructions, which is effective for small scales but limits growth.
A similar situation is observed in fast-growing companies in the Middle East and Africa, where staffing begins to outpace knowledge transfer. The second finding concerned internal communication. The company was scaling up capabilities faster than it could inform its own employees about them. Useful tools existed but were underutilized because a regular mechanism for informing the entire business about available resources and how to use them was not established. This is easily fixable once the resources are visible, but while the process is ongoing, it remains unnoticed.
The cost optimization pillar, according to the author, is what business leaders should examine first. It does not ask if the cloud service bill is too high. It investigates how that figure was achieved. In most organizations, the technology budget for the next year is simply increased by a percentage of the current amount, and the initial figure is rarely revisited. To this is added the currency factor: cloud services are billed in dollars, while budgets are approved in rials, dirhams, naira, or shillings, so exchange rate fluctuations can lead to overspending unrelated to system design.
The question of where the money goes, who approves it, and what will happen if 15% of those funds are removed constitutes a financial dialogue initiated by the cloud structure. Sustainability behaves similarly. Many organizations in the region publicly declare a commitment to reducing emissions, but they lack practical methods for measuring progress. This pillar provides a starting point, and the logic extends beyond the cloud's carbon footprint, covering buildings, travel, and equipment refresh cycles.
For companies operating in multiple markets, the review benefits twice. The questions remain identical, but the answers change depending on the jurisdiction. Data residency rules differ, as do regulators. Compliance satisfying one country's supervisory authority does not always meet the requirements of the next. Conducting the same structured review across different markets allows for the use of a common language to compare risks, instead of having several national reports that cannot be compared.
Most enterprises are currently investing in artificial intelligence, and the question of whether it will add value is already insufficient. It is worth adding the question of whether people have been provided with the necessary means to use it: training, context, and a clear justification for its application. We ask this question for every solution we deliver to a client. Creating a working system is only half the battle; value manifests when users can use it without our involvement.
This is operational excellence again, but in a different form. Adoption is an operational activity problem. The framework works because it is perceived as a dialogue with a checklist, not an inspection. People answer honestly, and honest answers reach places that formal internal audits do not reach. The result is presented as prioritized risks, which helps resolve disputes about what needs fixing first, even before the meeting begins. Although the review can be conducted per application, it is best to first consider the six pillars in the context of the entire organization and involve more people than just the technical team.
