Enterprise Architecture Atlas

What this atlas is for

Most cloud documentation teaches one vendor at a time. You learn what an Azure subscription is, then what an AWS account is, then a Google Cloud project, and you are left to work out for yourself which differences matter. This atlas goes the other way. It starts from the handful of things every enterprise system is made of, shows how Azure, AWS, Google Cloud, Microsoft 365, Kubernetes and on-premises estates each build on them, and then spends most of its length on how those systems fail.

It's written for architects, platform engineers, security engineers and the people who review their designs. If you already run production systems, the first page should give you the whole model in about ten minutes. The rest is there for when you need the detail: the evaluation order of an IAM request, the size of a KV cache, the window in which a revoked permission still works.

The atlas covers enterprise infrastructure and AI on the same footing, because they are the same problem. An AI assistant over company documents is a distributed system with an authorization problem in the middle of it, and it fails in the ways distributed systems fail.

The model in one picture

Strip any enterprise estate back far enough and you reach a short list of forces. Two are physical: latency, because every 100 km of fibre adds about a millisecond to a round trip, and partial failure, because some part of any large system is always broken. Three are logical: identity (who is calling), authorization (what they may do) and state (what the system currently believes). Time sits underneath all five, because no two machines share a clock, and every token lifetime, cache TTL and lease is a bet about how far apart they have drifted.

Every cloud construct exists to manage one of those forces. Regions and availability zones manage partial failure. Replication and consistency levels manage state across distance. Accounts, subscriptions and projects give identity and authorization a boundary to work inside.

The clouds then add something of their own: a control planeControl planeThe part of a system that creates, changes, authorizes and configures things. Usually shared and often global, which is why the biggest outages start there.Control plane and data plane that turns API calls into state, and a data planeData planeThe part of a system that does the actual work: serving the request, reading the object, forwarding the packet. It should keep working while the control plane is down.Control plane and data plane that serves requests using that state. That split is the single most useful idea in the atlas.

Running data planes usually survive an incident. What fails is the ability to change, launch, authorize or route. And because configuration moves through the control plane quickly and to every region at once, a bad configuration is the fastest way to break a large system. The design goal that follows is static stabilityStatic stabilityKeeping the data plane working, with what it already has, while the control plane is impaired. It usually costs spare capacity provisioned in advance.Static stability: the data plane keeps working, with what it already has, while the control plane is down.

Five things to take away

These are the findings the rest of the atlas supports. Each links to the page that argues it.

1. Control planes are where large outages start. In the five incidents studied here, running workloads mostly kept serving. What broke was the ability to make changes, launch capacity, sign in or route traffic. Design so that "keep running" and "can change" are separate properties, and test the first without the second. See Failure architecture.

2. Configuration is code with a faster blast radius. All five incidents were bad data or configuration that spread faster than a code change would have been allowed to. Two of them came from a component whose code was regional while its data was replicated globally. See Failure architecture and principle P8.

3. Safety, independence and freshness are budgets, not absolutes. Every check has to declare how it fails: closed, open, static or degraded. Every failure domain has to declare what it still shares. Every authorization path has to declare how stale it can be, a figure this atlas calls the revocation window. See Identity and the fail-mode taxonomy.

4. The three clouds do not evaluate permissions the same way. AWS intersects layers of allow under an explicit deny. Google Cloud checks where a principal may act before it checks deny and allow, and fails closed on anything it cannot evaluate. Azure adds up role assignments, and the only deny assignments are ones Azure creates itself. A policy that means "nobody may do X" has to be built differently on each. See Cloud providers compared.

5. AI over enterprise data inherits the permission state of that data, and adds a second decision. Microsoft 365 Copilot shows a user everything they can technically open, so years of oversharing become searchable overnight. A sensitivity label and a DLP policy can then stop the AI processing something the user is allowed to read. Retrieval is where AI meets data governance. See Microsoft 365 and Retrieval, MCP and agents.

The incidents behind the model

The atlas leans on five public post-incident reports from 2024 and 2025. They were chosen because each provider published enough detail to see the mechanism, and because together they show the same shape five times.

Three of the five also impaired the tools people needed to see or fix the problem: a status page, a management portal, a recovery path. That pattern has its own principle: observability has to be independent of what it observes.

How the atlas is organised

The pages are meant to be read in roughly the order the left-hand menu lists them, but each stands on its own.

• Foundations. From primitives to cloud constructs builds the model above in detail. Distributed systems and time covers timeouts, retries, quorum, fencing and clocks. The numbers architects reason with works through availability, queueing, Little's law, KV-cache sizing and error budgets.
• Cloud platforms. Azure, AWS and Google Cloud compared, then one page each on networking and DNS, identity and authorization, data and storage, compute and Kubernetes, security, secrets and PKI and observability and operations.
• The enterprise estate. Microsoft 365 as an authorization graph, and hybrid, private cloud and on-premises.
• AI systems. Inference and the model gateway, and permission-aware retrieval, MCP and agents.
• Failure and design. Failure architecture, twenty-two principles, trade-offs and second-order effects, 28 reference scenarios and three worked examples.
• Practice. Misconceptions and false abstractions, exercises and design reviews, and technology lifecycle.
• Reference. Evidence and open questions and the glossary.

How to read the evidence labels

Cloud services rename themselves, protocols publish breaking revisions and prices move. A document like this goes stale, so every claim that could go stale says how it was checked. You'll see small labels after some sentences:

Facts about AI services, Microsoft 365 and prices were verified in October 2026 and should be re-checked after 90 days. Facts about how the clouds work underneath change more slowly, and are good for about 180 days. The evidence page lists what was checked, against what, and what is still unresolved.