Martin Fowler's 2019 guide page is built around Ralph Johnson's decades old refusal to pin down what software architecture means, and that non answer may be the most useful definition the field has produced.
Two decades after an email exchange that helped coin it, the cleanest one-line definition of software architecture is still a shrug. "Architecture is about the important stuff," Ralph Johnson wrote. "Whatever that is." Engineers have been borrowing the line ever since, partly because it is funny, and partly because nobody has produced a better one.
Johnson, one of the four authors of the influential "Gang of Four" design patterns book, was not dodging the question. He was describing the shape of the question itself. The important stuff in any given system is the part that is hard to change later, the part that quietly constrains everything built on top of it. The hard part is recognizing it before it has been built.
Martin Fowler has spent most of his career on this problem, and his Software Architecture Guide page is the most condensed version of his answer. Dated 1 August 2019, the page presents itself as an orientation rather than a manifesto. It links deeper into Fowler's site, into talks he has given, into the books and collaborators who shaped his thinking. The first thing a reader notices is what the page does not do: it does not define architecture.
Fowler calls the term "hazily defined" and notes that it is often used with "an unhealthy dose of pomposity." He resolves the tension by redefining the goal. Good architecture, he writes, is the part of a system that "supports its own evolution" and is "deeply intertwined with programming." The phrasing is deliberate. Fowler is not saying architecture is unimportant. He is saying the field's energy has been misspent on the label, and would be better spent on the underlying work of keeping systems changeable.
This is a quieter claim than it sounds. Most software disasters do not begin as architecture failures. They begin as database choices, as framework defaults, as API contracts, as the small decisions a team makes in the first month of a project and then never revisits. Two years in, the team discovers that the thing they thought was a detail is now a load-bearing wall. The original decision is, in Johnson's sense, architectural, not because anyone called it that, but because everything else is now built on top of it.
The Fowler page treats this recognition as the actual skill. Architecture, in his framing, is the shared understanding expert developers carry in their heads about how a codebase actually fits together: the unspoken map senior engineers carry around about why this service calls that one, why this table is the one nobody is allowed to rename, why a particular abstraction exists at all. That map is rarely written down. It lives in the heads of the people who have been there longest, in code review comments that say "we don't do it that way here," in the quiet vetoes during design meetings. Fowler's contribution is to argue that this map is the architecture, and that the work of software architecture is keeping that map accurate as the system grows.
For most of the field's history, that has been a manageable problem. The people holding the map were the people writing the code. The map updated itself, slowly, through the normal rhythms of pull requests and postmortems. The architectural decisions surfaced when they needed to, and the people making them were usually close to the consequences.
That assumption is under stress. AI coding tools have moved large parts of the implementation work, the part of software work that used to be the main way engineers built the shared map, out of human heads and into model context windows. A junior engineer with a competent assistant can now produce in an afternoon what used to take a senior engineer a week. The code gets written. The map does not necessarily get updated.
This is not an argument against the tools. It is an argument for paying attention to what they change. The architectural map, in Fowler's sense, has never been the code. It has been the cumulative judgment of the people who know the code. When the production of code accelerates, the production of judgment has to accelerate with it, or the map stops matching the system. The decisions that used to be made by the people who would live with them are now sometimes made by the people who will not.
A useful way to read the page, then, is as a kind of stress test. The definition Fowler offers is not a list of boxes a system must check. It is a question the team has to keep answering: in this system, what is the important stuff, who is holding the map of it, and what happens to that map when the people holding it are no longer the only ones writing the code? The teams that can answer that question in plain language are the teams that will recognize the architectural decisions when they show up. The teams that cannot are the ones that will discover, eighteen months into a database migration, that the original choice was architectural all along.
Fowler's 2019 page is a useful restraint here, not a verdict. He does not claim that any of this is new. He notes, in the same page, that most of his career has been spent on what good architecture looks like, how teams create it, and how to cultivate architectural thinking in organizations. The page is dated August 2019, before the current wave of AI coding tools, but the question it opens, what is the important stuff and who decides, is the right one to be asking now.
Johnson's shrug was never a refusal to think. It was an admission that the field's hardest work is not in defining its terms. It is in noticing, in each system, which decisions are the ones future engineers will not be able to undo. Fowler's page is worth reading now for the same reason it was worth reading in 2019: it tells the reader, in the plainest language the field has produced, that this is the work that matters, and that the work is never finished.