Enterprise Architecture Still Runs on Waterfall

The rest of the software industry shipped four generations of delivery practice while enterprise architecture was still debating whether to upgrade its governance model. Agile happened. DevOps happened. Continuous delivery happened. Platform engineering happened. And in a lot of large organizations, the Architecture Review Board continued to meet on the third Thursday of every month to rubber-stamp design documents that the teams had already built around.

Simon Rohrer, Global Head of Enterprise Tech Architecture at Saxo Bank, gave a talk at GOTO Copenhagen 2025 that names this problem without flinching and then spends thirty-seven minutes trying to solve it. The talk is organized around an ABCDE framework — Align, Better Value Sooner Safer Happier, Continuous governance, DevOps at enterprise scale, Evolutionary architecture — which either sounds like a lot of alphabet soup or like someone who has spent a decade watching the same dysfunction repeat itself and finally built a taxonomy for it. Rohrer is the second kind. He's been in enterprise architecture since 1994, and that longevity shows in the specific weariness with which he describes problems that the field has failed to fix.

The core argument is straightforward: most enterprise architecture practice was designed for a world of phase-based, project-oriented delivery, and that world no longer exists for organizations that compete digitally. The ARB model — position a review gate after the design phase, collect the documents, apply the stamp, release the architects back into the wild — made structural sense when projects took months to move between phases. When everything overlaps and teams are deploying continuously, the ARB is reviewing artifacts that are already obsolete or changes that have already shipped. It's not governance. It's archaeology.

What makes this specific to Rohrer rather than generic conference-circuit wisdom is that he's lived through the version of this argument that got labeled SOA governance, then service mesh governance, then microservices governance, and is now apparently becoming platform engineering governance. The terminology shifts. The pattern doesn't. An enterprise gets new tooling, the ARB reasserts itself as the checkpoint for using that tooling correctly, and the coordination cost problem that the new tooling was supposed to solve gets reproduced at a higher level of abstraction. Watching Rohrer describe this with the particular flatness of someone who has sat in that meeting in three different decades, you understand why he's building something different.

His replacement model has two parts. First, govern realized architectures instead of design documents — at Saxo Bank, this means pull requests for consequential decisions: adding a new service to a landscape that already has 1,200 of them, establishing a service-to-service connection, requesting an exception to the async-first preference. "We're not reviewing and rubber stamping a piece of paper that might go away," Rohrer says. "We're doing what's actually happening in the system." Second, paved paths — if a team wants to do something standard, the platform has already encoded the decision; just use it. The architecture team becomes a conversation, not a checkpoint.

This is a sensible model, and the pull-request governance idea in particular is one of those things that sounds obvious once someone says it but apparently required a decade of practitioners watching waterfall governance fail in agile contexts before enough people were ready to hear it.

The more interesting structural argument is about Conway's Law and what Rohrer calls the triangle: value, people, and technology. He quotes Ruth Malan — "If the architecture of the system and the architecture of the organization are at odds, the architecture of the organization will win" — and then points to Alan Kelly's counter-observation that management trying to reorganize without accounting for the existing system architecture will find the software won't cooperate. These two claims seem to contradict each other until Rohrer frames them as a feedback loop: organizations shape their systems, systems constrain their organizations, which is Winston Churchill's point about the House of Commons rebuilt adversarially after WWII and then applied to enterprise software by Gene Kim. You shape your architecture and then your architecture shapes you.

The implication for enterprise architects is that you cannot design systems in isolation from org design, and you cannot reorganize without accounting for the systems you're locked into. Rohrer's "teams of teams of teams" picture — cross-functional teams owning value streams, nested at multiple fractal levels, each independently deployable — is the Team Topologies model extended to full enterprise scale, and it's a reasonable description of what healthy sociotechnical architecture looks like. Whether most large organizations can get there from where they are is the harder question, and Rohrer is honest that Saxo Bank's own journey, nearly seven years in, still involves a lot of legacy.

The "Safer and Happier" components of Rohrer's outcomes framework deserve a moment. "Safer" — optimizing for security, privacy, and minimum viable compliance — is the least controversial piece and probably the most practically useful reframe for regulated industries where "we need to comply" tends to collapse into "we need a gate." "Happier" includes colleagues, customers, citizens, and — here's where it gets interesting — climate. Rohrer lists "happier climate" as one of the balanced outcomes enterprise architects should optimize for. The instinct is right: cloud migrations and architectural decisions have real carbon footprints, and ignoring that is a choice. But "happier climate" as a named outcome in an enterprise architecture framework is the kind of line that sounds excellent in a Copenhagen conference room in 2025 and meets its first real test the moment it collides with a budget constraint. Every framework since roughly 2015 has added sustainability as a pillar, and the experience has been fairly consistent: it stays in the framework until the CFO needs to cut something, at which point it turns out nobody had operationalized it anyway. Rohrer doesn't address the operationalization problem, which means the "happier climate" component is aspirational rather than architectural. That's not a knock on the talk — it's a genuine gap in the profession, not just in this presentation.

The evolutionary architecture section is where Rohrer is most clearly in his own territory. The punctuated gradualism model — evolution happens slowly and steadily until it doesn't, at which point something big forces rapid change, and then you're back to slow and steady — is a useful analogy for why both continuous improvement and occasional step changes are necessary. His position that organizations should default to strangling old systems rather than rewriting them is well-grounded in the historical record. He mentions Amazon and eBay as successful big-bang rewrites and correctly identifies that those happened during the first tech boom, with money that most enterprises don't have and won't. "Typically you should try and avoid that," he says of full rewrites, which is about as dry as thirty years of watching second-system syndrome will make you.

Where Rohrer lands is worth sitting with. He's running the architecture function at a regulated financial institution with 1,200 services in its configuration management database, and he's describing what he actually does, not the clean target-state diagram that lives on slide 47 of most EA decks and nowhere else. That's waterfall with a DevOps veneer, the mode most enterprise architecture shops are still running in — the slide deck shows the continuous loop; the actual governance structure has a monthly meeting. Rohrer's model is the loop without the theater.

The profession has been told this since the SOA era. It has been told it again via microservices. Platform engineering is the current telling. My honest read, after watching the same argument cycle through new branding for twenty years, is that the organizations where it lands are the ones where someone like Rohrer has enough institutional authority and enough patience to model it in production and wait. The ones where it doesn't land are the ones where the ARB still meets on the third Thursday, except now they're reviewing Kubernetes deployment requests instead of UML diagrams.

That's most of them.