Software Architecture Fundamentals and Principles
This domain tests whether you can define software architecture precisely and reason about it in the vocabulary of ISO/IEC/IEEE 42010: architecture is the fundamental concepts or properties of a system in its environment, embodied in its elements, relationships and the principles of its design and evolution. The architecture description is a distinct work product that expresses that architecture for identified stakeholders and their concerns.
Core rules and concepts
- Architecture is structures plus decisions. Module, component-and-connector, and allocation structures each answer different stakeholder concerns, and every significant decision should carry rationale.
- The 42010 chain is stakeholder, then concern, then viewpoint, then view. A viewpoint is a reusable convention for building and reading one kind of view; a view is the concrete expression, built from model kinds.
- Architecture is a trade-off discipline. Security competes with performance, modifiability with simplicity. Recording the trade-off is part of the architecture, not a by-product of it.
- Scope levels differ: enterprise, solution and software architecture must remain traceable to each other.
- Principles such as separation of concerns, abstraction, information hiding, high cohesion and low coupling exist to protect quality attributes when the system changes.
Worked example
A reporting engine is decomposed by process step: extract, transform, format, export. A new export format is needed quarterly and audit rules change twice a year, so both changes cut across every module. Applying information hiding, the team instead hides the decisions most likely to change behind interfaces: a format provider, an audit rule set, a source connector. Each forecast change now touches one module. The reasoning: decomposition follows likelihood of change rather than control flow, which raises modifiability and testability.
Traps that cost marks
- Defining architecture as the diagram or as high-level design; the standard separates architecture from its description.
- Listing quality attributes without tying them to named stakeholder concerns or scenarios.
- Presenting patterns such as microservices as principles; patterns are reusable solutions, principles are criteria for judging designs.
- Omitting principles, decisions and rationale and claiming architecture is structure only.