What is architecture, what is the essence of architecture

Whether we are developers or architects, we all work with software systems all the time, and architecture is one of the most frequently used terms in our work. So, what exactly is architecture? You may or may not have an answer. The understanding of "architecture" requires us to constantly think, summarize, and deduce in practice to form our own cognition.

1. What is software architecture

It is very difficult to define "what is the architecture". Different organizations have different definitions of software architecture, and everyone also has their own understanding of the definition of system architecture. Just like we can't express the model 100%, but can only produce views of different dimensions of the model, it is impossible to fully define the architecture.

As the saying goes, "Tao can be Tao, very Tao. Name can be named, very famous". This is also the definition or elaboration of "what is architecture" from different perspectives by different organizations and individuals in the industry.

The following is the definition of software architecture by the IEEE organization:

the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution         --ANSI/IEEE

The system architecture is defined as: Architecture is the combination of system organization structure + components and connections (between components and between components and the environment) + principles. Express the architecture definition in a graphical form as shown in the figure below. This is a very concise and conceptually clear definition, which succinctly expresses several core elements of the architecture:

• Organization of the system: expressing the macrostructure of the system
• Components and connections: Component thinking, while highlighting environmental elements. Components express the modularity of the system, and the association between components and between components and the environment expresses the interaction between elements.
• Principles: Principles used to guide the design and evolution of the system

Master Martin Fowler has a more succinct abstraction for the definition of architecture. Martin Fowler believes that software architecture is: important and difficult to change decisions . Architecture design is an art of trade-offs. The architecture design process is full of various decisions, and these decisions will eventually be reflected in the system architecture.

And Ralph Johnson has a more "generalized" definition of architecture: software architecture is important, no matter what it is!

The above definition gives an answer to what is architecture from a high-level abstract perspective. In contrast, Neil Ford starts with the elements of architecture and elaborates on architecture from a more practical perspective. The core idea is that the architecture of a software system consists of the following combined elements:

• Structure: the architectural style chosen by the application system, such as microservice architecture, monolithic architecture, or SOA, etc.
• Architectural properties: non-functional properties of the system, such as performance, availability, maintainability, etc.
• Architectural Decisions: Important architectural decisions in the system design process
• Design principles: guiding principles in the design process

structure

Structure is an important part of the system architecture, which describes the structural composition of the system from a macro perspective. One of the core tasks of architectural design is to choose the appropriate architectural style for the system. For example, based on contextual trade-offs, architects can choose a modular monolithic architectural style or a microservice architectural style.

Schema properties

Architectural attributes, also known as quality attributes, or non-functional attributes, usually represent a certain "capability" that the system needs to have or meet, such as high performance, scalability, elasticity, scalability, fault tolerance, testability, maintainability, etc. wait. The goal of architecture design needs to focus on the architectural attributes that the system needs to satisfy, and the architecture should ultimately reflect the relevant architectural decisions that support the architectural attributes. There are many architectural attributes, and the system needs to pay attention to a subset of these architectural attributes. The architectural attributes that need to be paid attention to in a specific architecture design need to be specifically analyzed according to the context of the problem domain. At the same time, there may be conflicts between different architectural attributes, which also require the architect's trade-offs and decisions.

architectural decisions

Architectural decisions are the choice of solutions during system architectural design, which describe the rules that the system must follow. Architectural decisions come naturally with trade-off analysis, which is one of the important dimensions of system architectural design. Not all decisions are architectural decisions, architectural decisions should focus on the parts that have a significant impact on the system. For example, the choice of architectural style has an important impact on the system, and the cost of its change is relatively high, which should belong to the category of architectural decision-making. Typical architectural decisions include, but are not limited to:

• Directly affects high-priority architectural properties
• Modify the external interface: The modification of the externally provided interface often requires a full impact analysis
• Introduce or remove dependencies: the addition and removal of dependencies often marks the introduction and abandonment of component capabilities
• Change the general structure of the system: engineering structure is one of the important dimensions of application architecture
• Forcing developers to change the way they develop
• Accept strategic technical debt: Technical debt with a high impact on refactoring tends to have a large impact on existing systems

