Ransford's Notes

Core path

Your path through this level

Progress saves in this browser and syncs after you sign in

Completed

0 of 9

Pick up where you left off

Discovery to requirements Design as boundaries Implementation with guardrails Verification proves claims Pipeline as control surface Operate with signals Evidence-first diagnostics Ilities as trade-offs Assessment as evidence

Optional

Full module map

Use this if you want the shape of the level before you start

Show

Module 1.1Discovery to requirements

Good requirements come from understanding journeys, risks, and constraints before design starts.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain discovery to requirements in your own words and apply it to a realistic scenario.
Good requirements come from understanding journeys, risks, and constraints before design starts.
Check the assumption "The problem is explicit" and explain what changes if it is false.
Check the assumption "Non-functional needs are named" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Building the wrong thing. If discovery is weak, teams build the wrong system very efficiently.
Hidden constraints. Hidden constraints appear later as incidents and delays.

Module 1.2Design as boundaries

Architecture design is choosing boundaries, responsibilities, and the flows between them.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain design as boundaries in your own words and apply it to a realistic scenario.
Architecture design is choosing boundaries, responsibilities, and the flows between them.
Check the assumption "Boundaries are explicit" and explain what changes if it is false.
Check the assumption "Decisions are recorded" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Diagram-first design. If you draw before you understand, diagrams become fiction.
Unowned interfaces. Interfaces without owners drift and break consumers.

Module 1.3Implementation with guardrails

Implementation is safer when guardrails prevent common mistakes and failures are visible.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain implementation with guardrails in your own words and apply it to a realistic scenario.
Implementation is safer when guardrails prevent common mistakes and failures are visible.
Check the assumption "Inputs are untrusted" and explain what changes if it is false.
Check the assumption "Errors are safe" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Silent failure. Silent failure breaks trust and increases incident cost.
Leaky errors. Leaky errors expose internals and help attackers.

Module 1.4Verification proves claims

Tests are how you prove architectural claims about safety, performance, and reliability.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain verification proves claims in your own words and apply it to a realistic scenario.
Tests are how you prove architectural claims about safety, performance, and reliability.
Check the assumption "Tests match risk" and explain what changes if it is false.
Check the assumption "Failures are actionable" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Green build theatre. A green build can hide gaps if you test the wrong things.
No regression coverage. If you cannot prevent regression, you re-learn the same lessons under stress.

Module 1.5Pipeline as control surface

CI/CD is where you enforce quality, not where you hope it exists.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain pipeline as control surface in your own words and apply it to a realistic scenario.
CI/CD is where you enforce quality, not where you hope it exists.
Check the assumption "Checks are fast enough" and explain what changes if it is false.
Check the assumption "Deployments are reversible" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Bypass behaviour. If gates feel unfair, bypass becomes normal.
Unsafe defaults. If defaults are unsafe, you ship risk repeatedly.

Module 1.6Operate with signals

Operations is feedback. Signals should trigger action, not only dashboards.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain operate with signals in your own words and apply it to a realistic scenario.
Operations is feedback. Signals should trigger action, not only dashboards.
Check the assumption "Signals reflect user impact" and explain what changes if it is false.
Check the assumption "Runbooks exist" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Alert fatigue. Too many alerts teaches people to ignore them.
No learning loop. If incidents do not improve systems, you repeat them.

Module 1.7Evidence-first diagnostics

OSI thinking is useful when it helps you isolate problems with evidence and tests.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain evidence-first diagnostics in your own words and apply it to a realistic scenario.
OSI thinking is useful when it helps you isolate problems with evidence and tests.
Check the assumption "Each step is testable" and explain what changes if it is false.
Check the assumption "Claims are written" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Guessing. Guessing is slow. Tests are faster.
Tool worship. Tools help, but the model makes output meaningful.

Module 1.8Ilities as trade-offs

Quality attributes are trade-offs: you choose what to optimise and what to accept.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain ilities as trade-offs in your own words and apply it to a realistic scenario.
Quality attributes are trade-offs: you choose what to optimise and what to accept.
Check the assumption "Trade-offs are explicit" and explain what changes if it is false.
Check the assumption "Measures exist" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Optimising one quality only. Optimising one axis can harm users elsewhere. Balance is the job.
Vague requirements. Vague ‘fast’ and ‘secure’ requirements create confusion and rework.

Module 1.9Assessment as evidence

Assessment is useful when it checks judgement and produces defensible evidence.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain assessment as evidence in your own words and apply it to a realistic scenario.
Assessment is useful when it checks judgement and produces defensible evidence.
Check the assumption "Assessment checks reasoning" and explain what changes if it is false.
Check the assumption "Evidence is safe" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Exam cramming. Cramming fades quickly. Practice builds judgement.
No feedback loop. Without feedback, assessment does not improve learning.

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Learning contract

Practice assessment outcomes

Read the explanation first, then use the tools to test the idea. Skip any tool that is not useful for your goal.

This is a scored practice assessment. It is free and not timed. Use it to improve architecture decision quality before high-stakes reviews.

Timed Software Architecture assessments are in build. This scored practice route is free and currently the main pathway.

Practice assessment bank not found for this level yet.

What to do next

Draft one ADR for a decision you have seen at work.
State constraints, trade-offs, and a review trigger in plain language.
Retake the assessment and compare whether your decision quality improves.

Open architecture labs Assessment roadmap Back to course Track CPD

Course materials are protected by intellectual property rights.View terms

Preparing the page...

Core path

Your path through this level

Progress saves in this browser and syncs after you sign in

Completed

0 of 9

Pick up where you left off

Optional

Full module map

