Standards vs Standardization in DevOps: The fine line between streamlining processes and hindering innovation

Standards in DevOps

DevOps Standards refer to best practices to follow; defining these standards involves putting together a set of foundational IT principles, and creating a common vocabulary.

Some of the key standards to be observed in DevOps services include:

• Observability
• Communication
• Continuous improvement
• Collaboration
• Accountability
• Automation

And then there’s Standardization

Standardization refers to an organization’s intent to streamline DevOps across the board. It is a framework to which all relevant parties in an organization must adhere to ensure processes are carried out within set guidelines. This is usually done by creating standardized tools. But keep in mind that there are two sides to standardization…

The good side:

1. Standardization offers a common vocabulary.
   This makes it easier to understand processes as well as control or change them if necessary.
2. Standardization offers common top-level principles.
   When centralized tools groups are created, it gives a global view of how things are being used across the organization. That way, best practices can be streamlined.
3. Standardization provides compliance-oriented “what to do” standards.
   It is a guideline of what is to be expected and therefore makes it easier to streamline work.
4. Standardization helps to budget.
   With standardization, organizations streamline budgets at a more centralized level and serve the needs of the organization across all groups.

But then there is the flip side:

1. Standardizing can be detrimental to innovation.
   While maintaining best practices is good, over-stressing prescriptive “how to do it” standards may have a stifling effect on the team’s ability to innovate or solve problems. There’s a temptation when following standards to follow them rigidly when possible. When standards become prescriptive instead of a set of guidelines, the focus is on compliance rather than outcome, which is not good. One needs to allow DevOps to evolve and create solutions without being bound by rigid walls of standardization.
2. Standardization may end up slowing down processes.
   Several smaller DevOps teams may be able to solve the issues “on the ground” rather than wait for a central team to implement a solution simply because that is what has been standardized. Also, some tools are good for specific use and not companywide. Standardization may therefore reduce productivity.

The ITIL example

Jayne Groll, CEO of The DevOps Institute, explains with the example of ITIL or the Information Technology Infrastructure Library. Initially developed by the Central Computer and Telecommunications Agency, UK, in the 80s, ITIL documented best practices in IT service management. It was viewed as a set of standards for improving IT performance but then lost steam as it was too rigid.

In an interview, Groll says that ITIL got over-standardized and couldn’t keep pace. Users of ITIL felt that they had no choice but to follow the rulebook religiously, as a result, there was no scope for flexibility and innovation, and ITIL is stagnating.

“In ISO 20000/27000, in the ITSM space, the rule on service management simply says, “You should record all your changes.” It doesn’t say how to record it, it just says it’s a great practice,” she says.

Meeting ISO 12207 standard for quality means following project-enabling processes and technical processes. Processes do not guarantee outcomes. Processes can be tested against 12207 but outcomes are auditable, so processes must be tweaked as needed to create the outcomes that are needed.

In short, standards and standardization are tools that can add a lot of value to your DevOps practice. But tread with caution to ensure your processes do not themselves become subservient to these tools.

CloudNow offers technology solution services that strike a balance between standardization and innovation to help manage costs, secure assets and maximize value. Talk to us today!