Architecture is a trajectory
A design is true on the day it's written. After that, the protocols it uses publish new revisions, the services it depends on are renamed or retired, prices change and regulations take effect. Protocol and product churn is load on the architecture, just as traffic is, and it has to be designed for in the same way.
So every architecture decision record should state three things beyond the decision itself: what will force it to change (a deprecation, a regulation, a price, a scale), the trigger for revisiting it, and what it would cost to undo.
The six states
| State | The signals | The architectural response |
|---|---|---|
| Emerging | Preview or beta; an unstable specification. DRA partitionable devices, for example | Isolate it behind an interface. Never Tier-0. Feature flags |
| Adopted | Early general availability, with breaking revisions still likely. MCP 2026-07-28, for example | Pin versions. Add a compatibility layer. Support both protocol versions for a while |
| Mature | Stable APIs. DRA's core and its Prioritized List, for example | Standardise on it |
| Changing | A rename or re-platforming. Vertex AI becoming Gemini Enterprise Agent Platform, for example | Record it as an alias. Verify the endpoints separately |
| Deprecated | A formal notice. MCP's Dynamic Client Registration, Roots, Sampling and Logging, with a twelve-month minimum window, for example | Write a migration ADR. Inventory everything that depends on it |
| Retired | Removal. Restricted SharePoint Search, closed to new enablement from 31 July 2026, for example | Put compensating controls in place. Assume nothing migrates automatically |
How versioning works, by kind
- Libraries use semantic versioning.
- Protocols and APIs are often dated: MCP's revisions, Microsoft Graph's
v1.0againstbeta. - Kubernetes graduates APIs:
v1beta1,v1beta2, thenv1, as DRA did.
Compatibility runs in two directions. Backward compatibility means new code reads old data. Forward compatibility means old code reads new data. A skew policy says how far apart producers and consumers may be; Kubernetes has a strict one, and the atlas recommends the same for configuration, after the Azure Front Door incident showed what happens without one.
A rename is not a migration. Record the old and new names as aliases, and verify the API identifiers separately, because the marketing name and the endpoint rarely change on the same day.
Strategies for replacing something
- Strangler fig: route a slice of traffic to the new system, and grow the slice until the old one can be switched off.
- Parallel run: run old and new side by side and compare the results.
- Anti-corruption layer: translate between the old model and the new, so the new one stays clean.
- Feature flags: switch behaviour without redeploying.
- Dual write with reconciliation: write to both, and check that they agree.
- Blue-green: two complete environments, with traffic switched between them.
Facts have expiry dates
Some facts in an architecture are only true for a while: prices (AWS Capacity Block prices changed on 7 October 2026 and are described as dynamic), regulatory dates (the Article 50(2) transitional deadline of 2 December 2026 for generative systems already on the market), and deprecation windows. Record them with a valid from and valid until, and they can be checked automatically rather than discovered late.
This atlas does the same for itself. Its facts about AI services, Microsoft 365, pricing and regulation should be re-checked within 90 days of verification, which means by 4 January 2027. Its facts about how the clouds work underneath should be re-checked within 180 days.
An architecture knowledge graph
Everything in the atlas can be held as a graph, and a graph can answer questions that documents can't. The node types fall into layers:
- Intent: requirement, constraint, principle.
- Abstraction: capability, pattern, primitive.
- Provider: provider, service, SKU, region, provider semantic, lifecycle status.
- Estate: environment, workload, application, component, resource, identity, network, data asset, model, index, tool.
- Assurance: control, risk, threat, failure, incident, lesson, evidence.
- Decision: ADR, alternative, assumption, revisit trigger.
- Economics: cost driver, unit metric.
- Operations: runbook, SLO, alert, change.
The second edition adds four: a Check, with its fail mode; a Time parameter (a TTL, lifetime, lease or propagation delay, with its owner and value); a Facet, for equivalence-class deltas; and an Owner.
The edges are typed: depends-on, hosted-in, authenticates-as, authorized-by, flows-to, reachable-via, derived-from, classified-as, fails-with, propagates-to, detected-by, recovered-by, learned-from, aliases, version-of, and now fails-as, stale-by, owned-by, valid-from and valid-until, revoked-via, resolves-via, keyed-by and skew-policy.
Read as sentences, the edges say things like: a requirement constrains a decision, which selects a pattern, which realises a capability, which a service implements in a region. A resource depends on DNS, an identity provider and KMS. A resource authenticates as an identity, which a policy authorizes. An index is derived from a data asset. One failure propagates to another, and a lesson is learned from it. A control mitigates a risk.
The questions it has to answer
- What is the blast radius of an identity-provider, DNS or KMS failure? (The transitive closure of
depends-on.) - Which indexes derive from data asset X, so that a deletion reaches all of them?
- Which decisions rest on assumption A?
- Which services in the estate are in preview or being retired?
- Which agents can reach tool T, and under which identity?
- What is the revocation window for resource R?
- Which checks fail open?
- Which facts expire this quarter?
- Which configuration producers are indirect?