What Is Software Architecture? Definitions, Types, and Design Principles Explained

In the software industry, there is much debate about what architecture means, with each author offering different definitions. Before discussing architecture, we first need to define the concept because differing understandings hinder communication. This article summarizes the concept based on various sources.

1. What Is Architecture

Linux has an architecture, MySQL has an architecture, the JVM has an architecture, and a business system built with Java on Linux also has an architecture. To clarify which one to focus on, we need to understand related concepts: system vs. subsystem, module vs. component, framework vs. architecture.

1.1 System and Subsystem

System : a group of related entities that operate according to certain rules to achieve capabilities that individual elements cannot accomplish alone. Key ideas:

Association: a system consists of related entities; unrelated entities placed together do not form a system (e.g., an engine and a PC are not a system, but an engine, chassis, tires, and frame form a car).

Rules: entities must follow defined rules, determining division of labor and collaboration (e.g., an engine generates power, which is transmitted to wheels via gearbox and driveshaft).

Capability: a system’s capability is more than the sum of its parts; it creates new abilities (e.g., a car can carry loads, which individual parts cannot).

Subsystem : a system that is part of a larger system.

1.2 Module and Component

Both are parts of a system, viewed from different angles. A module is a logical unit, while a component is a physical unit.

A module decomposes a system logically to simplify complex problems. Granularity can vary: a system, several subsystems, a service, a function, a class, a method, etc. The main purpose is responsibility separation.

A component can include application services, databases, networks, physical machines, as well as MQ, containers, Nginx, etc. Its purpose is unit reuse. The term "component" corresponds to the Chinese "零件" (part), emphasizing independence and replaceability.

1.3 Framework and Architecture

A framework usually refers to a software component specification that implements an industry standard or basic task, providing foundational functions required by the specification.

Examples: MVC, MVP, MVVM are frameworks; Ruby on Rails, Spring, Laravel, Django are open‑source frameworks that can be used directly or extended. Spring MVC, for instance, satisfies MVC conventions and provides annotations, Spring Security, Spring JPA, etc.

The distinction: a framework focuses on "specification", while architecture focuses on "structure".

Framework = Framework (e.g., Spring MVC is a "Web MVC Framework").

Architecture = Architecture (e.g., Linux operating system architecture).

TOGAF9 defines architecture as the formal description of a system’s components (subsystems, modules, components) and their relationships, including governance principles for design and evolution.

Architecturally, the term originates from ancient building terminology: "架" (to add/assemble) and "构" (structure). Thus, architecture is the structured connection of "wood" (components) into a "building" (system).

In software, "wood" represents architectural elements (subsystems, modules, services, components). The "structure" is the architecture’s product, defining how elements are connected via interfaces, integration mechanisms, distributed calls, etc.

In summary, architecture = elements + structure + connections. It is the top‑level structural design of a software system, a rational decision made after systematic thinking, trade‑offs, and resource constraints, resulting in a clear system skeleton (subsystems, modules, components) and their collaborative relationships, constraints, and guiding principles.

2. Purpose of Architecture Design

Without architectural design, a system is likely simple. As business grows, a monolithic application evolves into distributed and micro‑service architectures, increasing complexity and team size. Lack of architecture leads to chaos, causing issues such as unclear service boundaries, severe coupling, difficulty tracing problems, insufficient monitoring, and uncontrolled technology stacks.

The purpose of architecture design is to address complexity, providing orderly restructuring that aligns with business growth and enables rapid expansion. The four aspects involved are:

Systematic thinking for rational decisions (technology selection, implementation plans, cost evaluation).

Structure: clear system skeleton (which subsystems, modules, components exist).

Connection: how components collaborate to fulfill business requests.

Constraints and guidelines: principles ensuring orderly, efficient, and stable operation.

3. Architecture Classification

Two common methods: RUP 4+1 and TOGAF9. RUP 4+1 focuses on lifecycle views; TOGAF9 classifies by content dimensions. Combining both yields Business Architecture, Application Architecture, Data Architecture, Technical Architecture, Code Architecture, and Deployment Architecture.

RUP 4+1 Views

Introduced by Philippe Kruchten (1995). The five views are Logical, Development, Physical, Process, and Scenarios, each supporting different design decisions.

TOGAF9 Classification

TOGAF (The Open Group Architecture Framework) provides methods and tools for enterprise architecture. It defines Business Architecture (strategy), Application Architecture (tactics), Data Architecture, Technical Architecture, Code Architecture, and Deployment Architecture.

1. Business Architecture (Strategic)

Defines business planning, modules, processes, and domain models, turning real business into abstract objects. It includes strategy, current capabilities, future capabilities, and both business and IT capabilities.

2. Product Architecture

