Architecture is not a role, it's a skill
It's collective ownership
Traditionally, many organizations have placed architectural responsibility in a specific role: the “software architect.” However, this approach is becoming less and less fitting into modern, agile software development methodologies. Architecture should not be an isolated role, but a transversal skill that every development team should share and encourage.
The Danger of the Architect’s Role
Delegating architectural decisions completely to a separate role can lead to dangerous problems. It creates a knowledge gap (and important silos) between the “architect” and the rest of the team, where developers implement, but don’t fully understand the reasons behind the design. This increases the risk of architectural inconsistencies and difficulty in maintaining and evolving the system.
One of the four values in the agile manifesto is directly “Customer collaboration over contract negotiation”. In the same way that developers who don’t know the product they’re developing can’t adapt the software to the needs they’re trying to cover, if what we’re doing is negotiating an architecture contract with a third party within our own development cycle, we’re putting obstacles in our way.
In addition, architecture is not at all a once-and-frozen task. Every line of code, every library used, every pattern applied has architectural implications. It is almost impossible for a person to foresee and control all these decisions in advance without other perspectives.
A skill instead of a role
That’s why architecture should be seen as an essential skill that every software developer has to work on and master. A deep understanding of architectural principles, patterns, and styles is key to writing code that is truly maintainable, scalable, and evolutionary in the long run.
So how do you foster this architectural understanding and alignment across the team? Agile dynamics and practices are the solution: code reviews, technical slicing, technical retrospectives, and pairing as a practice to raise quality, all can be an opportunity to build and reinforce a shared architectural vision.
Some specific activities that can help form and foster architecture in the team are:
- Task/Story Planning: In this phase, the architectural implications of each story or task should be discussed before being assigned. Identifying the architectural patterns, principles or constraints that will need to be taken into account during its implementation. It is advisable to rotate who leads these discussions so that the whole team actively participates.
- Refinement sessions: Before starting to work on complex functionalities, conduct specific architecture refinement sessions. These sessions explore different approaches and high-level designs using proofs of concept. The entire team discusses and comments towards the best architecture before proceeding with the implementation. A good format can be that of the Bytesize Architecture Sessions by Andrea Magnorsky.
- Retrospectives: On a regular basis, you should review how the architectural principles and patterns defined for the project are being applied. Identifying “technical debts” and recurring architectural problems. These retrospectives allow us to propose actions and improvements in architectural processes and designs.
- Training and sharing: Organize regular training sessions on different aspects of software architecture. Team members themselves take turns preparing and leading these training sessions. In addition, books, tutorials, videos, and other resources on architecture are shared. Finally, encourage participation in events, blogs, podcasts, etc. to share lessons learned.
And when it’s time to make the big architectural decisions that will define the direction of the system, they need to be made collectively with the participation of the entire team. By bringing together everyone’s knowledge and experiences, we achieve more robust and consistent designs than any individual “architect” would.
Architecture is a team issue
Architecture is too important to be left to isolated roles. It requires a deep understanding and constant effort from the entire development team. Only by promoting architecture as a transversal skill, and making decisions collaboratively, will we achieve truly maintainable and evolutionary systems. It’s time to move away from siloed architectural roles and move towards a new paradigm of collaboration and collective ownership.