liveBook · Manning

Architecture advice process

As explained in Architecture Modernization: Socio-technical alignment of software, strategy, and structure

The architecture advice process is a decentralized decision-making technique in which anyone can propose an architectural decision after consulting affected people and relevant experts.

The architecture advice process decentralizes architectural decisions: anyone may propose a decision after consulting affected people and relevant subject experts. It preserves architectural quality while helping teams move without waiting for a centralized architecture group. section 15.3.2 section 15.8

A lightweight decision flow can include:

  • Identify the solution’s must-haves and invite ideas from participants. section 15.3.2
  • Allow anyone to propose a solution, then evaluate the alternatives. section 15.3.2
  • Consult people affected by the decision and experts in relevant topics before deciding. section 15.3.2
  • Record both the decision and the conversations in an architecture decision record (ADR). section 15.3.2
  • Vote using a score from 1 for the best solution ever to 5 for a terrible mistake, then address concerns to improve the result toward 3, an acceptable score. section 15.3.2

This is not permission to design systems arbitrarily or introduce technologies on a whim. Decisions with broader consequences, or those requiring more scrutiny, can be referred to an architecture guild working group or a fuller RFC process. section 15.3.2

A multi-team architectural decision

When related teams cannot make a collective decision promptly, an enabling team can establish this process: gather must-haves, invite proposals, consult affected teams and experts, document the discussion in an ADR, score the alternatives, and resolve concerns before accepting the outcome. section 15.3.2 section 15.1.2

How Architecture Modernization: Socio-technical alignment of software, strategy, and structure covers it

How deep it goes
Defines consultation, proposals, evaluation, ADR capture, scored voting, and concern resolution, while allowing escalation to a guild working group.
Examples
Uses must-have lists, solution proposals, expert consultations, ADRs, and scores from 1 to 5 with concerns resolved toward 3.
What it assumes
Requires access to affected people and subject experts, while reducing dependence on centralized architecture teams.
What you can do after
Apply it via ADRs, consultation, proposal evaluation, scored voting, and escalation for decisions needing broader review.
How it connects
Connects ADRs, architecture guilds, architecture operating models, RFCs, and decentralized decision-making.

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Architecture Modernization: Socio-technical alignment of software, strategy, and structure. The section links point to the parts of the book it draws on.