How you can make them work together.
DevOps and Segregation of Duties (a.k.a Separation of Duties) or SoD are not usually spoken about in the same sentence. DevOps is all about removing barriers and minimizing hand-offs, while segregation of duties is about adding gates to minimize risk.
When working in highly regulated industries, such as Finance or Healthcare moving teams towards a DevOps way of working can by quite challenging. This is due to the fact that regulators want assurances that only requested, approved and fully tested changes make it to production. In these situations the main control that is used to give this assurance is in fact Segregation of Duties.
Segregation of Duties
So what is Segregation of Duties?
Separation of duties (SoD; also known as Segregation of Duties) is the concept of having more than one person required to complete a task. In business the separation by sharing of more than one individual in one single task is an internal control intended to prevent fraud and error.
In the software engineering world, this basically means the person (or team) who developed the code cannot approveor deploy the code. Again, to prevent the accidental or malicious release of unauthorized code into production.
In contrast, DevOps is about bringing together (or merging) the two once discrete functions of Development and Operations into one. By having the same team that develops and tests the code, also support the operation of the code in production. Segregation, i.e. the act or practice of segregating; a setting apart or separation of people or things from others or from the main body or group, is the complete opposite of merging. Yet, this is still one of the most common practices to control what can or cannot be promoted to production.
What are the drawbacks of Segregation of Duties in DevOps teams?
- SoD can slow teams down by adding unnecessary hand-offs and has the potential to introduce errors. Every time a hand-off occurs, a transfer of information needs to occur, which not only slows things down but can also introduce a Chinese Whispers effect. Hand-offs not only impact the deployment of changes, but also responses to incidents that occur in production. In this scenario, who better to respond to an incident than the person (or team) responsible for the change.
- Shows lack of trust to teams which nurtures a culture of fear. DevOps teams need to be autonomous in order to get the full value and speed benefits that the practice preaches. In order to achieve this autonomy, the team needs to be trusted to do the right thing at all times. And in times when they do the wrong thing, they will be expected to take the responsibility of rectifying the error. Remember, with great power comes great responsibility (thanks Uncle Ben, R.I.P).
- The idea that SoD cannot address concerns relating to collusion. This is in regards to deliberately pushing unauthorized changes into production, whether for malicious intent or an attempt to undermine the process because of urgency. For example, “we didn’t have time to do full regression testing because we need to release tomorrow, can you please sign this off anyway?”. No matter how many controls are put in place, you cannot escape this issue.