It’s not trivial to find good sources for learning about software architecture.  Google something specific, like “the foo doesn’t work in the bar system, it throws BazException” and you’re pretty likely to get a specific and correct Stack Overflow answer or blog post. But search for “software architecture” or related terms and you get some good material plus a bunch of garbage disguised as good material.

Part of the problem is that software architecture is a bit like theology.  It’s arcane, deep, and people have lots of varied and strong opinions about it. One way to save yourself some headache is to focus on reading authors whom you trust.  For example, I read some of Martin Fowler’s writing, plus I checked out the reviews of his book on Amazon, and concluded I think he has good ideas.  So I’ll add him to my personal list of architects to follow.  The work of finding trusted sources is something everyone has to do for himself; it can be a good starting point to look for popular writers, but there’s no substitute for critically evaluating the author’s ideas.

What do I look for in an architect?  Mainly, someone who is able to see the value of different solutions to a software design problem.  Design patterns are not formulas to be followed blindly: they are idioms that have benefits and costs.  The complexity costs of patterns and abstractions are often greatly underestimated, even (or especially) by good engineers.  I particularly like his discussion of GUI patterns (linked previously).  He’s not afraid to discuss ambiguity and talk about how people sometimes use the same term to mean different things.  Architects have to be able to see and discuss the shades of grey in software design.