On the Criteria To Be Used in Decomposing Systems into Modules

The most influential paper ever written on software architecture, and it fits in five pages. Parnas demonstrated with a concrete example that the obvious way to decompose a system — along the steps of its processing — produces brittle designs, while decomposing along likely changes produces resilient ones. This is the origin of information hiding: each module conceals a design decision that might change. Every conversation about microservices, APIs, or team boundaries is a conversation about Parnas's criteria whether participants know it or not. For product directors who shape how teams are organised around systems, this paper is not optional reading — it is the intellectual foundation of the decisions they make daily.