In 2005, if a team at Aldermont wanted a server, they filed a request. The request went to a central infrastructure group, which reviewed it, approved it, ordered the hardware, racked it in the data center, and handed back a hostname some weeks later. That chokepoint was slow and everybody hated it. It was also, quietly, the single most effective architecture governance mechanism the bank has ever had, because nothing could exist without passing through it.
Today a team at Aldermont with a cloud account and a credit card can stand up a production database in ninety seconds. Nobody reviews it. The chokepoint is gone, and with it went the enforcement mechanism that central architecture never realized it was relying on. Everything the discipline had to become in the following two decades follows from that one fact.
The model EA was built for
Classical enterprise architecture, the TOGAF-shaped version this series spent its middle section on, carries a hidden assumption: that technology decisions flow through a center. A central team plans the target state, a central body approves deviations, and central infrastructure physically controls what can be built. The method assumes the architect has leverage.
That assumption was reasonable because it described reality. Hardware was scarce, expensive, and centrally procured. Deployments were rare, coordinated events. A five-year target-state architecture made sense in a world where the estate genuinely changed on five-year timescales. The central planning model worked because the physical constraints of the technology enforced it, whether or not anyone believed in the architecture.
The core idea: Cloud did not just change where systems run. It removed the scarcity that gave central architecture its authority. When any team can provision anything instantly, architecture loses the ability to enforce by controlling the gate, and has to find some other way to matter.
Two shifts happened at once, and it is worth separating them because they broke different things.
What cloud broke
Cloud dissolved the procurement chokepoint. Infrastructure became self-service, instant, and priced by the hour, which meant the architecture function lost its physical veto. A standard that is not enforced by a gate is now just advice, and advice is easy to ignore when the alternative costs a team two weeks.
It also broke the timescale. Target-state architectures written on multi-year horizons assumed the ground would hold still long enough to walk toward them. In an environment where a team can adopt a new managed service on a Tuesday, a four-year plan is not a plan; it is a guess that has already begun rotting. The currency of the architecture became a genuine problem, because the estate now changes faster than any centrally maintained model of it can be updated.
And it broke cost visibility in an unexpected direction. Cloud spending is decentralized, granular, and made by hundreds of small decisions rather than a few large ones. The architecture function that once reviewed a handful of major hardware purchases now oversees an estate where the spending happens continuously, invisibly, and everywhere at once.
What microservices broke
Microservices attacked from the other side. The whole point of the pattern is team autonomy: small teams owning services end to end, deploying independently, choosing their own tools, moving without coordinating. That is the benefit, and it is real.
It is also, by construction, a rejection of central technology standardization. If every team is free to choose, the estate fragments: five languages, four databases, three messaging systems, each locally optimal and collectively unmanageable. The architecture function that tries to prevent this by mandating a single stack is fighting the delivery model the organization deliberately adopted, and it will lose, because the delivery model has executive sponsorship and a business case behind it.
Between them, cloud and microservices produced a genuine crisis for the discipline. The central planner had lost both its enforcement mechanism and its mandate. This is the period when "enterprise architecture is dead" became a fashionable thing to say, and the criticism landed because the version of EA being criticized really had stopped working.
The adaptation: from gate to platform
What emerged is not a return to central control, and it is not surrender. It is a genuine third answer, and its clearest expression is the platform team.
The logic follows directly from the governance principle this series covered earlier: if you cannot enforce by blocking, enforce by making the right thing easy. A platform team builds an internal platform that gives delivery teams what they want, fast self-service provisioning, no waiting on anybody, while ensuring that what they get is compliant by construction. The database you provision in ninety seconds is encrypted, backed up, tagged for cost allocation, network-isolated, and logged, not because anyone reviewed it, but because those properties are baked into the thing being provisioned.
This is architecture enforced through paved paths rather than gates. The compliant option is also the fastest, easiest, best-documented option, so teams take it by preference rather than by mandate. Teams retain the autonomy that made microservices attractive. The organization retains the coherence that central architecture was protecting. The architect's product is no longer a document; it is the platform itself.
The role shift is the important part. In the gate model, the architect's power came from the ability to say no. In the platform model, it comes from the ability to make yes so easy that no is rarely needed. That is a service-provider relationship rather than a policing one, and it changes who the architect has to satisfy: not an audit committee, but the delivery teams who can, and will, route around a platform that is worse than the alternative.
Federated architecture
Alongside the platform sits the second adaptation: architecture stops being one central team and becomes a federated function. A small central group owns the genuinely enterprise-wide decisions, the ones that are expensive to reverse and affect everyone: identity, the integration backbone, data standards, the canonical customer model. Everything else is delegated to architects embedded within delivery teams or domains, who make local decisions locally.
The dividing line is a judgment about blast radius. Choosing the bank's identity provider affects every system forever, so it belongs at the center. Choosing a logging library affects one team and can be changed next quarter, so it does not. The failure of the old model was treating both as central decisions; the failure of pure autonomy is treating both as local ones.
What survives at the center, then, is small but non-negotiable. For Aldermont, no amount of team autonomy makes it acceptable for a fourth definition of "customer" to appear. That is precisely the class of decision that decentralization cannot be trusted with, not because teams are foolish, but because each team's locally rational choice aggregates into the incoherence the bank has spent this entire series trying to escape.
What did not change
It is worth being clear about what survived the transition, because the "EA is dead" narrative overshot.
The four domains still hold. Cloud changed the technology architecture radically and left the business architecture almost untouched; "originate a mortgage" is the same capability whether it runs on a mainframe or a serverless function. The capability map is, if anything, more valuable in a decentralized world, because when a hundred teams are shipping independently, a stable picture of what the organization does is the only fixed reference point available.
The portfolio discipline survived too, and grew harder. Cloud made it trivially easy to create new systems, which means the estate grows faster and the inventory decays faster. The TIME model and the rationalization discipline matter more, not less, when spinning up a new service costs ninety seconds and nobody is watching.
And Conway's Law, from the previous post, explains why the platform model works at all. A platform team succeeds precisely because it changes the communication structure: it replaces expensive coordination between delivery teams and a central authority with a cheap, self-service interface. The paved path is a communication structure, and the architecture follows it.
Summary
Cloud and microservices did not make enterprise architecture obsolete. They destroyed one specific version of it: the central planner whose authority came from controlling a procurement chokepoint that no longer exists. When any team can provision anything in ninety seconds, a standard that depends on a gate is not a standard, and a five-year target architecture is a guess that rots faster than it can be maintained.
What replaced it is neither central control nor free-for-all. Architecture shifted from gatekeeping to enablement, expressing itself through platforms whose paved paths make the compliant choice also the fastest choice, and through a federated model where a small center holds the decisions with enterprise-wide blast radius while everything else is delegated. The architect's product became the platform rather than the policy. Underneath, the discipline's substance was unharmed: the domains, the capability map, and the portfolio all survived, and the last of these matters more than ever now that creating a system is nearly free and nobody is watching.
For Aldermont, this is the reason the consolidation program cannot simply reinstate a strong central architecture team and start saying no. That authority is not available anymore, and trying to reclaim it would only teach teams to hide what they are building. The bank has to earn coherence by making it easy, which is a harder job than the one the discipline used to have, and a more honest one.
Part of the Enterprise Architecture series on this blog.
Part of the Explained series — concepts in tech, clearly.