Poorly Thought Automation!
How automation fails due to lack of collaboration and siloed cultures
Mr. X had a certain new found spring in his steps. After years of dealing with what has been delivered and making it keep running, through long change management forms which demanded more effort than the change itself, things have started to look better.
A good guy introduced his team to something called Infrastructure as Code. Mr. X was skeptical, to say the least, he had seen many such good guys come and add to the already existing myriad of tools and processes in his team's kitty. But the late night pizza dinners in office because production is burning routine had just refused to die. With quite a natural skepticism at the approach, he along wth his team started playing on some tool which let them define infrastructure through a descriptive language his mom could understand. That was the first wow! moment. And so they started moving all the mundane and painful things onto this new practice. It went well, deployment times reduced, the production was more predictable, well at least they knew when things are about to go wrong. And most importantly, those pricey jerks called developers (in Mr. Xs world) had lesser excuses to throw things on them.
But then the fire-fighting routine started again, this time, those pricey jerks called developers had a better trick! "You didn't write your code well enough! Let us do it". That was hard to swallow for a self-respecting admin who had stood the test of time & stress in IT Operations. Life was starting to get unfair again for Mr. X and his team.
At the heart of it was one little problem, when Mr. X and team wrote the DSL based code that defined infrastructure, it was extracted from a pre-production environment usually called “Staging” in most companies, and then there was another set for Production.
Seeing that the Ops team was “failing” to perform, again, his bosses called for another good guy. A person with a pleasant attitude, he spent the first day talking to most of his team instead of looking at the scripts as Mr. X would have wanted. The next day he went straight to those pricey jerks called Developers, much to Mr. X’s dismay. And to further deepen his distraught, took the production Infrastructure As Code scripts and put them straight in Development Environment. Mr. X was convinced that man was out of his mind. The next day he got a call from the Scrum Team to listen to their daily scrum as they had some things to discuss post-scrum.
Mr. X listened to the scrum meeting that day and realized the Scrum Team has no idea what the production environment looks like, or what are the restrictions and compliances. He spent that day making the production Infrastructure As Code scripts work on Development Environment, had lunch with those pricey jerks called Developers, and realised they were neither pricey nor jerks.
The Development Environment had more or less started mirroring production, and Infra As Code made more sense now than when it was just a cool tool!