📘 How does software architecture shape a system?

What you’ll learn

1. What Software Architecture Is (and Is Not)Define software architecture as the set of structures comprising elements, their relations, and their externally visible properties, and distinguish it from detailed design.Software architecture is the set of structures needed to reason about a system, comprising software elements, the relations among them, and the properties of both. It operates at a higher level of abstraction than detailed design, focusing on the decisions that are hard to change and that most affect system-wide quality attributes. Architecture is recorded as a set of related views, each addressing a distinct set of stakeholder concerns. Every system has an architecture whether or not it is documented; the engineer's job is to make it explicit and intentional.
2. Quality Attributes and Architecturally Significant RequirementsIdentify the quality attributes that architecture must satisfy and express them as testable quality attribute scenarios derived from architecturally significant requirements.Architecture exists primarily to satisfy quality attributes, the measurable non-functional properties such as performance, availability, modifiability, and security. The requirements that most shape architecture are the architecturally significant requirements (ASRs), which the SEI recommends capturing as six-part quality attribute scenarios. The ISO/IEC 25010 product quality model provides a shared vocabulary of eight quality characteristics and their sub-characteristics. Because quality attributes conflict, the architect's task is to make deliberate, justified trade-offs rather than to optimize any single attribute.
3. Architectural Patterns and StylesCompare common architectural patterns and explain which quality attributes each pattern promotes and inhibits.Architectural patterns, sometimes called styles, are reusable solutions that define element types and their allowed relationships to address recurring design problems. Each pattern packages a set of trade-offs: layered architecture promotes modifiability and separation of concerns but can add overhead; microservices promote independent deployability and scalability at the cost of distributed-system complexity; event-driven architecture promotes decoupling and scalability while complicating end-to-end reasoning. Choosing a pattern means choosing which quality attributes to favor for a given set of architecturally significant requirements. Patterns are starting points to be adapted, not rigid templates to be applied unthinkingly.
4. Documenting and Communicating ArchitectureApply view-based documentation approaches such as Kruchten's 4+1 model and Simon Brown's C4 model to communicate architecture to different stakeholders.Architecture documentation captures decisions so that stakeholders can understand, build, and evolve the system, and it works best when organized by views aimed at specific concerns. Kruchten's 4+1 model organizes architecture into logical, process, development, and physical views, unified by scenarios. Simon Brown's C4 model provides a hierarchy of context, container, component, and code diagrams that lets readers zoom from system-wide context down to implementation detail. Architecture decision records complement diagrams by capturing the rationale behind significant choices, which is often more durable and valuable than the diagrams themselves.
5. Evaluating Architecture and Conway's LawUse structured evaluation to surface architectural risks and trade-offs, and account for the organizational forces described by Conway's Law.Because architectural decisions are expensive to reverse, evaluating an architecture before heavy construction reduces risk. The SEI's Architecture Tradeoff Analysis Method (ATAM) is a scenario-based evaluation that builds a utility tree and then identifies risks, non-risks, sensitivity points, and trade-off points against quality attribute scenarios. Conway's Law observes that systems tend to mirror the communication structure of the organizations that build them, so team structure is itself an architectural force. Skilled architects treat evaluation and organizational design as part of the architecture rather than as afterthoughts.
6. Capstone Simulation: Design and Defend an ArchitectureBuild a mini architecture artifact for a sample system by deriving ASRs, selecting a pattern, documenting a view, and defending the design against trade-offs.This final lesson is an interactive simulation that integrates the course: you take a sample system brief, derive its architecturally significant requirements, choose and justify an architectural pattern, document the design with a C4-style diagram and an architecture decision record, and then stress-test it ATAM-style by naming risks and trade-off points. The deliverable is a compact architecture artifact that demonstrates reasoning from requirements to structure to evaluation. Mastery is shown not by picking a 'correct' pattern but by making and defending justified trade-offs.

Questions this course answers

Grounded in trusted sources

• Bass, Clements, Kazman, "Software Architecture in Practice," 3rd ed., Addison-Wesley / SEI Series, 2012
• ISO/IEC/IEEE 42010:2011 — Systems and software engineering — Architecture description
• ISO/IEC 25010:2011 — Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — System and software quality models
• Bass, Clements, Kazman, "Software Architecture in Practice," 3rd ed., 2012 (quality attribute scenarios)
• Software Engineering Institute, Carnegie Mellon University — Quality Attribute Workshops (QAW)
• Bass, Clements, Kazman, "Software Architecture in Practice," 3rd ed., 2012 (architectural patterns and tactics)

Every Wunder lesson is built from real, reputable sources — never invented.

Related courses