The strong and weak forces of architecture - Deepstash

Bite-sized knowledge

to upgrade

your career

Ideas from books, articles & podcasts.

created 14 ideas

Understanding the strong and weak forces of team architecture


The strong and weak forces of architecture

The strong and weak forces of architecture


464 reads

The Forces Of Architecture

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 decis...

Technology governance and what is considered ‘good architecture’ is mostly considered with a ‘one size fits all’ approach.

  • Many organisations try to apply the same strict governance at all levels - limiting tech choices, and disempowering teams.
  • Oth...

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 custodi...

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...

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.


  • 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 he...

  • 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 cou...

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 hav...

  • 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 s...

  • 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 complian...

  • 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, ...

1 Reaction



created 16 ideas

The Independent Service Heuristics (ISH) are rules-of-thumb (clues) for identifying candidate value streams and domain boundaries by seeing if they could be run as a separate SaaS/cloud product. The ISH approach is a “rapid results” approach, and complementary to the approaches from Domain-driven Design (DDD).



288 reads

It's time to




Jump-start your

reading habits

, gather your



remember what you read

and stay ahead of the crowd!

Takes just 5 minutes a day.


+2M Installs

4.7 App Score