Organisational Constraints

Definition

Organisational constraints are the non-technical bounds on the solution space: team structure, skills, change processes, approval bodies, contracts, and culture. They are as real as technical constraints and they are more often ignored, because they feel negotiable and are not.

The ones that most often invalidate a design

Team structure and Conway's Law. A design that cuts across the org chart will be fought by gravity for its entire life. Two teams sharing one service drift into a de facto split; one team owning six services deploys them together. Either align the design to the organisation or plan the reorganisation as part of the work — but do not pretend the constraint is not there.

Skills. Forty Java engineers and one Go enthusiast is a constraint on the technology choice. An architecture that requires expertise the organisation does not have and cannot hire is not an architecture, it is a proposal.

Change process. A monthly release window makes continuous delivery unavailable until the process changes, and changing it is a separate project with its own sponsor.

Operational model. An outsourced operations partner with a fixed runbook-driven contract cannot operate a system requiring judgement, however good the design.

Approval bodies. An architecture review board meeting fortnightly adds a fortnight to every decision that needs it.

Cognitive load. A team can only own so much. A design distributing twelve services across four engineers will be badly operated regardless of its elegance.

How to handle them

Name them explicitly in the design. "This design assumes teams are aligned to these three capabilities" makes the dependency visible and creates the conversation early rather than during implementation.

Distinguish hard from soft. A regulator's requirement is hard. A change process is soft — expensive to change, and changeable. Say which is which, and who could change each.

Design within them by default, and challenge deliberately. Challenging a constraint is a separate project with its own cost and sponsor. Confusing "this constraint is bad" with "I may ignore this constraint" is the most common way architectures fail to survive contact with the organisation.

Failure scenarios

• A microservices design for an organisation with one release train.
• Boundaries cutting across teams, so every change requires coordination.
• Assuming a reorganisation that nobody has agreed to.
• A design requiring operational maturity the organisation does not have.

Interview question

"Which organisational facts would make you reject a technically sound microservices design?"