The essence of architecture, the way among thousands of methods

[[163803]]

Currently, there are more articles discussing architectural practice (techniques), but fewer discussing architectural concepts (Taoism). This article is based on the author's practice and thinking in the architecture of large-scale e-commerce systems. I would like to talk to you about architectural concepts, hoping to provide some inspiration and promote your understanding of architecture.

What is Tao and what is Shu? Tao is the essential law of the development of things, and Shu is the specific way of the development of things. There is only one law, but many ways. All roads lead to Rome. Rome is Tao, and the road is Shu. Tao is the basis, and Shu is the way. If you know where Rome is in advance, then there are roads everywhere, and all roads are connected. The same is true for architecture. If you can understand the essence of architecture, you will not stick to the existing practice and theoretical framework, but solve problems in the most direct way. No tricks are better than tricks. The content of this article includes the essence of architecture, the service objects of architecture, the architect's ability model, and the realm of architecture.

The essence of architecture

Any system, under natural conditions, goes from order to disorder. This is scientifically based. According to the second law of thermodynamics, all spontaneous processes in nature have directionality. An isolated system will go from order to disorder, that is, its entropy will continue to increase and eventually die. However, organisms can interact with the outside world, actively metabolize, and create "negative entropy" to ensure their own order and continue to survive.

Similarly, as a software system acquires more and more functions and the number of calls increases dramatically, the entire system gradually becomes fragmented and increasingly disordered, and ultimately becomes impossible to maintain and expand. Therefore, after a period of wild growth, the system also needs timely intervention to avoid becoming increasingly disordered.

The essence of architecture is to reconstruct the system in an orderly manner, continuously reduce the "entropy" of the system, and enable the system to evolve continuously.

So how does architecture achieve order from disorder? The basic method is to break up the system first and then reassemble it.

[[163804]]

The process of splitting is to split the system into various subsystems/modules/components. When splitting, we must first solve the positioning problem of each component, and then divide the boundaries between them to achieve reasonable splitting. Integration is to organically integrate the various separated components according to the final requirements. Relatively speaking, the first step of splitting is more difficult.

The result of the split enables developers to focus on business and skills and achieve agile development. The result of the combination is that the system becomes flexible and can change according to needs, thus achieving business agility.

For example, in the Web 1.0 era, HTML and script codes were mixed together in an ASP or JSP page. The more script codes there were, the more chaotic the system became (i.e., entropy increased), and eventually even the developers themselves could not understand it. At this time, the system needs to be restructured by introducing the view helper mode, separating HTML and scripts, with HTML becoming the view and the scripts becoming the helper class. Then simply integrate them together. By re-dividing and combining, the entire system has a clear hierarchy and clear responsibilities, and the system is less disordered and easier to expand. At the same time, developers with different skills, such as UED and programmers, can be responsible for different parts, effectively improving development efficiency.

A good architecture is like a beautiful piece of prose, which is scattered in form but not in spirit. It appears disordered on the surface but is actually highly ordered.

Architecture Classification and Service Objects

Architecture can generally be divided into business architecture, application architecture, and technical architecture. So what problems do they solve and who do they serve? Let's first look at the process of a system implementation:

For the developer, what they fear is that the business is too complicated, the code logic is too messy, and it is beyond their understanding, making the system unmaintainable. Therefore, the development requirement is that the overall concept of the system is clear, easy to understand, and easy to expand.

The machine responsible for running the system is afraid that the business concurrency is too large and the system core resources (such as database connections) are insufficient. It hopes that when the business volume increases, the system can support horizontal expansion and hardware fault tolerance (such as avoiding single point failure).

The pain points of development are mainly solved by business architecture and application architecture. Business architecture helps developers understand the system from a conceptual level (dynamic ones include business processes/nodes/inputs and outputs, and static ones include business domains/business modules/document models).

Application architecture helps develop and implement systems from a logical level (application type/application form/data interaction relationship/interaction method, etc.). The entire system is easy to understand logically. SOA, which has been talked about a lot recently, belongs to the category of application architecture.

The pain points of the machine are mainly solved by the technical architecture, such as the selection of the technical platform (operating system/middleware/equipment, etc.), and the deployment hopes to support multiple computer rooms, horizontal expansion, and no single point.

