Erik Doernenburg is a technology principal at ThoughtWorks, Inc., where he helps clients with the design and implementation of large-scale enterprise solutions.
AS ARCHITECTS, WE WANT TO KNOW how good the software is that we are developing. Its quality has an obvious external aspect—the software should be of value to its users—but there is also a more elusive internal aspect to quality, having to do with the clarity of the design, the ease with which we can understand, maintain, and extend the software. When pressed for a definition, this is where we usually end up saying “I know it when I see it.” But how can we see quality?
In an architecture diagram, little boxes represent entire systems and lines between them can mean anything: a dependency, the flow of data, or a shared resource such as a bus. These diagrams are a 30,000-foot view, like a landscape seen from a plane. Typically the only other view available is the source code, which is comparable to a ground-level view. Both views fail to convey much information about the quality of the software: one is too high level and the other provides so much information that we cannot see structure. Clearly, what is missing is a view in between—a 1,000-foot view.
This 1,000-foot view would provide information at the right level. It aggregates large amounts of data and multiple metrics, such ...