Key Factors to Consider When Designing Software Architecture

Basic Concepts Related to Architecture

Module: a set of statements that accomplish a specific function, including input, output, logic, internal data, and runtime environment.

Component: an important, nearly independent, replaceable part of a system that implements a defined function within a clear architectural context.

Pattern: a proven solution template applicable to one or more practical environments, covering structural and behavioral aspects (e.g., architectural patterns, analysis patterns, design patterns, code patterns).

Architectural pattern: a predefined organization scheme for a software system, specifying subsystems, their responsibilities, and rules for their relationships.

Layer: a way to group packages at the same abstraction level, allowing logical separation of subsystems and controlling dependencies for looser coupling.

Common layering methods include three‑tier services (presentation, business logic, data), multi‑tier technical models (presentation, middle, data), network three‑tier (core, aggregation, access), RUP layers (application, business, middleware, system software), Java‑based B/S structures, six‑layer structures, and the "4+1" view model.

Factors to Consider in Architecture Design

Architecture design should address both runtime structure and source‑code organization.

Runtime Structure Considerations

1. Requirement compliance: correctness, completeness, functional and non‑functional requirements.

2. Overall performance: memory management, database organization, parallelism, network operations, critical algorithms, and hardware/network interfaces.

3. Manageability: ease of controlling and monitoring the system, simple module communication, and effective error handling.

4. Compatibility with other systems and hardware/network interfaces.

5. Security: ensuring data confidentiality and integrity across the system.

6. Reliability: redundancy, fault tolerance, and rapid recovery.

7. Business process adjustability: modular design to accommodate workflow changes.

8. Business information adjustability: minimizing impact of data changes on code.

9. Usability: simple interfaces and operations.

10. Consistency of architectural style.

Source Code Organization Considerations

1. Development manageability: supports team division, load balancing, schedule optimization, and mitigates staff turnover; aids configuration management; balances size and complexity.

2. Maintainability: facilitates fault diagnosis and localized modifications.

3. Extensibility: allows system upgrades, scaling, and performance enhancements.

4. Portability: supports various clients, application servers, and DBMSs.

5. Requirement compliance from a code‑structure perspective.

Writing Architecture Design Documents

Start architecture work when requirements are about 80% complete.

Provide a clear system overview and consistent outline.

Define high‑level subsystems, their tasks, and initial module/object lists.

Describe inter‑subsystem communication, aiming to minimize coupling.

Identify likely change areas and how the architecture will adapt.

Consider reuse or off‑the‑shelf solutions and their impact.

Address detailed design decisions: external interfaces, UI, database, algorithms, memory management, parallelism, security, portability, multi‑user operations, and error handling.

Ensure traceability of requirements to modules.

Balance static system goals with dynamic development constraints such as resources, schedule, and environment.

Conclusion

Software architecture design is tightly coupled with specific development platforms, so no universal solution exists; designers must flexibly balance the many factors discussed and adapt strategies to their particular context.