WICSA 2005 Talk:Why Architecture Isnt Just Design Decisions
From WICSA Conference Wiki
Comment, Anton Jansen In the design decision process an issue/problem could very well be that for some terminology there is not a common understanding and that some decisions have to be made about this if you want to move forward. Assumptions and misinterperations are typical sources for problems/issues of the software architecture. Sometimes, the decisions to resolve these issues have already been made and the sharing aspect of design decisions is the main issue, in other cases identifying this as a problem is the problem itself.
For instance, one could make the decision to use a certain documentation approach and use its accompaining terminology. This defines a lot of concepts in a single decisions, without a lot of effort ... However, it does not prevent issues coming up from misunderstanding the used concepts and terms.....
Right, you made my point. Before we can even coherently discuss a design decision we must share common terminology about it. Of course no representation is perfect, but some description and coherent underlying model are required for people to have an effective discussion of alternatives. We want to highlight some particular properties of the proposed or actual software structure and ignore other properties. For example, I might be interested in the scalability properties of 2 different architectures.
Perhaps this is just my bias as a design patterns researcher showing, but this exact same sort of discussion of 'missing commonality' in terminology was one of the core pushes behind the production of the software design patterns literature. While I am aware of the architecture patterns literature to some extent, it surprises me that I haven't seen much serious talk of the AP literature here. Is this not considered in the architecture community as a viable approach to creating the common terminology and consensus of concepts, as it has been well accepted in the software field?
Above I was actually talking about common terminology with respect to the particular system under design and not so much the solution space that design patterns would address. That said, the solution space descriptions are clearly an issue as well. In the Design Patterns book object models are used to illustrate the designs. These models have clear mapping to implementation and hence evoke something developers that read the pattern can understand. I believe something similar can be done with architecture level contructs. For example, I claim that package/library co-dependency leads to the Ball of Mud. So the pattern would have to do with how to structure build time package dependencies.
The big issue with architecture patterns, in my view, is trying to decide what rises to the level of an architecture pattern. This simple question is very hard to answer. I've actually held a couple workshops on this topic and you can see some of the results on the Architecture Patterns Wiki.
"The big issue with architecture patterns, in my view, is trying to decide what rises to the level of an architecture pattern." I'll actually take a somewhat unpopular view and say that I'm not sure there is a sharp line that can be drawn between a 'design' pattern and an 'architectural' pattern. I use quotes because I consider them both to be design, and actually internally think of architecture patterns as 'system design patterns'. In fact, I'll go so far as to say that I believe there is a contiguous path of design patterns, in a conceptual sense, from the very basics of software production up through the Gang of Four level and then up to the architecture level. The context changes, and the concepts become ever more abstract, but I've yet to be convinced that there are sharp definitions that I see some claim. Eden's Locality criteria is an interesting observation, but my work in detection of design patterns from source code has shown that many design patterns are *widely* flung in a system, even at what is considered the 'low' level of design patterns. When you have a Decorator pattern scattered across three independent libraries, it is difficult to say that the concern is local. (Granted, that was an emergent behavior that was later cleaned up into an explicit design feature, but the behavior was there, and it was definitely non-local.) I can work with the distinction when it comes to the intentional design case, but it doesn't jibe with either my gut instinct, or my industry experience, when it comes to how systems actually evolve in the wild. Instead, I'd recast the Locality as conceptual, not structural... which to me just says 'higher level of abstraction'.
If you look at design patterns in a more general way, along the lines of Alexander's original 1964 _Notes_, they essentially boil down to a series of design decisions that lead to a solution guideline expressed as both a formal description and a functional description. I firmly believe that the formal description will change with the context, although consistency is desired for fulfilling the communication goal of patterns. (For instance, even at the GoF level, UML is a really poor notation for expressing the gestalt of Facade.) One thing to note about Alexander's original definition of a design pattern (which we seem to have lost along the way in software design, to some degree) is that a 'pattern' that lacks either the formal or the functional half is not a pattern, but an incomplete solution. You either get the discussion, and no example solution, or you get an example solution, but no discussion giving it context.
So I guess, in my opinion, the architectural patterns problem boils down to:
- What are the important concepts of intent in systems design that keep occurring? - What are the design decision classifications that those concepts rely on?
Also important, but not first-path critical in my mind:
- Can a 'formal' notation be created that allows expression of those concepts, and optimally, the decision classifications?
This last part may be the most difficult, but I'm not sure how it can be adequately tackled without at least rough answers to the first two. I like the discussions I see in the ADL realm, but I can't help but feel it's a case of putting the cart before the horse in some ways. Perhaps there will be a unification as we saw with the UML definition in SE, once the concepts are teased out more thoroughly.
Unsurprisingly, these are the same questions that the software design community has tackled in the past at a different scope and context, although the design decisions are treated very vaguely in the current literature. (Something I'd like to see change.)
Getting back to your original point about wanting to home in on a particular, perhaps cross-cutting, concern in a design, this is what I see a patterns literature body *for* - to provide that common terminology and allow focus on one concept at a time. So I think we're in agreement on this point, at least.
