DevOps: The Internal Sell

As you all know, I’ve been living on my DevOps soapbox for what seems like decades and more projects than I can count – well – I can count pretty high, but since most traditional DevOps projects fail somewhere in the middle, the number is irrelevant (or irrational, if you are a mathie or geek like me); rather how I feel when things go horribly wrong. Fortunately, things have gone well on my projects recently, thanks mostly to my involvement with the git eco-system and the git team itself that are a fountain of wisdom.

Contemplating what makes good projects and what makes bad ones brings me to an interesting bunch of conclusions and myths:

DevOps success depends on choosing the right technology

Status: Part Myth

The right eco-system is really important for your success, and that part is no myth. It has to be capable of handling many integration points. It has to handle builds, tests, deployments, and most importantly it has to be able to coordinate between different platforms. But if you get into arguments about whether to use BitBucket, GitHub, or GitLab, with JIRA, Jenkins or Travis-CI or Trello, GitLab-CI, Ansible, Ansible-Tower, you are just arguing for the sake of arguing. I’m not suggesting one over the other, because you can do very similar things with each. The questions are: What are you trying to do? What integrates with your NonStop? What lower level, end-point, or edge support do you need? The common denominator is git. You are simply not going to be able to build a full-function DevOps eco-system built on SCCS, CVS, or ClearCase. Not for NonStop anyway. Integration at the edges, where humans and applications have to interact with your DevOps structure is the key success criteria.

DevOps success depends on choosing the right people

Status: Part Myth (a small part)

People are always the hard part of DevOps. I have seen the most ardent silo supporters be converted to DevOps advocates once they realize the power of the Dark Side… I mean automation. Even in development, we all know that the most fun parts really represent only 10-20% of what we do. The other parts are grunt work. Packaging. Approvals. Delivery. Yuck. People get it (being DevOps) when they realize they get to focus more on the fun bits, or at least their core jobs, rather than worrying about delivery infrastructure. If you build something useful and easy, people will come – assuming you can get past the initial phases of a DevOps project and not fall into the 78% failure rates, but more on that below.

But don’t count on everyone becoming converts so easily. I have seen nearly holy wars break out in places where people are divided on which the build engine to use. Honestly, who cares whether you are on Jenkins or Travis-CI? Well, you do when you are talking to NonStop. Jenkins is easier mostly because more of us have built integrators for it than Travis. But does this matter? Are the arguments productive? Not if you empower groups to do their own thing, while keeping the core process flows consistent across platforms. You can drop in the tools you need where you need them. So, Travis might work better for your Android apps, while Jenkins works better for NonStop, go with both, as long as the triggers are consistent.

DevOps success depends on Management Buy-In

Status: True

Someone has to pay the bills. That should say it all, but it usually does not. Management is going to expect instant gratification with a DevOps implementation project. You have X weeks and Y budget. Make it happen. Sounds familiar? I’ve seen Agile “implementations” go the same way and never work out. Let me quell another myth: Agile is not a methodology, it is a philosophy. To become Agile, you have to rework your organization, and that is a massive undertaking that could involve years. Treating DevOps like Agile is a huge mistake. DevOps, on the surface looks like a philosophy, but it has a series of very quantifiable technology changes that do not require people to change. But is it a project? No. Not at all. It is a series of simple projects carefully laid out leading to a robust pipeline with one key goal and a few side benefits:

Reducing time to market.

If your primary goal is not reducing how long things take, look again, because that’s why we do “DevOps”. It is about cutting down the human interactions with software so that business capabilities can get to customers faster. Full stop. To realize that, you may have to adopt Agile at some point, but only to the end that is improving delivery speed. You may have to reorganize your teams or recognize vulnerabilities or bottlenecks, and a well running DevOps structure can give you the data to need to figure that out. But it all goes back to the primary goal of achieving shorter time to market.

If you are on the technical side, and need to implement DevOps in your organization, it will have to be funded. Understand that the CIO is at the pressure point between compliance (enter your SCM solution) and time-to-market (your deployment plans and processes). If you can show what areas you can optimize to meet that goal, you might actually get approval and more importantly supportive management buy-in.