Design Principles

Design principles differ from architectural decisions in that the essential difference is that design principles are guidelines, not mandatory rules. Architectural decisions need to be followed, and design principles provide informative guidelines.

For example, the design principle may be: where possible, use asynchronous message mechanisms for cross-system communication to improve performance and reduce coupling.

The above definitions of architecture have their own characteristics:

• IEEE definitions are more structured and standardized
• Martin Fowler's definition focuses on the importance of architectural decisions
• Ralph Johnson is more general, highlighting the core factor of "importance"
• Neil Ford is more figurative

Personally, I prefer Ralph Johnson's abstract definition of architecture, which is simple but does not lose the essence of architecture. This is also one of the criteria for judging the boundaries of architecture in my work.

2. Boundaries of architectural design

If you are the architect of the team, do you have the following confusion:

• To what granularity should the system architecture be designed?
• Does the architectural design need to be detailed enough to directly guide developers in their coding efforts?

If you are the core developer of the team, have you ever "complained":

• "Architecture design" is too detailed, covering the "details" of implementation, and there is no room for it except CRUD.
• "Architecture design" is too macro, based on the design scheme, it can't guide the development at all, and you have to redesign it yourself.

In fact, many architects themselves lack a deep understanding of the boundary between architecture and design. Compared with narrowing the boundary of architecture, the boundary of architecture design often enlarges: architects regard architecture design as a detailed technical solution Design, firmly control all the details of the system implementation, produce a large number of design documents, and then hand over to the core developers to do the execution of the code implementation .

This phenomenon can lead to problems such as:

• Compress the design space of the core developers of the team, which is not conducive to the improvement of their technical level and cognition
• As an architect, can you really cover all the details? Even if a "complete" design is completed with great effort, can the various scenarios faced by front-line developers be predicted and captured in advance?
• If the requirement iteration continues like this, most of the core developers will have "complaints"
• As a team architect, the energy is limited, and the continuous output of details will consume a lot of energy, and cannot pay attention to the more macro level
• …

What is the root of the above problem? The boundaries of architectural design cannot be clarified! So how to solve this problem? Clarify the relationship between architecture and design!

All architecture is design, but design is not necessarily architecture! Looking at the boundary of architecture design from the definition of architecture, select two perspectives:

• Architecture is what matters in the system, whatever it is (important because of the high cost of change)
• Architectural design covers important architectural decisions in the system

Therefore, architectural design should cover the important things in the system. These "important things" may be:

• Choice of application architecture style
• Ways of Information Communication Between Subsystems
• The layering and interlayer constraints adopted by the project
• The development specification that the project should follow
• The third-party class library introduced by the project, or the third-party framework
• High-priority architectural attributes: For example, a certain requirement construction is very concerned about system performance, or architectural attributes such as scalability
• Other "important stuff"

Architecture design covers important architectural decisions required by the system, and guides system implementation from a macro level. The detailed design provides guidance for specific development and implementation, such as detailed ER diagram design, specific code-level mode selection, specific implementation of a component, and so on.

The architecture is not static and requires continuous evolution, and the implementation-related design may also continue to change during the project. Therefore, the two cannot be completely separated, but two-way feedback is required during the implementation process:

• Architectural design information should be efficiently synchronized to developers
• Changes in the implementation process also need to be fed back to the architecture so that the architecture design can be adjusted

Pay attention to a crucial factor when making architectural boundary judgments: context! ! ! The above judgment criteria must have value in a given context. For example: In the implementation process, we often apply some design patterns, such as strategy patterns. So, does the choice of this design pattern belong to architectural design or detailed implementation design? The answer is: It depends!!! Specific circumstances, specific analysis.

