Built‑in Quality: Embedding Quality Practices Across Architecture, Code, System, and Release

Inspection cannot improve quality, nor can it guarantee quality. Inspection is too late. The quality of a product, good or bad, already exists. Product or service quality cannot be inspected; it must be built‑in. - W. Edwards Deming

Built‑in quality practices ensure that every solution element meets appropriate quality standards at each increment throughout the development process.

Whether an enterprise can deliver new features in the shortest sustainable time and adapt to a rapidly changing business environment depends on solution quality. Therefore, built‑in quality is a core safety value and a principle of the Agile Manifesto’s emphasis on technical excellence and good design, as well as a core lean‑agile principle that helps avoid delay costs associated with recalls, rework, and defect fixes.

Software and hardware share the same goals and principles for built‑in quality, though hardware’s physical and economic aspects differ. This article discusses both.

Details

Enterprises must continuously respond to market changes. Software and systems built on a stable technical foundation are easier to modify and adapt, especially for large solutions where small defects can accumulate into unacceptable results.

Building high‑quality systems is serious work that requires ongoing training and commitment, but the business benefits justify the investment:

Higher customer satisfaction

Improved speed and predictability of delivery

Better system performance

Enhanced ability to innovate, scale, and meet regulatory compliance

Figure 1 illustrates the five dimensions of built‑in quality. The first dimension, Flow, shows that built‑in quality is a prerequisite for achieving a continuous value‑flow state; the other four describe quality applied to the system itself.

Figure 1. The five dimensions of built‑in quality

Implementing Flow and Test‑First

Built‑in quality drives a safe continuous delivery pipeline and capability release. Figure 2 shows the SAFe DevOps radar’s Continuous Integration portion, illustrating how built‑in components are tested across multiple environments before production. Replacing slow or expensive components (e.g., an enterprise database) with faster proxies (e.g., an in‑memory database) doubles test speed.

Figure 2. Continuous delivery pipeline ensures quality before release

To support pipeline testing, organizations must shift testing left early in the development cycle. As a rule, every system behavior—story, feature, function, or non‑functional requirement (NFR)—includes automated tests. This test‑first approach lets teams apply quality practices early and continuously, creating a rich test suite for the pipeline.

The remainder of this article discusses the other four dimensions of built‑in quality: architecture & design, code, system, and release.

Achieving Architecture & Design Quality

Built‑in quality starts with architecture and design, which determine how well a system can support current and future business needs. Good architecture makes future requirements easier to implement, simplifies testing, and helps satisfy NFRs.

Supporting Future Business Needs

As market changes, discoveries, and other factors evolve requirements, architecture and design must evolve too. Traditional processes often force early decisions that lead to either costly rework or sub‑optimal compromises. Determining the best decisions requires experiments, modeling, simulation, prototyping, and other learning activities, as well as a set‑based design approach to evaluate multiple alternatives.

Design Features that Predict Quality

High cohesion, low coupling, clear abstraction, encapsulation, readability, and separation of concerns are design traits that predict good quality. Solid principles foster these traits.

Architecture & Design Simplify Testing

Well‑defined interfaces create seams that allow testers and developers to replace expensive or slow components with test doubles. For example, a speed‑control component that normally receives GPS data can be tested with a simulated GPS source, dramatically reducing development and test effort.

Figure 3. Module seams simplify testing

Applying Design Quality to Cyber‑Physical Systems

The same design principles apply to cyber‑physical systems. Engineers in many disciplines use modeling and simulation to gain design knowledge; integrated circuit design (VHDL, Verilog) follows software‑like practices and benefits from the same solid principles. Hardware design also uses simulation and modeling to test before physical fabrication.

Changing the mindset to plan for future changes rather than optimizing for current requirements yields better long‑term outcomes for hardware as well.

Implementing Code Quality

All system functionality ultimately runs as code (or components). The speed and ease of adding new features depend on how quickly and reliably developers can modify code. Inspired by Extreme Programming (XP), the following practices are recommended:

Unit Testing and Test‑Driven Development (TDD)