Use this if you want the shape of the level before you start

Show

Module 1.1Discovery to requirements

Good requirements come from understanding journeys, risks, and constraints before design starts.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain discovery to requirements in your own words and apply it to a realistic scenario.
Good requirements come from understanding journeys, risks, and constraints before design starts.
Check the assumption "The problem is explicit" and explain what changes if it is false.
Check the assumption "Non-functional needs are named" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Building the wrong thing. If discovery is weak, teams build the wrong system very efficiently.
Hidden constraints. Hidden constraints appear later as incidents and delays.

Module 1.2Design as boundaries

Architecture design is choosing boundaries, responsibilities, and the flows between them.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain design as boundaries in your own words and apply it to a realistic scenario.
Architecture design is choosing boundaries, responsibilities, and the flows between them.
Check the assumption "Boundaries are explicit" and explain what changes if it is false.
Check the assumption "Decisions are recorded" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Diagram-first design. If you draw before you understand, diagrams become fiction.
Unowned interfaces. Interfaces without owners drift and break consumers.

Module 1.3Implementation with guardrails

Implementation is safer when guardrails prevent common mistakes and failures are visible.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain implementation with guardrails in your own words and apply it to a realistic scenario.
Implementation is safer when guardrails prevent common mistakes and failures are visible.
Check the assumption "Inputs are untrusted" and explain what changes if it is false.
Check the assumption "Errors are safe" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Silent failure. Silent failure breaks trust and increases incident cost.
Leaky errors. Leaky errors expose internals and help attackers.

Module 1.4Verification proves claims

Tests are how you prove architectural claims about safety, performance, and reliability.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain verification proves claims in your own words and apply it to a realistic scenario.
Tests are how you prove architectural claims about safety, performance, and reliability.
Check the assumption "Tests match risk" and explain what changes if it is false.
Check the assumption "Failures are actionable" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Green build theatre. A green build can hide gaps if you test the wrong things.
No regression coverage. If you cannot prevent regression, you re-learn the same lessons under stress.

Module 1.5Pipeline as control surface

CI/CD is where you enforce quality, not where you hope it exists.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain pipeline as control surface in your own words and apply it to a realistic scenario.
CI/CD is where you enforce quality, not where you hope it exists.
Check the assumption "Checks are fast enough" and explain what changes if it is false.
Check the assumption "Deployments are reversible" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Bypass behaviour. If gates feel unfair, bypass becomes normal.
Unsafe defaults. If defaults are unsafe, you ship risk repeatedly.

Module 1.6Operate with signals

Operations is feedback. Signals should trigger action, not only dashboards.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain operate with signals in your own words and apply it to a realistic scenario.
Operations is feedback. Signals should trigger action, not only dashboards.
Check the assumption "Signals reflect user impact" and explain what changes if it is false.
Check the assumption "Runbooks exist" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Alert fatigue. Too many alerts teaches people to ignore them.
No learning loop. If incidents do not improve systems, you repeat them.

Module 1.7Evidence-first diagnostics

OSI thinking is useful when it helps you isolate problems with evidence and tests.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain evidence-first diagnostics in your own words and apply it to a realistic scenario.
OSI thinking is useful when it helps you isolate problems with evidence and tests.
Check the assumption "Each step is testable" and explain what changes if it is false.
Check the assumption "Claims are written" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Guessing. Guessing is slow. Tests are faster.
Tool worship. Tools help, but the model makes output meaningful.

Module 1.8Ilities as trade-offs

Quality attributes are trade-offs: you choose what to optimise and what to accept.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain ilities as trade-offs in your own words and apply it to a realistic scenario.
Quality attributes are trade-offs: you choose what to optimise and what to accept.
Check the assumption "Trade-offs are explicit" and explain what changes if it is false.
Check the assumption "Measures exist" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Optimising one quality only. Optimising one axis can harm users elsewhere. Balance is the job.
Vague requirements. Vague ‘fast’ and ‘secure’ requirements create confusion and rework.

Module 1.9Assessment as evidence

Assessment is useful when it checks judgement and produces defensible evidence.

Open

Prerequisites

No previous technical background required
Read the section explanation before using tools

Outcomes

Explain assessment as evidence in your own words and apply it to a realistic scenario.
Assessment is useful when it checks judgement and produces defensible evidence.
Check the assumption "Assessment checks reasoning" and explain what changes if it is false.
Check the assumption "Evidence is safe" and explain what changes if it is false.

Practice

Complete one guided exercise and explain your decision in plain language
Use the recap only after reading the main section

Artefact and failure modes

A short module note with one key definition and one practical example
Exam cramming. Cramming fades quickly. Practice builds judgement.
No feedback loop. Without feedback, assessment does not improve learning.

What changes at this level

Level expectations

Each level is independent but clearly deeper than the last. This panel makes the jump explicit.

Learning contract

Practice assessment outcomes

Read the explanation first, then use the tools to test the idea. Skip any tool that is not useful for your goal.

This is a scored practice assessment. It is free and not timed. Use it to improve architecture decision quality before high-stakes reviews.

Timed Software Architecture assessments are in build. This scored practice route is free and currently the main pathway.

Practice assessment bank not found for this level yet.

What to do next

Draft one ADR for a decision you have seen at work.
State constraints, trade-offs, and a review trigger in plain language.
Retake the assessment and compare whether your decision quality improves.

Open architecture labs Assessment roadmap Back to course Track CPD

Course materials are protected by intellectual property rights.View terms

Software architecture practice assessment. Foundations

Level expectations

Practice assessment outcomes

Software architecture practice assessment. Foundations

Level expectations

Practice assessment outcomes