Skip to content
Software Architecture Guide

Software Architecture in Its Context

Explanation

Section titled “Explanation”

A software architecture is not designed in a vacuum. Outside forces push on it. Three of them matter most here: the organization, constraints and stakeholders.

The organization shapes the design. Conway’s law says that organizations designing systems end up producing designs that copy their own communication structures. A company’s communication structure tends to resemble its administrative structure. So a system often looks like the company’s organization chart. Team boundaries and reporting lines can show up as system boundaries.

Constraints limit the architect’s freedom. An architecture constraint is a requirement that restricts the architect’s freedom in design and implementation decisions. Some constraints reach beyond one system. They can apply to a whole organization or company. One way to sort them is into technical constraints, organizational and political constraints, and conventions. The articles on arc42 Constraints and Architectural Constraint cover this in more depth.

Architects must always deal with constraints. Some are negotiable. So architects need to know where they are free and where they are bound.

Stakeholders steer the big decisions. A stakeholder is a person or group with an interest in the system. The quality goals of the most important stakeholders influence fundamental architectural decisions. Stakeholders also determine how much work the architect does and how detailed the results are.

What follows for the architect. The architecture sits inside a larger picture. Reading it well means looking at the organization, the constraints and the stakeholders around it.

Example

Section titled “Example”

A company has three teams: one for the web shop, one for payments and one for shipping. Each team talks mostly to its own members. The resulting system has three separate parts, one per team, which follows Conway’s law. A company-wide rule requires one approved database product. That is a constraint, and the architect asks whether it is negotiable. The most important stakeholders care about fast checkout, and that goal weighs heavily on the main design decisions.

Trade-offs

Section titled “Trade-offs”

Constraints reduce the architect’s freedom, but they must still be handled, and some can be negotiated. Treating every constraint as fixed may close off good options. Ignoring them risks a design that cannot be built. Likewise, stakeholders set how much detail the architect delivers, so the effort has to match what they need.

Organization, constraints and stakeholders all influence the architecture.

Diagram source 
flowchart LR
  O[Organization and its structure] --> A[Software architecture]
  C[Constraints] --> A
  S[Stakeholders and quality goals] --> A

Checks

Section titled “Checks”
  • Constraints that limit design and implementation freedom are listed, grouped as technical, organizational, political or conventions.
  • The document notes which constraints come from the wider organization rather than from this system alone.
  • The document shows which constraints are fixed and which may be negotiable.
  • The quality goals of the most important stakeholders are stated.
  • The level of detail of the document matches what the stakeholders need.
Section titled “Related”

Sources

Section titled “Sources”