Two kinds of DevOps: horses don't grow horns

The DevOps principles apply to horses and unicorns, but we act on them in different ways, even for different goals.

A new organisation engineering from scratch will implement Unicorn DevOps with an integrated tool chain, full automation, and a funky crew of culturally-selected hotshots sitting on swiss-balls.

An existing enterprise on the other hand is constrained by its individual bespoke snowflake servers, monolithic spaghetti applications, and large existing staff carrying cultural debt (What I call RealIT). In this situation we don't aspire to be a unicorn, only to move in that general direction. The unicorns are our navigational stars not our destination.

Horse DevOps becomes an optimisation exercise and a strategy for future improvements to architecture. We seek to improve throughput and quality of our existing value streams. Re-engineering a functioning organisation is an entirely different ballgame to standing up a start-up.

So when I am instructing on DevOps Foundation training and we go through the list of DevOps enablers, I am careful to emphasise that the absence of any one of the enablers does not preclude or excuse us from taking a DevOps journey - it merely limits just how far we can get. Every organisation - no matter how archaic and entangled its architecture - can improve culture and improve flow to some extent by applying DevOps principles: no cop outs.

Therefore to judge a horse enterprise by Unicorn DevOps standards is unreasonable: horses cannot be expected to grow horns. I am running an experimental DevOps Readiness survey with a client, and I quickly had to coach the respondents that rating the capabilities at level 1 or 2 on a scale of 5 is no shame for a horse. We are looking for an improving trend not the absolute level.

And consultants: don't tell a horse they can fly. It will end messily.

This is not to say that Horse DevOps and Unicorn DevOps are totally different things. Like a horse and a unicorn, most of the characterisitics are the same. The execution and outcomes are different but the principles are the same. Whether a horse or a unicorn, we still pursue

• trust
• empowerment
• iteration
• experimentation
• smaller increments
• smoother flow
• automation
• instrumentation
• feedback
• collaboration
• and community

But a unicorn seeks to fly, perform magic, and poo rainbows, whereas a horse is happy to run faster and learn to tap dance.

For a unicorn, the end game is continuous deployment with a batch size of 1 by small self organising Agile teams.
For a horse, the end-game is improvements in throughput and quality, with higher levels of trust and empowerment of happier people.

So much said is still about Unicorn DevOps. I want to hear more about Horse DevOps.

[Clarification: with enough time and money a horse can turn itself into a unicorn. Amazon completely re-engineered itself. If we had that much money we could too.
Meanwhile in RealIT my clients try to get a good job done with jaw-droppingly limited budgets, because they are not in competitive retail sectors.
Once you reengineer your core spaghetti applications into SOA, once you virtualise your servers and networks, once you refactor all your apps to standardise your servers, once you pay down your technical debt and cultural debt, once you lift your culture... then and only then you'll have glitter dandruff and rainbow droppings.