From lean manufacturing to DevOps: The software factory revolution

In our journey through the evolution of compliance in the DevOps era, we’ve seen the limitations of traditional compliance methods and the high stakes of compliance failures. Manual processes, siloed teams, and a lack of automation have turned compliance into a bottleneck, hindering the agility promised by DevOps. In this third article, we’ll trace the roots of DevOps back to lean manufacturing principles and introduce the concept of the “software factory” as a revolutionary approach to integrating compliance and agility.

The Clash of Paradigms

On the surface, traditional compliance and modern DevOps seem fundamentally incompatible. Compliance emphasizes control, documentation, and risk avoidance, while DevOps promotes collaboration, automation, and experimentation. This clash of paradigms creates friction and inefficiencies in software delivery, as compliance struggles to keep pace with the speed of DevOps.

As Nicole Forsgren, co-author of the book “Accelerate,” points out,

“The old way of doing compliance doesn’t work in a DevOps world. We need a new approach that integrates compliance into the fabric of the development process.”

However, the concepts of lean manufacturing developed by W. Edward Deming sprung forth from his signature human-centered view of systems thinking, one that put people at the heart of organizational success. See Deming’s Journey to Profound Knowledge by John Willis.

The Lean Roots of DevOps

The roots of this new approach lie in the world of lean manufacturing. Two key principles from this world, jidoka and poka-yoke, have particularly profound implications for DevOps and compliance.

Jidoka, which can be translated as “automation with a human touch,” emphasizes the importance of building quality into the production process. In a jidoka system, every worker is empowered to stop the line if they detect a defect, preventing quality issues from propagating downstream. This principle was famously implemented at Toyota, where any worker could pull the andon cord to halt production if they noticed a problem.

Jidoka, which can be translated as “automation with a human touch,”

Poka-yoke, or “mistake-proofing,” is about designing processes to prevent errors from occurring in the first place. By making the correct action the easiest (or only) action, poka-yoke reduces the reliance on inspection and rework. A classic example is the design of USB ports, which can only be inserted in one orientation, making it nearly impossible to plug them in incorrectly.

Poka-yoke “mistake-proofing,”

The Software Factory: Industrializing Software Development

These lean principles found new life in the world of software with the emergence of the “software factory” concept. Just as the industrial revolution transformed manufacturing with standardized, automated production lines, the software factory aims to industrialize software development.

The software factory creates a standardized, repeatable path for software to travel from idea to deployment. By integrating tools, services, and practices into a seamless pipeline, the software factory enables the efficient creation and updating of software products while maintaining high standards of quality and compliance.

As Jez Humble explains,

" Lean product development directly drives software delivery performance… Fundamentally this is about is building quality in, make sure that the things you care about in your software are built in by developers rather than trying to fix those problems later."

Secure By Design

So in the software factory model, compliance is not a separate step at the end of the process, but an integral part of the development workflow. Compliance policies are codified as automated tests and checks that are integrated into the CI/CD pipeline. Every change is validated against these policies, and any deviations are caught and corrected early.

This “shift-left” advocated by CISA in the “Secure by Design” movement is to approach to compliance offers several key benefits:

Quality: Consider secure by design principle early in development, to reduce rework and fixes downstream.
Speed: Automated checks run in parallel with development, catching issues early without slowing down delivery.
Consistency: Compliance policies are applied uniformly across all changes and environments.
Audit-ability: Automated checks provide a clear, auditable trail of compliance.

By integrating security testing into the development pipeline, we transform compliance checklists into a continuous improvement loop, ensuring applications are secure from the very beginning. As Bob Lord, Senior Technical Advisor in CISA Live! Presents Secure by Design, explains,

“The first principle of movement will hopefully change [the software engineering] mindset from simply delivering code to actively considering downstream effects. The second principle is to think about radical transparency with shared facts and information.”

Jack Cable, Senior Technical Advisor at CISA, further explains

“modern software development is synonymous with better security, so companies reap the benefits of both greater security but also greater quality and better use their developers time have fewer bugs and offer a higher quality product on the market.”

Golden Paths, Policy as Code + CI/CD Governance: The Next Frontier

Taking the concept of shift-left compliance to the next level, we arrive at the idea of golden paths, “policy as code” and CI/CD governance embraced by many security engineers and DevOps leaders. In this approach, compliance policies themselves are written in a machine-readable format and stored in version control alongside the application code.

Golden path development is a standardized process for creating software with predefined routes to guide developers through building, deploying, and testing applications. These routes, also known as paved paths, outline best practices, steps, and required tools to achieve a specific goal.

With policy as code, compliance policies can be managed, versioned, and updated using the same tools and processes as the code itself. This enables a level of automation and agility that traditional compliance methods simply can’t match.

For a simple example, consider a compliance policy written in the Open Policy Agent (OPA) language:

This policy specifies that a service can only be deployed if it listens on ports 80 and 443, has encryption enabled, and has authentication enabled. By codifying policies in this way, we can automatically validate every change against the policy, ensuring continuous compliance.

However, this only scratches the surface of what’s possible using the lean manufacturing concepts of jidoka and poka-yoke.

Because together with CI/CD governance you empower developers to be autonomous throughout the entire SDLC process via golden paths and policy-as-code. With secure by design flow state achieved, you’ll unlock next levels of quality in continuous delivery.

These modern approach can include SAST security scans, validated secure containers, and traceable QA tests. It may require SBOMs, and Artifact Binary Provenance of every workload. That way you can alway know what’s running in production, trace back to the code, and validate the chain of custody and compliance.

Here’s a preview of where we are going with “Compliance at the Speed of Devops”

Compliance at the Speed of Devops

https://www.kosli.com/how-it-works/

The Cultural Shift

Implementing the software factory model requires more than just new tools and processes. It requires a fundamental shift in culture. Traditional compliance often operates in a culture of fear and blame, where the focus is on punishing mistakes after they occur. The software factory, in contrast, promotes a culture of collaboration, experimentation, and learning from failure.

This is the culture that allowed Toyota to revolutionize manufacturing with its lean production system. As Taiichi Ohno, the father of the Toyota Production System, said,

“Eliminating waste is not the problem. The problem is that management does not understand normal from abnormal.”

In a software factory culture, everyone is responsible for quality and compliance. Developers are empowered to make decisions, provided they also have the tools and processes to ensure those decisions are compliant.

The Journey Ahead

Transitioning to a software factory model is not a one-time event, but an ongoing journey of continuous improvement. The journey involves progressively shrinking the scope of manual compliance work by automating and integrating compliance activities into the development process.

The next article in this series will explore the concept of System of Record (SoR) for point-in-time compliance. By combining policy as code and compliance as code, building a SoR enables organizations to achieve continuous compliance at scale.

The software factory represents a fundamental shift in how we think about software development and compliance. By applying the principles of lean manufacturing, by automating compliance checks and integrating them into the development process, and by fostering a culture of collaboration and continuous improvement, we can turn compliance from a barrier to innovation into an enabler of it.