Facilitating Software Architecture

Foreword

We develop software very differently now than we did when I started out as a developer more than 20 years ago.

The changes that have happened—Agile, DevOps, and the move from project to product among them—have all involved increasing decentralization and increasing independence. Teams now generally release their own code, support their own systems, and decide how they are going to solve business needs.

But the one role that has been more challenging to sort out, in my experience, has been the role of the architect.

When I was building monolithic systems more than a decade ago, architects worked in a separate team, designing the architecture for the whole system, setting standards, and choosing which database, programming language, or deployment mechanism to use. There are several reasons why that doesn’t work in modern engineering organizations: these decisions become a bottleneck, stopping teams from making progress, but also there is even less chance nowadays that a single decision will work for all teams.

But what’s the alternative? You can allow teams to make their own architectural decisions, either by assigning architects to work hands-on with those teams or by making “architecture” a thing that people in senior engineering roles do (along with everything else). However, that can lead to a wide divergence in approaches. That can be risky: are all the different data stores patched and up to date? It can also be a waste of effort as many teams solve the same problems. ...