The architecture diagram in the bid was beautiful. Highveld Provincial e-Services, a fictional provincial service platform, had asked three suppliers for a target architecture for its next phase, and one response arrived with a single A3 page holding forty-one Azure service icons, colour-coded by category, connected by a lattice of arrows. Front Door, Application Gateway, API Management, Container Apps, Functions, Service Bus, Event Grid, Cosmos DB, SQL Database, Key Vault, Monitor, Sentinel and more were all present.
Lerato, Highveld's lead architect, spent an hour with it and wrote one sentence in her evaluation notes: "I cannot tell from this how a citizen's request reaches the records system, who can see it on the way, or what happens if Johannesburg loses power."
That sentence is the subject of this series. An Azure diagram can be complete as an inventory and empty as an architecture. The logos are implementation candidates. The architecture is the set of decisions that explains why those candidates were chosen, how trust and traffic flow between them, and how the result is operated, changed and recovered.
Why posters persist
Service posters are attractive for understandable reasons. They show breadth, which reassures evaluators that nothing was forgotten. They are quick to produce from a stencil. And they look like the reference diagrams that cloud providers publish, which are designed to show what a platform can do, not what a particular organisation should do.
The cost appears later. A poster cannot be reviewed for security because it does not show trust boundaries. It cannot be costed because it does not show which services are shared and which are per department. It cannot be operated because it does not say who owns what. One diagram cannot answer every question explains why an architecture pack needs several purposeful views. This series adds an Azure-specific method for checking whether those views carry decisions.
Twelve decision layers
Highveld's platform serves four groups: citizens using web and mobile services, provincial officials, delivery partners who submit and receive work through APIs, and branch offices in district towns. It needs public access, secure employee access, connectivity to on-premises records, integration events, governed analytics and an auditable delivery pipeline.
For a platform like this, a credible Azure design answers questions in twelve layers. The layers are CloudNala's framing; the services named are examples of candidates, not recommendations.
| Layer | The decision it must explain | Example candidates |
|---|---|---|
| Users and external access | Who enters, from where, and with what identity | Microsoft Entra ID for staff; a customer identity service for citizens |
| Edge and public entry | Which traffic is public, and where it is inspected | Azure Front Door, Application Gateway with web application firewall |
| Identity and trust | How services prove who they are to each other | Managed identities, role assignments |
| Network and hybrid | How branches and on-premises systems connect | VPN or ExpressRoute into a hub network |
| Landing zones and subscriptions | Where each workload sits and which guardrails it inherits | Platform and workload landing zones |
| Compute and application | What runs the code, and why that service | App Service, Container Apps, Functions, AKS where justified |
| Integration | How systems exchange events and requests | API Management, Service Bus, Event Grid |
| Operational data | Where transactional data lives and who owns it | Azure SQL Database, Cosmos DB |
| Analytical data | How reporting data is produced and governed | A governed analytics platform, if justified |
| Private service access | Which platform services are reachable only privately | Private endpoints, private DNS |
| Security, observability and recovery | How the platform is watched, defended and restored | Azure Monitor, Microsoft Sentinel, Azure Backup |
| Delivery automation | How changes reach production and who approves them | Infrastructure as code, pipelines, policy |
A diagram that answers each of these, in views a reviewer can follow, is an architecture. A diagram that shows one icon per row is still a poster.
The landing zone vocabulary has moved
One example of why first-party checking matters. Microsoft's Cloud Adoption Framework page What is an Azure landing zone? (checked on 5 November 2026) describes an Azure landing zone as a platform landing zone, which holds the governance, security and shared resources, plus workload landing zones where workload teams deploy within the platform's guardrails. Many older documents and proposals say "application landing zone". The underlying idea is the same, but a design that uses current terms signals that its author checked current guidance. The same page notes that most organisations should have only one platform landing zone per Microsoft Entra tenant, and that what is centralised should be limited to capabilities with a clear benefit across workloads. That second point is itself a decision a diagram should show: which capabilities Highveld centralises, and why.
For the networking side of that decision, Enterprise landing-zone networking covers hub and spoke, central inspection and ownership in detail.
Read the decisions out of the diagram
Lerato's evaluation method had four steps. It works on a supplier's diagram or on your own team's.
1. Follow one request end to end. Pick a real journey, such as a citizen submitting a permit application with a supporting document, and trace it across the diagram. At each hop ask: what identity is used, is this hop public or private, and what is logged? If the diagram cannot answer, the design has not decided.
2. Find the trust boundaries. Mark every place where the level of trust changes: internet to edge, edge to application, application to data, cloud to on-premises, platform to partner. A diagram without visible trust boundaries has not been through a security review.
3. Ask "why this one?" for each icon. For every service, the design should be able to name the decision it implements, the alternative considered and the reason it lost. "Container Apps, because we need container workloads without operating Kubernetes, and the team has no AKS operations skills" is a decision. "Container Apps" alone is a logo.
4. Ask who operates it. For every component, name the team that patches, monitors and pays for it. Components without an owner are where incidents go unanswered.
The decision ledger
The output of that review is a short table, which Highveld now asks every supplier and internal team to submit alongside their diagrams. It is deliberately boring.
| Component | Decision implemented | Alternative considered | Why chosen | Owner | Evidence |
|---|---|---|---|---|---|
| Edge service with WAF | All public traffic enters through one inspected entry point | Separate public endpoints per service | One place for WAF rules, TLS and DDoS posture | Platform team | Policy denying public endpoints elsewhere |
| Message broker | Partner submissions are queued and processed asynchronously | Direct synchronous API calls | Partners send in bursts; records system is slow | Integration team | Load test results |
| Private endpoints with public network access disabled | Databases are not reachable from the internet | Service firewalls with IP allow-lists | Removes a whole class of exposure | Platform team | A policy denying public network access, and its compliance report |
A ledger like this makes the diagram reviewable. It also exposes padding. When the supplier behind Highveld's forty-one icons was asked for a ledger, eleven components had no decision behind them. They had been added because the reference architecture they were copied from contained them.
Architecture diagrams should be evidence, not artwork explains how to keep diagrams tied to a source model. The ledger is the decision record that sits beside that model.
Common mistakes
Copying a reference architecture whole. Microsoft's reference architectures are worked examples. Each assumes requirements that may not be yours. Use them to find options, then justify each choice for your workload.
Premium by default. AKS, a dedicated analytics platform or GPU capacity may be right for some workloads and wasteful for most. The design should say why the simpler option was not enough.
Hiding the hybrid path. For a provincial platform, the link to on-premises records is often the most fragile and least documented part of the system. It belongs in the main view, not a footnote.
Ignoring region and recovery. A diagram that shows one region should say what happens if that region is unavailable. When Azure is the right answer sets out the South African recovery caveat; your design should state its position on it explicitly.
No date on product names. Microsoft renames and restructures services regularly. A design should record when its product facts were checked.
A review checklist
- Can one end-to-end journey be traced with identity, exposure and logging at every hop?
- Are trust boundaries drawn and labelled?
- Does every component have a decision, an alternative and an owner in a ledger?
- Is the split between platform and workload landing zones explicit, with what is centralised and why?
- Are the hybrid connection and the recovery position shown in the main view?
- Are product names and capabilities dated and checked against current first-party documentation?
Key points
- A diagram full of Azure services can be complete as an inventory and empty as an architecture.
- Check a design across twelve decision layers, from external access to delivery automation.
- Trace one real journey end to end and mark every trust boundary before judging any service choice.
- Ask for a decision ledger: decision, alternative, reason, owner and evidence for each component.
- Use current Microsoft terms, such as platform and workload landing zones, and date every product fact.
Next: Part 2, From pilot to critical platform: how an Azure architecture changes. All parts are on the series page.
How CloudNala can help
CloudNala reviews Azure architectures, whether from your own team or a supplier's bid, by reading the decisions out of the diagrams. We trace real journeys across the design, mark trust boundaries, build the decision ledger with you, check product facts against current Microsoft documentation and identify the components that have no decision behind them, so that what you approve is an architecture you can operate and defend.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book an Azure Architecture Review or write to us at consult@cloudnala.co.za