A building is a static, tangible artifact, while an information system is a dynamic, intangible artifact. In many respects, it really only exists when it’s running, and when it’s running, it’s changing continuously. I am reminded of the famous line from Goethe’s “Faust”: “Alles vergängliche ist nur ein Gleichnis,” or “Everything transient is only an allegory.”
Finally, representations of IT architectures are much less (if at all) representative to end users than a building’s plans, sections and elevations. Anyone can look at an architect’s drawings and readily grasp what the building will look like, inside and out, and how well suited it will be for its occupants. Three dimensional architect’s models are even easier to interpret.
I think a more fruitful analogy might be drawn with music. Consider the following table, which compares the two analogies:
Some points are worth elaborating a bit. While the physical elements of IT infrastructure are static and tangible, it is only when they are running and sourcing, transferring, transforming or sinking data that they are delivering value, and this data is itself a dynamic commodity. The “architectural representation” of music is a score. Unlike an architect’s blueprints, drawings and models, but much like IT specifications and models, a musical score is an abstract, and to the uninitiated, cryptic representation of a dynamic phenomenon that can be understood only with considerable training and experience.
When a new musical work is premiered, most listeners don’t have any real idea of what it will sound like until the performance actually takes place, or in this analogy, the information system is built, deployed and run. Commercial music (e.g., film scores, advertising jingles, brand audio tags) may have client requirements. One could argue that building architects are in many respects just as loosely constrained. Their clients want a building that “makes a certain kind of statement,” encloses a certain amount of space and partitions it in certain ways, and won’t fall down.
Within those constraints a building architect is largely free to do as he/she pleases, i.e., express their own ideas and hope the client agrees with them. The external context of an IT initiative is an enterprise architecture, the external context of a building is a city plan.
Both analogies are equally effective in distinguishing the many roles necessary to achieve success.
As noted earlier what makes a model (and hence an analogy) useful is how well it models the things you care about. If you agree that a piece of music is a better analogy to an information system than a building is, then we should look to a musical score rather than a building blueprint for an understanding of what IT architecture is really about.
Next time, I’ll follow up this idea, and compare and contrast it with the “conventional wisdom” on what IT architecture is about.
Len Fehskens is The Open Group’s vice president and global professional lead for enterprise architecture. He has extensive experience in the IT industry, within both product engineering and professional services business units. Len most recently led the Worldwide Architecture Profession Office at Hewlett-Packard’s Services business unit, and has previously worked for Compaq, Digital Equipment Corporation (DEC), Prime Computer and Data General Corporation.