Uncovering the True Essence of Software Architecture: From Machine Code to Modern Design

1. Machine Language

The earliest software was written in machine language, using binary code (0 and 1) to represent instructions and data. For example, moving the content of register BX to AX is expressed as:

1000100111011000

Too difficult to write, too difficult to read, too difficult to modify!

2. Assembly Language

Assembly language was created to alleviate the difficulties of machine code by using mnemonic symbols for opcodes and labels for addresses. The same BX‑to‑AX operation becomes:

mov ax,bx

Assembly language still depends on specific CPU instruction sets, requiring multiple code versions for different processors.

3. High‑Level Languages

High‑level languages abstract away low‑level details, allowing programmers to focus on business logic. For example, the addition 4 + 6 in Lisp is written as: (+ 4 6) These languages are compiled into machine code for various CPUs, so a single source can run on many platforms without rewriting.

4. Two Software Crises

First Software Crisis & Structured Programming

The rise of high‑level languages led to larger, more complex software, causing quality, schedule, and cost problems (e.g., the 1963 FORTRAN error that caused a rocket failure). Structured programming emerged as a response, emphasizing top‑down design, stepwise refinement, and modularization.

Second Software Crisis & Object‑Oriented Programming

As hardware advanced and business requirements grew, software complexity shifted from logical intricacy to extensibility challenges. Object‑oriented programming addressed the “extension” problem by introducing objects, yet it proved not to be a silver bullet.

First crisis: software logic became overly complex. Second crisis: software extension became overly complex.

5. Emergence of Software Architecture

When system size grew, algorithmic concerns receded and the organization of many components became the primary design issue. Architecture arose to tackle problems such as massive scale, severe coupling, and intricate logic that hinder maintenance and evolution.

Huge system scale leads to low development efficiency. Severe coupling makes changes ripple throughout the system. Complex logic causes bugs that are hard to locate and fix.

Architecture introduced the concepts of modules, objects, and components, each representing a higher‑level decomposition as software complexity increased.

System vs. Subsystem

A system is a group of related entities that operate under rules to achieve capabilities beyond the sum of its parts. A subsystem is essentially a system that exists as part of a larger system.

Association: entities must be related to form a system. Rules: entities follow defined coordination mechanisms. Capability: the system exhibits abilities not present in individual entities.

For example, WeChat is a system containing subsystems such as chat, login, payment, and moments; each of those contains further subsystems.

Module vs. Component

Modules are logical partitions aimed at responsibility separation, while components are physical units intended for reuse. Components (or “parts”) are independent and replaceable.

Framework vs. Architecture

A framework defines conventions (the “norm”), whereas architecture defines the structural organization of a system. Statements like “the project uses an MVC architecture” refer to structure; “the project uses an SSH framework” refer to conventions.

Redefining Architecture

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

Architecture must identify the individual parts (subsystems, modules, components) and the rules governing their interaction.

Summary

Architecture is a solution to software system complexity, requiring careful judgment and trade‑offs based on constraints such as team experience, cost, resources, timeline, and business stage.