<ul><li>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.</li><li>Custodianship of each system should still be clearly understood, usually best kept within one team.</li><li>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.</li></ul>

Code Contribution models: Domain Level

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

Shared Code And Infrastructure: Vertical (weakened force)

Good technical design decisions are very dependent on context. 
Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force. As we zoom out in a larger organisation, an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Recognising the differences in these strong and weak forces allows us to make better decisions.

The Forces Of Architecture

<ul><li>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.</li><li>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.</li><li>More formal sharing of solution options and proposals keeps choices aligned effectively.</li></ul>

Technology Choices:  Vertical(Weakened Force)

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

Shared Code And Infrastructure: Domain (strong force)

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

Integration Patterns: Connecting Systems Together

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

Technology Choices: Domain (strong force)

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.

Within A Domain: Strong Forces

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.

Shared Code And Infrastructure: Whole of Org (weak force)

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

Code Contribution models: Whole of Org (weak force)

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

Technology Choices: Whole of Org (weak force)

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.

Whole Of Organization: Weak Forces

Technology governance and what is considered ‘good architecture’ is mostly considered with a ‘one size fits all’ approach.
<ul>
<li>Many organisations try to apply the same strict governance at all levels - limiting tech choices, and disempowering teams. </li>
<li>Others have allowed teams complete autonomy at all levels, meaning teams are left to make their own choices with no constraints at all. </li>
</ul>
Neither of those approaches are ideal.

One Size Fits All Approach

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.