What is the advantage of software architecture?
Architecture, as we know, is just a useful metaphor that symbolizes the complexity of software development. This metaphor suggests that we must consider not just technology, but also budgets, stakeholders, and our team. At the end of the day, it is the main tool for decision making, and for changing those decisions at the right time.
Software architecture is something you learn all your life because it keeps evolving. What I love is that today we have so many high level concepts that it seems as if architecture is becoming a commodity, something one of my colleagues once remarked. In principle, you do not have to create concepts from the ground up, you just need to combine them. For example, there are many services in the Cloud and what you need to understand is what a service does, and how much it costs. Then all you need to do is to put the pieces of the puzzle together.
Software Architecture has changed so much since the days when The Mythical Man-Month was written, though even at that time the author knew where the story of architecture was heading. Namely, that high-level programming languages would make development easier and faster. This is indeed what has happened.
I am not sure how much further architecture will evolve, as it can go in many directions. For example, machine learning has lately become relevant, and quantum computing, now on the distant horizon, will be a real game changer.
Architectural decisions should and must be made by the whole team. I am not a huge fan of assigning the role of Software Architect. If you explicitly assign it to one person, you might be discouraging the team from making architectural decisions. This might make the team feel a lack of responsibility and motivation for the project.
One could argue that every decision in software development is an architectural decision, some being riskier than others. Traditionally we say software architecture is solving "wicked problems" – those that are difficult to decide because you cannot foresee all the consequences. Yet today there are no longer many wicked problems because it is easier to evolve architecture.
I am a big believer in evolving architecture. I have seen in several projects that changes that used to be hard are today much easier. You need less time, but a good strategy and some negotiating with stakeholders. With this you can even transform the whole product, piece by piece; if that is within the project’s scope.
We often talk about big or greenfield projects, but even for smaller extensions you must think about the conceptual integrity of the system when making decisions. Architecture therefore encompasses everything from folder structure to large system scaling.
In software engineering, architecture and team organization go hand in hand. Note that whoever spends time on team organization will have less to spend on programming, especially when the team count and project complexity are high. But we must not forget that the Tech Lead is first and foremost a developer. You always need to keep up your technical prowess. This is necessary because you do not want to program just for its own sake, but to develop concepts that will be used by the team as "best practice". That is how you can achieve impact by programming as a tech lead.
Software development should be quite simple, that is why team members should reuse from each other and not create a completely new concept every time. Use simple code and a modest amount of it, and you should be able to read that code like a poem. Avoid what one of my colleagues jokingly called "patternitis" – using every design pattern in the book. This is another important reason to know the framework you are using well, so you can rely on concepts that the framework already offers, instead of creating new ones.