Altering the role of software architects to reduce code

The primary job function of software architects must be to reduce the amount of code being written. You could extend it to reduce internal communication, reduce dependencies, reduce complexity, and even reduce the number of components.

This way of defining an architect's role makes their engagement more relevant throughout the development process. Every code review now is an opportunity to understand the patterns and abstract them out for the developers. Every performance issue, code smells, and technical debt is an opportunity to take things out and eliminate the problems rather than fix them.

When developing software systems, the complexity and quality typically are directly proportional to the amount of code being written. And this is so independent of the experience and skill level of the developers. A good architect with an eye for patterns and an understanding of the business needs can iteratively make a big difference to what gets built.

Often I see software architect's doing the exact opposite of this, especially with the trend around micro-services over the last decade. The result is an architectural bloat consisting of technologies, components, and complexity.

Unfortunately, we see the magnitude of a complex system while overlooking the effort involved in building something simple. The result is a notion of the complex being harder and better than the simple. In effect, complex thus is also easier to build.

Finally, when you see the role of a software architect this way, they become invaluable to any development project. They are the innovators who find ways of doing more with less. Making systems robust by keeping them simple as they evolve.