liveBook · Manning

Modularity

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

A modular architecture organizes a system into separable modules with well-defined responsibilities and limited dependencies between them.

Modularity separates a system into parts that teams can understand and change without routinely disrupting unrelated work. Its value becomes clear when a growing system slows compilation, testing, deployment, and onboarding—and when changes in one area break another. Looser coupling and ownership of system parts can help restore the ability to innovate. section 10.4

A category system under strain

Vinted’s marketplace expanded beyond women’s clothing into six departments. Its category tree needed to grow deeper and wider, but the existing architecture blocked a newly formed categories team from delivering value. Engineering leaders agreed that a loosely coupled, modular architecture, paired with teams owning parts of the system, was needed. section 10.4

Team boundaries and software boundaries may not change at the same pace. During a phased transition, teams can still share technical artifacts and need closer collaboration. At CloudSuite, a backend API crossed team boundaries; because physically separating it required considerable effort, collaboration and modularization within the component came first. section 17.4

Figure 17.5 In phase 1 of the inverse Conway maneuver, teams were reorganized first.

The first-phase diagram shows why reorganizing teams does not immediately remove dependencies in the existing architecture. section 17.4

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

How deep it goes
Explains the organizational rationale and a phased transition, but does not specify how to implement module boundaries.
Examples
Uses Vinted’s expanding category tree and CloudSuite’s shared backend API to show different pressures on modularity.
What you can do after
Practice/perform phased modularization by planning collaboration where team boundaries still cross shared technical artifacts.
How it connects
Connects modularity to loose coupling, team ownership, and the inverse Conway maneuver.

Also explained in

Compare how 10 books explain modularity →

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.