Unit tests break code into small parts and ensure each part has automated tests that run on every change, giving developers confidence that modifications won’t break other parts. Tests also serve as documentation and executable examples of component usage.

TDD guides unit‑test creation by specifying tests before writing code, forcing developers to consider edge cases and boundary conditions early, leading to faster development, fewer bugs, and less rework.

Pair Programming

Two developers work together at one workstation, alternating roles between driver (writes code) and navigator (provides real‑time review). Pairing shares knowledge, perspectives, and best practices, improving overall team skill and maintaining quality.

Collective Code Ownership and Coding Standards

Collective ownership reduces dependencies between teams and ensures no single developer blocks rapid value flow. Any developer can change any line of code to add features, fix bugs, improve design, or refactor. Coding standards promote consistency, making components easier to understand and maintain.

Applying Code‑Quality Practices to Cyber‑Physical Systems

Although hardware designs may not have “code,” the collaborative creation process can benefit from these practices. Computer‑Aided Design (CAD) tools for hardware provide “unit tests” as assertions, and simulations act as test benches. Collective ownership and coding standards yield similar benefits, producing designs that are easier to maintain and modify.

Some hardware design techniques (e.g., VHDL) resemble code, with well‑defined inputs and outputs, making them suitable for TDD‑like practices.

Implementing System Quality

While code and design quality ensure components are understandable and changeable, system quality confirms the system works as intended and that everyone stays aligned on changes. Key techniques include:

Creating Alignment for Fast Flow

Alignment and shared understanding reduce developer delays and rework, supporting fast flow. Behavior‑Driven Development (BDD) aligns product owners and developers on precise behavior of stories or features, reducing rework and errors. Model‑Based Systems Engineering (MBSE) extends this alignment to the whole system, providing a high‑level, complete view of all proposed functions and how the design implements them.

Continuous Integration of End‑to‑End Solutions

As shown in Figure 2, CI/CD gives developers rapid feedback on changes. Each change is quickly built and integrated across multiple levels and environments, with automated testing for functional and non‑functional requirements. Some exploratory or usability tests may still require manual execution.

Applying System Quality to Cyber‑Physical Systems

Even when physical component delivery is long, cyber‑physical systems can support fast flow and CI/CD using simulations, models, or previous hardware versions as proxies. Figure 4 shows a system team providing a demonstrable platform that connects these proxy components to test incremental behavior. As components mature, the end‑to‑end integration platform matures as well.

Figure 4. Continuous integration for cyber‑physical systems

Implementing Release Quality

Release enables the business to validate the assumed benefits of a feature. Faster releases mean faster learning and more value delivery. Defining standard interfaces between components allows independent, small‑scale releases, which are faster, more frequent, and lower risk, but require an automated pipeline (as in Figure 2) to ensure quality.

Immutable infrastructure does not allow manual changes to production servers; instead, changes are applied to validated images that replace the running servers, creating more consistent, predictable versions and enabling automatic rollback.

Supporting Compliance

For systems that must provide objective evidence for compliance or audit, releases must also demonstrate that the system meets its intended purpose without harmful side effects. A lean quality management system (QMS) defines approved practices, policies, and processes that support a lean‑agile, process‑based, continuous integration‑deployment‑release workflow.

Scalable Definition of “Done”

“Done” is a critical method to ensure work is considered complete at the right time. Table 1 shows an example; each team should tailor its own definition, typically sharing a core set of items.

Table 1. Example scalable definition of “Done”

Release Quality in Cyber‑Physical Systems

Release quality means not letting changes sit idle waiting for integration. Instead, integrate large portions of the system quickly and frequently until changes reach a verification environment. Some cyber‑physical systems can validate in the customer environment (e.g., over‑the‑air updates for vehicles); others use models that emulate the environment, providing early feedback as shown in Figure 4. The maturing end‑to‑end platform offers higher fidelity over time, supporting early verification & validation (V&V) and compliance work, which is crucial for many systems.

Overall, built‑in quality across architecture, design, code, system, and release creates a safe, predictable, and continuously improving delivery pipeline that aligns technical excellence with business agility.