IT4IT DevOps Manifesto

I help a l

ot of organizations with their DevOps journey and implementation. Many times the organizations I work for are large enterprises or bigger companies. Because there are many teams within these organizations that have more or less the same requirements, there is often a so called IT 4 IT department, that is creating some centralized capabilities.

Although I think that IT 4 IT is not always a good option, because it interjects with the fundamental DevOps principles like autonomous teams, it can make sense if applied correctly.

When doing DevOps it is important to do this in a secure way. Especially in an enterprise this is top of mind and the reason why departments as Change Management, Release Management, Change Architecture Boards etc. exist. When it comes to security and enterprise regulations, certain things are required to be in place. Whether it is ISO, SOX , COBIT or whatever other framework is used to validate whether you are compliant, a few principles are important to have in place.

• Ensure integrity by having audit trails on code and artifacts
• Ensure the 4-eyes principle on every change to production
• Embed Security Testing throughout your process
• Prevent unauthorized (data) access

Translating these principles into an implementation often results in restricting access, close down functionality, denying actions and instantiating control authorities. Because, that is what we are used to.

For this purpose I created the IT4IT DevOps Manifesto. A simple set of principles that can be used in guiding people to make the right decision.

• Protect vs Blame
• Report vs Control
• Enable others vs Doing yourself
• Allow vs Deny
• Automated vs Manual

Protect vs Blame

When you implement something that results in an audit trail, it automatically becomes visible who did something. This blame culture is not something we want to encourage. Therefore, measures are not implemented only to see who has approved or done something. Implemented measures should contribute to higher protection, security or traceability.

Report vs Control

When you write tools to prevent people from doing the wrong things, they eventually will work around you. And worse, they will never learn to the right thing. So tools that check if the things are done right, need to be in place, but as a validation check. The report is sent to the people and it is their responsibility to do the right thing. Support, help and what else can be given but with great power come great responsibility

Enable others vs Doing yourself

Who does not like to be served? Can you create xyz for me or can you update abc? Rights, knowledge, time, here is always a reason why you sent the work to somebody else. But if somebody else does our work, it becomes their burden when something is wrong, and they become your bottleneck when you want to move on. So instead of DOING things for others, we do things WITH others and ENABLE them to do it themselves by automating or plain teaching

Allow vs Deny

Computer says no! When we take a stand that everybody is doing their best, we should consider allow (or yes) over Deny (no!). A request is granted and then checked instead of the other way around. Most of the things are allowed in the end, so why not revert the ones that were not OK in the first place. It is our responsibility to check as much as we can in automated fashion.

Automated vs Manual

In 9 out of 10 cases it is easier to do something manual then to do it automated and repeatable. But very soon you are in a position that you are only doing manual work. We automate everything we can. During our automation effort, we can consider to do it manually, but be careful with this!

I hope that it also can be of a benefit to you!