Using a systematic approach to software architecture design
Process · Chapter 5
Why be systematic
Section titled “Why be systematic”If you’re going to invest in designing an architecture (rather than letting it emerge), do it in a principled, systematic way. A defined design process gives guidance so the architecture actually satisfies its architectural drivers. Designing Software Architectures: A Practical Approach makes the point that satisfying drivers requires a principled method — one accounting for every relevant aspect and providing the guidance needed to guarantee the drivers are met.
A general model of architecture design
Section titled “A general model of architecture design”The paper A general model of software architecture design derived from five industrial approaches (Hofmeister, Kruchten, Nord, Obbink, Ran, America) compared five methods and found they share three core activities. A general model lets us understand typical design activities and compare methods’ strengths and weaknesses.
Most processes analyze the drivers, design candidate solutions, and then evaluate those decisions/solutions for correctness. The three activities:
| Activity | What happens | Output |
|---|---|---|
| Architectural analysis | Identify the problems the architecture must solve — the architecturally significant requirements (ASRs) — and address all drivers (design objectives, primary functional requirements, quality attribute scenarios, constraints, concerns). | A set of architectural drivers, feeding synthesis. |
| Architectural synthesis | Design solutions from those drivers, leveraging design concepts (patterns, reference architectures, tactics, external software) combined with structures/elements/relationships. | One or more candidate solutions. |
| Architectural evaluation | Check candidate solutions solve their intended problems and that decisions are correct. | Each candidate is validated or invalidated (see Reviewing software architectures). |
Design is iterative
Section titled “Design is iterative”- Too complex to address all drivers at once, so design proceeds over multiple iterations until every driver is handled.
- Each iteration selects the drivers to tackle; validated solutions are integrated into the overall architecture.
- When no drivers remain, the validated architecture is complete; otherwise a new iteration begins.
Selecting a design process
Section titled “Selecting a design process”Many processes exist. Compare them by examining their activities and artifacts:
- What are the activities/artifacts? Any that seem unneeded? Any that seem missing? What techniques and tools does it use?
- Optionally map them against the general model (names may differ; some may have no counterpart either way). This reveals each process’s strengths/weaknesses so you can pick the best fit.
- You may tailor a process thoughtfully — remove an unneeded activity/artifact, or borrow a technique/tool/another process to supplement a gap.
Three concrete processes explored next: ADD, Microsoft’s technique, and the ACDM (plus the enterprise-focused ADM).
Related concepts
Section titled “Related concepts”- Architectural drivers
- Attribute-driven design (ADD)
- Microsoft’s technique for architecture and design
- Architecture-centric design method (ACDM)
- Reviewing software architectures
Citations
Section titled “Citations”- Software Architect’s Handbook (Packt, 2018), Ch.5 “Using a systematic approach to software architecture design”, pp. 330-337.