DEPENDENCY ARCHITECTURE
What are we dependent on? — The Foundation Stage of Cloud Strategy
MATURITY POSITION — CLOUD ARCHITECTURE STAGE 01 OF 07
- Current Stage: Foundation — Maturity Stage 01 of 07
- Primary Architectural Concern: Identifying, classifying, and quantifying the service, identity, data, operational, and regulatory dependencies that constrain cloud strategy decisions — before those dependencies are encountered under migration, consolidation, sovereignty, or exit pressure
- Primary Failure Mode: Dependency-Blind Architecture — the condition in which cloud strategy decisions are made without explicit dependency mapping. Dependencies are discovered only during change events, when remediation cost is highest, optionality is lowest, and the vendor relationship has already closed the negotiating window
- Stage Outcome: Ability to identify, classify, and quantify architectural dependencies before they become movement constraints, cost drivers, or control plane risks
- Next Stage: CS2 — Movement Architecture — What controls our movement?
Dependency architecture is not an audit exercise. It is the foundational discipline of cloud strategy — the layer that every subsequent stage in this path builds on.
The conventional cloud maturity model begins with cost visibility: optimize spend, right-size instances, model reservations. That sequence is architecturally backwards. Cost is a downstream signal of dependency decisions already made. Before any meaningful cost optimization, workload movement, or strategic vendor decision is possible, the architecture must answer a more fundamental question: what does this system actually depend on, and what do those dependencies constrain?
You cannot optimize what you cannot exit. You cannot exit what you haven’t mapped. And you cannot map what no one in the organization has been assigned the architectural responsibility to understand. Most cloud strategy failures do not originate in bad cost management or poor governance. They originate in the gap between the dependencies the architecture team believes exist and the dependencies that surface under real pressure — during a renewal negotiation, a repatriation decision, a sovereignty audit, or an exit attempt.
This stage establishes the vocabulary, the classification model, and the diagnostic discipline that every subsequent stage in this path depends on.
WHY THIS STAGE EXISTS — DEPENDENCY-BLIND ARCHITECTURE
At this Foundation stage, the question is not whether cloud strategy is governed — it is whether the architecture understands what it depends on before those dependencies become constraints that governance cannot change.
Dependency-Blind Architecture develops when cloud infrastructure is built without explicit dependency classification. Services are adopted for their capabilities. SaaS platforms embed into operational workflows. Identity systems expand from access management into approval and execution authority. Data accumulates in provider storage with egress implications never modeled. Regulatory constraints are discovered during a jurisdiction expansion rather than incorporated at design time. None of these are operational failures — they are architectural omissions that compound silently until a change event makes them visible at maximum cost.
The Dependency Awareness Boundary (Framework #126) marks the point at which dependencies are understood before they constrain decisions. Below it sits unknown dependency space — dependencies that exist in the architecture but have never been explicitly mapped, and will surface as Exit Shock, Renewal by Default, or Concentration Collapse when a strategic decision forces their discovery.
How Dependency Architecture Anchors the Full Path
| Stage | Name | Question |
|---|---|---|
| 01 | Dependency Architecture | What are we dependent on? |
| 02 | Movement Architecture | What controls our movement? |
| 03 | Economic Architecture | What determines our economic behavior? |
| 04 | Control Plane Architecture | Who owns the control plane? |
| 05 | Operational Architecture | How is the control plane operated? |
| 06 | Strategic Governance | Who governs strategic authority? |
| 07 | Strategic Resilience | How does the architecture survive dependency failure? |
Every stage after Dependency Architecture assumes dependencies are understood. Movement Architecture maps movement constraints from those dependencies. Economic Architecture models the economic behavior they create. Control Plane Architecture asks who owns the control plane those dependencies have formed. None of those questions can be answered without the dependency inventory this stage builds.
Stage Anchor Framework — Dependency Architecture
Dependency Awareness Boundary (#126)
The point at which architectural dependencies are explicitly understood before they are encountered under migration, consolidation, sovereignty, or exit pressure. Above the boundary: known, classified, and measured dependencies that inform decision-making. Below the boundary: unknown dependency space that surfaces only when discovery is most costly.
Named Failure State: Dependency-Blind Architecture · Indicators: no dependency register · exit cost never modeled · SaaS platforms governing operations without classification · regulatory constraints discovered post-deployment · renewal occurring by default
What This Stage Is Not
Not an exit planning stage. Exit readiness is a diagnostic output of dependency architecture, not its purpose. Teams that will never exit cloud still need dependency architecture — because renewal negotiations, workload placement decisions, and strategic governance all depend on knowing what you depend on. The Exit Readiness Window (Framework #104) is a dependency concentration metric, not an exit planning instrument.
Not a FinOps or cost optimization stage. Cost is a downstream signal of dependency decisions already made. Economic Architecture (stage three) addresses the cost structure those dependencies create. Dependency Architecture addresses the dependencies themselves — the structural layer that determines what Economic Architecture will find.
Not a vendor evaluation framework. Dependency architecture is vendor-agnostic. The discipline applies regardless of which cloud provider, SaaS platform, or identity system is involved. The goal is not to evaluate vendors — it is to understand what the architecture depends on so that vendor decisions are made with full awareness of the constraints they create.
Not a one-time audit deliverable. Dependency architecture is a continuous practice, not a project. Every new service adopted, every SaaS platform embedded in an operational workflow, every new regulatory jurisdiction entered changes the dependency profile. The discipline produces three continuous outputs: a dependency register, an exit cost model, and a movement constraint map — all of which require ongoing maintenance to remain architecturally accurate.
>_ Estimated Reading Depth
| Format | Count | Estimated Time | Notes |
|---|---|---|---|
| Architecture articles | 6 | ~3 hrs | Core reading sequence — dependency pressure, lock-in mechanics, SaaS authority, exit cost, repatriation economics, regulatory constraints |
| Live dependency diagnostic | 1 | ~30–45 min | SSA — Shadow Sovereignty Auditor; returns Dependency Visibility Score and Control Plane Concentration Score |
| Total stage depth | 6 | ~3–4 hrs | Foundation stage — complete before Movement Architecture to ensure movement constraints are mapped against a classified dependency surface |
>_ Where to Enter This Stage
This stage is the correct entry point if cloud strategy decisions are being made without an explicit dependency inventory — or if one exists but has never been measured across depth and concentration, not just breadth. Specifically, enter here if:
- Cloud vendor renewals are negotiated without a current dependency depth and concentration model
- Exit cost has never been calculated as an architectural metric — only as a migration estimate triggered by an active project
- SaaS platforms embedded in operational workflows have not been classified for control plane authority
- Regulatory constraints on data residency or sovereignty were discovered after deployment rather than incorporated at design time
- The organization has adopted cloud-native services without modeling the portability gap each one creates
Do not enter this stage expecting to resolve movement architecture questions — those belong to CS2 — Movement Architecture. And do not enter expecting a cost optimization framework — that belongs to CS3 — Economic Architecture. CS1 answers one question: what are we dependent on? The answer to that question determines what every subsequent stage can do.
>_ Architecture Maturity Position
| Stage | Name | Maturity Level | Stage Question |
|---|---|---|---|
| CS1 ← YOU ARE HERE | Dependency Architecture | Foundation | What are we dependent on? |
| CS2 | Movement Architecture | Operational | What controls our movement? |
| CS3 | Economic Architecture | Operational | What determines our economic behavior? |
| CS4 | Control Plane Architecture | Strategic | Who owns the control plane? |
| CS5 | Operational Architecture | Strategic | How is the control plane operated? |
| CS6 | Strategic Governance | Strategic | Who governs strategic authority? |
| CS7 | Strategic Resilience | Resilient | How does the architecture survive dependency failure? |
>_ Where This Stage Sits
The Cloud Architecture Path Is a Dependency-Progression Model
| Stage | Architectural Question |
|---|---|
| CS1 — Dependency Architecture | What are we dependent on? |
| CS2 — Movement Architecture | What controls our movement? |
| CS3 — Economic Architecture | What determines our economic behavior? |
| CS4 — Control Plane Architecture | Who owns the control plane? |
| CS5 — Operational Architecture | How is the control plane operated? |
| CS6 — Strategic Governance | Who governs strategic authority? |
| CS7 — Strategic Resilience | How does the architecture survive dependency failure? |
Dependency Architecture maps what exists. Movement Architecture maps what constrains movement. Strategic Resilience tests whether the architecture survives when those dependencies fail.
>_ Stage Reading Sequence
The sequence below is organized by dependency progression. Each cluster answers: what becomes architecturally unstable if this dependency class is misunderstood?
DEPENDENCY MAPPING BEGINS HERE
Dependency Architecture establishes what the architecture depends on. Every stage that follows — movement constraints, economic behavior, control plane ownership, operational governance, strategic authority, and dependency survivability — builds on the dependency map this stage produces. A cloud strategy built without dependency architecture is not a strategy. It is a set of intentions constrained by dependencies that were never named.
The reading sequence below begins with dependency pressure and ends with regulatory constraints — the hardest dependency class, and the one with the least architectural flexibility.
Architectural question: What determines whether movement remains possible?
What determines whether movement remains possible?
The foundation of dependency architecture is understanding why strategic movement fails not at the point of decision, but at the point of execution — because the dependencies that constrain movement were never mapped before the decision was made. These two articles establish the core model: why exit strategies fail because they start after dependency accumulation has already closed the architectural window, and where lock-in actually forms — not at the API layer, but at the operational and network dependency layer that most organizations never explicitly classify.
Architectural question: When does a SaaS dependency become a control plane event?
When does a SaaS dependency become a control plane event?
The two most consequential dependency transitions in cloud strategy are: when a SaaS platform crosses from a service dependency into a control plane dependency, and when exit cost transitions from a project estimate into a structural architectural constraint. These two articles address both transitions directly. The first maps the moment when a SaaS platform begins governing operational decisions — identity workflows, approval chains, execution authorization — and becomes a control plane re-architecture problem rather than a migration problem. The second introduces exit cost as a first-class architectural metric that should be modeled at dependency adoption time, not discovered at migration time.
Architectural question: What do dependency economics and regulatory constraints actually cost?
What do dependency economics and regulatory constraints actually cost?
The final cluster closes the dependency classification model with two constraint types that operate at opposite ends of the cost discovery spectrum. Repatriation calculus maps dependency economics at the decision point — how dependency depth, data gravity, and operational lock-in shape the actual cost calculus when a strategic movement decision is made. The sovereign cloud article closes with the hardest constraint class in the dependency model: regulatory dependencies that are non-negotiable, discovered late, and require workload re-platforming when they surface after deployment. Together they demonstrate why regulatory and data dependencies belong in the Dependency Architecture classification model, not discovered at the Movement Architecture or Economic Architecture stage.
>_ Framework #126 — The Dependency Awareness Boundary
Framework #126 — Dependency Awareness Boundary
The Dependency Awareness Boundary is the point at which architectural dependencies are explicitly understood before they are encountered under migration, consolidation, sovereignty, or exit pressure.
Above the boundary sits known dependency space — service, identity, data, operational, and regulatory dependencies that have been classified, measured, and incorporated into architectural decision-making. Below the boundary sits unknown dependency space — dependencies that exist in the architecture but have never been explicitly mapped, and will only surface when the cost of discovery is highest.
Failure state: Dependency-Blind Architecture — the condition where the organization’s architectural decisions are constrained by dependencies that have never been named.
The boundary is not fixed. Every new service adopted, every SaaS platform embedded in an approval workflow, every regulatory requirement added by a jurisdiction — each one moves the boundary. The architectural discipline is not a one-time audit. It is a continuous practice of keeping the known side of the boundary as large as possible, so that no dependency surfaces as a surprise under pressure.
>_ The Five Dependency Classes
Cloud dependencies do not all carry the same architectural weight, the same exit cost, or the same governance implications. Understanding which class a dependency belongs to determines how it should be measured, governed, and prioritized in exit and movement planning.
Managed databases, proprietary ML platforms, serverless runtimes, and cloud-native services with no portable equivalent. The dependency is not the service itself — it is the gap between what the service provides and what the organization could replicate elsewhere.
SSO providers, directory services, and federated authentication chains. Identity dependencies carry outsized architectural weight because they govern not just access, but approval workflows, deployment authorization, and audit chains. An identity dependency that has grown to control execution paths is no longer an access dependency — it is a control plane dependency.
Where data lives determines where compute must run. Data gravity is not a preference — it is a physics constraint. Every cross-region pull is a billable egress event. Large stable datasets do not move freely. Data dependencies define the actual envelope within which architectural movement decisions are possible.
Tooling, runbooks, team capability, and muscle memory built around a specific provider’s operational model. Operational dependencies are the most underestimated class — they do not appear on architecture diagrams, they do not show up in cost analysis, and they do not surface until a migration is in motion and the team discovers it cannot operate the target environment with the skills it currently has.
Sovereignty requirements, data residency constraints, sector regulations, and contractual obligations that restrict where workloads can run, which providers can be used, and what control plane access is permissible. Regulatory dependencies are non-negotiable — they are the hardest constraint class because no cost model, migration plan, or architectural redesign overrides them.
>_ Measuring Dependency Risk: Breadth, Depth, and Concentration
Knowing which dependencies exist is necessary but insufficient. The architectural question that drives decision-making is how much risk each dependency carries — and risk is not a single dimension.
01 — BREADTH
How many dependencies exist?
Breadth is the count of dependencies across all five classes. High breadth creates exit inertia through volume — no single dependency is insurmountable, but the collective surface area makes comprehensive movement planning difficult. Breadth is the easiest dimension to measure and the one most organizations focus on — which is why depth and concentration cause the actual failures.
02 — DEPTH
How embedded are they?
Depth measures how deeply a single dependency is embedded in system architecture. A proprietary queue service used in 40 microservices is a depth dependency that rewrites the exit cost model — not because the service is expensive, but because the migration path requires touching 40 systems. Most dependency audits count services. The architectural risk is depth. A five-service footprint with three deeply embedded services carries more exit risk than a fifty-service footprint of surface-level API integrations.
03 — CONCENTRATION
How much architectural authority does a single dependency control?
Concentration measures how many architectural decisions are gated by a single dependency. A single identity provider that gates access, approval workflows, audit logging, and deployment authorization is not one dependency — it is one dependency controlling four decision surfaces. Concentration is distinct from depth: a dependency can be shallow but highly concentrated. The failure mode is Concentration Collapse: when multiple dependencies consolidate authority into a single vendor, exit requires re-architecting all controlled surfaces simultaneously.
>_ The Exit Readiness Window — A Dependency Concentration Metric
Framework #104 (Exit Readiness Window) is frequently misread as an exit planning tool. It is not. It is a dependency concentration metric.
Exit readiness measures the relationship between dependency accumulation and the point at which movement remains architecturally viable. An organization with low exit readiness is not necessarily one that wants to move — it is one whose architecture has accumulated enough dependency depth and concentration that movement has become structurally expensive regardless of intent.
An organization that cannot answer the dependency audit is not ready to exit — but more importantly, it is not ready to renew from a position of architectural clarity either. Renewal negotiations conducted without dependency awareness always occur on the vendor’s terms, because the vendor understands the switching cost better than the customer does.
Exit readiness is maintained through continuous dependency discipline, not through periodic audits triggered by renewal pressure. By the time a renewal cycle forces a dependency review, the window for exercising architectural leverage has typically already closed. The full Exit Readiness Window model is in Most Cloud Exit Strategies Start Too Late.
>_ SaaS Dependencies and the First Signal of Control Plane Architecture
SaaS dependency management begins as a procurement and cost discipline. At Foundation maturity, the architectural concern is simpler: is this SaaS platform something we depend on, or something we’ve become governed by?
The distinction matters because every mature SaaS dependency eventually becomes a control plane question. Once a platform begins governing operational decisions — identity workflows, approval chains, execution authorization, audit trails — replacement becomes a control plane re-architecture rather than a migration. The tooling changes. The integration points change. But more fundamentally, the system of record for operational authority changes, and that requires re-engineering the decision surfaces that depend on it, not just the platform itself.
This is the first appearance of the concept that Control Plane Architecture will formalize: who owns the control plane? At this Foundation stage, the diagnostic question is not yet that formal. It is simpler: have any of our SaaS dependencies quietly become the control plane? Identifying that moment before it is operationally entrenched is the Dependency Architecture contribution to the larger architectural picture.
The full treatment of SaaS as control plane event is in The SaaS Control Plane Problem.
>_ Dependency Failure Patterns
>_ Cloud Dependency Failure Patterns
>_ Dependency Mapping as an Architectural Practice
Dependency mapping is not an event. It is an architectural discipline with three continuous outputs that inform every strategic decision downstream.
Dependency Register — an explicit inventory of service, identity, data, operational, and regulatory dependencies, each classified by type, measured by depth, and rated for concentration. Not a spreadsheet of service names — an architectural document that captures the relationship between each dependency and the decisions it constrains.
Exit Cost Model — per-dependency estimated migration cost and timeline, updated at each architecture review. The exit cost model is not built when an exit is planned. It is built now, maintained continuously, and used as an architectural input to every new dependency decision. Every new service adoption, every deeper SaaS integration, every new regulatory jurisdiction entered changes the model.
Movement Constraint Map — an explicit record of which dependencies are currently blocking architectural decisions in flight. Not all dependencies are equal pressure — the movement constraint map surfaces the ones that are actively gating strategy today, rather than treating the full dependency surface as undifferentiated risk.
The architectural teams that maintain these three outputs do not encounter Exit Shock. They encounter renewal negotiations from a position of architectural clarity — knowing exactly what movement would cost, what it would require, and how long it would take.
>_ Live Diagnostics
>_ Stage Graduates Can Now
You now have the architectural vocabulary for dependency classification. What changes at Movement Architecture — the next stage — is the shift from understanding what you depend on to understanding what those dependencies prevent you from doing. Movement constraints are the structural consequences of the dependency profile this stage maps — the forces that govern where workloads can go, how fast they can move, and what they cannot leave behind.
- Classify dependencies by type: service, identity, data, operational, and regulatory
- Measure dependency risk across three dimensions: breadth, depth, and concentration
- Use Framework #104 (Exit Readiness Window) as a dependency concentration metric — not an exit planning instrument
- Identify when a SaaS dependency has crossed from a service dependency into a control plane event — the first signal of the question Control Plane Architecture will formalize
- Identify when multiple dependencies have consolidated into a single architectural authority center — the Concentration Collapse precursor that determines what Control Plane Architecture and Strategic Governance will find
>_ Where Do You Go From Here
You’ve Mapped the Dependency Surface.
Now Find Out What It’s Costing You.
Dependency depth, concentration risk, and exit readiness are architectural properties — not spreadsheet exercises. Most teams discover their dependency profile under renewal pressure. The architecture review surfaces it before that window closes.
Cloud Strategy Architecture Review
Vendor-agnostic review of your cloud dependency profile — service, identity, data, operational, and regulatory dependencies classified and measured across breadth, depth, and concentration. Exit Readiness Window scored. Control plane concentration identified before it gates the next strategic decision.
- > Five-class dependency classification
- > Depth and concentration scoring
- > Exit Readiness Window assessment
- > Control plane dependency identification
Architecture Playbooks. Field-Tested Blueprints.
Cloud strategy decision architecture delivered weekly — dependency mapping patterns, exit readiness analysis, control plane ownership failures, and the cloud cost architecture patterns that surface before the renewal window closes.
- > Cloud Dependency & Exit Architecture
- > Control Plane Ownership Failures
- > Economic & Egress Architecture
- > Real Failure-Mode Case Studies
Zero spam. Unsubscribe anytime.
>_ Frequently Asked Questions
Q: What is dependency architecture in cloud strategy?
A: Dependency architecture is the discipline of explicitly identifying, classifying, and quantifying the service, identity, data, operational, and regulatory dependencies that constrain architectural decisions. It is the Foundation stage of cloud strategy because cost, movement, control plane ownership, and strategic governance decisions all depend on understanding what the architecture depends on before those questions are asked.
Q: Why does cloud strategy start with dependency mapping rather than cost?
A: Cost is a downstream signal of dependency decisions already made. You cannot optimize what you cannot exit, and you cannot model exit cost without first mapping dependency depth and concentration. Teams that start with cost optimization build efficient architectures that remain strategically constrained because the underlying dependency profile was never understood.
Q: What is the Dependency Awareness Boundary?
A: The Dependency Awareness Boundary (Framework #126) is the point at which architectural dependencies are explicitly understood before they are encountered under migration, consolidation, sovereignty, or exit pressure. Above the boundary: known, classified, and measured dependencies that inform decision-making. Below it: unknown dependency space that surfaces as Exit Shock, Renewal by Default, or Concentration Collapse.
Q: What is the difference between dependency depth and dependency concentration?
A: Depth measures how deeply embedded a single dependency is in system architecture — how many systems reference it and how much re-engineering removal requires. Concentration measures how many architectural decision surfaces are gated by a single dependency — how much authority it controls regardless of how deeply it is embedded. A shallow identity provider can be highly concentrated if it governs access, approvals, audit, and deployment authorization simultaneously.
Q: When does a SaaS dependency become a control plane event?
A: A SaaS dependency becomes a control plane event when it begins governing operational decisions — identity workflows, execution authorization, approval chains, or audit trails. At that point, replacement requires re-architecting the decision surfaces that depend on it, not migrating the tool. This is the first signal of the control plane ownership question that Control Plane Architecture addresses formally.
Q: What is Renewal by Default?
A: Renewal by Default is the failure state where a contract renewal occurs not because the vendor is the right strategic choice, but because dependency depth and concentration have made movement no longer practically achievable within the renewal decision window. It is the strategic consequence of Dependency-Blind Architecture discovered too late.
>_ Related Systems
The next stage — what controls architectural movement. Dependency classification at this stage directly determines which movement constraints Movement Architecture surfaces.
Open Stage →The stage where SaaS control plane events and concentration collapse patterns identified at Dependency Architecture become formal architectural problems requiring ownership decisions.
Open Stage →The pillar page for Cloud Strategy architecture — the full decision framework for dependency, movement, cost, and control plane design.
Open Pillar →The private cloud control plane counterpart — how control plane dependencies manifest in hypervisor environments and what topology decisions mean for dependency concentration.
Open Stage →The AI Infrastructure path equivalent of strategic authority — runtime governance as the operational expression of the control plane ownership questions Dependency Architecture first identifies.
Open Stage →Federal reference for identity architecture — relevant to the identity dependency classification and the governance implications of federated authentication chains.
Open Reference →The EU Data Act’s cloud switching provisions — the regulatory framework that formalizes switching cost, porting obligations, and the legal architecture of cloud dependency.
Open Reference →