I define architecture as a word we use when we want to talk about design but want to puff it up to make it sound important (Martin Fowler)

What does an Architect do?  If we're talking about building a bridge, then probably the person is in charge for designing the structure, calculation, cost and what not. Would a Software Architect be a direct counter part to this role?

I would consider an architect as someone who's responsible for making the difficult decision. These decisions are the ones that are hard to fix if not impossible to undo.

So for a Software Architect, what are these key decisions most likely be?

Aligning long term plan with long term vision

A software architect is probably asked to ensure that the overall software system supports the business goal for the specified amount of time.

Deciding on the expensive stuff

Someone needs to be responsible for making decision on team model, framework selection, third party services and more. It would make sense for a Software Architect to do this.

Coordinating the work

A Software Architect is also probably responsible to send the message to the rest of the team. Sending out the mandate from the mothership.

Taking the blame

The bad (good) thing though, this person is probably most likely will get the blame if there's a catastrophic issue with the produced software system.

With that out of the way, does it mean we need a Software Architect on every project?

We need an architect when things are hard to change

Things that are often perceived as hard to change might not ever change, or at least can easily be designed so that it can easily be changed.

We need an architect to guide the development teams

It takes a super human (er.. super-developer?) to do the role of a Software Architect as described above well. Making thorough decisions upfront requires black magic (although some might argue it should be called ’˜experience'). With the amount of variables, and moving pieces, only people with the best of knowledge on both the operational and business long term vision can take up on the responsibility.

Unless a Software Architect can confidently predict everything upfront with little room of failures, most Architects should be with the team, attend stand ups, take part of code reviews, take on critical user story/work items/task, do unit test, not break the build as much as the next guy. More importantly, this person is responsible for sharing the vision and long term business goals with the rest of the team.

Christopher Deweese, a 2009 microsoft MVP Solution Architect puts in his blog:

The truth is, every developer is a little bit of an architect.  Some of us just care a little more than the next guy.

A good idea is a good idea despite who had thought of it. And at times, those might not come from the most senior person in the room. It is up to the culture of the team to empower people to own the problem together and therefore be as caring as the next guy.