Foreword to the Second Edition

A colleague of mine, in the market for a home, fell in love with an older property that had been designed by a student of Frank Lloyd Wright himself. Curious about its history, its structure, its evolution, he contacted the local planning office, which happily and quickly provided him with a copy of the original blueprints.

Why, my friend asked me, can we get the drawings for a house that’s several decades old, but we are unable to see the architecture of software written last year?

In this book, the authors offer some pragmatic wisdom that helps attend to my friend’s lament.

The theory and the practice of the architecture of software-intensive systems are in a very vibrant phase. The early work of Mary Shaw and David Garlan in particular gave rise to software architecture as an identifiable domain of study, and in the years since, we’ve seen the emergence of architecture-as-an-artifact as a mainstream concern for the development and evolution of systems. This has manifest itself in notations such as the Unified Modeling Language (which was explicitly influenced by Philippe Kruchten’s 4+1 model view of software architecture) as well as a panoply of architectural frameworks, such as The Open Group Architecture Framework and the Department of Defense Architecture Framework. Add to these methods such as IBM’s Unified Process and, at another extreme, the Federal Segment Architecture Methodology, and it is clear that architecture-as-an-artifact has found an important role in the reasoning about and governing of software-intensive systems.

There are some things we can say with confidence. Every system has an architecture. All complex systems are hierarchical in nature, but also exhibit other patterns of regularity. There’s an intimate dance that occurs between the processes of architecting and of implementation. And, to understand and reason about the architecture of a software-intensive system, one has to consider multiple views from the perspectives of specific concerns from multiple classes of stakeholders.

The most commonly used notation and tool for describing a system’s architecture is a boxes-and-lines sketch created on a whiteboard. Such documentation is both expeditious and useful, but it is neither enduring nor rigorous nor complete. In this book the authors offer the definitive reference on the documenting of the architecture of software-intensive systems, in ways that are enduring and rigorous and complete. And useful, by the way!

I remember reading the first edition of this book, and e-mailing my compliments to the authors for producing such a comprehensive reference. Well, they’ve outdone themselves. This new edition is brighter, shinier, more complete, more pragmatic, more focused than the previous one, and I wouldn’t have thought it possible to improve on the original. As the field of software architecture has grown over these past decades, there is much more to be said, much more that we know, and much more that we can reflect upon of what’s worked and what hasn’t—and the authors here do all that, and more.

So, my hope for you, dear reader, is this: May the software you write today have an architecture that your children’s children may discern and celebrate.

—Grady Booch

IBM Fellow