Anyone who has been following what we're doing at UpGuard knows that we like to keep things simple. With this in mind, we like to look at DevOps through the lenses of Collaboration and Automation. Almost all vendors in this space focus on the latter. Why is this? Well, automation tool vendors do it by definition. In reality the collaboration angle is avoided by vendors because it is hard. If you're looking to the market for assistance in "doing" DevOps then you'll be drowning in offers for help with automation. Help with collaboration? Not so much.
Is your automation initiative negatively impacting collaboration?
Is this a problem? Isn't tackling half the DevOps battle still a good thing? Well, yes and no. In my last blog post (You're Doing DevOps Wrong: Automation in the Enterprise) I spoke about the risks of rushing into automation without laying the appropriate groundwork of visibility and accountability. Another risk of automation though is diving into it without an awareness of its potential impact on collaboration. Tackling half a problem may seem better than doing nothing, but if you are giving with the right hand whilst taking with the left are you really better off?
Automation tools suck at collaboration. There are three main reasons for this:
Pay no mind to the neckbeard open source warriors. They may be comfortable with arcane DSLs and esoteric programming languages. Heck, individuals within your organization could be too. The key word in that last sentence though is "individuals". The focus of this blog post is the impact of automation tools on collaboration. Automation tools have notoriously steep learning curves. This restricts the number of users for that tool within your business. Usually to a single team. Often to a single person. How do you expect your devs and ops teams to play nice if one group holds the keys to your automations? It won't happen. With sufficient buy in up front and significant investment in training you may have several glorious months of cross team contribution. We've seen time and time again though that this is very hard to sustain.
- Your automation project is driven solely by one team
- People who should be using the tool are refusing to for technology/capability reasons
- Religious debates over technology abound
Our entire infrastructure is now defined in code
Ask any CIO what they think of that statement and I don't think you'll get an overly enthusiastic response.
Recipes, manifests and yaml files are effective means of automating systems. They are an awful way of storing desired state though. Desired state should be visible. It should be easy to understand and simple to modify by any stakeholder. Be they development, operations, security or even QA.
If the systems that define your desired state are not open and accessible then collaboration will suffer. When knowledge is locked up, collaboration breaks down. Finger pointing ensues because people lack the means to justify and validate their points of view.
- Everything is automated but few, if any, can articulate desired state
- All reports on configuration state go through one team (or person)
- The relationship between desired state and business goals is non-existent
Enterprises embarking on an IT automation initiative are prone to replacing business improvement metrics with vanity metrics. Agility, speed to market and costs are harder to measure than "Number of applications automated".
There was a great quote from Kevin Behr in our webinar last week. He said:
Automation is necessary, but not sufficient, for Enterprises. It doesn't buy you awareness.- Kevin Behr (Phoenix Project)
The automation of a system is often considered an "end", not a "means". Bad process and bad design become codified because they get buried. Taking the necessary steps to ensure collaboration on requirements is often pushed aside in the interests of simply getting it done.
- Success of your automation project is being measured in number servers automated
- No one is talking about business benefit
Automation done right provides enormous value for businesses. If you are doing it under the guise of a "DevOps" initiative though it is absolutely critical that you are aware of the impact you are having on collaboration.
Automation that kills collaboration equates to zero sum DevOps. It represents such a huge risk to the Enterprise because its effects can take months to become visible.
Be aware of the risks going in. Watch out for the warning signs. Don't sacrifice long term success for short term glory.