Three Guiding Principles for IT Decision Makers Part 2: NoOps

In my previous post which focused on NoDev, in order to better inform our decision making we defined a computer as:

computer, n. Any device or machine (physical or virtual), that increases productivity by automating cognitive and algorithmic processes.

Automation is the key word in this definition. By automation we really mean eliminating the need for manual intervention in the execution of a process. I shouldn’t have to remind anyone why manual intervention is undesirable but here are the main reasons in no particular order:

• Slow — humans executing repetitive cognitive and algorithmic processes pertaining to the management of IT infrastructure are going to be undeniably and drastically slower than computers.
• Error Prone — It doesn’t matter how many times a human has executed a repetitive function, statistically they will make errors far more frequently than computers.
• Costly — whenever one assigns a human to do work that a computer can carry out you can expect a substantial rise in the total cost of that activity to your business.
• Insecure — humans can be easily manipulated to leak data, open access or otherwise compromise the security of your business.

Given the above, we should consider which processes require manual intervention with great care. The term NoOps is not new (unlike NoDev for which I have found no precedence) and I strongly recommend readers visit Adrian Cockcroft’s Blog: “Ops, DevOps and PaaS (NoOps) at Netflix” (March 19th 2012). Here’s a short quote from that entry to whet your appetite:

This is part of what we call NoOps. The developers used to spend hours a week in meetings with Ops discussing what they needed, figuring out capacity forecasts and writing tickets to request changes for the datacenter. Now they spend seconds doing it themselves in the cloud.

All the activities described above, the information exchange between developers and operations, capacity forecasts, change requests, etc are needless dependencies created between developers and operations that once removed naturally allow the simplification of processes, their standardization and ultimately their automation. This brings me to my first NoOps assertion:

Eliminate all dependencies between application teams (broadly developers) and infrastructure teams (Networks, Storage, Database and Middleware).

To put it another way:

Deploying code into any environment should be the job of the application team that owns the code, NOT THE INFRASTRUCTURE TEAM THAT OWNS THE INFRASTRUCTURE.

Having a centralized operations team that is responsible for execution of code releases to infrastructure that they “own” is, in my opinion, an appalling miss-allocation of enterprise resources. This form of organisation now makes the operations team responsible for something they know nothing about (the application) and disenfranchises the development team forcing them to “knowledge transfer” to the operations team when they should be coding the next set of features demanded by your customers (well that’s what your competitors developers are doing…)

What is more, one almost invariably finds that the centralized operations team seem to take pride in the extent of manual intervention captured in their runbook. The amount of manual poking of systems is almost a measure of their importance and a reflection of their job security.

Rather than allocating resources to building the systems that facilitate fully automated provisioning (build, test and deployment) time is wasted dealing with lengthy release cycles and mopping up the miss-configurations after every deployment.

Application teams should have the ability, given the correct roles and access controls, to self service their infrastructure. To deploy their code, make any necessary configuration changes and liaise with other stakeholders’ without any intervention from operations and in a manner that is fully traceable to auditors. This can be facilitated, safely, on shared infrastructure given the use of the appropriate container technologies that can isolate workloads and user interfaces that lift the burdens of regulatory and compliance demands on process workflow.

Just as every line of code should be considered a liability and not an asset, every manual intervention should be considered a miss-allocation of resource in poorly thought out process which is costing your business, alienating your employees and destroying creativity and value.

Let’s distil our second NoOps assertion:

Eliminate all manual intervention.

While you’ll may never be able to fully automate every aspect of your operations, for example some regulators demand four eyes process approval and execution, rigorously challenge the unthinking orthodoxy which currently governs most of your IT processes. Automate, Simplify and Standardize; I subscribe to this mantra but one has to proceed in the right order, that is, Simplify, Standardize and then Automate otherwise you literally risk making an ASS out of your IT automation efforts.

I can say with a high degree of certainty that any failure to automate a process could probably be traced back having made no attempt to simplify the process before automating it. No attempt was made to challenge the process; to question who is doing what and why before automating it, indeed no effort was made to question the existence of the process in the first instance.

Once a process has been simplified, standardizing it follows almost naturally. Stakeholders adopt your process because is it simple, it saves them time and generates value for them.

The opposite is also true, a poorly thought-out, complex process will never win buy-in from users. Any attempt to put lipstick on such a pig will be fraught difficulty often resulting in the vast majority of users and stakeholders finding exceptions to your attempts to increase adoption of the offending process.

Simplified, standardized process with broad adoption and use are the ideal targets for automation. They yield the largest benefit in terms of productivity gains per cost unit and also have the benefit of increasing stakeholders confidence in IT with every process that is quickly automated. Once a culture of automation has been created a virtuous spiral of Simplification, Standardization and Automation is established resulting in continuous improvement. A culture of automation will also attract the right kind of talent to the business, i.e. knowledge workers that want to generate value for their co-workers and customers, not IT workers that want to plumb hardware into datacentres.

For me NoOps is simply the way I would design my IT systems given the constraint to maximize productivity, (profit) while securing the business. The alternative is miss-allocation of resources, and the managers making those decisions should, I am afraid, be swiftly removed for the sake of the investors in that business.

In my next post on the 3IT principles I’ll focus on NoIT. To give you something to look forward to, I’ll leave you with the key assertion from NoIT:

Eliminate IT from the business.

:)

“In the City respect is everything”