# Modern Enterprise Architecture: Architecting for Outcomes • Simon Rohrer • GOTO 2025

[Watch on tuber](https://tuber.guzus.xyz/video/UMaZ-O2KRCw/summary) · [YouTube](https://youtu.be/UMaZ-O2KRCw)

**Score: 64/100 · skim**

The speaker, who heads enterprise architecture at Saxo Bank, argues that enterprise architecture (EA) in large, digital, fast-changing organisations has to stop working in phase-gated, document-heavy project mode. He organises the alternative as an "ABCDE" model: **A**ligning value, people and technology; **B**etter value sooner, safer, happier; **C**ontinuous, conversational governance; **D**evOps at enterprise scale; and **E**volutionary architecture. The goal throughout is business outcomes rather than technical outputs, with managing complexity treated as the main job.

- **0:14-2:05** — **Speaker background and framing.** The speaker has 31 years in the field. He started as a developer, took TOGAF training, became an enterprise architect, and then led an "agile transformation" with Jon Smart. That effort was later renamed "agile adoption" and finally just "ways of working." He moved to Copenhagen in 2019 after Brexit, now heads EA at Saxo Bank, and wrote a chapter of IT Revolution's *Sooner Safer Happier*. He bases the talk's title on Dave Farley's *Modern Software Engineering* and presents it as a break from traditional EA, focused on outcomes.

- **2:05-3:25** — **What "modern enterprise" means, and the ABCDE outline.** He means organisations made of "teams of teams of teams," roughly more than 150 people (he admits the Dunbar number is a shaky basis). They deal with customers digitally, change constantly, and run a mixed estate: old and new, monoliths and distributed systems, vendor and in-house software, all working as a system of systems. He then introduces the five letters that structure the rest of the talk.

- **3:25-8:10** — **How we got here.** He runs through a timeline: the 1994 Standish CHAOS report (70% of software projects failing), the first Scrum paper in 1995, and Kent Beck's *Extreme Programming Explained* in 1999. Since then "software ate the world," and delivery moved from months-long phases with handoffs between teams (plan → build → test → release → operate) to DevOps product teams that can go from idea to production in days or hours. His central complaint is that many enterprise architects never adjusted and still think in phases. Meanwhile complexity has become the main problem. Roger Sessions' "spider's web" diagram shows what happens when integration isn't governed, and Sessions argued that without a working EA programme you pay heavily in IT complexity. Dan North said the 1990s mistake was borrowing civil-engineering processes. The 2020s problem is complexity, which is why project-management coordination techniques are creeping back in.

- **8:10-11:40** — **A: aligning value, people and technology.** He reconciles two takes on Conway's law that seem to contradict each other. Ruth Malan says the organisation's architecture beats the system's architecture. Allan Kelly says the existing software blocks reorganisations. Gene Kim's version of Churchill's line ("we shape our buildings and then afterwards our buildings shape us") shows these are one feedback loop. The organisation shapes the system, and the system then constrains the organisation. So managers (who are really organisation architects) and system architects have to design together. Gregor Hohpe describes EA as aligning business and IT architecture, and business architecture today usually means value streams. The result is a triangle of value, people and systems that you either manage on purpose or get stuck with by accident.

- **11:40-17:00** — **Fractal team structure.** At the bottom level is a Team Topologies-style two-pizza, full-stack team that builds and runs its own software. That software should be "team-sized," fitting in the team's heads (Matthew Skelton building on Dan North's "software that fits in your head"). It should also be domain-driven and independently deployable and testable. Skelton's point is that the real question is team-owned software, not monolith versus microservices. Within the team, the architect is a coach, as Martin Fowler argued in "Who Needs an Architect?" and "Is Design Dead?". Vlad Khononov's work on balanced coupling explains why teams aren't islands. The same pattern repeats at higher levels: teams of teams own bigger chunks of value with OKRs, nested domains and shared public domain events. Saxo has about 90 teams, all working on what is effectively one product. Nobody can hold the whole system in their head (David Woods, SNAFU Catchers report). What an enterprise architect should hold is a sociotechnical map: which teams exist, what they own, and who to talk to. He closes the section by quoting Conway directly: the first design is rarely the best, so keep organisations lean and flexible.

- **17:00-19:00** — **B: the outcomes, better value sooner, safer, happier.** Traditional EA goals like standardisation, consistency, predictive planning and cost cutting are not the right outcomes. Neither are "move to cloud / Kubernetes / microservices / AI," which are outputs. The outcomes come from *Sooner Safer Happier*:
  - **Better:** value specific to your business, measured with a balanced scorecard of quality.
  - **Sooner:** flow, measured as time from concept to cash or concept to learning.
  - **Safer:** security, privacy and "minimum viable compliance," which matters outside banking too.
  - **Happier:** customers, colleagues, citizens, and the climate.

  As systems grow, coordination takes over and crowds out the work that creates value.

