James Governor, in a post recently on MonkChips, raised the issue about code architecture and complexity, (IBM architects catch lesscode virus? maybe not) that started me thinking about the specific role of architects themselves. The term (or title, depending upon how its used) has a comparatively recent currency, and I suspect really started gaining vogue only about the time that Bill Gates decided to leave the position of CEO for the somewhat nebulous title of Chief Architect. All of a sudden, it seemed, the architecture position in a company become one of the most coveted spots possible, leading to a rather dramatic inflation in the number of “architects” in the field.
When I was a kid in Boy Scouts (lo those many years ago) the troop went on a field trip to a company (likely to someone’s dad, though which of us had such a cool dad I never did find out) that created scale models of prospective office buildings for architectural firms. At the age of twelve, it was perhaps understandable that I immediately equated architects with model builders, even though that wasn’t completely accurate in this particular case. However, the analogy is not a bad one from a programming standpoint.
The models in this case were made of resin and epoxy, replete with little toy figures placed at strategic places to show plastic marketing people entering into these perfect buildings (that analogy is also curiously appropriate, come to think of it…) but it was the idea of being able to get at least a basic sense of how very preliminary blueprints would become real buildings that I found especially intriguing. Now, of course, the resin and epoxy have given way to elaborate computer simulations, superimposed over the existing landscape, with the walls catching the light in scintillating fashion that somehow never quite seems to translate into the real world, but even here what you are dealing with is perfection. A model is fundamentally perfect - it hasn’t yet been eroded by the imperfections inherent in being in the real world, and a good architect understands this (even if they don’t replicate the graffitti, the winos in the back alleys and the effects of corrosive rains when the client comes around).
A few years later, at the University of Illinois, I also saw the model of the architect, and its reality. LIke most schools, the U of I has dorms, almost barracks-like in their design, and the dorms are generally positioned such that students in any given discipline would be parked farthest from where there classes would be, for some truly bizarre reason. For this reason, the dorm I was in happened to overlook the dorms where most of the architecture students were encamped. Thus, I was privileged to witness an annual rite of late spring there - the firing of the models. Competition in the architecture school was tight, and washing out was always a very real possibility. Thus, a not uncommon spectacle at the end of term was the sight of a crazed architect student tossing out his (always his) enamel, resin and epoxy model from the highest point available in the dorms, usually well doused with lighter fluid, along with the subsequent toss of a match to set the whole thing ablaze. After a while, the police and the fire department would show up along with the obligatory psychiatrist, and next time you saw the ex-architect he was usually asking “Do you want fries with that?”. It’s tough being an architect.
An architect must be a polymath. While its not strictly required that an architect be an artist, he or she does need to have the ability to visualize complex systems — buildings, computer applications, and what’s more, communicate those visualizations to others. However, this artistic striving also needs to be tempered with engineering precision, knowledge of human psychology and a fairly deep understanding of business. They should of course know the characteristics of the materials they work with - an architect of buildings must understand materials science and the nature of forces, an architect of code must know how both software and hardware work at a fairly intricate level.
This does not, however, mean that they need to be materials engineers or hot shot programmers, and indeed, too indepth a knowledge of a given domain of programming can often blind people who would strive to be architects from the advantages of taking different approaches. This means that architects must also be generalists, knowing enough in any given area to both assess the technologies in question and to know who to approach to get the detailed answers. I’ve seen too many software projects over the years derailed because an architect/programmer chose what he or she knew to solve a problem rather than what was the best solution overall, especially when that architect was just as likely NOT going to be the one living with actually writing the code.
An architect must also be a systems theorist, something which I believe to be an increasingly critical requirement. Systems theory is the analysis of how agents work across networks, whether those networks are physical (the interplay of forces within a building or a bridge) or metaphysical (the interaction of code components across a distributed environment). Indeed, a systems architect’s primary responsibility is to ensure that all of the components being developed in a given application can work in conjunction with one another. This in turn necessitates developing a head for working with abstraction, typically at a level above (sometimes considerably above) those writing the code segments themselves.
I bring this last point up because it is very much germane to a discussion I’ve had in previous columns — that you cannot eliminate complexity from an application, you can only shift it from place to place. The role of the architect in that regard includes determining where that complexity will emerge, and to insure that the complexity is in general passed on to those programmers (or systems or frameworks or whatever) that are most capable of handling them, reducing the complexity elsewhere in the application as a consequence. Doesn’t always happen of course, but the failure to do that can result in some truly bad architecture, and it seems to come at the point where the architect loses sight of the purpose of the application in the first place.
Going back into the realm of buildings for a minute, a classic case in point is the new library building for the City of Seattle, opened up in Spring 2005. On paper, it looked impressive - a large angled window facade, sections designed to be organic and flowing and non-linear, an aspiring vision for the future. However, somewhere along the line the architect forgot about the two fundamental facets of libraries - it houses books and provides a space for readers to read them. Books are fundamentally rectangular prisms. This in turn means that they work best on linear shelves that can be arranged row upon row, with each row in turn maintaining a specific space between them to let people move through them browsing while at the same time minimizing the distance to insure the storage of a lot of books.
Angled walls and organic, rounded corridors cut down on the available space for books, forcing the need for open terraces that in turn gave the accoustics of the library all of the characteristics of a modern airport terminal. The inefficiency of storage cut down on the amount of space available for books and forced readers to go much farther to find their desired books, which in turn reduced the available space for study carrols and reader areas, and in keeping with the organic motif meant that there were fewer places to sit and read or study, largely in very stylish but incredibly uncomfortable chairs. In other words, it was a nice piece of Modern Art, but as a library it was a disaster, all because the architect failed to take into account the primary aspect of his job - that he was designing a building that needed to serve a very specific purpose with very strong constraints, not indulging in an artistic whim.
It is ultimately a lesson that software architects should take to heart. Design to the needs of the project, not the vanity of the architect, the extent of his comfort with certain technologies, or the desire to end up on the cover of a technical magazine. If the job is done well, most people should not think about it at all, though those that are in the know will certainly appreciate the talent and dilligence (and ultimately will reward appropriately). Let the work speak for itself, not by being flashy and gaudy, but by being well engineed and clearly defined and just as clearly documented. Otherwise you might was well just douse the design in lighter fluid and throw it, flaming, to the commons below.
Kurt Cagle is an author and occasional system architect.