index.md 8.0KB
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.
Separation of Architecture & Implementation
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.
Creating a Chasm
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.
A Better, Integrated Structure
I suspect distinct architecture jobs and teams are created for several reasons, including:
- Hiring efficiency (simple job description and experience to look for)
- Operational efficiency (spread architects over many teams)
- Promotion and professional growth incentives
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:
- Eliminating the separation of strategy and execution and all of the dysfunctional risk associated with that organizational structure.
- Architects living with, and getting feedback on, their decisions throughout implementation. The feedback loop promotes learning and better future decision making.
- Architects being able to contribute to development effort.
- Architects staying knowledgable of new tools, processes, and paradigms that can make a difference during implementation.
- Architects teaching junior developers architecture and development practices. Living with and coding through early architectural decisions allows architects to establish and maintain trust and respect with their teammates. A relationship of trust and respect allows for teaching and learning to occur.
At a summary level, the integrated architect approach sets the stage for:
- Increased morale
- Increased quality
- Increased speed of execution
- Nearly free staff development that occurs in the midst of product development
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.
Risk of an Integrated Structure
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.