IT as Lego: Why This False Metaphor Does More Harm Than Good—and What to Use Instead (#Architecture)
At ArchDays 2024, in my talk on the evolution of architecture at T-Bank, I had a slide titled "IT as a Lego." That was how the concept of solution reuse looked: identify blocks, assemble systems from bricks, everything interchangeable and neat. Back then I said briefly that the metaphor does not work. Now I want to explain exactly why, especially since Chad Fowler is writing a book for O'Reilly titled "Regenerative Software" about precisely this (the book is excellent, and I will write about it as soon as I finish reading it).
Why Lego is seductive A brick has one interface, the standard studs, and any brick snaps onto any other. A brick has no state and does not change while nobody touches it. Replacing a brick costs nothing. This yields a very convenient planning logic: a system equals a list of blocks, a block equals a budget line, reuse is free, and replacing a system is a project with an end date. In essence it is the same construction metaphor as "a service is a building", just with an assembly manual.
It sounds great, but what is wrong with this metaphor? A service is not a brick. It has data and history, implicit contracts, and consumers who have long relied on undocumented behavior. In the talk I put it this way: from the Lego point of view, replacing an element is just a brick; from the point of view of a living system, it is a transplant of a vital organ. Decisions made in Lego logic are recognizable by their phrasing: - “Let's take the boxed product now and replace it later,” and the original box lives on next to two waves of its replacements. - “Let's call this a platform and everyone will reuse it,” and a block pulled out of its environment drags that environment's assumptions along and does not fit anywhere else. - “It's a small service, we'll replace it in a sprint,” and it was only small in lines of code.
I prefer the plant metaphor and the image of a rice field from the same talk of mine: we gradually extend it and do not know what is hidden at the bottom. A system is not assembled but grown. It responds to its environment, it has immunity and a recovery period after surgery. Different decisions follow from this metaphor - A migration is planned with a coexistence period, not as flipping a switch - Investment should go into the environment and the immune system: the platform, tests, and observability - And we must accept that parts of the system will grow on their own and need pruning.
The book "Regenerative Software" takes this metaphor further. It is now being written by Chad Fowler—co-creator of RubyGems, author of The Passionate Programmer, and former CTO of Wunderlist. The book is out in O'Reilly's Early Release, with the final version expected in April 2027, and it grew out of the essay series "The Phoenix Architecture", which Fowler has been publishing since December 2025. The thesis: code is no longer the asset; the system is. When generating code is almost free but verifying it is not, the defining property becomes replaceability—the ability to safely replace a component as a whole. What must be preserved is whatever you cannot recreate it without: behavior, boundaries, evaluations, evidence, and provenance—that is, the history of why a decision is the way it is. I liked his deletion test: “If I deleted this codebase and regenerated it from scratch, what would I rely on to decide whether the result was correct?” Fear at that question means the knowledge lives only in the code.
Fowler opens the second chapter with a story from Wunderlist: replacing a "simple" group membership service was given an afternoon, and the team tripped over their own unique-ID system, through which everything else located data and which nobody fully understood anymore. The very same organ transplant, described from the inside.
If we continue the biological analogy (this is mine, not Fowler's), he proposes not transplanting organs but regrowing them from the system's "genome": specifications, tests and decision history. The organism stays itself even though its cells have been replaced. Whether this works beyond tasks with rigorous evaluations is still unclear, and Fowler himself notes that replaceability can be the wrong goal. But as a decision-making frame, it is certainly better than bricks.
So the next time you hear "it's just a brick, we'll swap it," ask: which organ is it, what has grown around it, and what will you rely on to verify the replacement?
#Architecture #Software #Engineering #AI #Books #Management #SystemDesign