- **19:00-22:10** — **The layered "Hello World" example.** He walks through a legacy setup with separate teams for the UI, the API layer, a greeting service, a planet service and the database. Solution architects have to split even a trivial feature across all of them, including a database naming convention enforced by the DBAs. The feature ships weeks or months later with a letter missing. Citing Gregor Hohpe, he says layering across teams is inefficient. The fix is to restructure both the organisation and the architecture so that one cross-skilled team owns the capability end to end. Scott Prugh's "accounting vs physics" talk puts numbers on it: removing a single dependency cut handoffs from four to one, which he describes as 4× more efficient, 8× less risky and 5× cheaper.

- **22:10-28:10** — **C: continuous, conversational governance.** Complexity is asymmetric: adding it is cheap, but removing it from distributed systems is expensive, so the aim is to stop it getting in. Traditional architecture review boards are an anti-pattern now. They worked when there were clear analysis and design phases with documents to sign off. With continuous design they either review a sketch that will change or arrive after release. Saxo governs the architecture that actually gets built, through pull requests and quick conversations:
  - A new service (Saxo has about 1,200 in its CMDB) needs a case for the extra complexity it adds.
  - New data access, service-to-service identity and access rules, and firewall openings go through PRs.
  - Exceptions to principles, such as using synchronous calls instead of the preferred async/event-driven style, also go through PRs.

  Paved paths built on Gregor's platform ideas need no approval. Only genuinely new things need a conversation. A small Architecture Centre of Excellence works alongside a wider community of practice. Charlie Betts (Forrester) describes the deal as two-way: teams accept the platform's standards, the platform ticks most compliance boxes, and architects stop being blockers. Governance becomes continuous, conversational and automated where it can be.

- **28:10-32:05** — **D: DevOps at enterprise scale.** The DevOps loop should run fast at every level: team, team of teams and enterprise. His EA team behaves like a DevOps team and works closely with service managers and SREs. Sam Newman's observation is that in most organisations, data-driven non-functional requirements (SLOs/SLIs) sit in an SRE silo that never talks to architects. Ruth Malan says diagrams serve two purposes: intention (looking ahead) and reflection (looking back at what actually happened). Architects should use observability tools to learn from production, because systems that last for decades behave in ways nobody can fully predict (he mentions residuality here). He says few enterprise architects do this. He combines John Cutler's "you build it, you run it" maturity diagram with the DevOps loop to argue that full product teams also cover opportunity selection and product ownership, using a probe-sense-respond approach for complex problems.

- **32:05-37:35** — **E: evolutionary architecture, then recap.** He cites *Building Evolutionary Architectures*. Neal Ford points out that fitness functions are easy to measure inside one process but hard across distributed systems. He uses "punctuated gradualism" from evolutionary biology as an analogy: mostly steady change, with occasional big jumps. In practice that means continuous attention to complexity debt, funded at around 20% for improvement, with rare business cases for a rewrite, purchase or outsourcing. Second-system syndrome warns against rewrites. Amazon and eBay are exceptions that could afford it during the first tech boom. The default tool is Fowler's strangler fig. Saxo is gradually moving its roughly 1,200 services toward autonomous business capabilities, and he doesn't expect to see the job finished. Simon Wardley's maps show that competition forces evolution, and one of Wardley's principles is "design for constant evolution." The last Standish report, about seven years ago, said to stop doing projects and just keep developing software. He finishes with a recap of the five letters, each set against the old way: bilateral conversations, traditional EA outcomes, phase-based reviews, change-only focus, and letting entropy win.

**Practical takeaways**
1. **Design the organisation and the architecture together.** Reorganising teams without architects in the room, or redesigning systems without considering team boundaries, runs into the Conway feedback loop.
2. **Replace architecture review boards with governance through pull requests.** Govern what gets built, such as new services, new connections, access rules and exceptions, and let paved platform paths go through without approval.
3. **Measure EA by business outcomes** (value, flow time, safety and compliance, wellbeing), not by technology adoption or standardisation.
4. **Remove cross-team dependencies and layer-based ownership.** End-to-end team ownership cuts handoffs, risk and cost a great deal.
5. **Keep about 20% of capacity for ongoing complexity reduction**, prefer strangler-fig evolution to big-bang rewrites, and use production observability to see how the architecture actually behaves.

## Audience signal

- No high-signal audience themes available.