The Implicit Architecture of Every Modernization Decision
The workloads moved in 18 months. The migration took four years. The extra time didn’t go to technology. It went to the operating model the migration silently required: a platform team that had to develop product discipline, a new identity model, a cost-management practice nobody had before, a networking story nobody had written. None of those were on the slide. None had a roadmap or an owner. The enterprise I was advising had done everything right on the technology side. That turned out to be the smaller of the two jobs.
Every modernization has two architectures. The stated one is technical, well-scoped, and backed by vendor material. The implicit one is organizational, much larger, and almost never on anyone’s slide deck. The first gets a roadmap. The second stays invisible until the project starts struggling to explain why it’s behind.
The shape of the gap
The pattern is consistent across cloud migrations, container adoptions, and AI rollouts. The stated goal sits on a slide. The implicit goal sits in the gap between the operating model you have today and the one the stated goal silently assumes.
Cloud migration is the cleanest example. The stated goal is “move workloads to AWS.” The implicit goals (a cloud platform team, a new identity model, a new networking story, a new cost-management discipline, a new operations runbook) are each as large as the stated one. When the gap is small, modernization succeeds. When it’s large and unnamed, the project doesn’t fail visibly. It runs over its timeline by some multiple, and the slip is impossible to attribute to any single decision.
The gap is rarely a function of the technology. It’s a function of the distance between your current operating model and the one the technology silently assumes. Two organizations adopting the same platform, with the same engineers, can have wildly different timelines because one has the implicit prerequisites in place and the other has to build them in flight.
workloads, services,
tools"] Implicit["Implicit architecture
operating model,
decision rights,
identity, FinOps,
runbook"] Stated --> Project["Project plan"] Implicit -.->|"invisible"| Project Project --> Outcome{"Outcome"} Outcome -->|"small gap"| OK["Modernization lands"] Outcome -->|"unnamed gap"| Stall["Project stalls
cause unattributable"] style Implicit fill:#fff5e0 style Stall fill:#fdd style OK fill:#eaf2fa
Figure 1. The stated architecture is what the proposal funds. The implicit architecture is what the proposal silently requires. The teams that name the implicit one early do it when surfacing it is still cheap; the teams that don’t do it during incidents.
Three modernizations and their hidden architectures
Three cases I’ve watched closely, and the implicit work each one quietly required:
| Stated change | Implicit architecture | What gets missed | Cost of ignoring it |
|---|---|---|---|
| Cloud migration | New identity model, new networking story, a platform team with product discipline, a cost-management practice nobody had before | The operating-model track | Years of partial adoption; costs invisible until finance escalates |
| Container adoption | Platform-engineering commitment most orgs have never made; orchestration, networking, policy, and observability redesigned for ephemeral workloads | The difference between “we run Docker” and “we run Kubernetes” | Seven teams with seven slightly different clusters and no shared operating model |
| AI adoption | Data infrastructure investment, evaluation discipline, decision rights about which use cases are allowed and who signs off | That this is a substrate problem, not a model project | Deployed models with no lineage, no evaluation baseline, no clinical or business sign-off authority |
Cloud migration’s workload track is what gets tracked. The operating-model track is what determines whether the cloud era succeeds. The teams that handle it well treat it as a separate program with separate funding. The teams that handle it badly assume the workload migration is the project.
Containers arrive dressed as a packaging change. Treating Kubernetes as “the next compute platform” without naming the platform-engineering commitment is how you end up with seven teams running seven slightly different clusters and no shared operating model.
AI adoption is the most current and the least named. A biomedical research startup I advised paused their AI rollout after a pre-mortem surfaced gaps in their data lineage, evaluation discipline, and research validation authority. The pause became a yes well over a year later, after the prerequisites were built. The deferred yes was a more confident yes than the original one would have been.
The pattern across all three: the technology arrives looking like a tool decision and turns out to be an organizational decision. The same dynamic shows up in the technology decisions you postpone, where the cost of the deferral lives in the implicit architecture you didn’t build alongside the explicit one.
Why the implicit architecture stays implicit
Vendor narratives are tuned to the stated goal, not the implicit one. They have no incentive to make the bill visible. The pitch deck shows the workload migration. It does not show the eighteen months of identity-model work that has to happen alongside it. That’s not dishonesty. It’s that the vendor is selling the part they’re paid to deliver, and the implicit architecture is the part you have to deliver yourself.
Internal champions are selected for excitement. The person who advocates for the modernization is usually the person most enthusiastic about the destination. Enthusiasm and organizational realism are not the same skill, and the org rarely pairs them on the same person.
The implicit architecture often crosses team boundaries no one wants to renegotiate. Cloud migration changes the relationship between security and engineering, between finance and platform, between vendor management and architecture. Each renegotiation is its own political conversation. Avoiding them is easier than having them, and the avoidance shows up as a stalled project nobody can quite explain.
How to surface the implicit architecture
Four questions, asked early, do most of the work. Each one is uncomfortable in a planning meeting, which is exactly why each one is useful.
What would have to be true about our organization for this to succeed? It forces the conversation from “what does the technology require” to “what does our operating model have to become.” The answers usually surface three or four prerequisites nobody had named.
Who runs this on Tuesday at 3am, and do they exist yet? If the people who would handle the 3am incident don’t exist, aren’t trained, or aren’t on a rotation, the system isn’t ready for production no matter what the architecture looks like.
Who is allowed to say no to this in two years, when it conflicts with something else? Most modernizations have an enthusiastic sponsor at year zero and a much harder political situation at year three. If the decision-rights question doesn’t have an answer at year zero, it’ll be answered by whoever has the most political capital at year three — rarely the right person.
Which existing functions does this require to mature, and on what timeline? The modernization usually depends on FinOps becoming a discipline, security becoming a partner, or product management showing up at the platform level. The modernization’s timeline is bounded by the slowest of them.
An architecture decision record for the implicit work
The tool most teams already have for making implicit work explicit is the architecture decision record. Below is a template tailored to the organizational prerequisites, not the technical ones. The point is to force naming before the project begins.
# docs/decisions/adr-0012-cloud-migration-implicit-prerequisites.yaml
id: ADR-0012
title: Cloud migration — implicit organizational prerequisites
date: "2024-09-15"
status: accepted
deciders:
- Head of Engineering
- VP of Infrastructure
- CISO
- VP Finance
context: |
The cloud migration proposal funds workload movement.
It does not fund the operating-model changes the migration silently requires.
This ADR names those prerequisites and assigns owners before the project begins.
implicit_prerequisites:
- name: Cloud platform team
description: >
A dedicated team with product discipline, not a rotation of engineers.
Required before workload migration begins; workload teams block on it.
owner: Head of Engineering
target_date: "2024-Q1"
funding_status: not yet approved
- name: Identity model
description: >
Federated identity replacing per-account IAM users.
SSO, SCIM provisioning, and break-glass procedures required.
owner: CISO
target_date: "2024-Q1"
funding_status: in progress
- name: FinOps practice
description: >
Cost attribution at the service level. Showback reports monthly.
Chargeback model agreed with finance before workloads migrate.
owner: VP Finance
target_date: "2024-Q2"
funding_status: not yet approved
- name: Networking story
description: >
Transit Gateway design, VPC peering vs PrivateLink decision,
and DNS split-horizon documented and reviewed by security.
owner: Principal Network Architect
target_date: "2024-Q1"
funding_status: in progress
decision: |
Migration timeline is gated on the implicit prerequisites above.
No workloads move until the platform team and identity model are in place.
FinOps and networking prerequisites must be complete by first production wave.
consequences: |
Timeline extends by one quarter relative to the proposal.
The extension is the cost of naming this work explicitly rather than
discovering it through slippage.
When the implicit architecture is too big
Some modernizations are correct in principle and wrong for your organization this year. The honest options are three: defer, accept a smaller scope, or build the implicit prerequisites first and revisit.
The hardest part is making “not yet” say-able. Internal champions often can’t deliver it without external air cover, because the political cost of being the person who said no is higher than the political cost of being the person who said yes to a project that quietly slipped. I’ll admit I’ve underestimated that political cost more than once from the outside. Saying “not yet” from the outside is cheap. Saying it from the inside, when you’re the head of engineering and the CEO has been talking publicly about the initiative, is something else entirely.
The cost of the wrong yes compounds: years of partial adoption, organizational fatigue, and a muscle memory that says ambitious projects don’t deliver. Rebuilding that is much more expensive than getting one of these decisions right in the first place.
Reading the modernization honestly
4 questions"] --> Named{"Implicit work
named?"} Named -->|Yes| Size{"Org ready
to build it?"} Named -->|No| Invisible["Stays invisible
until incident"] Size -->|Yes| Go["Go: fund both
architectures"] Size -->|No| Honest{"Honest
options"} Honest --> Defer["Defer"] Honest --> Smaller["Accept smaller
scope"] Honest --> Prereqs["Build prereqs
then revisit"] style Go fill:#eaf2fa style Invisible fill:#fdd style Defer fill:#fff5e0 style Smaller fill:#fff5e0 style Prereqs fill:#fff5e0
Figure 2. The pre-mortem questions are the decision point. Organizations that skip them don’t avoid the implicit work; they fund it through timeline slippage, incident response, and attrition of the engineers who had to carry it.
That enterprise eventually finished its cloud migration. The workloads moved, the platform team matured, the cost-management discipline got built, the identity model got rationalized. But “in the end” was several years, not the original 18-month plan, and the difference between the proposal and the reality was the implicit architecture nobody had named at the start.
Naming the implicit architecture is not the same as building it, but no organization can build what it can’t name. If your modernization is on the way and nobody can answer “what would have to be true about our organization for this to succeed,” you’re not ready to start.