Last time, I suggested that the obvious analogy between IT architecture and real building architecture was potentially flawed, because of the dramatic differences in their medium of expression, and that another analogy (with music) might be more appropriate in some ways.
The real lesson, though, is that all such analogies have serious limitations. While these analogies are intuitively appealing, they ultimately fail as models when it comes to the most important property of a useful model: the ability to straightforwardly apply what one learns from the model to the thing being modeled. This is because these analogies imply too many irrelevant details that obscure the essentials, the things that really matter.
How can we get at those essentials? Ideally, how can we develop a model for architecture that not only applies to “our kind” of architecture, but might also be applied to civil architecture and music, because it captures and expresses those things common to all three disciplines, the things that enable those appealing analogies? By answering the question I originally posed,—what is it that we want “our kind” of architecture to do for us?—that led to the consideration of analogy as an approach.
This time, I’ll start by trying to answer that question, and then start wrestling with how we might get from there to a useful definition of IT architecture.
The conventional wisdom about IT architecture has historically included statements like:
- Architectural decisions are more abstract than design decisions;
- Architectural decisions are global in scope, i.e., architecture is about a holistic perspective, or the big picture; and
- Architectural decisions are hard to change.
These three observations seem to flow into one another. Because architectural decisions are more abstract, they apply more broadly, i.e., are more global, and thus affect many more things, increasing the consequences of changing them. But these observations, even if they’re correct (and I’ll argue later that they’re not), don’t really help us understand what the benefits of thinking architecturally might be. And if architecture is just a more abstract form of design, where does architecture end and design begin?
Why call it architecture rather than, for example:
- Preliminary (as opposed to final) design, or
- Abstract (as opposed to concrete) design, or
- Logical (as opposed to physical) design, or
- High level (as opposed to low level) design, or
- General (as opposed to detailed) design?
These terms are frequently used, so we must ask, if they’re not architecture, then how does architecture differ from them? Not much help here either understanding what architecture is good for or how it differs from design.
Lately, other kinds of statements are increasingly heard:
- Architecture is about multiple views addressing the concerns of different stakeholders.
- Architecture is about adaptability.
- Architecture (especially enterprise architecture) is about aligning business and technology, i.e., delivering business value from IT investments.
The first of these recent characterizations is more about how one should represent an architecture, though it implies something important about what we hope to get out of architecture: reconciliation and integration of multiple stakeholder perspectives.
The second reflects the current obsession with being responsive to change. Adaptability is only one of many “-ities”, sometimes called pervasive attributes, system qualities or nonfunctional requirements. These are properties of a system as a whole, which cannot be readily isolated in a single component. While adaptability is certainly important in many situations, it is probably unduly restrictive to make it the primary focus of architecture.
The last, though, more directly addresses the question of the value of architecture, and it is inclusive of the other two perspectives on architecture. If this is what we expect of architecture, i.e., aligning technology with the needs of the business, what does architecture need to be to deliver on this promise?
Agile Programming
One answer, the premise of the agile programming movement, is that architecture, specifically when caricatured as “Big Design Up Front” (BDUF), can’t possibly deliver on this promise, and should just get out of the way. While there are a lot of very useful ideas in agile programming, there are too many of us whose first hand experience with architecture has shown that it works in real-world situations to “throw the baby out with the bath water”. Besides, if architecture is really distinct from design, it can’t be confused with “Big Design Up Front”.
One of the most valuable insights of the agile programming movement is that you can’t build a system that delivers business value if you can’t define what business value you need to deliver. Agile programming traces this problem to two sources: lack of understanding of what is needed, and the inherently dynamic “moving-target” nature of what is needed.