Azure Architecture Without the Poster
A credible Azure design explains who enters the system, where trust boundaries sit, how traffic and hybrid connectivity work, how identity and data are handled, and how the platform is operated, deployed and recovered. Product logos are implementation candidates, not design justification. This three-part series shows how to read the decisions out of a diagram, how an architecture changes from a small pilot to a critical multi-department platform, and how to choose between Microsoft Foundry and Copilot Studio by operating model rather than feature list. It follows Highveld Provincial e-Services, a fictional provincial service platform; its systems and figures are illustrative. Microsoft product names and capabilities were checked on Microsoft Learn on 5 November 2026.
3 articles
- Part 1An Azure diagram is not an architecture until it explains the decisionsA diagram with forty Azure icons can still leave every important question unanswered. Part 1 of Azure Architecture Without the Poster gives a method for reading decisions out of a diagram: twelve decision layers, a trust-boundary view and a decision ledger that turns logos into justified choices.7 min read
- Part 2From pilot to critical platform: how an Azure architecture changesA pilot, a production service and a critical multi-department platform need different architectures, and the change should be triggered by evidence, not by a calendar. Part 2 of Azure Architecture Without the Poster shows what changes in each decision layer, who owns it, and how recovery is proven.8 min read
- Part 3Foundry or Copilot Studio? Start with the operating modelThe choice between Microsoft Foundry and Copilot Studio is usually framed as pro-code versus low-code. The better question is who will build, change, operate and answer for the agent. Part 3 of Azure Architecture Without the Poster works through that question for two fictional provincial use cases.8 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala