title: Software Architect - A Role, Not a Job
url: http://spin.atomicobject.com/2015/02/19/software-architect-role/
hash_url: 375d50703a
A product development organizational structure where software architects work on a team separate from the development team can be a recipe for dysfunction, reduced quality, and poor morale.
The corporate ladder for software developers can lead to the software architect job. An architect usually works on a team of architects who are responsible for early application architecture design, approval at points during development, and approval before production launch.
The development team inherits constraints defined by the architect. During execution, the development team checks in with an architect at specific checkpoints or when the constraints defined by the architect are challenged.
Doug Sundheim’s article Closing the Chasm Between Strategy and Execution insightfully describes the risks and dysfunction I’ve observed when architects work on a distinct team separate from the development team.
I agree with Doug—especially as relates to software projects—that:
“The process is always a little ugly. The executors’ dirt-in-the-fingernails view on the ground is much different from the strategists’ high-minded view from the air.”
The longer architects stay in their role decoupled from implementation, the less qualified they are to judge the maturity and risk profile of new tools, processes, and paradigms. Up-front decisions made by architects become painful for the implementation team. Developers get frustrated with the “out of touch” architects. Architects get frustrated by their “adversarial” development teams.
I suspect that managers creating or maintaining an organizational structure that separates strategy and execution believe that individuals on each side will behave rationally, build relationships, and communicate effectively in order to get their work done. But as Doug puts it:
“Unfortunately, it’s far from common practice. What typically happens is an awkward hand-off between the two. In the worst cases the strategists adopt an elitist, disconnected mindset: We’re the idea people, someone else will make it happen. They don’t bother to truly understand what it takes to implement the ideas. They don’t engage the executors early and ask, ‘How will this actually work?’ The executors contribute to the trouble as well. Often they don’t truly understand the thinking behind the strategy. They take it at face value and don’t ask enough tough questions…
“The problem is that both sides don’t see it as their responsibility to intelligently pull the two sides back together again. They leave a chasm, hoping that it will miraculously close on its own. It never does. Things just fall through it.”
Doug identifies that it’s a set of beliefs, not process, that the best strategists and executors use to close the chasm. You should read the beliefs outlined in Doug’s article. They create a great mindset for teams or individuals working together in a hierarchical fashion.
I suspect distinct architecture jobs and teams are created for several reasons, including:
But I believe the rationale in the points above can still be satisfied in a better organizational structure that integrates architects and implementation teams. Architecture and implementation should not be separate jobs.
Instead of employing architects, an organization should employ senior developers who are responsible for architecture. Each product team should have one person responsible for architecture. The integrated architect should lead by creating team buy-in, not by fiat.
At a detailed level, integrating architects into implementation teams has the benefits of:
At a summary level, the integrated architect approach sets the stage for:
Hiring efficiency using the integrated architect model should not be any more challenging than hiring architects in the traditional sense. Hire senior developers who have architecture experience and don’t want to give up coding.
Operational efficiency can be preserved by using several ideas from Spotify’s organizational model. Integrated architects can support and learn from one another by participating in Chapters and Guilds. Chapters and Guilds allow integrated architects from separate teams to share knowledge and tools that all teams can benefit from. Individual, team, and company growth occurs faster. Economies of scale are able to be leveraged from the insights of a single team.
Promotion and professional growth incentives can still be simple too. When someone is capable of filling the architect role, award them for achieving a recognized competency instead of a promoting them to a new job. Give recognition and adjust their compensation accordingly.
One risk of the integrated architect model is that an architect can get preoccupied by implementation. The interplay between architecture and implementation can loose structure and discipline.
If Chapter and Guild sync-ups don’t provide enough checks and balances, the team should regularly employ the discipline of taking a break from the picnic and zooming out. Getting the team’s head above the trees allows them to see the forest and validate if their work is satisfying a cohesive architectural plan.