I have been thinking a lot lately about what is expected of a software architect, the name usually comes with the idea of someone who lives in an ivory tower, unreachable, isolated from the world, when architecture is needed for a project he will arrive, draw a bunch of UML diagrams, write some documents and vanish, leaving implementation of his godly plan to the development team, who most of the time will face issues because the requirements may change a little, because framework X and Y as good as they are alone the integration may be a problem, this may result in some confusing blob of code as the developers try to continue the development, and the possibility of the architect return to help and re-define how everything works fades as time passes.

This is how most people I know see a software architect, I believe this idea may come from the waterfall project management from the old days.

Well, that’s not what I believe the role of a software architect should be. He should write code, he should design and implement the foundation for the development team, to make their life easier, to allow them to develop faster, he should provide guidance, coach the juniors who are still learning the best practices, or even seniors as they adapt to his architecture, not just say how it’s done but explain the motivations of his decisions. He should be willing to listen to the team, because sometimes a better solution may come up in a 10 minute talk, from some random ideas that others throw around. The architect should be with the project until the end, he should be constantly seeking solutions to simplify the development team job, be it either through automation of repetitive tasks or improve on his architecture in order do reduce code duplication and speed up development. Should he document the architecture? Of course, he should also do the efforts to make sure the code is easy to understand, avoiding long documents this way, but his job can’t be exclusively produce a bunch of diagrams and documents and be gone.

This has been my approach to software architecture, maybe because I started working on architecture a little by accident at first, I got on a project where the architect had done his work and was already gone, as the project was moving forward the team was having trouble with the lack of foundation to develop on, before I knew it and without any kind of explicit responsibility I started improving on the project architecture mostly out of need, adding to the structure, refactoring. With time it got a little more “official” and although my official job description was not explicit about my role as an architect, I was recognised by the team as such, I think you should earn it not just claim a title or role.

Summing up here are some points on what I believe that a software architect should be doing:

• Listen to the team;
• Define the coding standards, code style, development workflow, etc;
• Configure the base of the project and its modules;
• Guide the team;
  
• Create sample code (relevant to the project of course) in order to allow the team to have an example to better understand and follow;
• Ensure the code is testable;
  
• Automate everything that is repetitive;
• Look for constant improvements;
  
• Always be willing to learn (you never know everything, no matter how long you have been doing it).