WICSA 2005:Why Architecture Isnt Just Design Decisions
From WICSA Conference Wiki
Some papers and WICSA participants are suggesting that software architecture is just a series of design decisions. I respectfully disagree.
Certainly design decisions are important. Design decisions certainly capture information about reasons behind a particular software architecture, but it is only part of the picture. In fact, before we can even communcicate the reasons about a design decision we must share a common understanding of the software structure.
A simple analogy is in order. Consider the design decisions behind the type of knot used to tie a child's shoes. There are actually many factors that play into the final form the knot takes including the length of the laces, the material of the laces, how tightly the knot is tied, etc. But I suggest that before I can even describe the design tradeoffs involved in choosing a double-knot over a single knot, I have to describe the structure of the solution alternatives and the constraints. In this case, it can be described trivially because everyone understands the differences between the double-knot versus single knot solution.
What's the Architecture Model Anyway?
In software describing the solution structures are not so simple. The solutions involve representing the dynamic execution of code. Of course, the counter argument is that we already know everything about modeling architectures: ADL's views, etc. Do we really know this?
Simple experiment. Put 20 software architects in a room and ask them to develop a solution to an architecture problem. What language will they use to describe the solutions and tradeoffs? Abstract boxes and lines? ADL's? What relationship will these solution representations have to the actual code that would acutally be implemented?
In Practice
So what happens in the real world? It varies, but really important architectural decisions on larges projects in sophisticated organizations may involve a long exploration and study resulting in an a design artifact, such as a design rationale document, that describes the reasons behind a particular decision. Integrating this decision analysis 'into' the final architectural model doesn't really make sense. The rationale and description involves several views of alternative architectures -- not just the final architecture.
