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:
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.
Modeling
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.