We tell our children, “Sharing is caring.” In the work place, though, it’s sometimes a different story. A big catch phrase in DevOps is to “eliminate silos” so that the work can be shared and continuously flow through the pipeline. In reality, what I see is that the silos are staying up and being fortified from within, and there’s not enough sharing.
Why is this the case? The problem is a focus on automation.
Hang on just a second. I know you’re thinking: “isn’t automating everything what DevOps is all about?”
Yes, it is. But maybe the DevOps community is too focused on the question of what to automate, rather than why they are really automating.
When the DevOps clarion call of automate everything echoed through the valley, teams and individuals started picking off low hanging fruit for quick automation wins. They introduced more open source tools, maybe a little GitHub, Jenkins, Ansible, and of course Python, as the glue that holds the whole thing together. Next thing you know, the developers automated themselves into a very cool, but also isolated, silo.
It turns out that a lack of automation was a symptom of lack of speed and agility, not the actual problem, and the root cause was something different. So, if a lack of automation is a symptom of a lack of agility, what is the root cause?
Maybe it’s a lack of self-service.
If you are delivering a service, either to an internal or external customer, it’s best you work on providing that service dynamically, and through self-service on-demand.
Until the mantra in DevOps becomes, “on demand, globally accessible, self-service” as a service delivery standard, I’m afraid the silos will remain, and new ones will be erected.
It’s in Our Nature
I notice that while parents are very adamant about teaching their children to share, they totally roll over every time a child doesn’t wait for his or her turn. Kid tries to grab toy. Parent tells kid to wait his or her turn. Kid looks at parent with a look on his or her face saying, “Wait? You’ve gotta be kidding, right?” Kid goes over to toy shelf, grabs similar toy and gets instant gratification.
Whether a toddler that just wants a toy, or a developer that just wants an environment, it’s very natural to take the path of least resistance. And, if there’s some other way for instant access to something, that other way instantly becomes the default way to go.
Shadow IT is the organization’s problem. The way to solve that is to become the path of least resistance. Not all services should be taken in house. You’ll still want to rely on third party service and tool providers and leverage Shadow IT visibility tools. But you can’t outsource DevOps.
If you’re in DevOps mode and are finding trouble breaking teams out of their silos, look at where they rely on manual IT for environments, data, feedback, etc., and see if you can’t work on providing one or more of these services on-demand via self-service.
And don’t worry, you’re not alone. The DevOps journey is chock full of barriers. Check out the results of our 2016 DevOps survey, or the accompanying webinar.