Where do software architects come from? There is a simple, obvious answer, but that is not what I mean I am referring to company environments. I can’t help noticing that more often than not, architects come from one of the following sources:
- Architect by appointment” (not skills). Somebody got promoted to be the architect (implying the role carries a higher value than that of a programmer), or somebody got simply pointed out
- Not-so-great programmers who are thought to be good enough for “drawing boxes and lines on an abstract level”
- Programmers who are so far removed from the trade they don’t have the insight any more what their options are, and what impact their decisions have
- Non-programmers who, well, can’t code and therefore must do something that does not require coding
That is weird, assuming you choose your architect to help, improve, complement the implementation project on a level that is different from that of a programmer.
But maybe those who choose architects don’t know what to expect and what to look for. There is evidence for that: companies often don’t educate their people to be architects, or even have an expectation (that they communicate).
I can only offer my own standpoint: An architect is a person dedicated to looking at and being responsible for the quality aspects of a software project.
What kind of qualities? I would stretch that pretty far: Can the structure of the system be easily understood? Does it fit the purpose of the project? Does it address the problem and the constraints of the environment in a fitting way? Does it reduce the impact of changes to the requirements or infrastructure on the system?
While programmers must address quality issues, too, they are primarily occupied by translating functional specifications into technical reality (which is why code generation will not happen before arbitrary natural language can be understood by a computer), and wrestling with the intricacies of highly complex APIs, other people’s code, and their own.
The architect in my opinion must be a seasoned senior developer who knows what works, knows what doesn’t, and understands and can explain why that is so. S/he, too, has the (urgently) necessary people skills to promote good architecture, to convince management that additional effort will pay off, and to convince programmers that the marching direction is the right one.
You can’t study to be a “software architect”, though there are certifications. There are some great books that for sure can help. I believe a certain attitude to programming, long experience in many various projects, being awake at the IDE, and musing about why things went the way they did are a good base.