Understanding the Essence of Software Architecture: Principles, Service Objects, and the Architect’s Capability Model

There are many articles discussing concrete architectural practices, but few that address the philosophical side of architecture. Based on the author’s experience with large‑scale e‑commerce systems, this piece shares thoughts on the essence of architecture, its service objects, the architect’s capability model, and levels of mastery.

Essence of Architecture

In nature, systems tend to move from order to disorder according to the second law of thermodynamics. Biological systems counteract this by exchanging entropy with the environment. Similarly, a software system accumulates entropy as features grow and traffic increases, eventually becoming fragmented and unmaintainable. Architecture’s essence is to reorganize a system, continuously reducing its entropy and guiding its evolution.

The primary mechanism is “divide and combine”: first split the system into subsystems/modules/components, then recombine them according to the final requirements. The division step is usually harder.

Dividing enables developers to focus on specific business or skill domains, achieving development agility; combining yields a flexible system that can adapt to changing needs, achieving business agility.

For example, in the Web 1.0 era an ASP or JSP page mixed HTML and script code, increasing entropy. Introducing a view‑helper pattern separates HTML (view) from script (helper), then recombines them, resulting in clearer layers, defined responsibilities, lower disorder, and easier extensibility. Different specialists (UED, programmers) can work on their parts, improving efficiency.

A good architecture resembles a beautiful prose: the form may appear scattered, but the underlying structure is highly ordered.

Architecture Classification and Service Objects

Architecture can be divided into business architecture, application architecture, and technical architecture, each serving different concerns.

Developers worry about complex business logic and tangled code that hinder maintenance; they need a clear overall system concept that is easy to understand and extend.

Operations teams worry about high concurrency and insufficient core resources (e.g., database connections); they need horizontal scalability and hardware fault tolerance.

Business and application architectures address developers’ pain points: business architecture clarifies concepts (processes, domains, models), while application architecture defines logical layers, interaction patterns, and data flows (e.g., SOA).

Technical architecture solves operations’ pain points: platform selection, multi‑datacenter deployment, horizontal scaling, and eliminating single points of failure.

Remember, a system is ultimately a system for people; clear business concepts, reasonable application logic, and human‑friendly design are paramount. Technical discussions (high‑concurrency design, distributed transactions) dominate because they lack business context and are easier to communicate, but architects should first focus on business and application layers.

Architect’s Capability Model

An architect’s work is essentially “divide and combine,” yet the role demands a broad and deep skill set, both technical and non‑technical.

Key capabilities include:

Broad technical breadth across multiple domains and deep, forward‑looking expertise.

Strong abstract thinking to conceptualize large systems (e.g., breaking a B2C site into procurement, operations, front‑end search, ordering, fulfillment).

Ability to see the essence behind problems, such as understanding how Java code executes on the JVM or how a network call traverses OS kernels, NICs, and physical media.

Practical implementation skills, effective communication to achieve consensus, and balanced decision‑making within resource constraints.

Levels of Architectural Mastery

Architects progress through four stages, metaphorically described as “seeing the mountain”:

First stage: unable to grasp the business, seeing the mountain as not a mountain.

Second stage: can describe the current problem clearly, “seeing the mountain as a mountain.”

Third stage: abstracts the problem to its essence, recognizing patterns that apply to many situations, “seeing the mountain as not a mountain.”

Fourth stage: returns to the concrete problem with a concise, balanced solution that addresses present needs while allowing future growth, “seeing the mountain as a mountain.”

Each stage has its pitfalls: the first offers no solution; the second solves only surface issues; the third over‑engineers with excessive abstraction; the fourth delivers a minimal, well‑balanced design.

In Buddhist terms, the first stage lacks both form and emptiness, the second over‑emphasizes form, the third over‑emphasizes emptiness, and the fourth harmonizes both, embodying the natural way of architecture.

Original source: 代码说

Long‑press the QR code to open in a browser.

Download the online course app for Android and iOS.

Qunar’s latest and hottest video courses are all here!