Good Architecture

Robust - lacking bugs and tolerant of external faults
Maintainable - easy to maintain and extend
Useful - utility, beyond the immediate need (due to flexibility and extensibility)
Scalable - ability to grow in capacity, not in features
Common Vision - direction, strategy
Agile - simple and "elegant" enough to refactor easily; flexible
Extensible - ability to grow in features or in depth
Responsive - performance now and after adding features or expanding scale

Note that many of the facets of good architecture depend on each other. Common vision is essential to insuring this integration of purpose.

Maintainable and Agile is prolly the same, but the first is a more common term, at least for me. -- JuergenHermann

I can see the difference between Scalable and Agile but defining Scalable as evolvable confuses things as I would normally associate evolvability with refactoring ease -- good point, my humility is overpowering me as I've changed the detail above...feel free to make your own changes!

Might Agile be better stated as Mutable? I think good architecture in Software is unique in this sense. It should be able to evolve and change, maybe even lend itself to extension. Also, you may want to take a look at AttributeBasedArchitecturalStyles as they have a whole set of QualityAttributes with which to evaluate a SoftwareArchitecture with. --RobertDiFalco

This exercise is strikingly similar to RobertPirsig's recounting of what makes good rhetoric (the part later in ZenAndTheArtOfMotorcycleMaintenance when he's teaching the writing class). A review of that might be informative.

In 'building architecture', for comparison, we have the 3 classic Vitruvian qualities to which 'GoodArchitecture' aspires:

'Firmitas, Utilitas and Venustas' (Marcus Vitruvius Pollio 'The Ten Books of Architecture' 1st C AD).

These qualities may be translated as: 'Technology, Function and Form' (C St J Wilson 'ArchitecturalReflections?; Studies in the Philosophy and Practice of Architecture' 1992 ISBN 0-7506-1283-5

or, in the slightly more familiar but antique: 'Firmness, Commodity & Delight'

For further thoughts about 'Delight' see BeautyIsOurBusiness

-- MartinNoutch

I think I would have to disagree with the above assertions. I think a Good Architecture is one which meets the requirements set out for it. Robustness, maintainability, agility, scalability, are all requirements that are valued differently in different systems by the parties interested in the success (or failure?) of the system. The infamous Olympics system built by IBM for the Atlanta games(?) didn't need to be maintained, extended, or possible even scaled beyond the requirements laid out for it. I have a couple of friends from that project who quoted the team lead/architect stating "I only want it to work for two weeks!" That system may be more of an exception, but each system is different, so, in the spirit of the simplest thing, the simplest definition of GoodArchitecture in my mind be "a good architecture is one which satisfies the requirements." Anything else is a BadArchitecture?. HowToExtremelyArchitect? is what I would like to grok.

-- JefNewsom

As a programmer, I like an architecture that makes it easy and enjoyable to continue building the system. I can't remember ever hearing users talk about systems as having good architecture or bad architecture. For the most part, they don't seem to care. Since it's often hard to know when you (or someone) will be finished building a system (I include maintenance in that description), we tend to want systems that are elegant on the inside. Jef's case, above, seems to be the exception. But I even wonder about that, because of the time it takes just to get the first release out. BadArchitecture? can make life miserable sooner that one might think, and screw up the schedule as well.

HowToExtremelyArchitect? -- what might that mean?

This is called SystemMetaphor in ExtremeProgramming. -- GuillermoSchwarz

Some additional thoughts. An architecture may be this, that and the other (mutable, flexable, etc., etc.), but what it is fundamentally is a large grained structure, like the large bones of your body. The most mutable of architectures is not an architecture at all, just as the slug's skeleton is not a skeleton. A "good" architecture is also an expendable one, one that knows when to retire from the project and let another architecture have a go.

--WaldenMathews

This has a similarity to the ISO 9126 definition of software quality:

Portability
Efficiency
Reliability
Functionality
Usability
Maintainability

Is it possible to refer to the quality of an architecture without reference to the problem to be solved? It seems to me that that attributes of GoodArchitecture

mentioned above are variables that that can be used to measure the quality of fit between a particular architecture and a particular problem. No architecture is good or bad except how it fits a problem.

--JonStrayer

It seems to me that an "architecture" is a reflection of an (implicit or explicit, and ongoing) domain analysis. From a domain analysis you build a commonality and variability assumption set that applies across the domain of interest. The commonality is expressed in rigid bits of the architecture, and the variability is reflected in plug-points or base classes or whatever.

Variability points encapsulate your understanding of expected points of requirements change. So, you can say that an architecture is "good" in one sense if it covers expected requirements change well in its points of variability. However, variability points are potentially invalidated by unacticipate requirements change. Unless we can change variability and commonality points readily, the architecture will be hacked. Hacking is the process of forcing an unanticipated requirements change into an architecture that does not accommodate it (by mutating commonality and variability points abusively - force-fitting square pegs into round holes).

Hacking can lead to architectural petrification - wherein layer upon layer of implicit architecture builds up on top of the legitimate architecture. Petrified architectures are essentially impossible to unravel, comprehend, and adapt with confidence. Consequently, a petrified architecture becomes unable to reflect any form of requirements change (either anticipated or unanticipated).

We usually term systems with petrified architectures "legacy systems" - and they most definitely have "bad" architecures, since the continually resist the reflection of on-going requirements change and hence become progressively less and less useful.

So, to me an architecture is "good" if it can accommodate anticipated requirements changes within current variability points. An architecture is, perhaps, "excellent" if unanticipate changes can be reflected by allowing the introduction of new variabilty points at previously anticipated points of commonality without damaging side effects and without unbearable effort.

---Anthony Lauder

Well I was going to say something but Anthony already did it :). So, "what he said". This conforms to my definition of architecture. Oh, I might note that I use the word "agile" to describe a system in which static qualities are made dynamic e.g. scalability by online addition of components. -- Richard Henderson

See: GoodDesign, GreatDesign

How about PluggableArchitecture? It would be certainly Maintainable, have CommonVision?, be Agile and Extensible. Performance would not be affected, unless you plug a slow PluggableModule?, which of course you can always unplug then the replace. -- GuillermoSchwarz

CategoryArchitecture, CategoryComparisons