When Architecture Governance Should Follow the Physics of Teams

Technology governance often defaults to one of two extremes: a uniform set of strict rules applied everywhere, or complete autonomy with no guardrails. Both miss the point. Good technical decisions are deeply contextual, and the right level of governance depends on how tightly the people making those decisions actually work together.

At MYOB, teams are arranged by product and business capabilities, grouped into domains, and then into larger verticals representing customer segments. This structure informs a practical model for governance: the strength of alignment between teams determines how much coupling, shared code, and informality is safe. Where alignment is strong, teams can move fast with less ceremony. Where it is weak, more rigor is required.

Strong Force: Within a Domain

Teams within a single domain share a strong force of alignment. They work on systems that are functionally cohesive, deal with the same concepts, and often change together to meet customer needs. The people involved can negotiate schemas and system interactions quickly, and sometimes the same people implement both sides of an integration.

This close social distance has practical consequences for architecture. "Private" interactions between systems inside a domain can tolerate tighter coupling without incurring the full cost of versioning, backward compatibility, or managing shared dependencies. Coupling at this scope is not an evil to be vanquished—it can be a useful tool that reduces effort and speeds delivery.

Weakening Force: Within a Vertical

As you move out to the vertical level, social distance between domains grows. Negotiation becomes slower and more strained. Technology choices and design approaches must adapt to this reality. Shared code and infrastructure can still be managed at this level, but the drag it introduces needs careful monitoring.

Weak Force: Whole of Organisation

Across verticals, the force of alignment is very weak. Work is prioritised independently, making atomic changes across the landscape nearly impossible to coordinate. Design decisions must be built for this environment. Interfaces that span the whole organisation demand the highest attention to published schemas, versioning, contracts, and deprecation strategy.

Applying the Model to Common Governance Decisions

The strength of these forces varies by scope, and so should the approach to key technology decisions. The following areas illustrate how this model plays out in practice.

Technology Choices

  • Domain (strong force): A small set of agreed technology choices, governed informally through technology leadership, is usually highly effective.
  • Vertical (weakened force): A slightly larger set of choices is needed to cater to multiple domains. Formal sharing of solution options and proposals keeps things aligned.
  • Whole of org (weak force): A technology radar sets direction, and solution proposals encourage dialogue, but centralised alignment is minimal.

Shared Code and Infrastructure

  • Domain (strong force): High-bandwidth communication makes changes to shared code manageable. The cost of coupling is outweighed by the benefits.
  • Vertical (weakened force): Sharing is possible but should be monitored for drag it introduces on teams.
  • Whole of org (weak force): Only highly stable, highly useful items should be shared. These are limited to versioned libraries and well-encapsulated self-service infrastructure that rarely needs core changes.

Code Contribution Models

  • Domain (strong force): Collective code ownership across teams is reasonable, though custodianship of each system should stay with one team.
  • Vertical (weakened force): Cross-system contributions via pull requests are common and require only small amounts of re-work.
  • Whole of org (weak force): Managing contributions across verticals is difficult and often harmful, especially for complex or sensitive systems. Cross-vertical collaboration can work for new features, but as demand grows, architectural investment is needed to make systems safe to extend and configure.

Integration Patterns

  • Domain (strong force): Closely coordinated changes mean less effort is needed on backward compatibility. Even legacy issues like database-level integration have contained impact.
  • Vertical (weakened force): Coordinated changes should be rare but manageable when necessary, relying on expand-contract changes to API contracts.
  • Whole of org (weak force): Highly coupled integration such as ETLs or database links should be absolutely avoided. Published APIs and events require rigorous versioning and deprecation planning.

A Balanced Governance Model

This approach enables "aligned autonomy" at MYOB. It avoids centralised control over every decision while preventing complete chaos. Simple models like the strong and weak forces of alignment help teams understand what will be easy and what will be hard, making it possible to choose pragmatically rather than dogmatically. The result is technology governance that matches the reality of how people in the organisation actually collaborate.