Communications of the ACM
A Software Architect Is the Person You Blame
How efficient is your current software project, and could it potentially benefit from the addition of a software architect? More importantly, what exactly does a software architect do, and what can they provide to your team? With the world of software development rapidly moving towards more agile workflows amidst democracy in the front seat, the importance of the software architect is understated. A position misunderstood by many is a crucial component that delivers unparalleled guidance in the project pipeline, assigning responsibility, to an individual who can turn a company vision into code.
Some might believe that the title of a software architect is merely a status symbol placed upon a senior coder, signaling that a specific level of respect should be delivered; this assumption is wrong. The job of the architect is one that can be highly significant if it is adequately bestowed and the person who receives the title has the qualifications necessary to lead a team. Most importantly, the individual must be able to take the blame for project failures.
The software architect is the individual who takes the blame for when a project fails or is praised when the software, and the team, succeeds. Now, we must understand what is meant when using the word "blame" and why such a large association would be placed with an individual. The software architect is your team's guide; they are selected to carry the initial vision to a fully solidified working piece of code. As leaders, they elect to take the responsibility for the direction in which they lead their team.
Lead Software Engineer at EPAM Systems, Nikolay Ashanin, compared the responsibility of a software architect to that of a bridge worker from the 19th century in his published article The Path to Becoming a Software Architect and had said at that time that the key group of engineers, architects and workers stood under the bridge while the first vehicles were on it; thus, they staked their lives upon the construction and the strength of the structure.
When we say that a software architect must absorb the blame for a project, we are merely saying that the project outcome that is produced shall fall upon their shoulders. It is entirely up to the software architect to delegate responsibilities of a project utilizing their methodologies whether that be additional toolsets, their authority, or mentorship and coaching.
Project managers do not always have the option to hire a software architect, as they are typically individuals who are curated by their company, learning and understanding their team over time. In an excellent article by Simon Brown of InfoQ, a division of C4 media that focuses on software development, he noted that "becoming a software architect isn't something that happens overnight or with a promotion. It's a role, not a rank."
Most importantly, the decision of a software architect must be treated as final. Otherwise, without a true final say in the matter, the individual won't be looked upon as an authoritative figure. Even a project manager must treat the software architect as the final decision maker when it comes to implementing and producing code. Rather than overruling the decisions of their architect, project managers should seek to replace the individual if product end visions are not adequately aligning. An individual does not need to be fired, but perhaps placed back within the standard pool of programmers; over time, they might professionally grow to attempt the opportunity once more.
A software architect is the guiding rails for a project; they keep their team of developers moving forward and on-vision while accepting the responsibilities for the team's actions as a whole. Not only must an architect be able to lead, but also to understand the skills of their team, and how they can contribute to a finished project.
Beyond the ability to craft beautiful code, lead a team to completion, and work under pressure, a software architect must stand as a figure able to accept responsibility for a project; this is the characteristic that defines a true architect. More than simply a senior programmer, more than simply a leader, the software architect stands as a gatekeeper for quality and as a guiding vision for their team. In the end, whether the result is positive or negative, the software architect can stand up and take the praise or blame for what their team accomplished.
Yegor Bugayenko is founder and CEO of software engineering and management platform Zerocracy.
Comments
Richard Brooks
Well stated, Yegor. The characteristics you describe of a true SW Architect have diminished over the years as the job has become more of a "rank" as opposed to a role, as Simon indicated in his article.
One additional detail I would include is the importance of the SW architect in "orchestrating" the work, helping to set the tempo and setting quality expectations for the team- just like the role of a conductor of an orchestra. This has helped me produce many successful software projects on time and of the highest quality.
It's time for all people with the title of "SW architect" to "stand under the keystone".
Displaying 1 comment