The Architecture of Architecture, Part IIIlast 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:
A good definition of architecture should make it clear what is architecture and what is not. It is tempting, when you dont 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.
Lets 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 Ill 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 doesnt matter, so its absence wont affect the properties and behavior you are interested in. An analogy is a kind of model, so its 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 frombuilding or civil architecture. (Its 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 Vitruviuss 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, theres no real news here; IT stakeholders clearly expect utility (i.e., business/IT alignment) and IT systems that wont fall down. Its 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 isnt 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 ityou can only carry it so far. This lesson is particularly applicable to the temptation to analogize IT architecture and building architecture.
Finally, representations of IT architectures are much less (if at all) representative to end users than a buildings plans, sections and elevations. Anyone can look at an architects 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 architects 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 architects 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 dont 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, Ill follow up this idea, and compare and contrast it with the conventional wisdom on what IT architecture is about.
Len Fehskens is The Open Groups 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-Packards Services business unit, and has previously worked for Compaq, Digital Equipment Corporation (DEC), Prime Computer and Data General Corporation.