In his post What do you need to know to be an IT Architect? Simon Guest (editor of the Microsoft Architecture Journal) identifies some key elements of architectural knowledge: IT Environment, Business / Technology Strategy, Design Skills, Quality Attribute Skills, and Human Dynamics.
I think there are two important clarifications we can make here.
Firstly, Simon's starting point is, rightly, know-how (skills) rather than body-of-knowledge (theory). Nick Malik makes a similar point in his post on Enterprise Architecture Interview Questions: "proven abilities and past experiences, and not book learning".
The distinguishing characteristic of an architect, in my view, is a certain way of paying attention to a certain class of problems and opportunities. (Just as a chess grandmaster has a vast body of knowledge of past games and variations, as well as a complex mental library of patterns, but these are only useful for playing the game of chess.)
Therefore the architect's knowledge (of the organization, of the business) needs to be active knowledge, what Vickers called appreciation.
Secondly, when Simon talks about "the organization", "the business", and so on, these terms can be interpreted in two ways. Does the architect need to know about organizations-in-general, business-in-general? Or does the architect need to know about this particular organization, this particular business?
In his blog last year, Ali Arsanjani characterized this choice as one between two philosophers: So is Kant right or Hume? and Back to Kant and Hume. (See also my comments to his posts.)
Do architects concentrate on some apriori (generalized, enterprise-wide or industry-wide) schema (Kant), or do they remain grounded in the specific local requirements (Hume)?
(Some people refer to this choice as top-down/bottom-up. But I think this terminology is vulnerable to wide misunderstanding, because different people have different orientations - is the business at the top, or is the generic model at the top?)
I believe the best architects are those that can do both - who have both general knowledge/know-how and particular knowledge/know-how, and can make intelligent connections between the general and the particular. In what ways is this bank like any other bank, and what particular things differentiate this bank from other banks?
That's how we train our SOA architects to think.