In software, "architect" and "engineer" are controversial. They overlap other industries' recognition of formal training and certification. In software, the implication of "formal" training does not exist. Someone may be an "architect" or "engineer" without formal training – indeed without any training. 
I can't change the world. The vocabulary ship has already sailed. Nothing is going to unwind architect or engineer from the software lexicon. We have to roll with the punches. And since we are, let's try to establish a little clarity – specifically around architect.
Software architects design solutions, but may also write or develop software like engineers. Likewise, software engineers write or develop software, but may also design solutions like architects. One thing no one ever does is "architect" anything. The word architect is not a verb; design is a verb.
So, why not just call them designers. You see, there is an unfortunate ambiguity in the software industry with designer. Designer is typically understood to be a graphics designer – someone responsible for the look-and-feel of something. Basically, that parking spot is already taken by Mac users.
Let's start.
As I see it, there are three types of software architects. Hopefully, the subsequent text will bring you to the same conclusion. The most important part is: there is not just one type of software architect. That alone might be the most important point.
At its highest level, an architect is responsible for a plan. It is the level or scope of this plan that separates the different types. Although these three roles are discrete, some architects may fulfill two. Very few architects (very very few) can address all three. But, necessity guides the world.
The Enterprise Architect
The Enterprise Architect is the high-level visionary. He doesn't develop software beyond the white board. He thinks in multi-year, multi-platform, and multi-vendor terms. He is sensitive to economic, competitive, and strategic implications. He may have been an engineer once, maybe.
The Enterprise Architect produces the technical vision for an organization. He prefers PowerPoint over Visio, and presents to both technical managers and the Board of Directors. He is responsible for innovation, agility, and practicality. He may be titled "Chief Architect" or CTO.
An Enterprise Architect might say, "We want our products to be Software as a Service."
The Solution Architect
Less likely to wear a tie than the Enterprise Architect, the Solution Architect interacts with teams in practical ways. The Solution Architect (sometimes called Solutions Architect) selects technologies, platforms, and vendors in the context of real software initiatives. He was once an engineer.
The Solution Architect produces project designs for engineers. He prefers Visio over Visual Studio, and remains loosely engaged though a project's lifecycle. He is responsible for project integration, high level implementation consistency, and modernization.
A Solution Architect might say, "We want to expose Product ABC with Web Services."
The Technical Architect
The Technical Architect may be confused with a Lead Developer. A project with more than one team may have more than one Lead Developer. But a project will only have one Technical Architect. He interacts with the team daily. He selects components, patterns, standards. He settles debates.
The Technical Architect produces reference implementations for engineers. He prefers Visual Studio over anything else. He is typically a lead developer. He is responsible for team cohesion, software quality, and the correct implementation of the Solution Architect's design.
A Technical Architect might say, "Product ABC public services will use WCF over SSL."
Lead Developer (I mention him only to clarify Technical Architect.)
The Lead Developer, sometimes called Team Lead, is responsible of team morale, mentoring, code review, and on time delivery. He is a developer, but has the elevated authority necessary to ensure his team's adherence to the Technical Architect's reference implementation.
A Lead Developer might say, "I'll implement encryption, you validate the input parameters."
Wrap it up
Software terms are dangerous because they mean different things to different people. You may or may not agree with my definition of architect. No matter what, this is true: before your project begins, make sure every member has shared definition for titles and understand clearly who is what.
