Foundations · Module 8
The ilities framework
Evaluate systems across quality attributes including security, privacy, accessibility, performance, reliability, scalability, maintainability, and more.
Previously
OSI model and diagnostics
Master troubleshooting tools and techniques using OSI layers, browser DevTools, command-line diagnostics, and TLS certificate inspection.
This module
The ilities framework
Evaluate systems across quality attributes including security, privacy, accessibility, performance, reliability, scalability, maintainability, and more.
Next
Foundations assessment
Now that you have worked through all eight modules, it is time to test your understanding.
Progress
Mark this module complete when you can explain it without rereading every paragraph.
Why this matters
Quality attributes guide trade offs.
What you will be able to do
- 1 Explain the ilities framework in your own words and apply it to a realistic scenario.
- 2 Quality attributes are trade-offs: you choose what to optimise and what to accept.
- 3 Check the assumption "Trade-offs are explicit" and explain what changes if it is false.
- 4 Check the assumption "Measures exist" and explain what changes if it is false.
Before you begin
- No previous technical background required
- Read the section explanation before using tools
Common ways people get this wrong
- 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.
Evaluate systems across quality attributes including security, privacy, accessibility, performance, reliability, scalability, maintainability, and more.
Quality attributes guide trade offs. This module keeps them explicit so teams do not argue about taste.
Mental model
Ilities as trade-offs
Quality attributes are trade-offs: you choose what to optimise and what to accept.
-
1
Security
-
2
Performance
-
3
Reliability
-
4
Accessibility
-
5
Trade-offs
Assumptions to keep in mind
- Trade-offs are explicit. If you do not write trade-offs, future changes break them by accident.
- Measures exist. If you cannot measure a quality, you cannot manage it.
Failure modes to notice
- 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.
Check yourself
Quick check. The ilities framework
0 of 5 opened
What is an ility in architecture
A quality attribute you must design and operate for, such as availability, maintainability, auditability, or accessibility.
Why pick a small set of qualities to focus on
Because trade offs are real. Focusing on a few measurable attributes prevents vague debates and makes priorities explicit.
Scenario. Write one measurable accessibility requirement
All key flows must be usable by keyboard only, with visible focus and clear labels, verified against WCAG 2.2 success criteria.
What is a trade off note
A short decision record that states what you optimise for and what you deliberately accept as less important, and why.
Why revisit quality attributes after launch
Because real use changes constraints. Measures and priorities should evolve with evidence, not stay frozen as assumptions.
Artefact and reflection
Artefact
A short module note with one key definition and one practical example
Reflection
Where in your work would explain the ilities framework in your own words and apply it to a realistic scenario. change a decision, and what evidence would make you trust that change?
Optional practice
Comprehensive quality attributes for system evaluation