The Architecture of Architecture, Part III

By Len Fehskens

(Back to article)

In my last post I promised this time I would describe my search for a definition of “our kind” of architecture that was not a fancy synonym for design and that could encompass varieties of architecture as diverse as enterprise, information technology, information systems architecture, solution architecture, infrastructure, network, software, application, management, security, process, service-oriented and maybe even Java.

So, what makes a good definition and what do we want a good definition of architecture to do for us?

A good definition:

  • Is simple, concise and easily remembered;
  • Is unambiguous;
  • States rather than implies what something is;
  • Facilitates making distinctions between things that are usefully distinguished;
  • Discourages making distinctions between things that are not usefully distinguished.

    A good definition of architecture should make it clear what is architecture and what is not. It is tempting, when you don’t really know what something is, to define it in terms of what you hope it will do for you. A good statement of what something is should strongly imply what it can do for you. The most frustrating definitions are those that accurately describe something in a way that provides no insight into its purpose.

    Let’s start by considering what it is we want architecture to do for us. While the definition itself should not be cast in these terms, the definition should be operationally useful in realizing those hopes. What do we want “our kind” of architecture to do for us? For the sake of simplicity I’ll refer to “our kind” of architecture as “IT architecture”. In what follows, though I will try to make the case that “our kind” of architecture can and should be about much more than just IT.


    One of the most powerful techniques architects use is modeling. A model is a simplified analogue of a system. The simplification makes it possible to consider the model and extrapolate its properties and behavior to the properties and behavior of the actual system. The art of modeling is leaving out the stuff that doesn’t matter, so its absence won’t affect the properties and behavior you are interested in. An analogy is a kind of model, so it’s not surprising that many IT architects use analogy as a way to try to understand their own discipline.

    An obvious analogy come from the discipline that we borrowed the name from—building or civil architecture. (It’s only recently that the word architecture had to be qualified to distinguish “real” architecture from upstart pretenders to the throne.) What does civil architecture do for its stakeholders, that IT architecture could also do for our stakeholders?

    Many educated commentators have invoked the work of Vitruvius (Marcus Vitruvius Pollio, a Roman architect living in the first century B.C., author of De Architectura, “The 10 Books on Architecture”), specifically his three essential qualities of a building, as a basis for defining IT architecture:

    I must admit that I have always been skeptical of this approach. Not to belittle Vitruvius’s insight, but I have to ask what direct relevance it has to the idea of architecture as applied to complex information systems. How does Vitruvius’ two thousand year old conception of what makes a good building apply meaningfully to a discipline he could not have imagined?

    That being said, there’s no real news here; IT stakeholders clearly expect “utility” (i.e., “business/IT alignment”) and IT systems that won’t “fall down”. It’s not clear what “beauty” means when applied to IT systems, and more importantly what business value it might provide to stakeholders. And there are many other classical architects who have written about their discipline (e.g., Palladio). Why isn’t their work considered as sound a foundation for IT architecture?

    When I was an undergraduate at MIT, my Eastern Religions Professor Huston Smith taught that “An analogy is like a bucket of water with a hole in it—you can only carry it so far.” This lesson is particularly applicable to the temptation to analogize IT architecture and building architecture.

  • 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.