Software architecture began before we had a settled name for it. Limited memory, costly machines, and the practical work of keeping programs running shaped systems long before components and connectors became subjects for textbooks.
In Software Architecture Saga — Chant 1 — The Epopee Begins…, I open the series with that early history. Mainframes and tightly integrated applications offered efficiency and control, but growing projects exposed the limits of relying on individual craftsmanship and intimate knowledge of every part.
The chapter follows two paths that gradually meet. One is the effort to bring discipline to development through software engineering and modular design. The other is the everyday composition of smaller programs through scripts, pipes, and job scheduling. Both question how much responsibility a single body of code should hold.
From there, the journey moves through the arguments over operating-system kernels and the arrival of client-server systems. Separating presentation, logic, and data changed the problems developers had to solve: communication and boundaries became as important as internal execution.
The first chant introduces architecture as a response to constraints and accumulated experience. The full article traces how those responses became a formal discipline, setting up the next chapter’s examination of monoliths and the persistent tension between cohesion and change.