Even within the same organization, software architecture can be a radically different practice from person to person. There are some like those you mention: they're aloof, they don't engage deeply with the business requirements and their deliverables range from useless to actively harmful. They set incorrect expectations with the stakeholders — often systematically underestimating the complexity of components they deem less important, like user interfaces, and they provide a rigid framework for the developers that ends up being implemented with more by-exception than by-the-rules.

A _good_ software architect is almost the exact opposite. She's a minesweeper, finding obstacles that would have caused re-work and scope change. She untangles the business requirements so that expectations can be clearly set and communicated. She does research on existing approaches to the problem, becomes acquainted with the relevant open source work and thereby serves as a check against "not invented here" syndrome. If this some of this ends up being best delivered in a document or a diagram, so be it, but the point is to enable the developers, not a masturbatory exercise in self-indulgence.