After my invited talk at OOPSLA, a gentleman asked me if I intended to document failures as well as successes. I replied that my intent was to limit my study to successful systems, because I wanted my work to provide good examples - not antipatterns - of good architecture. In retrospect, I realize that my answer was quite inadequate.
As I state in my goals for the Handbook, I'm "codifying the architecture of a large collection of interesting software-intensive systems" where the operative word here is "interesting:" architecturally interesting, interesting to the marketplace, and interesting to me personally. An obvious question this raises is if there is a correlation between a successful system and a good architecture. It is true that all of the hyperproductive projects I've encountered tend to develop their systems by growing an architecture through the incremental and iterative release of executables. However, it is also true that the resulting architectures are never by any means perfect. Rather, they are always good enough and so full of the warts, nicks, blemishes, and discontinuities you'd expect to result from any pragmatic engineering activity. In fact, I've seen some beautiful architectures that were commercially a failure (building a better mousetrap does not necessarily mean the world will beat a path to your doorstep) and I've seen a number of overwhelming commercial successes whose architectures are nothing to write home about (but do note that those organizations usually suffer for it in the next generation of systems).
So, what distinguishes a "good" architecture from a "bad" one? I don't have enough hard data to say conclusively, but it is fair to say that good architectures are simpler, more understandable, more resilient to change, looser, more regular, and more full of patterns then ones that are bad. Now, if you read that last sentence carefully, you'll realize that some of the attributes I list are emergent (i.e. more resilient to change) while others are more fundamental (i.e. more regular and full of patterns). I know a good architecture when I see it; I know a bad one when I see it too. But I'm not at a point where I'm self-aware enough to tell you how I know the difference.