A holistic framework for understanding, measuring, and improving software quality.
Executive Summary
Software quality is not a single attribute. It emerges from the interplay between the system that creates the software and the qualities of the software itself.
Most software quality models fail because they treat quality as a property of the software, rather than as an outcome of the system that produces it.
The 1+3 Software Quality Model (1+3 SQM) provides a structured, holistic view of software quality across four interconnected domains:
- 1 Enabling Quality: Organizational Quality
- 3 Resulting Qualities: Design Quality, Code Quality, Product Quality
In the model, Organizational Quality is expanded into three critical subdomains that together define the system of work that enables quality to emerge:
- Strategic Quality
- Practice Quality
- Environmental Quality
This white paper introduces the model, explains its rationale, and provides guidance for measurement and application.
1. Introduction
Software quality is often oversimplified as “few bugs” or “meeting requirements.” But modern software development has shown that quality is shaped by the organizational system, the technical system, the delivery system, and the product itself.
To guide leaders, architects, and teams toward sustainable high performance, we need a model that captures these dimensions clearly and pragmatically.
The 1+3 SQM offers this clarity by distinguishing between the qualities of the software itself, and the qualities of the organization that produces the software.
This distinction mirrors the realities of modern DevOps, lean engineering, and socio‑technical systems thinking.
2. The Structure of the 1+3 SQM
The 1+3 SQM is organized into two halves:
2.1 The Top Half: Organizational Quality (The “1”)
Organizational Quality represents the enabling system; it is the production system for software quality.
Organizational Quality consists of three subdomains:
A. Strategic Quality
The clarity, alignment, and long-term direction that shape how teams behave, focus and prioritize.
Examples include culture, quality goals and OKRs, architectural strategy, long-term capability investment, governance and decision frameworks.
B. Practice Quality (Leadership & Behavioral Execution)
The degree to which skills, craftsmanship, and knowledge are consistently applied through effective engineering and leadership practices.
Examples include collaboration, psychological safety, craftsmanship and engineering discipline. Leadership behavior, accessibility and follow-through, and decision-making tempo and clarity.
C. Environmental Quality
The infrastructure, tools, and ecosystem that enable engineers to deliver software effectively.
Examples are CI/CD pipelines, build and test automation, platform engineering capabilities, developer experience (DX), and documentation and knowledge systems
Environmental Quality is also where Operational Excellence (DevOps capabilities) finds its home, because CI/CD, automation, and deployment pipelines are part of the system of work, not part of the software itself.
2.2 The Bottom Half: The Three Resulting Qualities (The “3”)
These represent the qualities of the software itself, directly shaped by how the top half operates.
1. Design Quality
The structural integrity and architectural soundness of the software , which covers modularity, coupling & cohesion, dependency health, system boundaries, and architectural fitness and evolution
2. Code Quality
The cleanliness, maintainability, and correctness of the implementation, which covers static code analysis, readability and clarity, unit testing in many cases categorized as Clean Code.
3. Product Quality
The qualities experienced by customers and users.
Product Quality covers functional correctness, reliability and stability, performance and efficiency, security and safety, and usability and accessibility.
Design Quality constrains Code Quality, and Code Quality constrains Product Quality. All three are enabled by Organizational Quality.
3. Why the 1+3 SQM Is Needed
The 1+3 SQM reflects key insights:
1. Software quality emerges from a socio‑technical system consisting of architecture, craftsmanship and skills, culture and leadership, and tooling, which jointly shape quality.
2. Operational Excellence belongs to Organizational Quality, not Technical Quality. Pipelines, automation, deployments, tooling and processes are enablers, not software attributes.
3. Separating Design, Code, and Product Quality keeps the model precise. Each domain has its own properties, and can be evaluated and measured independently and improved systematically.
4. The 1+3 SQM is a diagnostic model. It provides a holistic and structured view of software quality by distinguishing between the system that creates the software and the qualities of the software itself. This allows teams to trace symptoms back to their true root causes; whether strategic, behavioral, environmental, architectural, code-related, or product-related.
This is extremely powerful for leadership.
4. Practical Application of the model
Organizations can use the 1+3 SQM to train leadership in software quality, set up a measurement framework, build targeted improvement programs, and assess teams.
Teams can use the model to identify whether quality issues originate in strategy, execution behavior, environment, design, code, or product practices.
Each quality domain can be measured through a set of underlying metrics, which may be aggregated into a composite Quality Index representing the maturity of that domain.
The model is intentionally simple, visual, and memorable, yet capable of capturing the full complexity of modern software engineering.
5. Conclusion
The 1+3 SQM provides a non-negotiable truth:
High-quality software depends on the quality of the system that creates it, and the skills and craftsmanship of individual engineers are an essential part of that system. The system amplifies, supports, and enables those skills to consistently translate into high-quality design, code, and product outcomes.