Use Regulation As A Reason To Improve The Delivery Of Software, Not Impede It

Some time ago, I was part of a rather fluid set of software development projects. Value was delivered frequently and the process was rewarding for everyone involved. For years, I had invested in the positive impact of automation on increasing the frequency of delivering software and receiving feedback.

Over time, it became apparent that changes to the process were necessary to comply with regulation. Being on the implementation side of the equation and coming from the perspective of an external resource, I was often disconnected from decisions. Unfortunately, efforts to address regulation erected walls that made it challenging to expand the role automation played in the process. In the end, manual checks and balances overran attempts to automate. Delivering value was much more difficult and much less frequent.

Fortunately, it doesn't have to be this way. What I realized as I listened to the increasing requirements of regulation, was that automation wasn't just a tool to improve delivery. Automation could be used to meet the challenges of regulation without impeding the rapid delivery of software.

When I say regulation, at a minimum I mean addressing controls necessary to ensure compliance with laws, but I also think it can be taken further to ensure a consistent, high level of quality is delivered to customers. Specifically, regulation addresses concerns including confidentiality, accessibility, availability and integrity of information. It also involves tracking changes and enforcing authorization of changes and the ability to audit this. To summarize, it's about accountability.

Manually enforcing compliance often results in responsibilities being split across teams and departments. Work ends up being thrown over the wall, resulting in a lack of collaboration, an increase in the time to deliver and a decrease in the frequency and quality of feedback. The entire process grinds to a halt. Instead of addressing the issues that regulation tries to safeguard, manual processes end up mitigating risk by slowing the process down so much it's hard to get anything done. If you aren't doing anything, there's nothing to worry about right?

Of course, this is really bad for business.

When I refer to automation I mean the capacity to automatically execute a process even if there's still a button to push to authorize the automation.

Here are some of the ways automation can be tailored to handle the needs of regulation without impeding the development and delivery of software.

Auditing changes

A cornerstone of any plan to automate the delivery of software involves a rigorous system of version control. Often, this leverages a distributed repository making the history of changes including who, what, when and why available to the entire team at any time.

Most teams already use a version control system to manage application code. It's just a matter of recognizing the history of changes is already audited and potentially integrating tools for non-technical participants to access the information.

With further investment in automation, artifacts to manage data migration, testing, configuration and deployment can be tracked alongside application code. This brings accountability to every aspect of change.

Authorizing changes

Automation involves a pipeline to build, test and deliver software. This pipeline is easily customizable to provide the unique level of accountability within an individual project. Addressing regulation involves fine tuning the auditing of this process to provide information about what changes were delivered, to which environment and at what time.

For more sensitive environments, especially environments that real users access, authorization can be added to the process. This authorization is manual, but only to the point of pushing a button to sign off on a set of changes being released. This allows for incredible flexibility in distributing authorization while not giving up any of the productivity and consistent auditing that automation affords.

The best part, the delivery process itself is documented, with changes that can be audited, in the form of scripts that are actually used to perform the delivery. Without automation, this process inevitably ends up in outdated documents describing a set of brittle steps to someone in another department to mindlessly click through in a feeble attempt to separate responsibilities!


  • Migrating confidential data - Occasionally, when releasing software, changes have to be made to confidential sources of data. Manual processes open these sources to designated individuals, for a limited time window, to perform the changes. With automation this is no longer necessary. Scripts to migrate data sources can be automatically tested, thoroughly tracked, authorized and applied without opening special access. Most organizations probably don't have trust issues, but think about how much easier it is to prove due diligence when you have this level of automation.

  • Test environments - Automation can be used to scrub data sources for test environments. Not only does this save time, it simultaneously decreases risk. As test environments more accurately reflect data in real systems, the development process will accelerate. Instead of opening access to real information when issues arise, developers can use pre-scrubbed, recent information to quickly replicate and fix the problem.

  • Testing user access - Sensible policies to address user level access to confidential information require some level of testing after each release. Instead of having a resource manually test with real accounts, all of these tests can be automated. For each release, this saves time, provides consistent verification and creates a history for auditing.

As releases increase, the burden on human resources stays the same, scaling the delivery of value to customers while maintaining a reliable process. Without automation, it's very difficult to be productive, let alone consistent, when working with confidential data.


Incrementally incorporating increasing levels of automation leads to a point when the state of a system can be regenerated at the push of a button.

When failure strikes, instead of relying on knowledge that remains tucked away in the heads of the few, we can instead rely on scripts that are exercised every day to rebuild our systems. This level of automation proves that we have prudently invested in the ability to rapidly respond to failure and provide the optimal level of availability!

The Time to Improve

Not only does automation provide consistency, it also frees up resources from time consuming manual work. This time can be invested in many ways to deliver more value to customers. Perhaps more value can be delivered through exploratory review of what's being delivered. The time could also be invested in further automation, to literally stand on the shoulders of automation to reach even higher levels of accountability.

Commit to Improve

I could go on, this is just the start of how automation is often the best response to regulation. Inherent in the process is that every artifact and step of the process becomes audited, including the process itself. This level of automation demonstrates dedication to the highest levels of compliance.

While I advocate for automation as the platinum response to regulation, it's still important to avoid getting carried away. ROI must be considered when investing in automation to strike a balance between desired outcomes and cost. After all, if over investing in automation puts you out of business, you aren't going to deliver a decent level of availability!

Think about how automation would help address the regulatory challenges your organization faces. Commit to using regulation as a reason to improve your delivery process, not impede it. Get a competitive edge and increase the value you deliver to your customers at the same time!