If I ever have to give a definition of 'architecture' I usually say something like:
An architecture [for a software system] is something
that answers three questions:
1. What are the structural elements of the system? Not just their names but also the roles they play.
2. What is the nature of the collaborations between these elements? Not just the messages they send to each other but the expectations they have for each other and their position of responsibility in the system.
3. What is the overriding style or philosophy that guides the answers to the first two questions.
For me it is the answer to the third question that differentiates an
architecture from a design (which only answers the first two - what
rather than what might be
). Code certainly gives you the
first two but not the third and I believe the third is essential if you
are extending the system in any significant way. And you are extending
the system in a significant way every time you use a framework (I had
the same problem as Ralph when I tried to figure out Erich's JHotDraw).
How do you get the answer to the third question? As Kent suggests, as
Ralph experienced, and as ExtremeProgramming
implies, the best way to do
this is to spend time with the architect - not necessarily the person
who has 'architect' in their title but the person who really understands
the system, who knows the system intimately, and who probably loves
the system a bit too. The second best is to read the pattern language
that influenced the architecture or was written as a consequence of
developing the architecture. After that you are grubbing about looking
for fragments of documents, fragments of answers from people that
have interpreted the architect's vision in their own way or, worst,
fragments of code that you have to interpret in your own way. Certainly
but I don't think it is the architecture.
I always get thrown by the word architecture
when it isn't used as the name of a discipline. Is the design of a house different from its architecture?
At OOPSLA97, I heard someone say that "architecture consists of
those aspects of a system that you have to live with for its entire
lifetime." In this sense, it is kind of like Paul's definition. The
base irreducible set of things that make a system what it is.
I'm using KenAuer
and it just wouldn't be HotDraw
figures, for instance. What Paul is talking about sounds like CRC.
Code is for the compiler or interpreter. Code can reveal the intentions
of those who created it, but it is indirect.
One of the things I did when I joined my current company is to run
an architectural review workshop. We all sat around with CRC cards
describing the responsibilities of the 'bits' of our system. This did two
things - it got people talking to each other face to face (which they
are a bit reluctant to do here) and it allowed me to produce a sketch of
For me this sketch is not 'the architecture' in the sense that
anything which contradicts it has to be wrong. It is merely an
imperfect reflection of how we collectively viewed the system at
one point in time. As such it is useful for communicating ideas
about our architecture to outsiders and each other but it shouldn't
be seen as the 'gospel truth'.
This is the role that I'd like to
see documentation playing - capturing nebulous ideas in a way
that they can be communicated in the absence of a face to face
discussion. Documentation should also be personal - reflecting a
view held at a particular time by a particular person. If you don't
understand something you should be able to go and talk to them. If
you don't know who to talk to and no one around can tell you, the
documentation will guide you to that person. And, if you can't talk to
that person for whatever reason, you can at least get some appreciation
of what they were thinking which might give you enough context to see
the architecture in the code.
I've been living in a parallel universe, and I can report back that it is possible to pick up a complex application framework without direct
contact with the original author, if your lucky. I was able to apply the UnidrawFramework
long before meeting the author, even before the GangOfFour DesignPatterns
book came out. But there were academic papers to read (where they talked about idioms
). And I had worked with earlier versions of the software, when it was just a drawing editor written in C++. And I had a twice-removed contact with the original author, where a friend saw what some colleagues of JohnVlissides
had done with the framework.
So the combination of those three made it work for me -- a general overview of the design, prior applicable experience, and knowledge that it was possible
to leverage the framework. Maybe this conclusion can't be generalized, because the framework author was thinking of design patterns every step of the way, and it comes out in the work. The same is true of HotDraw
oops, I forgot the fourth and maybe most critical factor, a mantra that took several years of repeating to become second nature. You have to be willing to StudyTheSourceWithaDebugger.
Also important, I think, is the fact along the way I took an incremental XP-like approach to learning the framework (ExperimentStudyRefine
). I've seen many people turn away from using it, because they couldn't get the instant gratification they were looking for. It has made me long for a system of ProgrammerApprenticeship?
, where knowledge could be transferred over time to new practitioners, similar to what they practice in the medical profession. -ScottJohnston
Is the design of a house different from its architecture?
I'm still thinking about this interesting question above, which hinges on the use of the word 'architecture'.
I think you might distinguish between these thoughts like this:
Design of a house
Principally the set of individual features that form the specific identity of 'this house', ie number & size & shape of windows, pitch of roof, group of materials used, height of stairs, number of levels, shape on the ground etc.
Principally the 'category' or type of Design.
When architects think about architecture primarily in terms of the 'BattleOfTheStyles?
' we use names/categories like 'Classical', 'Neo-Classical', 'Gothic', 'Modern', 'Post-Modern' etc to distinguish between different 'architectures'
Within each 'architecture' many 'designs' are possible.
Of course each 'architecture' is recognised by the use of a group of identifiable 'design features' or qualities. If you start an individual design in one type of 'architecture' but change too many of the variables you would end up with a 'design' categorized in a different 'architecture'.
However, this would be a superficial analysis to many architects who would see this argument a basically about 'style' (and different styles) rather than about
broader architectural themes which may transcend style (and styles).
Architecture (and different architectures) may be also categorised therefore by
approaches to the following for example:
-light, structure, atmosphere, iconography, response to site/location, use of materials, etc.
By the way, I'm surprised (but possibly in ignorance- someone correct me if I'm wrong) that the writings of Christian Norberg-Shulz (eg 'Genus Loci-Towards A Phenomenolgy of Architecture') haven't also been seized upon by programmer/computer types for widening the analogical considerations thrown up in Alexander's work.
So I think I'm concluding that the design of a house is
different from its architecture.
I think the first comments on this page go a good way in talking about 'architecture' in the wider use of the word, and would agree that item 3 is very important. 'Style' could be an unfortunate term, however, 'philosophy' is of course rather deeper.
That an individual building design (and Designer) has a philosophy is generally one of the distinguishing traits that separates 'Building' from 'Architecture':
ie 'Architecture' may be 'building with intent'.
If this sounds too esoteric the point is that in the built environment around us we see a lot of 'building' but how much of this is 'Architecture'???
Some definitions moved to WhatIsArchitectureAnyway.