A monolith is more than a deployment shape. In the enterprise software of the eighties and nineties, it could also express a belief that requirements, responsibilities, and change could all be arranged into a predictable sequence.
In Software Architecture Saga — Chant 2 — The Age Of Monoliths, I explore that relationship between process and structure. Waterfall promised control through successive phases. Layered applications gave that promise a recognizable form: presentation, business logic, and data, with clear territories and carefully managed handoffs.
The arrangement brought real strengths, including cohesive logic and transactional consistency. It also exposed the cost of assumptions that rarely survived contact with users: requirements would remain stable, communication would be exact, and a sufficiently complete design would prevent surprises. More hardware could relieve pressure without making the system easier to change.
The chapter follows the gradual search for flexibility through object-oriented design, patterns, and principles that loosen dependencies. Its central tension is between preserving useful cohesion and allowing a system to evolve without turning every modification into a struggle against the whole.
This second installment of the Software Architecture Saga looks at what the monolith taught us about consistency and control, and why its lessons still appear in contemporary frameworks. The original article carries the historical journey further, toward the ideas that made adaptation an architectural concern.