Grady Booch on Developing the Handbook of Software Architecture
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Software is invisible to most of the world. Although individuals, organizations, and nations rely on a multitude of software-intensive systems every day, most software lives in the interstitial spaces of society, hidden from view except insofar as it does something tangible or useful.
Despite its transparency, as Bjarne Stroustrup has observed, "our civilization runs on software." It is therefore a tremendous privilege as well as a deep responsibility to be a software developer. It is a privilege because what we do collectively as an industry has changed and will continue to change the world1. It is a responsibility because the world in turn relies on the products of our labor in so many ways2. In the context of that labor, software is perhaps the ultimate building material: it springs from pure thought and is intrinsically malleable, yet it can be made manifest in our hardware systems, limited only by our vision (and certain immutable laws of physics and software3). As software professionals, we seek to develop and deploy useful systems of quality in a manner that reduces the distance from vision to execution. That the fruits of our labor are transparent to the world is as it should be: users want results and value, not more technology. For this reason, the primary challenge of every software development team is to engineer the illusion of simplicity in the face of essential complexity.
Software development has been, is, and will likely remain fundamentally hard. To that end, the entire history of software engineering is one of rising levels of abstraction (for abstraction is the primary way we as humans deal with complexity), and we see this reflected in the maturation of our programming languages, platforms, processes, tools, and patterns. Indeed, every well-structured software-intensive system is full of patterns, ranging from idioms that shape the use of a particular programming language to mechanisms that define the collaboration among societies of objects, components, and other parts. At the highest level of abstraction, every system has an architecture, encompassing the key abstractions and mechanisms that define that system’s structure and behavior as seen from the perspective of different stakeholders, each with a different set of concerns. In every case - from idioms to mechanisms to architectures - these patterns are either intentional or accidental, but insofar as they are visible, such patterns reflect the style and inner beauty of each system.
It is a sign of maturity for any given engineering discipline when we can name, study, and apply the patterns relevant to that domain. In civil engineering, one can study the fundamental elements of architecture in works that expose and compare common architectural styles. Similarly, in chemical engineering, mechanical engineering, electrical engineering, and now even genomic engineering, there exist libraries of common patterns that have proven themselves useful in practice.
Unfortunately, no such architectural reference yet exists for software-intensive systems. Although the patterns community has pioneered the vocabulary of design patterns through the work of the Hillside Group and the Gang of Four (in their seminal book, Design Patterns4), our industry has no parallel to the architecture handbooks found in more mature design disciplines, such as Calloway and Cromley’s The Elements of Style5, Alexander’s The Nature of Order6, The Phaidon Atlas of Contemporary World Architecture7, Perry’s Chemical Engineers’ Handbook8, Sclater and Chironis’ Mechanism and Mechanical Devices Sourcebook9, Christiansen’s Electrical Engineers’ Handbook10, and the ICRF Handbook of Genome Analysis11.
Goals
The primary goal of the Handbook of Software Architecture is to fill this void in software engineering by codifying the architecture of a large collection of interesting software-intensive systems, presenting them in a manner that exposes their essential patterns and that permits comparisons across domains and architectural styles. Reflecting on his work on patterns, Christopher Alexander notes that he and his colleagues "made observations, looked to see what worked, studied it, tried to distill out the essentials, and wrote them down12." This approach is at the core of all good science.
The second goal of this work is to study these architectural patterns in the context of the engineering forces that shaped them and then to expose a set of proven architectural patterns that may be used to construct new systems or to reason about legacy ones.
The third goal of this work is to feed my insatiable curiosity. Whenever I encounter an interesting or useful software-intensive system, I often ask myself, "how did they do that?" By exposing the inner beauty of these systems through a study of their architectural patterns, I hope to offer inspiration to developers who want to build upon the experience of other well-engineered systems.
Organization of the Architecture Web Site
In order to collect and categorize these ideas, I have devoted a section of my web site to this endeavor. This site serves two purposes. First, as a work in progress, this site provides a collaborative environment - a virtual meeting place, so to speak - for collecting and studying the artifacts that I uncover and then organize in the process of my archeological digs. As such, most of this site is hidden from public view until such time as it is possible to assemble the results of my digs into a coherent representation of each system’s architecture, first for review and then for public presentation. Second, as each system is exposed to view, this site serves as an electronic Handbook of Software Architecture13.
This site is divided into five major sections, each accessible through the main menu:
The blog provides both a diary of my archeological digs as well as random commentary on things that interest me. The second section offers a general presentation on software architecture: what it is, what it is not, why it is relevant, where it fits in the development lifecycle, and how it can be represented. The third section is the center of this work, presenting the architecture of a large collection of interesting systems. The fourth section provides a summary of the major patterns harvested from these systems, presented in classic Alexanderien form. The fifth and final section provides a traditional and linear representation of this same material, serving as an electronic version of the Handbook of Software Architecture.
By registering and then logging in to this site, you will be given access to the publicly-released content of the Handbook. You may also be given access to other secure parts of the Handbook if you have been asked to contribute or review content.
Acknowledgements
My inspiration for this work comes from Bruce Anderson, who over a decade ago conducted a series of workshops at OOPSLA for the purpose of creating a handbook of architectural patterns. Much of what I know about the nature of software architecture comes from Philippe Kruchten, with whom I had the honor of working for many years. The work by Mary Shaw and her colleagues at Carnegie Mellon University, Paul Clements and his colleagues at the Software Engineering Institute, and Eberhardt Rechtin have also deeply influenced my approach to software architecture. I am indebted to the members of the Hillside Group (most notably Kent Beck, Ward Cunningham, Jim Coplien, and Dick Gabriel) and the Gang of Four (Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides) all of whom have inspired me to study and appreciate the inner beauty of software. I also thank the many thousands of software developers with whom I have had the opportunity to interact over the years and who have exposed me to so many interesting software-intensive systems that live in the world.
Thanks also goes to IBM for providing an environment in which I can carry out this work. I offer my sincere appreciation to Grant Larsen (my research assistant) as well as to Bill Higgins (who has done some additional investigative work for me) and Jim Conallen (my remote pair programmer and source of much insight on Apache/Tomcat/MySQL).
My greatest thanks go to my wife, Jan, who has patiently endured and encouraged my research for and the writing of yet another book.