The need for 'architects' in software development is questionable. Show me a company that is full of architects who would rather write verbose and arcane documents than code a prototype and I'll show you a company who can't produce decent software. Never trust a 'software architect' who can't program a prototype or who normal engineers can't understand.
A systems architect is a strange cubicle-dwelling creature (usually bereft of feathers or any other mating-related adornments) that, unlike your garden-variety engineer, produces copious amounts of paper (or virtual representations thereof), apparently providing conclusive evidence against the theory that engineers can't write properly formatted documents to save their lives. #
Those documents are often meticulously laid out, show a liberal tendency in the frequent use of diagrams and tables, contain copious footnotes and annotations, pride themselves in including extensive bibliography and references sections, and, last but not least, have precisely zero spelling and grammar errors.
They are, however, utterly unintelligible to anyone else but another systems architect, and, quite often, are only likely to be fully understood by another systems architect that happens to work in precisely the same field. This is especially the case in telecomms, where any random sentence picked out of a document is likely to include at least two acronyms (a one-to-five ratio between acronyms and "normal" words being quite commonplace).
Which is to say that their effective communication skills, despite their baroque efforts, are pretty close to the average engineers' - but they tend to use ten to twenty times the bandwidth to say the same.
The overall effect of putting a systems architect and a "regular" engineer in front of a non-technical audience is apparently different, but the end results are roughly the same: the systems architect will deliver a PowerPoint presentation, while the other guy will tell a couple of jokes and draw meaningless squiggles on the whiteboard while he explains things, but the audience won't understand what either of them is talking about.
Now, "real" engineers tend to look at systems architects as verborrheic snobs whose ideas "work only on paper", but my point here is a bit different - my take is that while "regular" engineers fail to communicate by sheer lack of skills, systems architects fail to communicate by needlessly complicating things. There seems to be a genuine lack of ability to churn out easy to understand, readable architecture documentation that doesn't border on the arcane.
My guess is that it's due to systems architects having sworn to read (and recite by heart on every third full Moon) all those 3GPP standards (which make IETF and IEEE documents look like comparatively normal English texts). Or to the need to stamp out ambiguity from every single little detail (especially on muitlnational teams, where English skills vary widely). Or maybe it's just the closest thing to academia in a corporate environment.