Software Architecture Notes
Read, design, and steward systems
- FoundationsSystems, boundaries, responsibilities, and diagrams.
- IntermediateDecomposition, styles, and quality attributes.
- AdvancedPlatforms, resilience, governance, and change.
- SummaryRecap, games, dashboards, and reflection.
CPD timing
Time estimate (transparent)
I publish time estimates because CPD needs to be defensible. The goal is honesty, not marketing.
Guided learning
50h
Core levels, structured learning
Practice and consolidation
3h
Summary, drills, revisits
Notional range
36 to 75 hours
Quick: core concepts + one exercise per module. Standard: exercises + reflections for CPD evidence. Deep: extra drills and portfolio artefacts.
How I estimate time
I use a notional learning hours approach and I keep the assumptions visible. Where modules are content heavy, I add practice so the hours are earned, not claimed.
- Reading: 225 words per minute, multiplied by 1.3 for note taking and checking understanding.
- Labs and practice: about 15 minutes per guided activity, including at least one retry.
- Reflection for CPD: about 8 minutes per module for a short defensible note and evidence link.
- Assessments: about 1.4 minutes per question for reading, thinking, and review.
If you study faster or slower, your hours will differ. What matters is that the method is consistent and the activities are real.
Assessment and practice assessment
Software architecture assessment blueprint (planned)
Software architecture already has the deepest question bank documentation in the repo. This panel is the common scaffolding view that will be used across tracks.
Design rules
- Questions should penalise vague words like scalable without a metric or constraint.
- Marking should reward explicit assumptions and clear trade-off reasoning.
Standards and certifications
The map we anchor to
I map each course to reputable standards so your learning is defensible at work. I also show common certifications and how their language differs.
Important: This content aligns with these standards and certifications for learning purposes. This is guidance, not endorsement. We are not affiliated with certification providers unless explicitly stated.
Primary anchor standards
- TOGAF StandardThe Open Group
A recognised body of knowledge and method framing that supports professional accreditation conversations.
Official reference - ISO/IEC/IEEE 42010 (architecture description)ISO/IEC/IEEE
Precise language for stakeholders, concerns, viewpoints, and views. Strong for academic and professional credibility.
Official reference
Certification routes
This course is not endorsed by certification bodies. It is built to prepare you honestly, including where exams simplify reality.
- practitionerTOGAF certification (Foundation and Practitioner)The Open Group
Useful for formal recognition and consistent architecture method vocabulary.
- practitionerCloud architecture certifications (AWS, Azure, Google)Major cloud vendors
A practical extension for learners building real platforms and services.
Organisations and resources
These are the kinds of organisations professionals reference. If you learn how to use them properly, you become harder to mislead.
- The Open Group
What it is: A consortium publishing architecture standards such as TOGAF.
Why it matters: It gives shared vocabulary and a recognised method scaffold.
- ISO/IEC/IEEE
What it is: Standards bodies that publish engineering standards.
Why it matters: Strong framing for rigorous architecture description and governance.
- SRE and reliability communities
What it is: Industry practice around reliability, error budgets, and operational design.
Why it matters: Modern architecture needs operational thinking, not only diagrams.
Terminology translation
Viewpoints and trade-offs
Most architecture arguments are not technical. They are vocabulary problems pretending to be engineering.
Architecture versus design
Plain English
Architecture is the set of decisions that are hard to change and shape everything else. Design is how you implement within those decisions.
How standards use it
ISO/IEC/IEEE 42010
Focuses on describing architecture via stakeholders, concerns, and viewpoints.
TOGAF
Provides method and content guidance for developing and governing architecture.
Common mistake
Calling a diagram architecture when it has no stakeholders, no concerns, and no decisions.
My take
If your diagram cannot answer why, it is decoration.
Quick check
Name one decision that is architectural and one that is design.
View versus viewpoint
Plain English
Viewpoint is the recipe. View is the cooked meal.
How standards use it
ISO/IEC/IEEE 42010
Viewpoints define conventions for constructing views that address concerns.
Common mistake
Mixing them and creating a diagram no one can reuse or compare.
My take
If you cannot repeat a view consistently, you cannot govern architecture consistently.
Quick check
What is the viewpoint for a deployment diagram and what is the view?
Quality attribute versus non-functional requirement
Plain English
Quality attributes describe the qualities of the system, like reliability and security. Non-functional requirements are how you make them measurable and testable.
How standards use it
ISO/IEC 25010
Provides a quality model that helps teams stop arguing about what quality means.
Common mistake
Writing high performance and calling it a requirement.
My take
Make it measurable, or admit it is a wish.
Quick check
Rewrite high performance as a measurable requirement.
🏗️Core path
Architecture Foundations
Systems, boundaries, responsibilities, and diagrams you can explain with confidence.
Applied Architecture
Decomposition, styles, quality attributes, and decision making that stays practical.
Digital and Cloud Scale Architecture
Event driven systems, CQRS, integration patterns, observability and digitalisation strategy across whole organisations.
Summary and games
Recap, games, dashboards, and reflection to consolidate architecture thinking.
Mapping
How this course stays defensible
This links the same four things CPD reviewers care about: what you learn, how you practise, how you are assessed, and what evidence you can show.
- TOGAF Standard (The Open Group)
- ISO/IEC/IEEE 42010 (architecture description) (ISO/IEC/IEEE)
Correct diagrams, boundaries, and responsibilities.
Trade-offs, quality attributes, and pattern choice.
Governance, evolution, and operational design.
Coverage matrix
Module-level coverage
This matrix makes the course defensible: each module is tied to an outcome focus, the anchor standards, and the evidence you can produce.
| Level | Module | Outcome focus | Domains | Alignment | Assessment | Evidence |
|---|---|---|---|---|---|---|
| Foundations | What Is Architecture sa-foundations-what-is-architecture Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Define architecture as trade-offs and change cost, not diagrams. | foundations | Other: Architecture fundamentals | Practice assessment | Template + rubric |
| Foundations | Building Blocks sa-foundations-building-blocks Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Use building blocks and boundaries to reduce coupling and increase clarity. | boundaries | Other: Boundaries and responsibilities | Practice assessment | Template + rubric |
| Foundations | Diagrams And Views sa-foundations-diagrams-and-views Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Create diagrams that serve stakeholders: review, debugging, onboarding, change planning. | communication | Other: Architecture communication | Practice assessment | Template + rubric |
| Intermediate | Architectural Styles sa-intermediate-architectural-styles Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Select styles based on constraints and failure modes, not fashion. | tradeoffs | Other: Style selection | Formative checkpoints | Template + rubric |
| Intermediate | Microservices And Integration sa-intermediate-microservices-and-integration Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Design integration and microservices boundaries with cohesion and operational evidence. | boundaries, operations | Other: Integration and decomposition | Formative checkpoints | Template + rubric |
| Intermediate | Runtime Tradeoffs sa-intermediate-runtime-tradeoffs Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Make runtime trade-offs explicit: latency, throughput, cost, and reliability. | tradeoffs | Other: Runtime trade-offs | Formative checkpoints | Template + rubric |
| Intermediate | Cqrs Event Sourcing sa-intermediate-cqrs-event-sourcing Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Use CQRS/event sourcing with explicit operational costs and observability needs. | operations | Other: Operational complexity | Formative checkpoints | Template + rubric |
| Advanced | Digitalisation Context sa-advanced-digitalisation-context Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Connect architecture decisions to organisational delivery and product outcomes. | governance | Other: Organisation context | Formative checkpoints | Template + rubric |
| Advanced | Architecture Governance sa-advanced-architecture-governance Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Run architecture governance as evidence-based guardrails, not ticket queues. | governance | Other: Governance and stewardship | Formative checkpoints | Template + rubric |
| Advanced | Roadmaps And Evolution sa-advanced-roadmaps-and-evolution Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Plan evolution with review triggers and explicit constraints and trade-offs. | planning | Other: Evolution planning | Formative checkpoints | Template + rubric |
| Advanced | Architecture In Practice sa-advanced-architecture-in-practice Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Apply resilience and operational thinking: assume failure and design recovery. | resilience, operations | Other: Resilience and operations | Formative checkpoints | Template + rubric |
| Summary | Summary You Made It soft-arch-summary-you-made-it Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Consolidate what you built and what changed in your assumptions. | evidence | Other: Reflection and consolidation | Formative checkpoints | Template + rubric |
| Summary | Summary Big Picture soft-arch-summary-big-picture Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Reconnect the big picture: constraints, trade-offs, boundaries, and change cost. | tradeoffs, boundaries | Other: Big picture reasoning | Formative checkpoints | Template + rubric |
| Summary | Summary Games Labs soft-arch-summary-games-labs Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Practise patterns and trade-offs with small drills and labs that surface misconceptions. | practice | Other: Practice and calibration | Formative checkpoints | Template + rubric |
| Summary | Summary Next Steps soft-arch-summary-next-steps Anchors: TOGAF Standard, ISO/IEC/IEEE 42010 (architecture description) | Create a next-steps plan: one decision record, one guardrail, one operational improvement. | planning, governance | Other: Next steps | Formative checkpoints | Template + rubric |
🛠️Further practice
Dashboards and labs to make latency, availability, and trade-offs concrete.
🏗️Capstones
📚CPD
Log minutes as you study and practise. Your records stay in this browser. Use the export view when you need a clean summary for your CPD system.
📚References and further reading
These notes draw on a wide range of sources. A few starting points are listed here so that you can explore the official material in more depth.
- Architecture handbooks and open course materials from recognised universities and industry leaders
- Documentation and guidance on cloud architecture, reliability, and security from major vendors
- Standards and playbooks on software design, observability, and operational excellence