Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

ConceptChapter I · Fundamentals · Building block 7 of 7

Architecture ownership

Architectural responsibility distributes concrete tasks and decision-making rights among stakeholders. Clear responsibilities keep decisions effective and verifiable.

By Michael Meierhoff · Meierhoff Systems

  1. Leadership roleThe task has a role to play.
  2. PostWhat the role delivers in concrete terms.
  3. EvidenceWhat to check for.

Context

Why this is important

Without clear responsibility, architectural issues remain or are decided twice. A task can only be verified if a leading role and proof have been established. The content of individual decisions is dealt with by a separate building block.

This building block explains responsibilities around architectural work. For the content of an individual choice, see Architecture Decision.

Shop example · Roles and responsibilities

Who wears what in payment integration?

In the payment integration of the shop, four roles work together. Each leads exactly one station and works on others – as in a squadron.

This is how you read the picture

  1. Leadership role The big icon above each station, such as the platform team at “Connect provider”.
  2. Post The text under the station, such as “Contract and Status Model”.
  3. Evidence The stamp of each station, such as “✓ Integration test”.

  1. LeadingProduct owner

    Clarify the payment date

    Business Results and Errors

    Accepted scenarios

    Work withPayment module owner
  2. LeadingPayment module owner

    Designing an interface

    Contract and status model

    Reviewed draft

    Work withProduct ownerPlatform team
  3. LeadingPlatform team

    Connecting providers

    Adaptor and access

    Integration test

    Work withPayment module owner
  4. LeadingOperations

    Operational verification

    Metrics and restart

    Performed exercise

    Work withPlatform team
Great above every station stands who leads; small, who participates. The stamp shows how to check the completion. Choose a role to highlight their stations.

Benefits & limitations

Helps if:

  • Several teams disagree on a decision on responsibilities or consequences.
  • Business stakeholders, development and operations need to work together on a significant design question.

Boundaries

  • Leading does not mean working alone; affected teams and subject matter experts participate; and Architectural decisions record their contributions in a comprehensible manner.
  • Requiring approval for every change creates a bottleneck. Teams need room for local decisions, with escalation for effects that cross team boundaries.
  • A role establishes accountability but does not explain the rationale; Architecture Decision Records serve that purpose.

In practice

  1. Identify stakeholders and their perspectives. Determine who knows the rules, owns the decisions and implements their consequences. This clarifies whose input is needed before a choice is made.
  2. Clarify authority and escalation. Identify who decides within the team's remit, which questions need joint decisions, and where unresolved conflicts are escalated. For a choice with lasting impact, an Architecture Decision Record can document the rationale.
  3. Ensure implementation and feedback. Assign each agreement to an accountable team and define how deviations or new findings are reported. This keeps accountability effective during implementation; Architectural Decisions describes the choice made.
  4. Check team handovers in the shop. Follow a new delivery option from business idea to operation. Identify the necessary coordination, decision-making authority and knowledge gaps; use Team Topologies to examine the responsible team's collaboration.
Read the detailed explanation

Architectural questions can affect business rules, technical implementation, security and operations at the same time. An accountable role brings these perspectives together, enables conflicts to be resolved and follows through on relevant consequences. Advice supplies knowledge; decision-making authority establishes who is responsible for reaching a decision. Architectural Decisions records the choice itself; Architecture Decision Records preserves the context and consequences for later readers.

Responsibility can be shared rather than concentrated in one central person. Teams can make local decisions while cross-cutting roles establish guardrails and escalation paths. The scope of responsibility follows the impact: shared interfaces and quality goals need coordination; internal details belong to the teams that implement and operate them.

Conway's Law describes a relationship between an organisation's communication channels and the structures of the systems it designs. Team boundaries and building block boundaries should therefore be considered together.

Gregor Hohpe's Architect Elevator connects business goals to technical decisions. In the shop, for example, the team explains how independent changes to Shipping enable faster delivery options and what operational effort they introduce. Team Topologies adds a perspective on team responsibilities, collaboration and cognitive load: how much system knowledge must a team hold at once to do its work?

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    Who leads the station "check operation", and what proof is included?

    View the solution with justification

    The operation, with metrics and restart as a contribution. The proof is the exercise performed; the platform team participates.

  2. ApplyingTransferred to a new situation

    The payment provider lacks access for the integration test. Who do you turn to?

    View the solution with justification

    To the platform team. It performs “connect provider” and provides adapter and access; its proof is the integration test.

  3. EvaluateWeighing an alternative

    Should the platform team also design the status model of the payment so that everything comes from a single source?

    View the solution with justification

    That saves voting. However, it takes the task of the module responsible payment, the contract and status model; the platform team is already involved there. The separation keeps the review of the draft regardless of the provider connection.

Explore further

These building blocks continue the thoughts of this page.

FundamentalsArchitecture decisionHere you identify influential design questions and learn how to make a well-founded architecture decision.Opening EvolutionArchitecture reviewAn architecture review evaluates designs against relevant goals, risks and scenarios.Opening DocumentationArchitecture Decision RecordAn Architecture Decision Record documents the context, rationale and consequences of a significant architecture decision.Opening

References

Continue on the learning path

With that, you have Fundamentals & orientation run through. It continues with Requirements & quality.

7 Building blocks

Next areaRequirements & quality