- On Architecture: Goodness of Fit
- Inventing Fortran
- An "ideal" architecture?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
An "Ideal" Architecture?
A striking architectural question derives from these three observations. Despite the facts that the original forces that led to Fortran are no longer valid and that John's team somewhat stumbled onto their compiler organization, the architecture of their original Fortran compiler—now 50 years old—looks amazingly like the general structure of many contemporary compilers for far more expressive languages. Does this mean that an "ideal" software architecture exists for any given domain?
From one point of view, the essential problem of compilation for Fortran in the 1950s is identical to that in contemporary languages such as C++ and Java. In both cases, the problem is I/O mapping: the source code (input) must be transformed (mapped) to machine code (output). In their book Software Architecture, Mary Shaw and David Garlan describe this as a pipe-and-filter architecture. As they explain it, this architectural style has the advantages of being simple while also letting developers reuse or replace processing components in the pipeline. However, it requires batch processing, so making incremental changes is difficult.
As it turns out, a subtle variant of the pipe-and-filter architecture makes incremental compilation possible. It didn't arise in the early Fortran days because incrementality wasn't a factor. This variant involves introducing an intermediate language such that the pipes and filters at the front of the pipeline create and manipulate this representation, and the pipes and filters at the back of the pipeline use that representation as their input. Especially for compilers, this intermediate pause in the pipeline has at least one advantage: it permits a better separation of concerns (with regard to the different machine languages to which a source language might be targeted).
Most modern integrated development environments use such intermediate languages to enable syntax-directed editing as well as context-sensitive semantic help and browsing (all front-end activities) while permitting compilation to different targets (all back-end activities). For several Ada compilers, there was even a formally specified intermediate language that gained wide use—namely, Diana (the Descriptive Intermediate Attributed Notation for Ada), developed at Tartan Laboratories and the University of Karlsruhe. IBM Rational's first product, the R1000 (essentially an Ada machine manifest in hardware), used Diana as its central data structure, and that design choice made incremental transformations of large programs possible.
Even with this variant, the pipe-and-filter architecture clearly has a goodness of fit to the compilation problem. By goodness of fit, I mean to measure how well a particular architecture resolves the forces that impose upon a given system. The same can be said of architectural styles as applied to other domains. For example, blackboard architectures are well suited to the speech recognition domain, which involves the resolution of knowledge from a variety of sources. Similarly, state-machine-centric architectures are well matched to event-driven (but not to time-driven) problems.
This problem of goodness of fit has parallels in civil architecture. Ernst and Peter Neufert's Architect's Data and Joseph DeChiara and Michael J. Crosbie's Time-Saver Standards for Building Types both offer architectural patterns for specific kinds and uses of buildings. Clearly, the fundamental architecture of a sports arena will vary widely from that of a hospital, and a warehouse's architecture will vary from that of a single-family residence. (We must be careful in taking this analogy too far: as witness to the resilience of warehouse architecture, many such lofts have been transformed into apartments in cities.) Indeed, in examining the state of the practice in civil architecture, for any given domain, time and use have evolved a core architecture with a goodness of fit, while at the same time allowing variants as in the compiler architecture case. As an example, look at the patterns that guide museum design (for example, the need for large open spaces) and yet the diversity that's still possible, from the Louvre to Frank Lloyd Wright's Guggenheim and more recently to Daniel Libeskind's Denver Art Museum.
So it appears to be with software architectures: For a given domain, even across the decades, forces are at play that are best resolved by a common architectural pattern that allows variants. One architectural style might be deemed "better" than another for that domain because it better resolves those forces. In that sense, there's a goodness of fit—not necessarily a perfect fit, but good enough.
Grady Booch is an IBM Fellow. He's one of the Unified Modeling Language's original authors. He also developed the Booch method of software development, which he presents in Object Oriented Analysis and Design. Contact him at architecture@booch.com.