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.
Central argument
Parnas argues that the conventional method of decomposing a system into modules — following the sequential steps of its processing flow — is inferior to decomposing along lines of likely change. His key finding, demonstrated through a concrete example, is that each module should encapsulate a single design decision that might need to change, hiding it from the rest of the system. This principle of information hiding means that when a decision does change, only one module is affected, producing designs that are far more resilient to modification than flowchart-derived decompositions.
Critique
Parnas's criteria assume that designers can reliably anticipate which design decisions are likely to change — a significant epistemic burden that the paper does not fully reckon with. In practice, the decisions that change most disruptively are often the ones nobody predicted, and a decomposition optimised around expected volatility can still produce coupling along unexpected axes. The paper also treats the system's design decisions as essentially technical, leaving largely unexamined how organisational dynamics, team turnover, or shifting business strategy alter what 'likely to change' actually means over a product's lifetime.
Why it matters for product
When a product director decides how to split platform capabilities across teams, or where to draw API boundaries between services, they are making Parnas-style bets about what will change independently — and getting those bets wrong produces the coordination overhead and deployment coupling that slow delivery down. The paper's logic also applies directly to organisational design: a team that owns a module with a stable interface but a hidden, changeable interior is the structural equivalent of a well-encapsulated component, and Conway's Law means the two cannot be designed separately. Understanding information hiding at this level helps product leaders diagnose why certain architectural or team structures generate chronic friction, rather than treating those symptoms as execution problems.