Who Is A Software Architect? — Part 3
In part 2 I mentioned that those developers who have only dealt with the collective way of making software architecture decisions might feel that something is amiss with this option. And, while they do sense that something is not quite right, their viewpoint would probably be based upon this thinking:
“I don’t like Software Architects. What is implicit in the SA role is that the rest of the dev team is full of dummies that can’t think strategically or architect big parts of the system. This naturally leads to the SA producing ever higher and more complicated abstractions that the simian developer tries to implement, poorly, and the SA becomes an irreplaceable high priest — inflating their salaries and prominence and depressing the salaries of the rest of the team.
Where I work, every developer is expected to be “architect-quality”. Sure, more junior folks don’t have the experience, but they’re expected to have the capacity for strategic, high-level thinking. As they mature, they take on more and more architectural decisions. If they can’t do that, then we’ve hired the wrong person.” — source
What would you say to this, based on what you’ve experienced in your professional life? Could be you’ve seen that some developers do good as developers, and… they are just fine as those, as they are not looking to “mature” into an architect-level thinker? Or, if your responsibilities include hiring decisions, would you agree that the “architect-quality” job candidates are as overabundant as rains in the tropical storm season *ironic* ? The not-quite-rightness of a group-based approach to the architecture decisions gets down to this: the collaborative knowledge and expertise of individuals, however brilliant or not brilliant they might be, does not magically convert to the well-rounded high-level decisions that — as we might have forgotten by now — are supposed to be a responsibility of a leader. A technical leader, if you will. The “dictator” software architects of the pre-agile era have compromised the leadership side of the SA position by their order giving. No wonder that as a reaction to this —here’s where the baby gets out, with the stale bath water, as mentioned in part 2 — the undoubtedly beneficial qualities of having a strong leader in charge have been blurred and misrepresented. I exaggerated the difference between the proponents of the collective ways and those who are nostalgic about the order giving on purpose, earlier, for the sake of making my point. By no means, not each and every architect-level expert would be embittered by the lack of the old-school “command” ways. More so that the qualities the team would expect from them would be the ones not of a commander… but of a leader, and of a mentor.
…and that’s where the knob switches from all things technical to all things human! The technical leaders of the new breed would be those who foster the ethos of caring both for the needs of the product, and for the needs of people. If many in the team stick with the opinion that Software Architect is only a bossy title, but yet they sense that there’s no one who is actually responsible — educate them by highlighting the positive sides of this role as performed by a single individual. Do some reflection and analysis to identify the process of making architecture decisions at your organization. Are those decisions well-rounded or not? Is everyone happy about the way those decisions are done, as by a group, or as by an individual, or as by some mix of those two options? If not, where’s the bottleneck: in the lack of the technical knowledge, or in the lack of an understanding in the team with regard of the personal responsibilities — and/or personal expertise/capabilities?
Actually, what’s written above is meant for those whose responsibilities go beyond the domain of software architecture purely. The intermix of roles has become so unique in the modern-day softdev organizations; that’s why there are no cookie cutter recipes.The same line of reasoning that I have provided in this 3-part article may just as well be applied to the other roles with the assumed collective responsibility e.g. to those of a Product Owner, or of a UX Architect.
