Business is essentially software-driven these days and in the era of AI generated code the need for better software delivery compliance tools has never been more critical. For companies in regulated industries, and those simply seeking higher quality software delivery, with processes and effective controls, compliance was already a significant challenge. Compliance and audit are closely related, and too often the approach has been to wait until the audit happens, and then hustle and hope. Oh the spreadsheets and interns! But unlike in years past where a set of batched application changes might occur every six months with a new release, today they are happening multiple times a day. The classic questions of who changed what, when, and why, and whether they had permission to do so, are significantly harder to answer. Version control gives us some answers, but certainly doesn’t offer a comprehensive view of the software delivery process, isn’t a system of record that provides a management backbone for software delivery that will also stand up to the needs of auditors.
Regulators have mercifully become more comfortable with modern software delivery in recent years- thankfully it’s now rare that they explicitly require you to take a screenshot of every app change, with a written explanation, for audit purposes. And yet – screenshots and documents, duct tape, chewing gum and band-aids, and an awful lot of time-consuming labour, remain the norm in many organisations. So how do we enable better processes, and software engineering cultures, that we can regulate and manage effectively? The answer, as is so often the case, is with better tools. Tools can drive the culture change.
We’re going to need a system of record that provides out of the box integration with all of the tools enterprises use to build software, that can then be used to report to multiple stakeholders. Engineering shouldn’t need to throw people at the problem. At the moment cost of audit is a strategic issue in companies in pretty much every mature industry sector – reduce costs and administrative overheads of audit and compliance, and you can focus on engineering and new application functionality, increasing overall business velocity.
But with buyers in different sectors all seemingly calling software governance and compliance different things, how are we going to standardise? A few years ago at DevOps World in Porto, hosted by Cloudbees, I spoke to a group of senior architecture people from different industries at a lunch about compliance – what was most striking to me was not how different the problems were in different industries, but rather how similar they were. It was amusing at the time to see folks from an automotive company’s shaking their heads as they realised how similar the issues facing them were to the pharma company talking at the same table. There is definitely a case for a horizontal technology approach, rather than one focused on vertical industries.
I recently spoke to Mike Long, CEO of Kosli, one of our clients, about the growing need for better tools, and a way to describe them to different stakeholders. It’s a good conversation – Mike is thoughtful about the challenges and opportunities. As he says:
Change Advisory Board meetings are still really common in financial services advisory board, where you know, as an engineer, you want to make a change, and actually you need 17 approvals, and you have to go to a meeting that happens on the second Thursday of every month and say, please, can I get in and this change window?”
Puts me in mind of Oliver Twist.
As Long says:
I think it’s actually quite helpful to look first at the industries, because you’re right. Everybody does see, we’ve worked with, automotive, defense, medical device manufacturers, financial services, everyone kind of feels like they’re very unique in this situation, because they’re either meeting different standards, like ISO and SOC2 and so on, or FedRAMP or military specs or FDA levels or, you know, essentially just getting audited by the financial regulators. But from a software perspective, the risks are kind of the same that you don’t want the X-rays to go off at the wrong time. You don’t want the car to drive off the road. You don’t want transactions to be going to the wrong place. Like, the risks are kind of the same in software, regardless of the outcome. It’s like, well, do we control the process? Do we know what’s going into the changes? Do we control the risk of those changes? And when you get down to the individual controls, they’re all the same – zoomed down everyone has to have a process that manages the risk of software development. Everyone needs to follow the the process they wrote down. And then the third part is you need records of the proof that you followed the process, because there’ll be someone coming to check. So that’s the same across industries. And then in between, you’ve got this layer of, well, like this is what like we’re going to meet, ISO 26262 if you’re an automotive or so on. So you’ve got this middle layer, which is very language specific to industry often, and quite vague. So you’ve got this big description of the requirements. And then when you go back down into the technology. It’s again, very concrete and similar. It’s like you must do peer review on your code. Like every code change must to be peer reviewed. Some industries call it four eyes review, or peer review, or never alone. But there’s some story around that, there’s by artifact, binary prominence or supply chain artifact tracking, there’s deployment controls, there’s release approvals, there’s, you know, really concrete stuff that every software org knows. So like at the high level, it’s super the same. At the bottom implementation level, it’s the same. And in the middle, everyone uses different language. And even in within an industry companies, we use different language for this stuff.”
So what do we call this stuff anyway? Some folks call it Governance Risk and Compliance (GRC) engineering, applying engineering practices to the GRC space. The Fintech Open Source Foundation (FINOS) is looking to standardise Common Cloud Controls. Software Delivery Governance? So if you’re in a regulated industry we’d really like to know what you call this move to automated compliance. So jump into the comments or email me and let me know how your organisation talks about it. And also check out the great work by our friends at Container Solutions on an Open Source Compliance Framework. Mentioning that, I am also getting flashbacks to some work RedMonk did literally a billion years ago – Compliance Oriented Architecture. But those were different times.
Kosli is a client, and sponsored this video. Cloudbees is not currently a client.
Rob Hirschfeld says:
May 29, 2025 at 2:32 pm
We see a similar need for Infrastructure Governance where consistent processes, strong controls, and regular audits create enormous value for RackN customers. They are delivering faster BECAUSE OF the controls. Unfortunately, it takes a lot of leadership investment to make these changes.
Also, we’ve observed the same power in process-focused tooling. When the tooling rewards process and standardization then it’s easier to pull the culture along.