System and Solution Architecture Modeling
What this domain tests
This domain tests whether you can select and produce views that answer specific stakeholder concerns, using recognised notations at a consistent level of abstraction.
Core rules
- ISO/IEC/IEEE 42010 separates viewpoint (the conventions for constructing a view) from view (the actual description). A view without a stated concern and audience is decoration.
- Match notation to question: context and container diagrams (C4) for scope and onboarding; component and sequence diagrams for runtime interaction; deployment diagrams for nodes, networks, and environments; state machines for lifecycle; BPMN for business process; ArchiMate for enterprise traceability from business to technology; SysML for systems engineering that includes hardware.
- State the abstraction level and keep one per diagram. Mixing a container with a class is the most common modelling defect.
- A model earns its cost only by staying consistent and maintained. An inconsistent model is worse than none because it misleads.
Worked example
Reviewers ask how a payment authorisation flows and where it can fail. A component diagram shows structure but not ordering; a class diagram is irrelevant. The right answer is a sequence diagram with the external acquirer as a lifeline, alt fragments for timeout and decline, plus a deployment view showing the acquirer link crossing the DMZ. Reasoning: the concern is runtime behaviour and failure modes, so choose a dynamic view with one supporting deployment view.
Traps
- Confusing view with viewpoint, or producing diagrams with no legend, scope statement, or owner.
- Modelling only the happy path; questions reward explicit failure and compensation flows.
- Assuming UML is mandatory; fitness for purpose usually matters more than notation loyalty.
- Treating the model as the architecture itself rather than one description of it.
- Presenting a static diagram to answer a dynamic question such as "what happens when the acquirer times out?".