The strong and weak forces of architecture

Within a domain we have multiple teams, each being responsible for some capabilities and underlying systems within the domain.

Sometimes this is perfectly aligned, with each team being custodians of a neatly bounded set of systems. More often this is imperfect in reality, with custodianship of some systems being shared across teams - often for legacy reasons. For teams within a domain, there is a very strong force of alignment.

In the middle ground we have our vertical structure, with multiple domains. The social distance between the people in one domain and another is getting stretched.

This makes negotiation and reaching alignment more strained and slower, and so necessarily this impacts our technology choices and approaches.

When we zoom out to all of the organisation - the force of alignment between the verticals is very weak indeed. It is quite hard to make changes atomically across the landscape - mostly because the prioritisation of work for each vertical is deliberately independent.

Coordinating work at this level is necessarily much slower and limiting. This means our design decisions and approaches need to adapt accordingly.

• Within a single domain, there should be a small set of technology choices agreed upon.
• Often this follows Default Trial Retire for each class of technology required.
• Informal governance through technology leadership is usually highly effective.

• At a vertical level, there would be a slightly larger set of agreed technology choices, to cater for the differing needs of the multiple domains.
• It is beneficial for the vertical to be able to move people closer to high priority work, so keeping aligned on technology is important here.
• More formal sharing of solution options and proposals keeps choices aligned effectively.

• The weakest force for aligning and governing technology choices is at the Whole of Org level.
• Solution options and proposals encourage dialog and improve alignment.

• Within a single domain, even across 3-5 teams, we should have high bandwidth communication and a short distance to empowered leadership.
• This means that when a change needs to be made to shared code or infrastructure, we can quickly inform and prepare for the changes.
• The coupling introduced by shared code and infrastructure has less impact, and the benefits often outweigh the costs.

Sharing code, artefacts, and infrastructure can often be managed at a vertical level - but the drag introduced should be carefully monitored.

Shared code at a whole of organisation level is limited to highly stable, highly useful things. Mostly these things are limited to libraries which can be distributed and versioned, and changed carefully.

Shared infrastructure is similar - at an org-wide level, shared infrastructure must have very high value, and be well-encapsulated (“as a service”, self-service). It should very rarely need a core change in response to a need from a single team.

• Within a single domain - with high degrees of alignment in terms of practices and technology - it can be quite reasonable for teams to contribute code across team boundaries, with a type of collective code ownership extending to the whole domain.
• Custodianship of each system should still be clearly understood, usually best kept within one team.
• At a vertical level, it is common for code contribution to happen across systems, e.g. pull requests in source control - with only small amounts of delay and re-work required.

• At the whole of org level, it is often quite difficult (and sometimes harmful) to effectively manage contributions that cross verticals.
• This is particularly true where systems are complex in nature, highly critical or sensitive in terms of accuracy, performance, privacy and compliance.
• When completely new system features are being established, it can work well to collaborate across verticals even doing pair-programming together.

• Domain (strong force): Systems that are owned within a single domain are relatively easy to change in a closely coordinated way.
• Vertical (weakened force): Changes that must be coordinated across multiple domains within a vertical should be rare, but can be managed when absolutely necessary.
• Whole of org (weak force): The impact of highly-coupled integration (e.g. ETLs, database integration) is very high, and should be absolutely avoided.