Mastering System Architecture: From Entropy to Order

What is Dao and what is Shu? Dao is the essential law governing the development of things, while Shu is the concrete approach to that development.

The law is singular, the paths are many; all roads lead to Rome, where Rome represents Dao and the roads represent Shu. Understanding the essence of architecture allows one to solve problems directly without being constrained by existing practices.

This article covers:

The essence of architecture

The objects served by architecture

The architect competency model

The levels of architectural mastery

Essence of Architecture

In natural systems, order inevitably turns into disorder according to the second law of thermodynamics; isolated systems increase entropy and eventually cease. Living organisms counteract this by exchanging with the environment to create negative entropy.

Similarly, a software system that continuously adds features and traffic becomes fragmented and disordered, eventually becoming unmaintainable. Architecture is the ordered reconstruction of a system, continuously reducing its entropy and enabling evolution.

The basic means to achieve order from disorder is “divide and combine”: first split the system, then recombine it.

The “divide” phase breaks the system into subsystems, modules, or components. Proper division requires first defining the purpose of each component and then establishing clear boundaries. The “combine” phase integrates the separated components according to the final requirements; the division step is generally more challenging.

Dividing enables developers to focus on specific business or skill areas, 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), clarifying responsibilities and allowing different specialists to work independently, thus reducing disorder and improving extensibility.

A good architecture is like a beautiful prose: its parts may appear scattered, but the underlying order is high.

Architecture Categories and Service Objects

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

Developers fear overly 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; they require horizontal scalability and hardware fault tolerance.

Business and application architecture address developers’ pain points: business architecture clarifies domain concepts, modules, and data models; application architecture defines logical layers, interaction patterns, and often includes SOA.

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

Ultimately, architecture serves people: clear business concepts, reasonable application logic, and understandable systems are paramount.

Architect Competency Model

Architects focus on dividing and combining, but they must possess a broad and deep skill set, combining technical expertise with strategic insight.

They should be excellent programmers, capable of handling code and system intricacies.

Beyond coding, they need breadth across multiple domains and depth in emerging technologies, understanding the trade‑offs of mainstream system designs.

Abstract thinking is crucial: the ability to conceptualize large systems (e.g., breaking a B2C site into procurement, operations, front‑end search, ordering, fulfillment) and to decompose problems effectively.

They must also drill down from abstraction to fundamentals, understanding how Java code executes on the JVM or how network calls traverse OS kernels, NICs, and physical media, enabling end‑to‑end problem solving.

Effective communication ensures consensus; balanced decision‑making keeps designs realistic within resource constraints.

Technical breadth and depth

High‑level abstract thinking and deep problem analysis

Empathy (communication) and rationality (balancing)

Levels of Architectural Mastery

Architects progress through four stages: “seeing the mountain is not a mountain,” “seeing the mountain is a mountain,” “seeing the mountain is not a mountain,” and “seeing the mountain is a mountain.”

At the first level, unfamiliar terminology makes the problem opaque (“the mountain is not a mountain”).

After business analysis and system understanding, a concrete solution emerges, clearly addressing the current issue (“the mountain is a mountain”).

Further abstraction reveals the problem’s generic nature, leading to a reusable design that solves both current and future similar issues (“the mountain is not a mountain”).

Finally, the solution is refined to be concise and balanced, solving the problem without over‑ or under‑design (“the mountain is a mountain”).

These stages mirror Buddhist concepts of form (color) and emptiness: the highest level integrates both, achieving natural, unobstructed architecture.