---
title: "Architecture Modernization is an org design project first"
description: "Nick Tune makes the case that modernizing a legacy estate is a decision about team boundaries before it is a choice of technology."
url: "https://michael.zazon.us/notes/architecture-modernization-is-an-org-design-project-first"
published: "2025-12-04T12:00:00-05:00"
kind: "book-notes"
subject: "architecture"
tags: ["decisions","team-design","code-quality"]
---
When modernizing an old system, at some point someone needs to decide what kind of project it is. That decision shapes everything that comes after. Usually, I think, this kind of project gets funded as a technology project (rewrite! migrate to a new platform!) with a budget and an end date. But what if we funded it instead as an org design project, and the first thing we did was redraw the ownership?

[Architecture Modernization](https://www.manning.com/books/architecture-modernization) by Nick Tune with Jean-Georges Perrin (Manning, 2024) answers the subtitle question with socio-technical alignment of software, strategy and structure. Tune writes that architecture includes how the business works and how the team is organized, so modernizing must update outdated thinking in those areas as well as in the code.

Technology-first leaves teams and boundaries in place and replaces the stack underneath. It seems faster and easier to budget for. In the [InfoQ podcast](https://www.infoq.com/podcasts/architecture-modernization-nick-tune), Tune describes the typical outcome: the new world gets built in isolation, collides with the old world's constraints late (network policies, compliance rules), and must bend around them. Often the old funding models and business processes need to be restructured too, and that's beyond the technology budget.

If you rewrite the same systems with the same teams along the same boundaries, you'll mostly recreate the old coupling on new tech. Conway's law doesn't care what the stack is. If two teams had to coordinate every release in the old system, chances are high that in the new system you'll still have two services that need to coordinate every release.

The org-design-first option starts with the business, not the stack. It maps strategy with Wardley maps and EventStorming, aligns loosely coupled boundaries with business domains, and shapes teams around them using Team Topologies value streams. Only then do we choose the tech for each boundary, by the teams who own them.

Tune's vehicle for this is the Architecture Modernization Enabling Team. It facilitates sessions like EventStorming, determines what support each team needs to stay on course, and avoids making architecture decisions centrally. There's a real cost to this approach.. it takes longer to show results, and Tune is explicit about that: deliver less now to do more later.

I'd rather do the org design first, because if you set up boundaries that match the business, you can make smaller, easier tech decisions (each team can make decisions for their own domain instead of having to make a single platform decision for all of it at once).

Tune says that modernization doesn't really finish.. "It's not like a party at the end where it's all done, it just people stop talking about it." If that's the case, I think that kind of open-ended work maps better to a standing capability (the enabling team that stays) than a closing project. If there's no finish line, does modernization belong in a project budget, or is the enabling team what gets funded?