Rohrer — Modern Enterprise Architecture: Architecting for Outcomes
The modern enterprise has evolved in many ways since some of the typical Enterprise Architecture principles and practices emerged. In this talk, Simon Rohrer will explain how the nature of the modern enterprise means many legacy Enterprise Architecture principles and practices are no longer applicable.
He makes some suggestions on how a modern EA practice can incorporate agile, DevOps, Systems Thinking and socio-technical ways of working at scale to achieve both short term business value, as well as effecting long term technology and organisation transformation — supporting better value, sooner, safer and happier; breaking dependencies rather than managing them.
TL;DR
A ~38-minute conference talk by Simon Rohrer, Head of Enterprise Architecture at Saxo Bank and a contributing author to Sooner Safer Happier, delivered at GOTO Copenhagen 2025 and published on the GOTO Conferences channel in August 2026. He frames it against Dave Farley’s modern software engineering: “it’s a break with how we’ve done things in the past in the enterprise architecture space, and it’s really all about outcomes.” His scope condition for “modern enterprise”: teams-of-teams-of-teams, roughly >150 employees, digital customer interaction, and a heterogeneous estate — “stuff that is old and new, big and small, slow and fast, some monoliths, some distributed systems, some vendor systems and some internal ones, all working together as a system of system of systems.”
This is a pre-AI source in an AI-saturated corpus, and that is most of its value. AI appears exactly twice in 38 minutes, both times in passing, and one of those is a rebuke — see §Why a 2025 EA talk earns a page below.
The structure is an ABCDE:
A — Aligning people, value and technology. The talk’s theoretical core, and the part most transferable. He sets Conway’s law against Ruth Malan’s “if the architecture of the system and the architecture of the organization are at odds, the architecture of the organization will win” (2008), then against Alan Kelly’s counter-observation that when management tries to reorganise, “the software won’t let it happen.” The resolution is a feedback loop, via Churchill (“we shape our buildings and then afterwards our buildings shape us”) as adapted by Gene Kim: “we shape our architecture and then the architecture shapes us.” Malan’s prescription follows: “system architects, who we call architects, and business and organization architects, who we actually call managers, should not work as if one has no impact on the other.” Rohrer’s version: “we’ve got to start to design our organization and evolve it in the same way we design and evolve our system, because the things are interrelated.” Hence the triangle — value, people, technology — aligned “for a sustainable flow.”
The alignment is fractal: a team owns a piece of value (Team Topologies’ two-pizza team, “full-stack team, full-burrito, t-shaped people, you build it you run it”), owning what Roger Sessions calls an autonomous business capability — domain-driven, independently deployable and testable, and, per Dan North via Skelton and Pais, “software that fits inside the team’s head.” Above it, teams-of-teams own higher-level value with their own OKRs, shared data models and public domain events. His own estate: “we have about 90 different teams. That’s not 90 different lines of business. It’s one line of business collaborating, hopefully decoupled, but ultimately one product.” And the honest limit, via David Woods’ STELLA/SNAFUcatchers report: “as the complexity of a system increases, the accuracy of any single agent’s own model of that system decreases rapidly. No one is going to have this entire system in their head. No one.” What the enterprise architect holds instead is the index: “who are the teams? What do they do? What’s the level of indirection? If I need to know something, who do I go talk to?”
He closes A on the fuller Conway quote, which is more prescriptive than the slogan: “organizations which design systems are constrained to produce designs which are copies of the communication structures of the organizations. The design which occurs first is almost never the best possible. The system concept may need to change. Flexibility of organization is important to effective design. Keep the organizations lean and flexible.”
B — Better value sooner, safer, happier. A replacement outcome set. “Traditionally in EA we’ve looked at things like standardization, or consistency, or predictive planning, or just cost reduction. These are not the outcomes you’re looking for.” And the line that does the most work in an AI-era corpus: “Instead — well, maybe we’re looking for, we want to move everybody to cloud, or we want to get everybody using AI these days, or we want to move everybody to Kubernetes or microservices. No, these are not outcomes. They’re outputs.” The replacements: better = a balanced scorecard of quality anchored on the firm’s actual value proposition; sooner = optimising for flow, “concept to cash or concept to learning”; safer = “agile, not fragile”, security, privacy, minimum viable compliance; happier = “not just happier customers, but happier colleagues, happier citizens and happier climate.”
The worked example is the best thing in the talk. A layered organisation — one team per UI, API layer, greeting service, planet service, database — needs solution architects just to route a trivial “hello world” feature across five teams, and ships weeks or months later with a missing character that the test team waves through as “not a showstopper defect.” Restructured — “I’m not allowed to call that refactored, because it’s not what refactoring is about” — into one cross-skilled team owning the capability end to end, the same feature goes concept-to-cash inside one team. He backs it with Scott Prugh’s DevOps Enterprise Summit figures: removing one dependency “removes handoffs from four to one, so you’re four times more efficient, reduces your risk by eight times and reduces your cost by five times.”
C — Continuous, conversational and automated governance. The architecture review board is named an anti-pattern, with a specific and non-obvious reason: it was temporally coupled to waterfall phases. “Architecture review boards worked when we used to do a project, when we used to do waterfall, when we used to do phase-based development… we could position an architecture review board after the analysis phase… certainly after the design phase we’ve got piles and piles of dead trees of design documents that we can rubber stamp.” Under continuous design there is no such moment: “where does the architecture review board sit here? If we are doing continuous design, what are they reviewing? We might have a sketch at the start, but we know that is going to change. It’s too late here, because the stuff’s already been released.”
His replacement is governance of realised architectures via pull request, and the examples are specific: adding a new service is a PR (“in Saxo Bank we have 1,200 services in our configuration management database. Adding a new one might be just adding a drop in the ocean — but no, it is adding yet more complexity”); a new service-to-service connection is a PR; identity/access and firewall changes between services are PRs; choosing synchronous over the preferred async event-driven default is a PR requesting an exception. “We’re not reviewing and rubber-stamping a piece of paper that might go away. We’re doing what’s actually happening in the system.”
Alongside it, paved paths: “if you want to do something that is simple and is something that everybody else does, you can do that already. No need to ask. Anything new, come and ask us and we’ll have a conversation about it.” He cites Forrester’s Charlie Betz for why platforms make this work: “if you are looking for checklists to be checked off, the platform has checked most of these off already for you. If you’re using the platform, you are seen to be secure, you’re seen to be architecturally compliant.” The trade is explicit and two-sided: “the software developers and the business owners accept a level of standardization, and the architects do not stand in the way of progress anymore, because decisions have all been made at the platform level.”
He also names the asymmetry that motivates governing at all: “creating and reducing complexity might sound like it’s symmetrical… if you put some complexity in, that can be fairly cheap. But reversing it out is asymmetrical, because now you’ve got to make changes, especially in distributed systems, in a whole bunch of places. So let’s try and avoid putting the complexity in in the first place.”
D — DevOps at enterprise scale. The claim is that enterprise architects wrongly live only on the change side. “For us in the architecture center of excellence, we effectively are a DevOps team. We look at operations. We do not just operate in the change world, in the dev world, in the future world. We are looking at what’s going on and learning.” He reports Sam Newman’s observation that architectural requirements typically sit siloed with SREs who don’t talk to architects, and via Ruth Malan frames diagrams as serving two directions — intention looking forward, reflection looking back at what production actually did. His conclusion: “systems last for decades and you cannot predict how they’re going to behave, and so you have to learn from them in production. And this is something as enterprise architects — I don’t find many enterprise architects doing this, and we really really must.”
E — Evolutionary enterprise architecture. Framed through punctuated gradualism: gradual Darwinian evolution and Gould’s punctuated equilibrium turn out to both be right, and the analogy holds for enterprises. “We have to pay continuous attention to complexity. If we don’t, then entropy will eat us up… pay down complexity debt, and we have to fund this continuously as well” — he cites roughly 20% funding for continuous improvement. Step changes are the exception, and he is sceptical of them: “this is second-system syndrome — they call it second-system syndrome because most people don’t end up building a third system. They learn that actually you don’t want to rebuild, you want to evolve.” The exceptions he concedes (Amazon’s and eBay’s rewrites) came “in the first tech boom when they had a lot of spare cash. Not many people have the spare cash to do these rewrites these days.” So: Fowler’s strangler fig, applied continuously. On his own estate he is candid about the timescale: “it’s a slow and steady process. We are getting there… I’m planning on staying around for a while, but even I don’t expect to see all of this go and become this sort of perfect modern architecture.” He closes on Wardley (evolution driven by competition, “designing for constant evolution”) and the final Standish report: “forget projects. It’s time to stop doing projects and just develop and implement software.”
What was actually ingested
The complete talk — all 360 caption segments across duration: 37:52 / length_seconds: 2272, with all eleven chapter markers. There is no Q&A in the recording. Note that Rohrer says at the outset he is “going to talk for 45 minutes”; the published video runs 38, so the session may have been trimmed or he may simply have finished early — nothing in the transcript suggests a cut.
Vintage note, load-bearing. The video was published 19 August 2026 but recorded at GOTO Copenhagen 2025. The title carries “GOTO 2025” and internal evidence agrees (he says he has lived in Copenhagen “nearly seven years” since early 2019, and dates Vlad Khononov’s Balancing Coupling in Software Design to “finally out this year”, published 2024–25). This page is dated on publish_date per the wiki’s video convention, but treat the content as roughly a year older than the file date. Practically this matters for one thing only: his single AI aside about “one-pizza teams” being discussed at an enterprise technology leadership summit is a 2025 observation, not an August-2026 one.
ASR cleanup was heavy, because the talk cites a dense roster of practitioners and the auto-captions mangled most of them: Kembbeck → Kent Beck, John SM → Jonathan Smart, Mark Andre → Marc Andreessen, Jin Kim → Gene Kim, Ruth Malon → Ruth Malan, Vlad Khanov → Vlad Khononov, Andrew Harlaw → Andrew Harmel-Law, Scott Pru → Scott Prugh, Charlie Betts/Forester → Charlie Betz/Forrester, Steven J. Gold → Stephen Jay Gould, sunny fora happier → Sooner Safer Happier, concept to cache → concept to cash, complexity depth → complexity debt. One passage was deliberately not corrected and is flagged in the raw file’s notes: — “sort of microservices or residues” (~6:00), where “residues” is probably “serverless” but the substitution would be a guess.
Scope warning. This is a practitioner opinion talk. Its only quantitative content is second-hand (Prugh’s 4×/8×/5× coordination figures, the 1994 and final Standish reports’ project-failure claims, his own estate’s ~1,200 services and ~90 teams). No before/after is offered for the Saxo Bank transformation itself — he is explicit that it is incomplete and slow. Cite it for the pattern vocabulary and the governance mechanism, not for evidence that either works.
Why a 2025 enterprise-architecture talk earns a page
Three reasons, and only the first is about enterprise architecture.
1. It is a pre-AI baseline for organisational claims the corpus otherwise only hears in AI framing. The wiki holds a large and growing cluster arguing that AI dissolves coordination overhead, flattens management layers, and enables small cross-functional teams to own whole capabilities — Blomfield, Allen, Beutler and others. Rohrer reaches the same structural conclusion with no AI premise at all, from Conway, Team Topologies, DevOps and coordination cost. That is a useful control: the organisational prescription is older than and independent of the AI argument, so convergence on it is not evidence for the AI mechanism. It plays the role for organisational design that Erginbilgiç plays for transformation — a non-AI anchor that lets the wiki separate what is specific to the AI era from what is a transformation primitive.
2. Governance-by-pull-request is structurally the same move as harness hooks. Rohrer’s C is: replace a phase-gated human approval ritual that no longer has a phase to attach to, with continuous, mechanised checks on the realised system, plus paved paths that pre-approve the common case so that only exceptions surface for conversation. That is, mechanism for mechanism, what He describes hooks and sandboxing doing for agents — deterministic gates on the actions actually attempted, with a sandbox that suppresses prompts for the ordinary case and escalates only on boundary-crossing. The two sources do not know about each other and are a year and a domain apart; the shared shape is worth recording on agent-harness as evidence that agent governance is re-deriving a pattern software governance already found.
3. The AI-as-output rebuke. “We want to get everybody using AI these days… No, these are not outcomes. They’re outputs.” Stated in 2025, before most of the corpus’s enterprise-AI-return-gap material was written, and it is the same diagnosis those later sources reach empirically. The wiki’s ai-washing and enterprise-ai-adoption pages both track the adoption-metric-as-goal failure; here it appears as a throwaway line in a list where AI sits interchangeably alongside cloud, Kubernetes and microservices — which is itself the point.
Dynamic-capabilities tagging
digital-transforming/redesigning-internal-structures— the talk is a structural argument end to end. The A section’s prescription is to co-design organisation and system rather than treating either as fixed; the B section’s worked example restructures five layer-owning teams into one cross-skilled team owning a business capability; the fractal team / team-of-teams / system-of-systems model is a design for “team-based structures” in the cell’s literal sense, with the autonomous business capability as the unit.digital-seizing/strategic-agility— E is a resource-pacing argument: continuous ~20% funding for complexity-debt paydown rather than periodic big-bang rewrites, with step changes treated as a reluctant exception (“second-system syndrome”). The cell’s “pacing strategic responses” and “accepting redirection and change” is what punctuated gradualism names — steady evolution punctuated by rare, deliberately-funded discontinuities, with the strangler fig as the mechanism for change that cannot be paused.contextual/internal-barriers— the talk’s antagonists are the cell’s antagonists, named precisely. “Rigid strategic planning” is the phase-gated architecture review board and the project-mode inheritance from civil engineering that Dan North diagnoses as the wrong metaphor. “High level of hierarchy” is the layered team structure whose coordination cost Prugh quantifies. He also names a barrier the cell’s wording does not anticipate — complexity as accumulated entropy, asymmetric to remove and fatal if unfunded.
Linked entities and concepts
- Martin Fowler — cited twice for Who Needs an Architect and Is Design Dead, and for the strangler fig pattern. Updated in this ingest.
- Thoughtworks — the Building Evolutionary Architectures lineage and the fitness-function discussion he draws on.
- systems-thinking — the Conway/Malan/Kelly feedback loop, Woods on model accuracy degrading with system complexity, and the sociotechnical framing throughout.
- agent-harness — governance-by-pull-request and paved paths as the pre-AI ancestor of hooks, permissions and sandboxing; recorded there per §Why a 2025 talk earns a page.
- enterprise-ai-adoption — “we want to get everybody using AI… these are not outcomes, they’re outputs” as an early statement of the adoption-metric-as-goal failure.
- ai-washing — the same line, read as the output/outcome confusion that AI-washing depends on.
- expert-generalist — “full-stack team, full-burrito, t-shaped people” as the team-level form of the expert-generalist argument.
- dynamic-capabilities — the three cells tagged above.
- YC — the AI-era version of the same Conway premise; see
relationships:. - AWS London Exec Forum — the agentic-vantage team-structure argument.
- Joshi, Venkatraman & Fowler — the individual-level counterpart.
Dangling (single-source mention, deferred per author-entity promotion): Simon Rohrer, GOTO Conferences (first appearance as a publisher — promote on a second source), Saxo Bank, Ruth Malan, Roger Sessions, Jonathan Smart, Gene Kim, Dan North, Matthew Skelton, Manuel Pais, Vlad Khononov, Scott Prugh, Charlie Betz, Simon Wardley, Sam Newman, David Woods, John Cutler, Alan Kelly, Andrew Harmel-Law, Gregor Hohpe, Barry O’Reilly.
Source quality note
Auto-generated captions with heavy proper-noun cleanup applied (see the raw file’s notes: for the full list, plus the one uncorrected uncertain passage). The speaker has a cold, which he apologises for on camera; delivery is otherwise clear.
This is a practitioner talk at a vendor-neutral conference, not vendor content — GOTO sells conference tickets, not architecture tooling, and Rohrer is describing an in-progress transformation at his own employer that he explicitly says is unfinished. The book he co-contributed to (Sooner Safer Happier) supplies the B section’s framework and is promoted throughout, which is the main commercial interest present.
Its epistemic weight is pattern vocabulary, not evidence. Nearly every claim is either a citation of someone else’s work or an account of one bank’s in-progress practice. What it can support: that these patterns were the working consensus among enterprise architects in 2025, what the governance-by-pull-request mechanism concretely consists of, and — most usefully for this corpus — that the small-autonomous-cross-functional-team conclusion was reached and argued in detail before the AI-native-company literature reached it independently.