Understanding Software Architecture: History, Concepts, and Definitions

Programmers often aspire to become qualified architects, yet many struggle when facing higher‑level design challenges.

The article begins by tracing the evolution of software development: the earliest 1000100111011000 machine language, the introduction of assembly language such as mov ax,bx , and the emergence of high‑level languages exemplified by Lisp’s (+ 4 6) , each step reducing the difficulty of writing, reading, and modifying code.

Machine language is hard to write, read, and change.

Two software crises are described. The first crisis, caused by growing code size and complexity, led to structured programming and modular design. The second crisis, driven by rapid hardware advances and expanding business requirements, highlighted the limits of structured programming and gave rise to object‑oriented programming, though it too proved not to be a silver bullet.

The first crisis stemmed from overly complex software logic; the second crisis stemmed from overly complex software expansion.

Software architecture emerged not as a direct response to a new crisis but as a necessary evolution when system scale introduced new design problems such as massive internal coupling, low development efficiency, and difficulty in modification and extension.

Huge system scale leads to severe internal coupling and low development efficiency. Strong coupling makes changes ripple throughout the system. Complex logic causes hard‑to‑detect and hard‑to‑fix issues.

The article defines key concepts: a system is a set of related entities operating under rules to achieve capabilities beyond individual parts; a subsystem is simply a system that is part of a larger system. From a logical perspective, a module is a unit of responsibility, while a component is a physical, reusable unit.

It distinguishes framework (a set of conventions) from architecture (the structural organization), noting that statements like “the project uses an MVC architecture” refer to structure, whereas “the project uses an SSH framework” refer to conventions.

Different viewpoints produce different architectural descriptions, illustrated with a student management system broken down by business logic, physical deployment, and development structure (images omitted).

Finally, the article redefines architecture as the top‑level structure of a software system, emphasizing that it must specify the system’s constituent parts and the rules governing their interaction.

Software architecture is the top‑level structure of a software system.

In summary, architecture is a solution to software complexity, requiring careful judgment and trade‑offs among factors such as team experience, cost, resources, time, and business stage.