Mastering Software Architecture: A Step-by-Step Design Process and Data Strategies

1. Software Architecture Design Process

Software architecture design lacks a universal methodology and remains an emerging field; the following is a personal interpretation of the process for reference.

1. Business analysis: Analyze industry business strategy, blueprint, functions, and processes to identify which functions can be handled by information systems, thereby defining the problems to be solved.

2. Solution design: Based on the business strategy, create an industry information solution that clarifies the supporting relationships among systems.

3. System function design: Define a list and hierarchy of system functions (e.g., decision‑making layer, management layer, operation layer) and group them into one or more subsystems.

4. System architecture design: Define the IT support expression, hierarchical relationships, and core functional and technical elements for each system.

5. Technical system design: Design interfaces, data storage, technology stack, deployment, and abstraction for implementation.

2. System Overall Architecture Design

Several common architecture patterns are introduced:

ASSF (access‑service‑standard‑foundation) pattern : Organizes the system as Access → Service (business) → Standard → Foundation. The deployment model requires separate description.

Location pattern : Suited for group‑level applications, offering clear logical expression of application logic.

3‑management‑level pattern : Shows decision, management, and operation layers, facilitating clear functional expression and stakeholder alignment.

The author recommends using the ASSF pattern as the main architecture, supplemented by Location and 3‑management‑level patterns for additional detail.

3. Data Distribution Design in System Architecture

Six common data distribution strategies are presented:

Independent Schema : Separate schemas for each subsystem, offering high manageability and low communication overhead.

Centralized : Consolidates data from multiple subsystems into a unified format, improving manageability and consistency.

Partitioning : Horizontal partitioning for geographically distributed users; vertical partitioning (field‑level) is less common but offers scalability.

Replication : Maintains multiple copies of data across nodes with consistency mechanisms, enhancing reliability.

Subset : A special form of replication where a node keeps a relatively fixed subset of the full data.

Reorganization : Different nodes store data using different schemas to support varied functions, though the data originates from the same source.

These strategies can be combined flexibly according to application needs.

4. Data Integration Design in System Architecture

Two primary integration approaches are discussed:

Physical data centralization : All data resides on a single database server, offering high query efficiency but lower real‑time performance and higher risk.

Logical data centralization : Distributed data is accessed through a unified integration platform, providing real‑time access but dependent on network performance.

Three common integration patterns are introduced:

Data Federation : Logical centralization via a virtual database; the integration platform acts as a data access gateway.

Data Replication : Uses consistency services to keep shared data copies across multiple sources.

Interface‑Level Integration : Systems share data via adapters; suitable for high‑real‑time, low‑volume scenarios and works well with partitioned or independent schemas.

5. Application Integration Design

Common concepts include:

EAI (Enterprise Application Integration): Integrates heterogeneous applications across platforms, enabling seamless data exchange among ERP, CRM, SCM, databases, and data warehouses.

MOM (Message‑Oriented Middleware): Provides platform‑independent messaging for distributed system integration.

SOA (Service‑Oriented Architecture): Defines services with neutral interfaces, allowing independent deployment across hardware, OS, and languages.

Selection of integration strategies should consider implementation complexity, scalability, and specific project requirements.

6. Interface Design

Key principles:

1. Collaboration decides the interface.

2. Subsystems or implementations should not dictate the interface.

General steps for interface design are illustrated below.