Why I am not superfluous as a software architect
Thoughts on the role of the software architect in an agile environment
In the good old days, the world was still okay for a software architect. He was given a task to think about in peace in order to find suitable solutions. Once he had found a possible solution, he described it more or less formally and handed it over to the development department. At that moment he had already forgotten the solution, because his mind was already occupied with the next beautiful problem.
The software architect – the most important figure in development
The software architect was the most important figure in a software project. Godlike. Of course, there have been project managers, business analysts, steering committee members, etc. before. But HE was the most important of all.
Naturally, even in the good old days, not all that glitters was gold. Most of the time, even the godlike software architect, our think tank, our source of enlightenment, didn’t get what he actually designed. But always: if something worked, he designed it implicitly, if it didn’t work, it was the others’ fault. It was a beautiful world – at least for the architect.
In fact, there was no malice on the part of software developers not to develop what an architect had designed. No, they had to develop things that reflected the current requirements, that met the technological possibilities. Requirements have never stood still. They develop. They adapt to the possibilities. Technology does not stand still. New possibilities develop that can better solve the problem. Not relying on such changes in development simply means running obsolete software from the very first production run. This was the case in the past and is still the case today.
The change of the role
Today, cross-functional teams develop software. They develop it, they test it, they design it. Yeah, teams design software. And designing software means designing the architecture.
But where is the software architect when the knowledge of the overall system is distributed in the teams and these teams know best what they are doing? The answer is relatively simple: the software architect must be part of the team.
And what happens to the topics that are not necessarily assigned to a team? If we don’t only deal with feature teams, but also with topics like authentication, logging, business monitoring, security, etc.? Who takes care of such cross-cutting concerns? Obviously, organisations need representatives who deal with cross-cutting issues across teams.
The Big Picture in sight
Nowadays, solutions for topics – even for overarching issues – are developed in teams. These are often good solutions that fit the environment in which the team works. Team A builds a solution for problem X. Team B builds a similar solution for a similar problem. Both teams are fast and independent. They do not need anyone to “rule” into their solutions. However, Team B might have been able to reuse parts of Team A. Keyword: Reusability.
I’m personally not a big fan of such reusability, as it often creates dependencies where they don’t necessarily have to be. But working economically also requires us to look beyond the horizon of our own team.
This “thinking outside the box” requires – from my very personal point of view – a “big picture”. Individual teams cannot achieve this without the help of others. During the initialisation of a project, the creation of a Big Picture helps to create mutual understanding. But if a Big Picture is to help in the further course, it must be allowed to change. Probably it will not change fundamentally, but subtly. But even such changes have to be allowed and observed.
The community of practitioners
So we have central topics like the Big Picture and the cross-cutting concerns, where teams should be supported. Interestingly, such support does not limit the self-responsibility of the teams, but makes it possible in the first place. “Offer” is the key word here, not “prescribe”. If a cross-team instance offers solutions for maintainability, availability, or security, for example, teams like to listen. Gone are the days when a godlike figure simply passed on his findings to the programming people in order to quickly turn to new problems.
A further offer is the exchange in a community of practitioners. The teams delegate members to this community to discuss questions of daily work such as architecture, technology, procedures, operation, etc.
And this is where the software architect comes into the picture again as a supporting role. He or she can mediate in case of conflicting views, reach agreements, and also document decisions. In addition, it is usually easier for a team-independent instance to try out new technologies in sample implementations in order to bring the corresponding knowledge into the teams.
The necessary prerequisite: decision-making competence
A community of practice quickly transforms into a toothless tiger in lived corporate practice if it is not given decision-making authority. Decisions within given guidelines must be able to be made in the community. Governing management into this decision-making competence often has fatal consequences. And even the software architect has to get used to the fact that he or she is heard, but the voice is only one among many. Otherwise, the members of the community will no longer get involved.
When the community is given decision-making authority, no one behaves like an architect anymore. The term architect comes from the Greek and means master-creator.¹ Today, teams alone are the master-creators of business content.
The community can take responsibility for everything that is not directly “business”. (By the way, this also applies to UX/UI design, but this is a topic for another blog post. 😉) It can decide on all architectural issues that cannot be resolved within the teams. Once a decision has been made, the teams have to stick to it. Since the decisions are made by team members, a high level of acceptance can usually be assumed. Moreover, team members also inform their teams about discussions, even if no decisions have been made yet. In this way, the knowledge of the community reaches the teams and they can contribute their individual views to the discussion. Everyone wins!
One more small thought: As with other decisions, community decisions only make sense if they are sustainable. It is therefore important to observe whether the decisions are taken into account in the teams and if not, why this is not the case. Of course, a community of practitioners can also be wrong. Therefore, community members must also be prepared to accept their own mistakes and revise decisions that have been made.
Conclusion
Where do I stay now? As a software architect I can support the community and help with words and deeds. I can prepare investment decisions and find appropriate arguments together with the teams. Maybe you can see it as a career break – I see it as a career jump. Only someone with great experience, great knowledge and simply a lot of humanity can fill this role and have fun doing it. It is an expert role that really deserves the name expert. And that is also the reason why I am not superfluous as a software architect.
Notes:
[1] https://en.wikipedia.org/wiki/Architect
Dr. Annegret Junker has published more articles in our t2informatik Blog:
Reasonable limits for self-responsible teams
Agility begins with the heart
From Monolith to Microservices
Dr. Annegret Junker
Dr Annegret Junker works as Chief Software Architect at codecentric AG. She has been working in the software industry for over 30 years in various roles and different domains such as automotive, insurance and financial services. She is particularly interested in DDD, microservices and everything related to them.