I’ve been reading an interesting book — Beyond Software Architecture, by Luke Hohmann. In his first chapter he discusses the more people- and business-related aspects of architecture, and makes the following points:

• Systems are designed to manage people dependencies, not just esoteric "code" dependencies.
• Systems are designed by people with non-technical motivations.

Point well taken.

I wanted to chime in with one additional observation. An architecture and the people who actively develop and maintain it are difficult to separate. I’d argue that a company that owns the source code of a so-called “architecture” but that has no engineer that understands it doesn’t really have an architecture — as with Schrödinger’s cat, the human observer matters.

A stark example of this has cropped up several times as I’ve done M&A work during my career. I have seen less technical executives repeatedly assume that the source code of a system = the system. In other words, they think people are fungible and an architecture can be purchased and transferred only by shifting source. In practice, that assumption causes problems. The boundaries around modules don’t always exist cleanly in files and directories on disk; sometimes they are more of a mental construct in the minds of those who build and service them. If you grab a wad of source and plop it down in front of people who’ve never worked with it before, the institutional knowledge that contextualized the system in the minds of its creators is missing. This is why a mediocre engineer well-versed in the context of a given architecture is likely to be more productive than a world-class engineer dropped into the architecture cold. It is also why layoffs and RIFs are more dangerous than you’d guess by simply looking at raw staffing numbers.