Enable JavaScript.

Software Architecture Blueprints

This essay is about the specifications needed to create robust, large-scale software systems. I am calling these specifications "blueprints" by analogy with the big sheets of blue ink drawings that are used to create buildings. In this essay, I assert that the blueprints produced by software architects are so crucial that we can justifiably say "The blueprints ARE the architecture!"

I made this assertion in a panel discussion on software architecture and considerable discussion ensued. For some people architecture seems to exist on a metaphysical plane, as the architect's vision of what is to be built, something conceived holistically, something that can never be fully expressed in any set of documents or even in any implementation. This is, of course, another example of Platonic ideal forms, that the idea of something is greater, or more perfect, or more important, than any real world manifestations of that idea; that the idea of a circle is necessarily more perfect than any real circle could ever be.

I believe this is a dangerous view, in architecture (as well as in philosophy and theology). It is too convenient an excuse for project failures; that a project failed to meet the metaphysical vision of the architect because the specifications were necessarily inadequate. In this sense, every project is a failure.

Can you imagine a civil architect blaming the collapse of a skyscraper on the inadequacy of the blueprints he or she provided? Never! Professional competence and self-esteem prevent it, to say nothing of legal liability. It is the architect's responsibility to provide adequate blueprints, to work with the construction firm to make sure they are understood, to work with building inspectors to validate conformance to the blueprints, and to make formal changes to the blueprints as new requirements are identified and as construction problems are discovered. No excuses are accepted. Nor should they be accepted from software architects. The blueprints are the job!

Dave West [West, 1998] reacted strongly to the assertion that "The blueprints are the architecture." He considered it a "materialistic view" of architecture. In a panel discussion, he made the following statements.

"The map is not the Territory!"

True, but maps are a great aid to understanding the topology of the territory.

"Blueprints can be produced by contractors and engineers — usually better than they might be produced by an architect."
Let's face it, there are great engineers and lousy architects. But in general, someone who has specialized in architecture and is experienced in producing blueprints will do a better job. Seriously, would you ever let a carpenter, however talented, design a skyscraper? A garage, maybe, but not something significantly more complicated.

"The only way you might assert that the models and blueprints ARE the architecture is if you believe that there is some implicit TRUTH captured in those documents."

An architecture, as embodied in its blueprints, exists independently of any implementations. Consider, for example, the famous design by Frank Lloyd Wright for a futuristic building on an island in New York Harbor. It was never built, and it is doubtful it ever will be, but it is considered to be an important part of Wright's architectural legacy.

"The artifacts (models and blueprints) represent nothing more than communication aids to a group of people actively engaged in the task of creating an architecture. They have no intrinsic value. Their meaning is dependent on the continuation of the community of people that created them."

Blueprints are, indeed, a communication aid, but they also have intrinsic value. If design and development teams are separated in space or time, blueprints create an enduring community. Ad hoc, verbal agreements are suitable only for trivial projects. Further, blueprints have lasting value as a source of information when changes are required to implemented structures.

"The effect of this position is to assert the primacy of the charismatic and communicatory and people roles of the architect. The architecture is a collective brainchild of those people - at all levels - involved in creating it."

If no blueprints are produced, the result is transitory, and no architecture is created.

So what are the "blueprints" of a software architecture? Blueprints are different things for different fields of endeavor. The following table compares the information contained in the blueprints produced by civil architects with the blueprints that software architects produce.

 

Civil Architecture Blueprints Software Architecture Blueprints
The name of the project. The name of the project.
The responsible architect. The responsible architect.
The date and version number of the blueprint. The date and version number of the blueprint.
The goals, objectives, budget, and schedule of the project. The goals, objectives, budget, and schedule of the project.
The building codes to be followed. The standards to be followed.
The site and environment of the new building. The network and application environments in which the software must exist.
Elevations showing what the building will look like from various angles. High level, structural views of the software. They can take many forms, from text and drawings, to elaborate models and hypertext documents. Each project can choose what is most appropriate.
The layout of the foundation. The patterns and frameworks to be used.
The room plan of each floor. Each subsystem or layer or tier, and how they relate to each other.
Construction details to the extent needed to convey how something should be built. Construction details about any special structures or algorithms to be used.

References

[Demers, 1992]
Demers, R. A., Fisher, J. D., Gaitonde, S. S., Sanders, R. R., Inside IBM's Distributed Data Management Architecture, IBM Systems Journal, Vol. 31, No. 3, 1992, pages 459-487.
[West, 1998]
West, David was the chairman of the Computer Science department at St. Thomas University in St. Paul, Minnesota. He sponsored a conference of the Object Technology Group at which I chaired a panel discussion on Software Architecture.

Les bleus pour l'architecture de logiciels

 

Cet essai porte sur des spécifications dont on a besoin pour la création de grands systèmes des logiciels.


Désolé, pas encore traduit.