What is the difference between current architecture and intended architecture in architecture governance?

Why This Matters for Security Teams

Architecture governance only works when teams can compare what was approved against what is actually running. Current architecture is the operational baseline: the services, identities, dependencies, and data paths that exist today. intended architecture is the policy baseline: the target state that defines acceptable patterns, prohibited dependencies, and required controls. The gap between them is where unmanaged risk, technical debt, and exception sprawl accumulate.

This matters because architecture drift often shows up first as security drift. A service may be added to a critical path, a secret may be embedded in a deployment workflow, or an integration may bypass the approved identity boundary. NIST’s Cybersecurity Framework 2.0 treats governance as an ongoing activity, not a one-time design review, and NHIMG’s Top 10 NHI Issues shows how quickly identity sprawl becomes an operational problem when it is not continuously reconciled.

The practical mistake is assuming the diagram in a slide deck is the current state. In practice, many security teams encounter architecture drift only after a dependency, identity, or control failure has already reached production.

How It Works in Practice

Effective architecture governance treats current and intended architecture as two separate artefacts with different jobs. The current architecture is discovered from source code, infrastructure-as-code, cloud inventories, service maps, and identity records. The intended architecture is defined through standards, reference patterns, and approved dependency rules. Governance compares the two to identify variance, then routes each variance into a normal delivery workflow as an issue, exception, or remediation task.

For identity-heavy environments, that comparison should include non-human identities, secrets, and trust boundaries. NHIMG’s Lifecycle Processes for Managing NHIs is useful here because lifecycle control is where architecture intent becomes enforceable practice. If the intended architecture says a workload must use short-lived credentials, the current architecture should show whether static keys, long-lived tokens, or unmanaged service accounts still exist.

• Use the intended architecture to define allowed component types, approved identity patterns, and dependency constraints.
• Measure the current architecture from operational evidence, not from documentation alone.
• Classify each deviation by risk, business need, and remediation path.
• Track exceptions with expiry dates so temporary divergence does not become permanent design.

In mature programs, architecture review and security review are the same workflow. Current architecture drives detection, intended architecture drives decision-making, and both are needed to keep governance actionable. This guidance tends to break down in fast-moving platform teams where service ownership is fragmented and no authoritative system exists for dependency discovery.

Common Variations and Edge Cases

Tighter governance often increases delivery overhead, so teams have to balance design purity against release speed and operational reality. That tradeoff becomes sharper in hybrid estates, mergers, and legacy platforms where the intended architecture may be aspirational rather than immediately achievable. Best practice is evolving, and there is no universal standard for how many deviations should be tolerated before a design is considered noncompliant.

One common edge case is when the current architecture is partially known. Shadow services, unmanaged APIs, and externally managed integrations can make the live picture incomplete, which means governance must combine discovery tooling with human review. Another is when the intended architecture changes faster than implementation can follow. In that case, the policy layer should distinguish mandatory requirements from preferred patterns so the organisation does not create unworkable standards.

NHIMG’s Regulatory and Audit Perspectives is useful when evidence must be retained for exceptions, while the 2024 ESG Report: Managing Non-Human Identities underscores why unmanaged identity drift becomes a recurring control issue. The goal is not perfect alignment on day one. The goal is a defensible process for finding, ranking, and closing the gap over time.

Related resources from NHI Mgmt Group

• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?
• What is the difference between code scanning and runtime identity monitoring?
• What is the difference between zero trust for users and zero trust for NHIs?