Why Software Architecture Matters: Roles, Processes, and Best Practices

1. What & Why of Software Architecture

What is software architecture? It is the arrangement of system components based on design principles, describing components, their visible properties, and relationships. Architecture design explains a system’s composition and characteristics from a macro perspective and involves layered decisions such as functionality, technical stack, in‑house vs. partner solutions, and commercial vs. open‑source choices.

Why design software architecture? Because business needs constantly evolve, systems become more complex, more participants join projects, and both common and unique challenges arise alongside rapid technological change.

2. Software Architect

2.1 What does a software architect do?

Acts as a bridge between requirements and development, possesses strong communication and big‑picture thinking, translates needs into technical solutions, guides development, and solves critical technical problems.

2.2 Required qualities

Global thinking – from business and market to technical implementation.

Strategic thinking – aligning with industry, business, and technology strategies.

Forward thinking – anticipating market, technology, competitor, and partner trends.

Abstract thinking – turning requirements into modules and modules into architecture.

Reverse thinking – questioning consequences of not implementing or delaying features.

2.3 Architect classifications

Common categories include:

Solution architect – combines business, market, and technology to deliver solutions.

System (application) architect – defines core framework and technical specifications.

Platform architect – builds system platforms and underlying technical platforms.

Business architect – focuses on cross‑system integration and future CIO‑level responsibilities.

Network architect – designs network infrastructure and cloud‑based deployments.

Mobile architect – considers both front‑end and back‑end aspects of mobile clients, balancing native and hybrid approaches.

Frontend architect – designs presentation layer (HTML/CSS/JS) and cross‑browser concerns.

3. Software Requirements

Requirements drive architecture. Three stages are identified:

Business requirements – raw client needs and goals.

User requirements – derived from interviews and scenario analysis.

Software requirements – technical specifications (SRS) produced by analysts and architects.

Typical artifacts include SOW, proposal documents, user‑research logs, and the Software Requirement Specification (SRS). Non‑functional requirements, such as those described by the McCall quality model, also heavily influence design decisions.

4. Architecture Process (ADMEMS)

The ADMEMS method divides architecture into stages:

Pre‑architecture – fully understand and structure requirements using the ADMEMS matrix.

Conceptual architecture – define high‑level components and their relationships.

Detailed architecture – apply view‑based techniques (e.g., 5‑view) to refine the design.

Implementation – produce detailed design documents and support coding.

Each stage involves specific activities with stakeholders such as project managers, analysts, and customers.

5. Architecture Design Methods

5.1 Multi‑view approaches

Widely recognized methods include SEI’s 3‑view (module, component‑connector, allocation), Siemens’ 4‑view (conceptual, module, code, execution), RUP’s 4+1 view (use case, logical, development, process, physical), and federal enterprise architecture views (technology, information, application, business).

5.2 The 5‑view method

It covers logical, development, data, runtime, and physical views, providing comprehensive analysis, early risk detection, multi‑stakeholder guidance, and alignment with quality attributes.

5.3 Design steps for each view

Logical view – define system functions, use‑case models, activity diagrams, and robustness analysis.

Development view – create layered architecture diagrams, select languages/frameworks, define module structure, and establish coding standards.

Data view – decide on centralized vs. distributed storage, design logical/physical models, and choose relational or NoSQL databases.

Runtime view – address synchronization vs. asynchrony, concurrency, state transitions, and quality attributes such as safety, reliability, and scalability.

Physical view – plan network topology, hardware performance, and deployment topology (centralized or distributed).

6. What Drives Architecture Design?

Potential drivers include:

Requirement‑driven design.

Quality‑attribute‑driven design (e.g., ADD).

Domain‑driven design (DDD).

Risk‑driven design.

Question‑driven design – continuous skepticism leads to improvement.

Analogies with shipbuilding illustrate how market demand, robustness, performance, interoperability, safety, risk, and continuous questioning shape the architecture.

7. Common Pitfalls

Over‑design without concrete implementation.

Ignoring trade‑offs between ideal and reality.

Missing critical constraints or non‑functional requirements.

Designing for a vague future, leading to excessive complexity.

Making premature key decisions.

Being a “yes‑man” for client demands.

Lacking foresight and measurability.

Attempting a one‑shot architecture instead of iterative refinement.

8. References

Wen Yu’s “A Front‑line Architect’s Practice Guide” and the original blog post: http://blog.csdn.net/cooldragon/article/details/48241965