For programmers, the term "architecture" is a common one. If you aim to become an architect, a clear understanding of the concept of architecture is essential. Without it, your architectural proposals are likely to be riddled with flaws, resulting in frequent issues, which can negatively impact your interviews, career progression, and team leadership.

What Is Architecture?

According to Wikipedia, software architecture is an abstract description of a system's structures and the rules for constructing these structures. These structures include software elements, the relationships between them, and their properties.

In this definition, the key concepts are system, elements, and relationships.

System

In software architecture, a "system" refers to a complex whole composed of multiple interacting parts that work together to fulfill specific functions or tasks. Architecture design is an abstract description of such a system.

Elements

The "elements" are the basic units that constitute the system, generally including subsystems, modules, and components.

• Subsystem: A part of a larger system with specific functional responsibilities, often capable of operating independently. Each subsystem can contain multiple modules or components, typically organized around specific business domains or technical functions.

• Module: A logical unit in the software architecture that encapsulates a set of related functions or services. Modules interact with each other through well-defined interfaces, supporting high cohesion and low coupling.

• Component: A self-contained, programmable, reusable software unit that is independent of language. Components can be easily assembled into applications and represent the smallest unit of deployment.

Some people may be confused by the distinction between modules and components. Simply put, modules are divided from a business logic perspective, while components are reused from a technical perspective. An example will clarify their differences later.

Relationships

"Relationships" refer to the connections and interactions between various elements (e.g., subsystems, components, modules, classes) within the system. These relationships define how elements cooperate and how they collectively achieve the system's functionality.

Let’s take a New Retail SaaS system as an example to explain the concepts:

• Subsystems include: Online store subsystem, POS cashier subsystem, order management subsystem, product management subsystem, customer management subsystem, warehouse management subsystem, distribution subsystem, central inventory subsystem, customer service subsystem, purchasing subsystem, etc.

• The order fulfillment system can be divided into the following modules based on business dimensions: C-end fulfillment service module, order dispatch module, order management module, picking management module, shipping management module, reverse fulfillment module, etc.

• From a technical perspective, the order management module relies on technical components such as MySQL, Redis, Elasticsearch, and security components.

Each subsystem, module, and component may establish relationships to collaboratively complete the system’s functions.

Views and Perspectives in Architecture

In practice, you often hear phrases like:

• "The business architecture is too complex, we need to carefully sort it out."

• "This project is complicated and requires an architecture review."

• "For the flash sale event, we need a high-concurrency architecture solution."

• "Top tech companies use microservice architectures, I need to master microservices."

But what exactly do these references to architecture mean? Are these statements correct?

In fact, all these statements are correct; they just take different perspectives.

Complex systems involve various stakeholders, such as customers, product managers, developers, sales teams, operations, and management. Due to different backgrounds and understandings, each person views the system from a different angle and with a different method.

To manage complexity, we need to design a set of architectural artifacts, categorize and define them, ensuring each artifact emphasizes a specific focus. This allows each stakeholder to quickly access the information they care about.

To achieve this, we first need to understand the concepts of views and perspectives.

Architectural Perspectives

What is a perspective? In simple terms, it refers to where you stand to observe.

Let’s take a city system as an example. Standing on a city street, what do you see? You might see several buildings, rows of trees, a few roads, and bustling people.

But if you look from an airplane, what do you see? You might see blocks of buildings, mountains, rivers, and lakes. So, what you can see depends largely on where you are observing from, and this also affects the granularity of what you perceive.

If we compare a perspective to a coordinate point, it requires a coordinate system, typically involving four dimensions: breadth, depth, view type, and time.

• Breadth refers to how wide your perspective is. For example, when looking at business processes, you may need to consider the processes within a single department, collaboration across multiple departments, or end-to-end processes across the organization.

• Depth refers to the level of detail you want to observe. For example, in business processes, do you focus on organizational level, departmental level, or detailed steps for a specific role? In software systems, do you focus on system-level, module-level, or line-by-line code?

Breadth and depth generally affect each other. The broader the perspective, the more abstract the layers become. This is similar to organizational structures—high-level management focuses on the overall picture, while frontline employees understand the details but have a narrower view.

• View type: Tailored to stakeholders’ concerns, a set of viewpoints will be introduced below.

• Time: This dimension is simple; it’s about whether you are looking at the past, present, or future.

Architectural Views

What is a view? Simply put, it’s what you want to see.

A view is a set of concerns tailored for stakeholders.

Taking the city system example again, a commuter is concerned with the quickest route, so they need a subway or bus route map. A tenant looking for a place to rent will be interested in nearby neighborhoods and rent prices, requiring a rental map. Meanwhile, a worker looking to clear out a sewer would care about the sewer layout, requiring a sewer map.

For the same city system, different roles focus on entirely different aspects and seek different information. If all this information were lumped together without separating views, it would become too overwhelming for anyone to extract the information they need.

Similarly, different stakeholders in software systems have varying focus points. To separate these concerns, various software views emerged, such as the famous "4+1" views and TOGAF’s business architecture, application architecture, data architecture, and technical architecture.

Let’s focus on the TOGAF view types: Business Architecture, Application Architecture, Data Architecture, and Technical Architecture.

• Business Architecture: The foundation of the entire architecture, it represents the structured abstraction of an enterprise's business model, including business capabilities, end-to-end value delivery, information, and organizational structures.

• Application Architecture: Based on the business architecture, it outlines the hierarchical structure of application systems, including systems, applications, modules, components, and their interactions.

• Data Architecture: Describes models, policies, rules, and standards that govern how data is collected, stored, distributed, and used in the system and organization.

• Technical Architecture: Describes deployable software packages, hardware capabilities, and their relationships to support business, data, and application needs.

By distinguishing between views and perspectives, we can manage complexity, break down large problems, and keep each part’s complexity within a manageable range. At the same time, having a unified coordinate system allows teams to standardize business practices and quickly respond to changing business demands.