si novi Talk to us

The Cloud Excellence Framework

Six pillars that sit alongside AWS Well-Architected and pick up where it leaves off, covering the product and the people using it as well as the workload underneath.

From workload to whole product

Sound infrastructure.
A useful product.
A team that can keep improving it.

Cloud-native applications underperform for reasons that rarely show up on an architecture diagram. The infrastructure is sound, but the product is slow on a phone, the team can't ship confidently, or nobody is quite sure what it costs per customer.

Our Cloud Excellence Framework sits alongside AWS Well-Architected. It extends the conversation to the product, the people using it and the team responsible for keeping it running.

It is a working tool, not a certification. The pillars are stable; the emphasis changes with the business and the system.

Six connected perspectives

The principles, and the questions behind them.

We ask these at the start of an engagement and at checkpoints throughout. Sometimes the answers change the scope.

  1. 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.

    A question we ask

    What happens if this project doesn't go ahead? What is the cost of doing nothing?

    Extends AWS Well-Architected
  2. 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.

    A question we ask

    What devices, browsers and network conditions do your primary users have, and how do you know?

    Extends AWS Well-Architected
  3. 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.

    A question we ask

    When did you last test a restore from backup, or a failover?

    Builds on Reliability, Performance Efficiency
  4. 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.

    A question we ask

    If you were breached tomorrow, what would you do in the first hour?

    Builds on Security
  5. 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.

    A question we ask

    How long does it take to get a one-line change from a developer's laptop into production?

    Builds on Operational Excellence
  6. 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.

    A question we ask

    Do you know what this application costs per customer, or per transaction?

    Builds on Cost Optimisation, Sustainability
The Architecture Canvas

One page the next engineer can pick up and read.

The framework gives us the questions. The Architecture Canvas is where the answers live: what talks to what, where it runs, who uses it and what needs attention.

The boxes come pre-drawn, so nobody starts from a blank sheet. We fill them in, cross things out, annotate and add connections.

Just as importantly, there is room for the manual deployment step, the unknown owner and the things the team would warn the next person about.

Architecture CanvasTemplate / system overview

  1. Users

    End users, admins, staff, third parties, integrations

  2. Entry points

    Domain, DNS, CloudFront, WAF, API Gateway, ALB

  3. Web and app layer

    Frontend, backend, admin app, public site, mobile API

  4. Compute

    ECS, Lambda, queues, workers, cron

  5. Data

    RDS, DynamoDB, OpenSearch, S3, cache

  6. External services

    Payments, email, source control, CRMs, analytics, APIs

  7. Security

    Auth, IAM, secrets, certificates, VPC, backups

  8. Operations

    Logs, alarms, alerts, deployments, environments

  9. Notes and risks

    Known weak points, manual processes, ownership, the things you'd warn the next person about

01 / Explore

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.

02 / Operate

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.

03 / Explain

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.

In practice

A working reference.
Not a one-off review.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

Every live system carries trade-offs. A good framework makes them deliberate, and leaves a clear record of what matters next.

See the work behind the framework