Focuses on enumerating product functions and defining module boundaries, organizing functional modules around specific business goals.

3. Application Architecture (Logical)

Describes which applications exist and how they integrate, bridging business and technical layers. It defines responsibilities, interfaces, and collaboration mechanisms.

4. Data Architecture

Guides database design, covering both logical models and physical storage considerations.

5. Code Architecture (Development)

Provides concrete guidance for developers, defining code units (configuration, frameworks, libraries) and organization (coding standards, module division, top‑level structure, dependencies). The "Alibaba Java Development Manual" is a good reference.

6. Technical Architecture

Specifies the actual runtime components (LVS, Nginx, Tomcat, etc.), their relationships, deployment strategies, and non‑functional requirements such as high availability, performance, scalability, security, and simplicity.

7. Deployment Topology Architecture

Shows node count, relationships, high‑availability, network interfaces, and protocols, focusing on operational concerns.

4. Architecture Levels

The pyramid model shows that higher levels contain lower ones: system level, application level, module level, and code level.

System level: relationships and governance across the whole system (layering).

Application level: overall architecture of a single application and its relation to the system.

Module level: internal module architecture, code modularization, data/state management.

Code level: ensuring architecture implementation from the code perspective.

Strategic vs. Tactical Design

Strategic design (business architecture) guides how to design system architecture. Tactical design (application architecture) follows the business blueprint, leading to technology selection and implementation.

5. Evolution of Application Architecture

Business architecture is the production force, application architecture the production relationship, and technical architecture the production tool. Architecture evolves from monolithic → distributed services → micro‑services.

5.1 Monolithic Applications

Suitable for simple early‑stage business. Typical three‑tier architecture (frontend, middle‑logic, database) using Java Spring MVC or Python Django.

Non‑functional improvements include caching, clustering, read/write splitting, reverse proxy/CDN, distributed files/databases.

Drawbacks as the system grows: high complexity, technical debt, low deployment frequency, reliability issues, limited scalability, and hindered innovation.

5.2 Distributed Applications

When business depth and breadth increase, monoliths become unwieldy. Splitting into services reduces coupling, clarifies responsibilities, eases scaling, and simplifies deployment.

5.3 Micro‑services

Further decomposition into fine‑grained services that focus on single business capabilities, enabling faster development, independent deployment, technology heterogeneity, but also introducing higher operational overhead, distributed complexity, API change costs, and potential code duplication.

6. Measuring Architecture Reasonableness

Architecture serves business; there is no "best" architecture, only the most suitable. Reasonableness is judged by efficiency, stability, and security.

6.1 Business Perspective

Solves current business needs.

Efficiently fulfills requirements with reusable solutions.

Forward‑looking design that remains viable for future growth.

6.2 Non‑Business Perspective

Stability: high availability, thorough testing (unit, integration, fault injection).

Efficiency: documentation, extensibility, high reuse.

Security: data protection via encryption, HTTPS, etc.

7. Common Architecture Pitfalls

Over‑ambitious designs that never materialize.

Missing critical constraints and non‑functional requirements.

Over‑designing for an imagined future.

Premature critical decisions.

Blindly following client demands.

Lack of foresight while executing.

Ignoring testability.

Attempting to achieve everything in one step.

Misconception 1 : Only architects should care about architecture; developers need not.

Architecture must be realized in code; every component must be solid, otherwise the system risks collapse.

Misconception 2 : Once the blueprint is set, the architect’s job is done.

Architects must stay involved to ensure the design can be grounded in reality.

Misconception 3 : No work begins until a perfect architecture is produced.

There is no perfect architecture; iterative evolution (single‑wheel → bicycle → motorcycle → car) is essential.

Misconception 4 : Over‑design for an uncertain future.

Early‑stage startups need rapid iteration; excessive future‑proofing can waste time.

Misconception 5 : Blindly copying solutions from large companies.

While large‑company practices are valuable, blindly imitating them can lead to misalignment with your own context.

Misconception 6 : Technology for technology’s sake.

Technology should serve business goals; choosing trendy tools without business justification can complicate the architecture.

8. Recommended Architecture Books

"Large‑Scale Website Architecture: Core Principles and Case Studies" – a comprehensive, easy‑to‑understand overview.

"Core Technologies of Billion‑Scale Websites" – detailed implementation techniques and code snippets.

"Architecture Is the Future" – explores the root causes of architectural problems and team management.

"Distributed Service Architecture: Principles, Design, and Practice" – practical guide to building reliable micro‑service systems.

"Talking About Architecture" – discusses business decomposition, architecture purpose, and the architect’s role.

"12 Practices of a Software Architect" – focuses on soft skills and personal development for architects.

Author: guisuhuang Source: Tencent Technology Engineering