How it really is...
The role of a true Enterprise Architect is to shield the developers (who do the actual work) from the herds of middle managers (who vaguely remember doing some work, but remember their crippling mortgage and school fees far more) who oversee the budgets. The Enterprise Architect applies a layer of technical sounding management drool, enough diagrams to keep the managers who aren't so good on words and thinking happy, ensures that no single budget item ever relates to a piece of concrete development, and sufficient procedures and protocols to give the ever circling auditors just enough for a full stomach and not quite enough for outright heartburn or death. Although giving auditors heartburn isn't actively discouraged.
For maximum efficiency, there should be no reporting lines - actual or implied, dotted or solid - between any developer and anyone who calls themselves an Architect (Enterprise or other), in the same way that developers should never be allowed to meet clients. When companies are so badly run that architects are allowed to converse with, and worse still, influence the direction of developers, the end result is always something totally overblown, baroque and unusable, but with as much tenacity as a skid mark on pure white porcelain - a fairly recent example is of course J2EE, a product and concept so laughably bad that even some architects are starting to have vague doubts about it.
In a truly ideal world, companies would not need Enterprise Architects, but in that same ideal world, companies would also not need anyone with 'Expert' in their job title, HR, Audit and General Counsel.
Finally, if you're ever in doubt whether you're sitting near a developer or an architect and you feel a direct question is somewhat inappropriate, ask them what their car is like, and who their mortgage is with. An architect will answer 'Beemer/Audi' and 'Santander'; a developer 'Can't remember/don't own one' and 'Paid it off years ago'.