Architecture is a group artifact

Architecture is not to be found in the drawing from the architect's office. Architecture is to be located in the source code repository. And in the build system. And in the configuration management repository. And in the deployed artifacts. And in the running system.

All these artifacts determine, in one way or another, the architecture of the system. They all have an impact on it.

These artifacts are created by a group of people. This implies that whoever is involved in placing a piece in the system is also contributing to the architecture of that system. Architecture is a group artifact. As such, it should be regulated by the group, too. Including developers.

One argument that goes against developers having a say in the architecture is that their context is too narrow and therefore, they do not have enough distance to make strategic decisions. This is wrong.

Indeed, their context is typically narrow. And indeed, due to the nature of their work, especially in a world made of short sprints, developers tend to focus on the immediate tasks. This makes them less keen on making decisions that might have far fetching impact, but it does not mean that they are not capable of making long term decisions.

They can make them, and should be at least involved in those decisions. In the end, it is developers that have to deal with the consequences of those decisions. Developers do live in narrow contexts, but this also means that they know those contexts. A broad architecture that does not fit the narrow context is worse than having no architecture at all.

Context matters and any process of decision making benefits from knowing it. The trick is to project a long term goal onto immediate actions. Like anything in software development, it requires a bit of trial and error to find a productive rhythm.

For example, one daily assessment pattern is to have all developers participate in an assessment stand-up in which everyone can raise a technical concern, can debate a concern, and can volunteer to solve it once the consensus have been reached.

The main benefit of the daily assessment exercise does not come from the specific decisions. The critical benefit comes from making architectural decisions explicit, from involving the entire team, and from the daily system cleaning. This works particularly well in agile settings where the team understands the importance of feedback and explicitly invests in obtaining it.

During the daily assessment, discussions only take place if (1) there exist one stakeholder, and (2) the issue has been made apparent through some sort of detection. This has two interesting aspects. First, the stakeholder has a direct interest in the problem and can defend the concerns he raised, thus providing good basis for a healthy debate. Second, the discussion is carried around hands-on examples obtained through checkers, thus ensuring that the debate is concrete. The combination of the two consistently leads to distillation of immediate actions.

Architecture is a group artifact, and it can and should be steered by the group, too.