3 min read
Something I’ve learned over the last 10 years of helping organizations with DevOps is that teams frequently struggle to define a software development process. You’ll find a lot of content on Google around refining your process, ensuring compliance in your process, making your process more secure, etc. But there’s not so much advice on actually defining one.
What I’ve heard from teams is that they don’t really know what their process should look like in the first instance. No two frameworks are ever the same and mapping requirements to a set of tools and processes is an underrated challenge.
But, whether a company is a financially regulated institution operating under license, or simply trying to conform to industry standards like ISO27001, SOC2 or HIPAA, there is a basic need to follow a software development process of some kind. And in my experience there’s no better guiding star than DevOps.
Defining good processes is hard and tools aren’t enough
One of the great benefits of adopting DevOps automation in your development culture is that it really helps you to conform to a process. A word of caution here though. It is a classic mistake to think that superimposing new tools on top of the status quo will somehow lead to great efficiencies. You don’t want to lock in conformity when a process is poorly defined or otherwise suboptimal. This will stop you from realizing the full potential of hard won improvements.
Simply adopting new tools isn’t enough. Being open minded about how they might enable new ways of working, of defining a new and better process, is vital.
This is harder than it might seem. In many cases software processes tend to become static and hard to change. Those doing the work can feel unempowered or even threatened by changes to the status quo. After all, their old process was how they’d passed audits in the past.
With DevOps we can share a common starting point
Having helped many customers through the journey from an old process to a new one I’ve seen many patterns emerge. Perhaps most surprising is that the governance framework, industry, and software technology don’t really matter - most software development processes are inherently the same.
That’s why we have created the Secure SDLC Process Template, as a common starting point for written process documentation.
We have distilled real processes used by leading regulated DevOps institutions to deliver compliant, secure, and audit-ready software. And we’ve done it in a way that means teams can get started quickly, and then iterate quickly. Our framework is based on the following basic principles:
- Easily configurable, versionable, and easy to replicate
- Self-host as an open source static website
- Shared with a permissive license MIT
- A common process documentation start point
DevOps Values and Continuous Compliance
The Secure SDLC Process Template is a defined secure software development process with DevOps Culture at its heart and it’s already used in many companies. It provides a great way for teams to understand process compliance while also showing how DevOps values can help them achieve the goal of continuous compliance.
One company using the framework successfully is Norwegian fintech, Stacc. Here’s the verdict from Espen, their CTO.
“When embarking on our ISO27001 journey, we knew we needed a process that could preserve our DevOps culture, but also stand up to audit. It had to fit our wide range of teams and technologies, while still ensuring standards and controls were in place. The DevOpsCTL process gave us a great starting point for building our own custom and evolving software process.”
You can find the framework at www.devopsctl.com, fork the repo, and get compliant! Pull requests are welcome! 🤗