I want to emphasize that the system is a human system, and the architecture is first and foremost for human service. The first priority is to have clear business concepts, reasonable application logic, and good understanding by people (i.e., the system is highly ordered). Now people are more discussing technical architecture, such as high concurrency design, distributed transaction processing, etc., simply because this does not require business context and is easier to communicate with each other. When designing a specific architecture, you should first pay attention to the business architecture and application architecture, and novices should pay special attention to this architecture.

Architect Competency Model

Architects only do things like division and integration, but they have very high comprehensive ability requirements, requiring both internal and external skills, and being able to work in the kitchen and in the hall. The following figure introduces the ability requirements of an architect through a typical architecture method:

On this basis, architects must have both technical breadth (multi-field knowledge) and depth (technological foresight), have a very good understanding of the system design of mainstream companies, know their pros and cons, and be able to quickly evaluate multiple solutions when encountering practical problems.

Abstract thinking is the most important ability of an architect. An architect should be good at conceptualizing and classifying physical objects. For example, when facing a large B2C website, an architect can quickly abstract it into procurement->operation->front-end search->order->order fulfillment. This divides the system into several parts and makes the architect lose sight of the whole cow.

Abstract thinking is to summarize and sublimate at a high level, from the concrete to the imaginary; while looking through the problem to see the essence is to go from the imaginary to the concrete, digging deeper. For example, when you see a piece of Java code, you know how it is executed in the JVM; when you make a cross-network call, you know how the data reaches the target through various media (operating system kernel/network card port/electromagnetic medium, etc.). Looking through the problem to see the essence enables architects to keenly discover the reality of the bottom layer, think about the problem systematically end-to-end, identify the shortcomings of the barrel and solve them.

An architecture that can be implemented is a good architecture. Good communication skills ensure that all parties reach a consensus on the architecture and are willing to take action. Good balancing and trade-off capabilities ensure that the architecture is the most reasonable under the constraints of existing resources, and the ideal will eventually become reality.

In summary, the ability requirements of an architect include:

1. Has both technical breadth (multi-domain knowledge) and depth (technical foresight)
2. Possessing both height (abstract thinking) and depth (from problem to essence) of thinking
3. Combining sensibility (communication) and rationality (balance)

Architecture Realm

Architects can be divided into four levels from shallow to deep: the first is to see mountains as not mountains, the second is to see mountains as mountains, the third is to see mountains as not mountains, and the fourth is to see mountains as mountains.

When I first took over the project, I didn't understand the business and was often confused by the terminology used by the business side. If the existing problem is compared to a mountain, it is like a ridge from the front and a peak from the side. I can't understand it at all. At this time, the mountain is not a mountain.

After sorting out the business and gaining an in-depth understanding of the system, we can design a simple solution to connect the various systems together, solve the current problem, and see the whole picture of the current mountain. At this point, we can see the mountain as a mountain.

Through further abstraction, we can find the essence of the problem. It turns out that this problem is common and there will be many similar problems in the future. We can summarize and sublimate the design and come up with a universal solution that can not only solve the current problem but also solve potential problems. At this point, we can see the essence of the problem. We can see that the mountain is not the mountain.

Finally, we return to the problem itself and remove excessive abstraction. The design given is concise and clear. If we add one point, it will be too fat, and if we subtract one point, it will be too thin. This not only solves the current problem but also retains the most basic extension. At this point, the problem is still the same problem, and the mountain is still the same mountain.

I can’t come up with a suitable solution for the first realm, so I won’t discuss it.

Solutions at the second level only solve superficial problems and are often not well designed. If other similar problems arise or the problem is slightly distorted, the system needs to be redone.

Solutions in the third realm are often over-designed. Excessive pursuit of generalization will create too much abstraction and fabricated concepts that are difficult to understand and implement. At this point, the disorder of the system increases, and too much is as bad as too little.

The solution of the fourth level is to understand the nature of the problem, take into account the current situation, evaluate the future, and do neither more nor less.

Buddhism talks about emptiness and color. Color refers to the phenomenon of things, and emptiness refers to the essence of things. In this sense, the first level of realm is neither color nor emptiness, the second level of realm is beyond color, the third level of realm is beyond emptiness, and the fourth level of realm stands between color and emptiness, being both color and emptiness, not clinging to the present, nor being empty of the future.

Neither empty nor colored, both empty and colored, the Tao follows nature, the nature is Tathagata, and it is the essence of the structure.