If there is a need for a separate position to do that - the softer side - what does that have to do with software architecture?? The best solution to the problem doesn't really care if the VP of Marketing is sad that they weren't involved.

However, I do agree that role is important but from what I've seen it's typically the job of a VP Eng, CTO, Scrum Master - "Management-y" types.

I respect your view, so up-voted, and yet disagree. I think anybody, regardless of role or industry can be more effective with those skills. And technical ability aside (note, that is critical), architects in particular should (in my opinion) be good at this stuff.

[Edit] Just saw you've an MBA. I now understand your thinking.

Well, I absolutely agree that the softer side is huge in just about any career. But if we're centralizing the softer side into a defined role (as you seemed to do with the "SA"), then I'd say it "better" lives somewhere else, as the other "technical" SA stuff is distributed to the team.

The usefulness of the Architect role may also depend on the size and topology of the organization. I work in a Very Large Enterprise Company, and our group's architecture team has to make sure not only that our group's systems/projects are well-designed, consistent, maintainable, scalable, etc, but also that they interact nicely with the MANY other geographically-, pyramidally-, and budgetrarily-distrubuted groups, that we aren't duplicating effort, that the lines of responsibility for a given system integration make sense, that we have the same vision for the trajectory of the overall enterprise strategy, etc.

This means our Architects have to collaborate/negotiate/politick with many other groups' architects (and the occasional program manager), while having both the 100,000' perspective on the entire company's organizational structure and systems, as well as the fine-detail nuts-and-bolts of the workings of our own group's systems so we know what complications may arise in interactions with other systems.

NB Our group director has a far-higher-than-normal grasp on these details (others are not so lucky!) but the level of cross-enterprise collaboration is more than he has time for.

Some of this sounds like it'd be the work of a Systems Analyst (which is what we use the SA abbreviation to mean), and that's true, but there are plenty of actual architectural and technological considerations as well: infrastructure issues, build/release coordination, enterprise schema maintenance, shared libraries/technologies (example: which of the four ESB technologies should we use for this project? Oh, really, you want to give us a flat file from the mainframe but wrap it in <xml></xml>? Argh.)

We also must keep a close ear to the product management/BA group and the stakeholders so we make sure our vision is in sync with the business's needs.

So you could say our architecture group is a mix of internal technical leadership, R&D, development of key moving parts (in our case, integration code), mentorship, systems analysis, negotiator, integrator, etc.