Many teams invest heavily in code quality, architecture and testing – yet still struggle with outages, slow response times, and unclear ownership.
The reason is simple: software quality is about more than technology alone.
In modern distributed systems, true quality emerges from the interaction of three dimensions:
- Technical Quality (How well is the system built?)
- Process Quality (How effectively does it support the business?)
- Operational Quality (How reliably does it perform in daily operations?)
Standards such as ISO/IEC 25010 provide a structured framework for evaluating software quality and define nine key quality characteristics: Functional Suitability, Performance Efficiency, Compatibility, Usability (Interaction Capability), Reliability, Security, Maintainability, Flexibility and Safety.
These criteria help organizations assess quality holistically, from correct functionality and efficient performance to security and maintainability. The model becomes particularly valuable when making architectural decisions or evaluating existing systems. It highlights strengths as well as trade-offs, such as balancing performance against maintainability or security against usability.
Quality attributes define what matters, such as performance, maintainability or security. Metrics make these requirements measurable and reveal how effectively they are being achieved.
Technical Quality: How well is the system built?
Technical quality describes the internal structure of a system and how easily it can be developed, maintained, and evolved over time. It forms the foundation for long-term adaptability and maintainability.
A useful example is the Change Effort metric: How many parts of the system must be modified when a requirement changes?
Imagine a small change affects 2 out of 10 services:
Change Effort = 2 / 10 = 0.2
A Change Effort of 0.2 indicates good maintainability.
- Low values (close to 0): High maintainability
- High values: Strong coupling and increased risk
Other important factors include:
- Cohesion (Clear responsibilities within a service)
- Coupling (Minimal dependencies between services)
- Granularity (An appropriate service size and scope)
Technical quality provides the foundation, but by itself, it is not enough.
Process Quality: Does the architecture support the business?
A system can be technically sound and still create problems if it does not accurately reflect business processes. This is especially important in service-oriented architectures, where services should align closely with business capabilities and responsibilities.
Common metrics include:
- Business Capability Fidelity (BCF): Do services accurately represent clearly defined business capabilities?
- Process Completion Traceability (PCT): Can end-to-end business processes be fully traced and monitored?
- Process Step Coverage (PSC): Are all process steps covered by services?
For example:
PSC = Covered Process Steps / Total Process Steps
A process consists of five steps, and four are covered by services:
PSC = 4 / 5 = 0.8
- 1.0 = Complete coverage
- < 1.0 = Gaps within the process
Without strong process quality, organizations struggle to gain visibility into their operations. As a result, they often face issues such as unclear ownership, difficult-to-trace workflows, and inefficient processes.
Operational Quality: Does the system perform when it matters most?
The third dimension is often underestimated, yet it is the one that matters most in everyday operations. Operational quality describes how reliably a system performs under real-world conditions.
It can be measured using operational metrics such as:
- MTTD (Mean Time to Detect): How long does it take to detect an issue?
- MTTA (Mean Time to Acknowledge): How long does it take for someone to respond?
- MTTR (Mean Time to Recover): How long does it take to restore service?
- Availability: What percentage of time is the system available?
MTTR (Mean Time to Recover)
→ The average time required to restore service after an incident
Formula:
MTTR = Total Recovery Time / Number of Incidents
Example:
Three incidents require 1 hour, 2 hours, and 3 hours respectively to resolve:
MTTR = (1 + 2 + 3) / 3 = 2 hours
Availability
The percentage of time a system remains operational.
Formula:
Availability = (Total Time − Downtime) / Total Time
Example:
720 operating hours with 3 hours of downtime:
Availability = (720 − 3) / 720 = 0.996
That translates to 99.6% availability.
While that may sound impressive, it can still be unacceptable depending on the application and business requirements.
These metrics directly impact:
- Downtime
- Operational costs
- Customer satisfaction
A system can be architecturally sound, but if incidents aren’t detected and resolved quickly, users will still experience poor service.
The reality of trade-offs: Why perfect quality doesn’t exist
The three dimensions often compete with one another. Common trade-offs include:
- Fine-grained services improve maintainability but increase integration complexity
- Asynchronous communication improves scalability but reduces traceability
- Strong consistency enhances security and compliance but limits flexibility
These trade-offs are unavoidable. Good architecture isn’t about eliminating them – it’s about making informed decisions based on business priorities and requirements.
The biggest opportunity: Improving operational quality
While technical and process quality are largely established during design and development, operational quality is where organizations can have the greatest impact on reliability and service performance. This is where SIGNL4 makes a measurable difference.
SIGNL4 improves operational quality exactly where it matters most:
- Instant alerting when incidents occur
- Direct delivery to the right person
- Automated escalation workflows
- Mobile response capabilities from anywhere
The results are measurable:
- Reduced MTTD (faster detection)
- Reduced MTTA (faster response)
- Reduced MTTR (faster resolution)
Which ultimately leads to:
- Higher availability
- Lower downtime costs
- Improved service quality
Want to learn more about MTTD, MTTA and MTTR? Check out our blog post.
Conclusion: Quality emerges through the interaction of all three dimensions
Software quality is not a single KPI, it is the result of multiple interconnected factors.
- Technical Quality ensures maintainability
- Process Quality ensures business alignment
- Operational Quality ensures reliability in everyday operations
Only when all three dimensions are considered together can organizations build systems that are not only well designed but also deliver consistently in production.
That’s the difference between software that simply works and software that teams can depend on every day.
