What Is System Architecture? A Simple Formula to Master Its Core
This article breaks down the concept of system architecture, derives a concise formula—elements plus connections plus solving specific problems—and explores its classifications, characteristics, and practical implications for designing coherent, goal‑oriented software systems.
1. Deriving the System Architecture Formula
1.1 Decomposing the Concept of System Architecture
When learning a technology you need to know what it is, why it exists, and how to apply it. "System architecture" is a broad concept with many definitions, which can confuse beginners. The article starts from the four Chinese characters "系统架构" (system architecture) to derive its formula.
"System" is defined as a set of interrelated, interdependent elements forming an organic whole with a certain structure and function. From this we get two points: the whole‑part relationship and structural nature.
"Architecture" (or software architecture) is an abstract description of a software system’s overall structure and components, used to guide design. The key term is "abstract description"—architecture reflects the relationships among system components.
Conclusion 1: System architecture describes the relationships between system elements.
1.2 The System Architecture Formula
Analyzing further, the word "架构" can be split into "架" (to add, wood) and "构" (structure). Thus, architecture is "connecting wood (elements) in a certain structure". Several questions arise:
What is "wood"?
What is structure?
How are they connected?
Answers in the software context:
"Wood" refers to the elements of a system.
"Structure" is the product of architecture, created to solve specific scenarios.
"Connection" is the process of organically linking the elements, following a method rather than random linking.
Conclusion 2: System Architecture = Elements + Connections + Solving Specific Problems
1.3 Deepening the Formula
In words, system architecture is about solving a specific problem by identifying system elements and combining them through appropriate means.
The three key questions are:
Solving specific problems: Identify the current main contradiction (e.g., high‑concurrency read/write bottleneck on a single database) and address it.
System elements: Elements vary by architecture type—business, application, data, technical, security, etc. For a technical architecture, the element might be a database; for a business architecture, it could be business components.
Element combination: Combine elements according to rules (e.g., separate read/write databases, sync via binlog) following hierarchical principles.
2. Classification of System Architecture
2.1 Specifying the Architecture Type
When discussing system architecture, you must specify the type (business, technical, etc.) to avoid misunderstandings, as each type emphasizes different aspects.
Conclusion 3: Always specify the architecture type to ensure consistent understanding.
2.2 Types of System Architecture
System architecture can be viewed from multiple angles to achieve a comprehensive understanding. It is not abstract; it considers both top‑level concerns and concrete implementation details.
Common categories include business architecture, application architecture, data architecture, technical architecture, security architecture, and deployment architecture. TOGAF describes four main types:
Business Architecture: Defines business strategy, governance, organization, and key processes.
Data Architecture: Describes logical and physical data assets and their management structures.
Application Architecture: Describes the structure and interaction of applications.
Technical Architecture: Describes the logical software and hardware capabilities needed to support business, data, and application services, including infrastructure, middleware, networking, and standards.
Thus, specifying the architecture type matters because each type has different focal points—business architecture emphasizes vision and processes, while technical architecture focuses on the technology components that solve real problems.
3. Characteristics of System Architecture
From the formula "System Architecture = Elements + Connections + Solving Specific Problems", we derive three key characteristics:
Goal‑orientation: The solved problem serves as a lighthouse guiding design.
Decomposability: The whole‑part relationship allows the system to be broken down for focused research or parallel work.
Layered nature: Architecture is organized in layers (e.g., scenario layer, business capability layer, business model layer, dependency layer), similar to network protocols or computer system structures.
Understanding these traits helps create orderly, well‑structured architectures rather than chaotic ones.
4. Perspectives from Others
Many definitions echo the same idea: system architecture is the description of components and their interactions, a collection of important decisions, or a process of splitting and recombining.
5. Summary
This article introduces the fundamentals of system architecture, presenting a simple formula to clarify the concept. While it does not cover implementation details, grasping this definition lays the groundwork for future articles that will explore practical application.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
ITFLY8 Architecture Home
ITFLY8 Architecture Home - focused on architecture knowledge sharing and exchange, covering project management and product design. Includes large-scale distributed website architecture (high performance, high availability, caching, message queues...), design patterns, architecture patterns, big data, project management (SCRUM, PMP, Prince2), product design, and more.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.
