Clickbait alert! It is not going to be about Software Architecture. And not about its evolution either. The post is about the evolution of software architecture organizations, such as departments.
Phase 1 - competence growth
In some software teams there may already be people with the Architect title. In others, there are really good developers who, with the pass of time, may be promoted to the Architect role. For now, these people only have the direct, big impact on their own product or software component. They drive and maybe even make many major decisions inside their software team.
Phase 2 - the forming of the architecture group
Someone clever in the organization notices that each team has a really smart person and - bang! What if we put all of these smart guys together? They will still be the architects in their respective teams, but together, they will for a body that will:
- drive company level initiatives,
- provide steering with regard to technology,
- ensure consistency in the way things are done across all the teams.
But of course, it sounds great! Let's do it!
Phase 3 - the critical moment
The critical moment is when the body formed of all these smart guys starts to be more of a blocker of work progress than actually a helper. The work slows down. The decisions require the body to meet and make the decision together. The decision needs to be prepended with an analysis. The body only meets once every two weeks to address architectural decisions and this month there will not be enough of them to actually decide on anything, because of vacation. If you need something from the body, you must write up an architectural proposal and present it for evaluation. If the body does not agree on something internally, it will take more than one meeting to reach a decision. Teams no longer make the decisions themselves. They only make proposals and requests.
The architects have less and less connection with ground control (code base). They start living in an artificial world, mostly consisting of paper, very far from the actual products, not to mention the software.
Phase 4 - life is sweet
Complacency has already sneaked into the lives of the architects. They enjoy their position and the feeling of importance. Finally someone recognized their wisdom and they can do all these really important things. They no longer have to keep track of how the company products are used and how they are evolving. But they can announce new non-functional requirements or standards that the products need to meet. Yes, it feels nice.
Phase 5 - there is the real life out there
There are other smart people still working in the software teams. These people, perhaps slowly but steadily, figure out how to live with the "help" of the architects. They start making some decisions themselves. At first, maybe smaller ones, but then also the bigger ones. They learn how to feel more comfortable asking for forgiveness than for permission. They get their teams back on the speedy track by avoiding the lengthy discussions and committee decision making. Thanks to their courage and initiative, the whole organization is saved from its own harmful decisions.
Not all companies are lucky enough to get to the 5th phase.
Conclusion
The description of the five phases above is obviously ironic and deliberately too colorful. It is because I wanted to emphasize some of the things that you may notice in your environment. I think the "phases" are a pattern and I think Phase 4 is business as usual in many organizations.
If the Architect role feels at least a little bit controversial to you, I absolutely need to recommend the article Who needs an Architect by Martin Fowler.