liveBook · Manning

Model architecture

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

Software architecture is the fundamental structure of a software system, including its major components, relationships, and guiding design decisions.

Software architecture shapes how a system can change. A tightly coupled legacy system can make releases risky and slow; a carefully designed architecture can help teams deliver value sooner. The choice is not just technical: domain boundaries, team ownership, and business outcomes all affect whether change can flow independently. section 1.0 section 1.5

An independent value stream brings these concerns together: it pursues a business outcome, belongs to an autonomous team, and has decoupled software aligned to a loosely coupled business subdomain. If software and team boundaries disagree, people may have to share codebases and coordinate changes that should be independent. section 6.1.1 section 11.1.6

Finding boundaries at an airline

An airline’s monolith was risky to change, required whole-system deployments, and remained unreliable at peak traffic. Stakeholders used EventStorming to explore the current system and identify domains and subdomains. They grouped related work where concepts crossed boundaries, while identifying subdomains that teams could largely own independently. The proposed structure reflected business language rather than an arbitrary split of the code. section 9.3.4

To examine an architecture, work progressively rather than assuming the first map is final:

  • Name the business outcomes the current system obstructs. section 9.3.4
  • Map domains and subdomains with stakeholders, checking where changes are coupled. section 9.3.4
  • Compare those boundaries with team ownership and communication patterns. section 11.1.6
  • Revisit decisions as the business and system change; modernization is an evolutionary journey, not a fixed target design. section 1.5
Figure 6.2 The four key characteristics of an independent value stream

Use the four characteristics of an independent value stream to check whether business purpose, subdomain, team ownership, and software boundaries reinforce one another. section 6.1.1

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

How deep it goes
Works through domain decomposition and team alignment, but stops short of implementation-level design.
Examples
Uses an airline’s monolith and domain map to show how business goals can guide architectural boundaries.
What you can do after
Evaluate/understand it by comparing business domains, software boundaries, and team ownership to find change coupling.
How it connects
Links domain boundaries, independent value streams, Conway’s law, EventStorming, and team ownership.

Also explained in

Compare how 13 books explain model architecture →

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.