Do you have a software architect in your project? Do you need one?
Well, most agile teams do not define such a role explicitly and work in a democratic mode. Every important technical decision is discussed with the entire team, and the most voted for solution wins. When such a team eventually decides to put a “software architect” badge on someone’s t-shirt, the most reputable programmer gets it.
The badge rarely changes his responsibilities, though. After all, the team stays the same and enjoys having technical discussions together, involving everyone. In the end, a software architect is more of a status than a role with explicitly defined responsibilities. It is a sign of respect, paid by other team players to the oldest and the most authoritative one among them. Right?
Absolutely wrong!
Obviously, an architect is usually someone who has the most knowledge, skills, experience, and authority. Of course, an architect usually knows more than others and is able to communicate his knowledge with diplomacy and pedagogy when required. An architect is usually one of the smartest guys on the team.
This is not, however, what makes him/her an architect.
And this is not what the team needs. My definition of a software architect is this:
An architect is the one who takes the blame for the quality.
You can replace “blame” with accountability or responsibility. Although, I prefer to use “blame”, because it much better emphasizes the fact that every quality issue in the product under development is a personal fault of the architect. Of course, together with the blame he also takes all the credit from happy customers, when the quality is good.
This is what the team needs — someone personally responsible for the quality of the software being developed.
How this guy will delegate this responsibility to others is his job. Whether he will use his knowledge and skills, or quality control tools, or unit testing frameworks, or authority, or coaching, or corporal punishment — it’s his business. A project manager delegates quality control to the software architect, and it is up to the software architect how to delegate it further.
The role of a software architect is crucial for every project, even if there are just two coders working at the same desk. One of them has to be the architect.
An ideal architect has all the merits mentioned above. He listens to everybody and takes their opinions into account. He is a good coach and a teacher, with a lot of patience. He is an effective communicator and negotiator. He is a diplomat. And he is an expert in the technical domain.
But, even if he doesn’t have all these merits, his decision is always final.
And this is the job of the project manager, to make sure that every technical decision the architect makes is not doubted by anyone. This is what delegation is all about — responsibility should always come with power.
As a project manager, you should regularly evaluate the results of your architect. Remember, the quality of the product your team is working on is his personal (!) reponsibility. Any problems you see are his problems. Don’t be afraid to blame him and punish him. But, always remember that in order to make your punishments productive you should give your architect full power in his actions. Let me reiterate: his decisions should be final.
If you, as a project manager, are not happy with the quality of the product and the architect doesn’t improve the situation, replace him. Downgrade him to a programmer and promote one of the programmers to an architect. But always remember that there can only be one architect in the team, and that his decisions are final.
That’s the only way of having a chance of building a perfect product.
Related Posts
You may also find these posts interesting:
- Continuous Integration is Dead
- Project Lifecycle in Teamed.io
- Why Monetary Awards Don’t Work?
- Remote Programming in Teamed.io
- Master Branch Must Be Read-Only
| Reference: | What Does a Software Architect Do? from our JCG partner Yegor Bugayenko at the About Programming blog. |
I find this “punishable” view of responsibility outdated and see the architect more as someone who will stand for the “big picture” while programmers dive into details. He also understands users more than the technical staff and has to communicate with all the levels in the project. Ultimately the project quality keeps on being with the project manager, not the architect, cause he is the one who allocates time and finds cooperating resources in other groups. The architect does not necessarily has to be the one who “knows more” than anyone, but the one who “understands more” the broad aspects… Read more »
Working in software development for 15 years I have met a few software architects. Some have a title to go with their authority others have just earned it being with a company for many years. I have also worked on projects without a architect and chaos can ensue. Developers just dumping in the newest framework without any thought, this is a recipe for disaster. Someone needs to mind the technical aspects of a project.
Tom