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.
Yes i totally agree with your points about integrating architects skills and implementation skills are very helpful and it provides good environment for learning and sharing knowledge within a team also. Unfortunately i had experience of what goes wrong if your architect and implementation team is not in sync. Its might be disastrous.
Thanks for your comment Ashish. Sorry to hear about your unpleasant experience.
Can you please share what happened in your experience?
I’d go further and say that architecture is an activity, and a responsibility, but not a role. The technical leadership needs to ensure it’s done, but not necessarily do it themselves.
Yeah I completely agree with this. “Architecting” is an activity that I go in and out of on a daily basis. And unless the spec is so specific it tells you what code you should write, you’ll have to do some thinking/architecting to implement any solution given.
That’s an interesting distinction Simon. Thanks for sharing it. In many cases, every developer on the team has the responsibility for architecture and will participate in architecture activities.
I believe there are some contexts where a defined architecture role can be beneficial so someone really owns the responsibility. For instance, someone might be tasked with developing and owning an entire solution architecture that is unproven and spans multiple devices or integration points. The team can still collectively own application architecture.
Thanks for your comment.
Tribes? Chapters? Guilds?
What a bunch of hogwash.
This comment made my day. Excellent user name.
What you’ve described may indeed happen, but that hasn’t been my experience.
For instance, in your list of reasons why companies create an “architect” position, one big reason is that they need someone who can think long term for the benefit of the company as a whole. As a developer, you’re often fighting fires and working off a long list of “client requests / to dos” that never seem to end.
You need someone who has the time to sit down and think about “this is how it currently works, and this is how it should work, and how do we get there”. That is a task that developers responsible for day-to-day operations cannot reasonably set aside time for because it takes weeks of dedicated effort. It’s just a different mindset. The best a developer will do for long term thinking is refactor some code, or rewrite an entire program when they find themselves with a free day or two. On the other hand, the architect thinks “do we really need to be doing this, or can we get the vendor to do that for us”?
A good software architect is the love child of a business analyst and a senior developer. Of course, you want them to be working closely with all parts of the business and not be sitting in an ivory tower thinking big thoughts. But that’s a different problem than saying “software architecture is not a job”.
Thanks for the feedback Scott. I agree with your perspective.
In my post, I mentioned the need to zoom and out consider long-term application architecture at a guild or chapter level. It’s a risk to not have a long-term perspective. It’s also a risk to isolate architectural lessons within teams (you get economies of scale when insights and learnings can be spread from a common hub).
I agree with you that it could be beneficial to have someone, or a team, dedicated to long-term thinking related to IT infrastructure, technology selection and consolidation, etc. I think most of those long-term considerations are related to macro-architecture more than application architecture (the context of my post was more focused on application architecture).
> A good software architect is the love child of a business analyst and a senior developer. Of course, you want them to be working closely with all parts of the business and not be sitting in an ivory tower thinking big thoughts.
I love your definition. Based on your description, I like to think of such a person as a technology strategist and internal consultant to the business and teams. Maybe this person should be called a Software Architect. Or maybe not. Regardless, the point you make is important.
Comments are closed.