There are three types of "good architectural choices"

The first: The ones that can be made after the original, bad ones. The second draft, which is an improvement in the first draft, in every field.

The second: His (or her) own. We all know there are developers out there who think they're the greatest thing to ever write code, and that everyone else's decisions are bad.

The third: The ones that really should have been made, in place of the ones that really shouldn't have been made. As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

> As in, "You wrote your own SQL parser using hardcoded strings and no grammar parsers?"

(Shuffles away sheepishly)

That's a product of context is it not? And of course part of the context is the rest of the current architecture.

I think in the end the best architecture is that which is thought through from a contract-oriented approach, rather than a buzzword checklist.

You've probably heard it as ones that lead to low-coupling and high-cohesion, which is correct. But in my experience this needs to be made more concrete -- many people can say these words, but couldn't tell you accurately to what degree a system was cohesive and uncoupled.

There are some methodologies for this: http://en.wikipedia.org/wiki/Architecture_tradeoff_analysis_...