The art of systems architecting, revisited
By Urban Bettag · 18 February 2023 · 3 min read
I found a book review I wrote twenty years ago. The surprise was how well Maier and Rechtin’s ideas have aged.
I recently came across an article I wrote twenty years ago, as an architect in the R&D arm of a global financial services firm. It reviewed The Art of Systems Architecting by Mark Maier and Eberhardt Rechtin, a book my manager had pressed on me. Rereading it, I was struck by how much still holds.
A rare book about systems, not hardware
Few design books focus on systems architecture rather than hardware. Maier and Rechtin’s, written as a graduate text at USC, manages to be accessible rather than academic. It runs in four parts: the art of architecting and its parallels with traditional architecture; new domains and the heuristics they yield; models and modelling; and the profession itself, including the politics and the education of an architect.
What architecture actually means
“Architecture” stretches from CPU instruction sets to software modules to enterprise IT, which is why it resists a tidy definition. A few principles help: every system has an architecture, but the architecture is not the system; the architecture and its description are different things; and a description always involves multiple views. “Architecting” is the work of designing for problems without precedent, where there is no standard process to fall back on. Where a solution is reproducible, that is engineering, not architecting.
Architecting is not engineering
This distinction is the heart of the book. Engineering deals in measurables with analytical tools: deductive, quantitative, scientific. Architecting deals in unmeasurables with guidelines and judgement: inductive, qualitative, client-focused. The authors set out four approaches. Solution-based and method-based sit on the engineering side, good for simpler or technical problems but poor with change and politics. Stakeholder-based and experience-based lean to architecting, engaging people or accumulating lessons, though both can slow down or resist validation. Engineers optimise; architects apply common sense to satisfy the client.
Heuristics: experience, made portable
Architecture is learned by doing, which raises a question: how do you learn from someone else’s experience? Heuristics are the answer. From the Greek for “to find a way”, they are short statements that capture experience in a context and lower the risk of failure. “Simplify, simplify, simplify.” “Don’t build it if you can’t analyse it.” A good heuristic is simple, non-trivial, broadly useful, and explainable in a page. Some describe a situation; others prescribe an action. You consult your catalogue, judge what fits, and apply it.
Is it worth the effort?
Specifying and building systems costs real time and money, and standard techniques often fail on genuinely novel problems. Architectures never stand alone; they align with product, information, security, organisational and business architectures. Even seasoned architects meet new problems with every system, and describing them, especially with off-the-shelf and third-party parts, is hard work. Standards like IEEE 1471 clarify views and viewpoints but say more about description than process. A living catalogue of heuristics would help an organisation understand why some architectures succeed and others fail.
The verdict
Maier and Rechtin cover the fundamentals thoroughly, but reading about good architecture is like reading about the piano: necessary, not sufficient. The 1998 edition predates collaborative systems and lacks modern case studies. Even so, it earns its place on any architect’s shelf. The lasting lesson is the value of heuristics: written down as shared best practice, they become a reference an organisation can actually learn from.
Originally published on Medium. ← All insights