A featured contribution from Leadership Perspectives: a curated forum reserved for leaders nominated by our subscribers and vetted by the Construction Tech Review Advisory Board.

DZ Bank AG

Data Mining - Moving towards actionable output with automation.

Within the last five years, DevOps practices and ideas have spread widely among various industries, including highly regulated industries like financial services and banking. However, for more than a decade, the reference framework for IT processes has been ITIL which, for practitioners, often seems to be a contradiction. This conflict is reinforced by additional regulatory frameworks from national authorities and supernational organisations. The question which arises: Is it possible for DevOps to operate in a highly regulated environment and still be consistent with ITIL and other regulatory frameworks? In my opinion, the answer to the question is yes. Let’s discuss some common problems and pitfalls.

# Segregation of Duty

Segregation of duty between developers (Dev) and people from operations (Ops) is among the most widespread problems. Traditionally, segregation is enforced by the segregation of organizational units. This leads to the well-known handshake problem between dev and ops. Therefore, segregation should be implemented by segregation of roles so that people can still be in the same team. In a more advanced setup, this pattern can also be dynamic. That is, the same person can be a developer in one task while testing and approving other tasks where a different member of the team is in the role of the developer. Though, in this advanced case, an automatic technical recording is mandatory.

# Everything is Code

When you start setting up CI/CD pipelines the fundamental question arises, should next to the code pipeline (code) the additional data, like environment information and environment-specific configuration, be treated as data or as code.

Segregation should be implemented by segregation of roles so that people can still be in the same team

If treated as data users are allowed to enter the information directly into the production system (without test and approval). If treated as code every change, no matter how small, has to go through a rigid test and approval process, the same process as for every (business) application code change. If a team submits itself to this process, it is regulatory compliant, transparent, and all changes are traceable. However, the team feels the same pain as all the others committing to the process and therefore has a high selfinterest in continuously improving the process as a whole.

# Eat your own Dog Food

In the former section, I proposed that the DevOps team(s) should treat everything as code and consequently stick to the same processes as all other 'developer' within the organization do. Further, I encourage every DevOps team to eat his own dog food, which means the team should use the CI/CD pipeline for their own development and test of the pipelines. This sounds like a chicken and egg problem in the first place (and for sure it is). However, by careful investigation of the problem, almost every apparent circular dependency can be resolved even the CD for CD challenge.

Sticking to this (advanced) pattern, compliance is enforced not only on the process but also on the tool level.

# Conclusion

Putting it all together I propose that DevOps and frameworks, like ITIL, can be friends, and moreover, the DevOps team(s) not only provide great tools and pipelines for the rest of the organisation but also serve as lighthouses on how to use them properly and be compliant with processes in place at the same time.

The articles from these contributors are based on their personal expertise and viewpoints, and do not necessarily reflect the opinions of their employers or affiliated organizations.

Weekly Brief