If in the current context, we are very concerned about the scalability of the system, and this architectural attribute is our high-priority architectural attribute, then the application of the strategy pattern of the core module can be regarded as the category of architectural design. And if scalability in the context is not a high-priority architectural attribute we care about, and we pay more attention to performance than we do, then this kind of code-level design pattern selection should fall outside the scope of architectural design, and need to be divided into implementation design The level is left to the core development to decide independently.

3. Architecture pattern and architecture style

Architectural patterns and architectural styles are two concepts that are easily confused. Many developers understand them as the same thing, but in fact they are fundamentally different.

• Architectural style is the top-level abstraction of system design, expressing our system composition from a macro perspective. Going a step further, architectural styles focus on the layers, modules, and interactive forms of the system.
• Architectural patterns focus on providing solutions to recurring problems

The two concepts are different and there is no conflict. The connection is shown in the following figure:

• Architectural patterns can be applied to architectural styles, and one or more architectural patterns can be applied within the same architectural style context
• Architectural styles can be combined to produce new architectural styles

A typical example is CQRS: CQRS itself is a pattern that separates the responsibilities of commands and queries in different dimensions. We can use this mode in the monolithic architectural style, or in the microservice architectural style, and of course, in the SOA architectural style.

4. Knowledge Model for Developers and Architects

As a developer, pay more attention to the depth of knowledge in order to have enough knowledge reserves to meet work needs. Early in their careers, developers should focus on growing their knowledge base and maintaining technical depth.

As an architect, the breadth of technology is more important than the depth, because one of the architect's important responsibilities is to make architectural decisions. System architecture design is an art of trade-offs. In a specific problem domain context, architects need to make trade-offs and make decisions among many feasible solutions, which also raises requirements for their technical breadth. As developers grow into architects, they should pay more attention to the breadth of knowledge and cultivate in several specific areas so that they have enough knowledge to support architectural decisions.

Although developers and architects have different concerns in the domain of knowledge, they can be unified into the Bloom cognitive hierarchy model at the cognitive level. The model divides cognitive levels into six progressive levels:

• Memorization: Recognizing and recalling factual knowledge
• Comprehension: understand the connotation of facts
• Apply: apply facts, rules, concepts, ideas
• Analysis: breaking down information, correlating, differentiating, experimenting, testing
• Evaluate: Evaluate the value of information or ideas
• Creation: Integrating different information to form a new knowledge system

Whether you are an architect or a developer, the Bloom Cognitive Hierarchy Model applies. Expand your own knowledge system through continuous learning. While memorizing, understanding and applying, you must continue to cultivate the ability to analyze, evaluate and create, and gradually improve to a high-level cognitive level. But it should be noted that knowledge is not equal to cognition, so avoid falling into the trap of knowledge learning. Knowledge is unlimited, and no one can learn unlimited knowledge with limited energy. Whether you are a developer, an architect, or any other role, you should not only devote your energy to the expansion of knowledge boundaries, but should focus on the transformation from knowledge to cognitive improvement.

As the sage Zhuangzi said: My life has a limit, but knowledge has no limit. If there is a limit, follow the limitless, it is almost dead! Those who are already knowledgeable are almost done!

Investigate things to gain knowledge, continuously summarize and deduce the appearance to the original image of things, explore the laws behind things, and establish a higher level of cognition. There are two ways for this cognitive level to rise from bottom to top:

• Enlightenment: From the inside to the outside, through continuous accumulation and continuous thinking, from quantitative change to qualitative change, until "enlightenment"
• Breaking: From the outside to the inside, high-level or different thought input collides to accelerate the breakthrough of the cognitive level

V. Conclusion

The discussion on the definition of architecture is actually a simple process of "searching things", and everyone should find their own answers. Breaking away from the perspective of discussing the definition of architecture, isn't everyone's work and study the same? ! From the avenue to the simplicity, different routes lead to the same goal, study things to gain knowledge, and encourage you together!