After a discussion on the twitters with Kellabyte and Iris Classon about software architects, I thought I’d summarise my position. Feel welcome to disagree.
What does a software architect do?
A software architect is there to identify risks that affect the technical implementation of the software product, and address those risks. Preferably before they stop or impede the development of the product.
That could mean doing tests to investigate the feasibility or attributes of a proposed solution. It could mean evangelising the developers to the clients or managers to avoid those people interrupting the development work. It could mean giving a junior developer a tutorial on a certain technology-or getting that developer to tutor the rest of the team on the thing that person is an expert on.
What a software architect doesn’t do
A software architect doesn’t micromanage the developers who work with them. The architect doesn’t rule by memos and UML diagrams. The architect doesn’t prognisticate on things they have no experience of. Perhaps confusingly, the role of software architect bears very little resemblance to the profession after which it’s named. If you want analogies with civil engineering, all developers are like architects. If you want to see the software analogue to the builder, that’s work done by the compiler and IDE.
Architects don’t make decisions where none is necessary. They don’t ignore or belittle suggestions that come from people who aren’t architects.
In one sentence
A software architect is there to make it easier for developers to develop.
Pingback: What’s a software architect? (blog.securemacprogramming.com) « AppDev Reading
Pingback: The Tao of the Software Architect « Rubber Tyres –> Smooth Rides