I've talked many times about the productivity benefits from automation. In this episode, I talk about the auditability benefits we get from automation - something you could describe as a side-effect. I discuss:
Or listen at:
Published: Wed, 22 Jun 2022 16:00:25 GMT
Links
- Episode 19 - Continuous Integration
- Episode 20 - Continuous Delivery
- Episode 21 - Continuous Deployment
Transcript
Hello and welcome back to The Better ROI from Software Development Podcast.
In this episode, I want to continue to look at the side-effects we can find in automation.
Automation is great - but it does come at a cost, so we need to try and justify the benefits that we get out of it - to justify that return on investment.
Now, most of the time we can see that in productivity. And in last week's episode, I talked about the benefits you get as a side-effect in terms of your increased security. This week, I want to talk about the side-effect of Auditability.
So when it comes to automation, there are many possible places that we can automate within our software development processes. However, for this episode I'll only be referencing Continuous Integration, Deployment and Delivery - so I'll give you a brief recap of those before I start.
We need to build our software for it to be useful. Historically, we may have done this on local development servers, which could often result in the "worked to my machine response".
Continuous Integration provides us with dedicated services to build consistent, clean results and not be subject to the vagaries of individual setups of individual developers PCs. And it also provides a great place to run all of our automated tests.
Continuous Deployment takes our built software and allows us to deploy to our servers at the push of a button. We automate the manual steps needed to download, install and configure our software - avoiding many of the mistakes that come from the manual approach - and of course allows us to do it quicker. Changing something that may well have been an overnight, or even a weekend event, previously to being a trivial activity that can be done multiple times per day. And again, it also provides a further place to run automated test against our production release quickly highlighting any release failures and allowing for rapid rollback.
And Continuous Delivery takes us a step further by reducing the need to press that button. By automating all of the approval processes - all of the things that led up to us being allowed to press the button under Continuous Deployment - Continuous delivery allows us to entrust to the system to ensure that everything has been done, avoiding the manual mistakes of either missing steps or not knowing even how to progress. Again, it's repeatable. Again, there is time saving. Again it allows us to cut down on the time it takes us to get the investment we've made in our development work into production where we can start to see the benefits.
I talk more about Continuous Integration, Deployment and Delivery in episodes 19 through to 21. I'll include links in the show notes.
So now let's move on to talking about the Audibility side-effects of using automation. There's a lot of similarities with the last episode, having automated systems helps us produce logs and with it a level of non-repudiation - much greater than we could have from just using a manual checklist.
And this is great for providing evidence for any audit checks.
Most organisations will have some form of audit check performed on them, be it an internal audit for their own compliance, be external audits to be allowed to handle and process credit card data, or it may be audits from industry bodies or governance organisations - audits are a necessary part of doing business for many organisations.
And the logs and the level of non-repudiation that comes from automation can go a long way to provide that evidence.
Take, for example, audits for credit card processing often focus on the controls that you have in place - controls for accessing any sensitive data, controls for any software processing that sensitive data, controls for confidence that that software and data hasn't been tampered with.
One of the first questions will be who has direct access to that production, data, software and systems.
If you're having to build and deploy manually, then every person that can do it becomes part of the scope of that audit. You will likely need to focus on ensuring segregation of duties to satisfy the audit. You will likely need to demonstrate that the developers do not have access to the data or the servers leading to complex handovers with the operations team that are allowed on the servers. Not only does this lead to complexity of process, it increases delays, risks and mistakes every time there is a hand off.
Whereas by automating the build and deployment of software you are removing, or at least minimising, the number of staff that have to have direct access to those sensitive systems.
It can really help to remove a whole class of audit questions.
By having the build and deployment via Continuous Integration, Deployment and Delivery in place, you're able to demonstrate that process that all software is going through, allowing focus on the automated checks rather than every member of staff in the team.
Another example I'd like to look at is the replacement, or streamlining, of the CAB process.
Many organisations have a Change Advisory Board that act as gatekeepers for any production change. This will have been added as a control for risk - risk of releasing the wrong thing, risk of breaking production systems. And this all made sense when we didn't have better ways of handling those risks. But now, with an ability to automate those tasks and limit risk, much of this is not just superfluous but actually causing our organisations harm.
While well-meaning, many processes simply have not kept up to date with how modern software can be delivered.
For example, in one organisation I was asked to stand in for the Head of Architecture to provide signoff for every change going through CAB and thus into production. When I asked the Head of Architecture what actions they took, they responded with "I just approve it. I don't need to check anything".
While I'm sure there had originally been a reason for involving the Head of Architecture on every production change, it had become one of simply rubber-stamping it.
In the same organisation, most of the changes also have to be approved by the CEO. More often than not, the only time the CEO would reject or question a change was because there wasn't enough or clear enough explanation of the change. This resulted in a lot of work to clearly document the change - just for the CEO to approve it into production.
This was all incredibly wasteful and caused the organisation harm.
Much of this bureaucracy was in place to provide an audit trail that the company had control over what changes were being made to its production systems and data. Most of it was rubber-stamping and nothing more than providing evidence to any auditor of that supposed control.
Most of this, from a control perspective, could have been removed. Any actual checks could have been automatically performed during the Continuous Integration, Delivery and Deployment stages, which would of course provide greater audibility than any manual process.
While I'm sure the manual procedures have been put in place for a good reason and everything is well meaning, by having this bureaucratic approval process after all the work has been completed, it was simply delaying seeing any benefit in that investment that you've made in development, something that automation could have resolved.
Money had been spent creating the hypothesis, the theory for the change. Money had been spent designing, building and testing the change. But before we could put that change into production to actually gain some benefit from that investment, gain some value from it, we had to spend additional money being able to approve the change. And all of this was delaying the return on that investment.
Many of these approval processes could have either been removed or automated, allowing that investment made into our change into production and providing benefit sooner.
If you're thinking about automating an audited process, make sure you talk to an auditor first.
Many external auditors will have had, or seen, similar in many organisations and they can potentially provide good advice on good practise. But the key here is what do they need to see?
Often we don't improve our overly bureaucratic processes because they passed audit last time. We avoid improvement due to the perceived problems it could cause and the concern that "we may not pass the audit next time". However, in my experience, auditors will welcome early conversations on any change. They will happily engage in any improvement processes. They'll happily provide clear advice on what they expect to see to be able to satisfy whatever audit they are carrying out.
In this episode, I've talked about the Auditability side-effect benefits of Automation.
We get so much audit evidence as a side-effect, much of which puts us in a stronger position than the comparable manual processes.
We should not fear automating audited processes as often we will achieve a better result for the organisation and for the auditor. Remember that the auditor is there to help us succeed. They're be interested in this and they will be able to help you make it better.
It's safe to say over the years to come, the burden asked to provide audit evidence is only going to grow. It isn't going to shrink. As we're asked to demonstrate how we handle things like security, how we handle things like supply chain attacks, we'll be asked for more and more evidence. We'll be asked for more and more data.
And alongside this, we'd be expected to provide provenance of our software, not just by auditors, but by our customers. They'll want to be confident that we know where our software has come from, how it's been built and the controls we have in place to ensure that that is safe, and their data that's going through it remains secure.
Thank you for taking the time to listen to this episode and look forward to speaking to you again next week.