Do we still need Software Architects
Agile Development and the role of the Architect
In a recent podcast by Software Architecture Radio Tudor Girba was making an unusual, but very interesting point. The reality of architecture is in the code — i.e. if there is something real about the architecture it will be in the code. All other aspects of the architecture are stuck in a netherworld of intention, ideation, and imagination.
Tudor asks, who writes the code? The developers, the engineers, the programmers. For architecture to be real, to be relevant, it needs to be owned by the developers. In effect each developer needs to be an architect.
Now, the first reaction to this is “but what about a junior developer”. No, the idea is not that each developer comes up with his or her own architecture. But rather each developer understands, believes, and owns the architecture so that he can realize it in code.
The End of Enterprise Architects
In the age of agile do we still need this role? Enterprise Architects, in a nutshell, ensure that in a world where technology is a “cost”, costs stay low. This might be cost of development, cost of licensing, cost of maintenance, cost of support. They come up with directives — use this product because the company has an existing licensing and support agreement, or set up your flow this way because it makes it easier to support. Very little of what they do affect the quality of code and the end user experience. More importantly, their directives stifle innovation, force group think, and entrench existing patterns in favour of new ways of doing things. Developers cannot own that architecture because they are developers not managers; developers may fiercely disagree but will remain powerless to change it; developers won’t recognize licensing as a valid software design constraint etc.
The EA is the easiest one to remove. The age of agile removes architects with grand visions; architectures that are intended to span decades are hurdles.
Let’s look at the Application Architect
In agile, the development team needs to own the architecture collectively. This means we need to work towards a solution as a team based on the vision, backlog, and long term goals of the product and the company. What we need are Lead Engineers who can help junior developers make sense of complex issues, so that these junior developers are able to participate effectively in the discussion, raise concerns early, and adopt a sense of ownership. What we need are leaders that raise the playing field for everyone — the Architect is the voice of the team, architecture is their expression.
And Solution Architects?
I am a Solution Architect and I want to say we are still relevant. But our roles have shifted. In the old enterprise we would be focused on ensuring that a solution conforms to the enterprise pattern (established by the EA), that security standards are followed, and that everyone is aligned on what will be developed. In the new world of agile, we need to work with the lead engineers to discover gaps in the team composition, ensure the team is effectively training, and adopting new skills; educate clients on the potentials.
But even so our role is blending into Technical Product Owners — folks who understand the technical implication of a product vision, or can enhance product vision through an understanding of technology.
How should teams do architecture
The simple answer: collaboratively. The better answer follow Neal Ford and Rebecca Parson’s concept of Fitness Functions as explained in their book Evolutionary Architecture. Fitness Functions allow us to collectively craft metrics around key aspects of the architecture. These metrics can be collectively established with a cross functional team spanning UX, Product, Delivery, and Development. Once these metrics and methods of measuring are established everyone can own the architecture, and everyone can discuss objectively the effect of a particular way of delivering a feature.
Even spikes have more objectivity as they can be directly evaluated against Fitness Functions instead of subjectively against metrics or ideas developed afresh.
So say good by to the Software Architect, say hi to the Agile Architect — a team with a way of doing things, not a person telling everyone what to do.
