N100FN100F
Published on

Reviewing without slowing down

Reviewing architectures against the organisation's standard does not have to be a bottleneck. With a written standard and a verdict classified by severity, the review helps instead of slowing things down.

Service line Cloud Architecture

The committee everybody avoids

In many organisations, reviewing an architecture before production means presenting to a committee that meets every two weeks, returns an unprioritised list of objections and reviews everything again in the next round. Teams learn to dodge it, and the standard stops being met.

The problem is not reviewing. It is reviewing without a written standard and without distinguishing the serious from the minor.

Review against a standard, not against opinions

A useful review compares the design with a written organisational standard: which zones must exist, which services are permitted, how identities, secrets, logs, backups and costs are managed. If a rule is not written down, it cannot be enforced.

A verdict, not a list of objections

A classified review verdictIllustrative deviations classified as blocking, major, minor and observations, with the verdict.ARCHITECTURE · REVIEWA verdict, not a list of objections22 CLASSIFIED DEVIATIONS2596Blocking2E.g.: Database publicly accessible from the internetMajor5E.g.: Backups never restoredMinor9E.g.: Incomplete cost tags on 12 resourcesObservation6E.g.: Consider a cache for the catalogueVerdict: not cleared for production yet.The 2 blocking ones are corrected and only those two are reviewed again. The rest, with a deadline.Illustrative data; they do not correspond to any real caseN100F · n100f.com

The outcome of the review is a verdict in which every deviation has:

  • The rule it breaches, cited.
  • Its severity:
    • Blocking: prevents going to production (for example, sensitive data exposed to the internet).
    • Major: must be corrected within an agreed period (for example, no tested backups).
    • Minor: corrected in the next iteration (for example, incomplete tagging).
    • Observation: a suggestion with no obligation.
  • A proposed correction, not just the problem.

With that classification, the decision is simple: with no blocking deviations, you proceed; with blocking ones, you correct only those and review only those again.

How to stop it slowing things down

  1. A public, stable standard, so teams design to it from the start.
  2. Reviews on demand, not on a committee calendar.
  3. Automate what is checkable: tags, encryption, network exposure and other points validate themselves with infrastructure as code. The human review concentrates on what requires judgement.
  4. Documented exceptions, with an owner and a review date, instead of prohibitions everybody dodges.

How we apply it: Cloud Architecture.

If your cloud cost keeps growing and nobody knows why, or your architecture depends on whoever built it, let’s talk.

Let’s talk