At what point does a developer stop being simply a developer and turns into a software architect. Or in other words, what's the minimum job description of a software architect?
I think there is no best answer than:
An architect do architecture.
So if you do architecture, you are an architect. Maybe you asked for what is a "good" architect ? Or maybe a predefined task list?
In addition to the other excellent answers, including the one from Jim Leonardo, please read this document:
Who needs an architect - Martin Fowler
My opinion ?
Architecture is a team sport
I could probably come up with 2 pages of humor here, but I'll assume you are taking this seriously. So, I'll respond as seriously as I can.
First thing you must understand: @Craig is right... differnet organizations mean different things. For some, it's just part of their advancement track and doesn't really mean much beyond that. For others, its a distinct role and very often, they get subverted out of doing any code or other hands on work and so lose their efficiency.
The point at which you stop being a developer and start being an architect is the point at which you spend 90%+ of your time engaged in the following
- Writing specs / drawing pretty pictures
- Meetings with management/Stakeholders
- Researching what technologies you should be using instead of learning what your team is using today.
- Wondering what the code for your apps looks like because you haven't seen the code in 4 months
Short of it is that an architect is the interface between the dev team and the stakeholders (the BA is the opposite). They need to be able to understand the business side and the technical details, but truth is, they are likely to not "get their hands dirty" all that often. Their primary 'technical' skills need to be with UML, a word processor, other technical drawing tools, and presentation software. So, in most cases, within a few years, they will start to become less and less effective as their knowledge of coding becomes dated (e.g. they are trying to think in C++ while the project is in C# or Java). At that point, the smart people learn how to lean on and learn from the hands on folks. The others become a pain in rear because they have a harder and harder time relating to state of the art.
Although it is true that software architects "do architecture", I think the role today has come to mean much more. Someone in the "software architect" role tends to be a leader, both in skill and in status.
I've always liked Ted Neward's definition of a software architect:
An architect is the captain of the ship, making the decisions that cross multiple areas of concern (navigation, engineering, and so on), taking final responsibility for the overall health of the ship and its crew (project and its members), able to step into any station to perform those duties as the need arises (write code for any part of the project should they lose a member). He has to be familiar with the problem domain, the technology involved, and keep an eye out on new technologies that might make the project easier or answer new customers' feature requests.
And later on:
...someone whose hands [are] dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details.
Unfortunately, not everyone who carries the title "software architect" fits this definition. Others fit the definition but don't carry the title. Nonetheless, I feel this is a more accurate definition of the modern software architect. If nothing else, it is a worthy goal to strive towards.
Like most IT job titles there is no definition, it is just a made up term. I would describe a Software Architect as someone who is in charge of the technical application design, building things like base libraries, application frameworks etc. Of all the various IT 'Architecture' jobs this is probably the lowest one on the food chain.
A guy whose coding skills are terribly out of date, but who is not capable of performing any managerial duties.
An impractical fool with an over-inflated sense of self-importance who destroys whatever thing he touches, never ceasing to bring layers of accidental complexity to even the simplest of contrivances, but who is, thankfully, kept out of harm's way by being assigned the task of writing grandiose-titled corporate documents that no one is ever expected to read.