Architectural decision

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

An architectural decision is a choice about the structure, behavior, or governing constraints of a software architecture.

An architectural decision chooses among structures, behaviors, or constraints while shaping domains, code organization, team boundaries, and the outcomes a product can pursue. section 10.4

Good decisions are socio-technical: teams must clarify what the product should optimize for before selecting a model that organizes architecture and ownership. section 10.4

Use a progressive decision process:

• Surface competing models and the product beliefs behind them. section 10.4
• Explore the domain beyond a superficial high-level map; inspect complexity and possible boundaries through focused workshops. section 6.2.2 section 9.2.6
• Choose techniques that fit the question, such as EventStorming, context mapping, Core Domain Charts, or Wardley Maps. section 10.4 section 6.2.2

Vinted’s category strategy

At Vinted, two category models attracted support from different groups because each reflected a different product strategy. EventStorming and context mapping exposed the disagreement; Core Domain Charts and Wardley Maps helped the team compare complexity, differentiation, and long-term outcomes before converging. section 10.4

Figure 10.21 Mapping the strategic portfolio with a Core Domain Chart

Use the strategic portfolio map to inspect how architectural options relate to complexity, differentiation, and other investments. section 10.4

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

How deep it goes

Moves from competing models into domain detail and strategic complexity, rejecting high-level views as sufficient for granular decisions.

Examples

Uses Vinted’s competing category models, EventStorming, context mapping, Core Domain Charts, and Wardley Maps.

What it assumes

Assumes product-strategy and domain understanding, then deepens both through focused workshops and complementary mapping techniques.

What you can do after

Evaluate architectural options by connecting domain complexity and team structures to product goals and long-term outcomes.

How it connects

Connects product strategy, domain boundaries, team structures, EventStorming, context mapping, Core Domain Charts, and Wardley Maps.

liveBookmanning.com

Read Architecture Modernization: Socio-technical alignment of software, strategy, and structure on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Collaborative Software Design: How to facilitate domain modeling decisionsAn architectural decision is a significant choice about the structure or organization of a software system together with its context and consequences.

Compare how 2 books explain architectural decision →

Related concepts

• architecture decision recordused by · An architecture decision record is a document that captures an architectural decision, its context, rationale, and consequences.
• architecture advice processconfigured by · The architecture advice process is a decision-making practice in which a decision-maker seeks input from affected stakeholders and subject-matter experts.
• solutionuses · A solution is an answer, approach, or assignment intended to address a problem or meet specified objectives or requirements.
• risk toleranceconfigured by · Risk tolerance is the degree and types of uncertainty or potential adverse outcomes that an individual or organization is willing to accept while pursuing objectives.
• model architecturepart of · The structural organization of a computational system’s components, relationships, and operations that determines how it processes information or behaves.

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.