Treat Your IT Automation Code Like Cattle, Too.
IT has to embrace standardization of the code that makes IT go or risk creating systems that siphon off the financial and efficacy benefits of IT automation.
I spent nearly a decade developing software. Embedded software. Web software. Client-server software. Middleware and mainframe software. I’ve professionally written code in nine different languages. Interesting thing is, I’ve don’t recall using more than two languages at the same organization.
Most enterprise organizations standardize not just servers and platforms and frameworks, but languages, too. There’s a goal of maintainability for software that has a life of more than minutes and is sometimes counted in decades. Maintainability is the characteristic of software that enables it to be picked up by someone else and supported throughout its lifecycle, regardless of how that lifetime may be measured. That’s often because of developer churn and the availability in the market for language proficiency as well as the costs of training and general maintenance. As a general rule, enterprises standardize programming languages.
That’s anathema to current trends in microservices and serverless computing that touts as a benefit its ability to support a highly diverse (polyglot) set of languages. Bob and his team can write in Go while Alice and her team develop in C or Java or Lambda. While certainly a bonus for developers (who all have their pet language) it’s not so good for enterprise organizations that need to maintain that software over time. APIs enable its integration and use, making its implementation language largely irrelevant in terms of application development, but in an enterprise the underlying code still needs to be maintained.
When it comes to IT automation – the internal digital transformation occurring on the production side of the business – it’s important for organizations to recognize the not only the benefits of standardization in the scripts and systems being built to support it, but the pitfalls of not doing so. Because you aren’t building these systems with the intention of throwing them away next week or next month or even next year. They’re a longer term investment that’s going to support digitization of deployment for years to come. That means laying a flexible but firm foundation that draws from best practices learned over decades by app dev in enterprises across the world, the first of which is standardization.
1. Maintainability
I know you like to write in PERL but everyone else uses Python. Developing automation in your favorite language makes it your pet, meaning no one else is going to be able to maintain it in the future. That’s bad for you, because you’ll be stuck with that thing for years, just like the goldfish you begged your parents for when you were eight. That’s bad for the organization because if you move out they’re stuck with code they can’t maintain and might be hard-pressed to support. A 2016 survey conducted by SIG and O’Reilly found that “70% of respondents believe that maintainability is the most important aspect of code to measure, even as compared to performance or security.”
It’s that important. View scripts and systems as shared resources that can be easily modified and supported by the majority of folks in IT now and in the future.
2. Compatibility
As more and more IT services are implemented as software, the task of keeping it up to date and compatible with other systems grows. If you think REST APIs eliminate the problem of “backward compatibility” think again. APIs are products (or should be) and thus they’re constantly evolving, too. And it’s worse in “the network” where differences even across the same line of products, with API differences from version to version that make standardization a Sisyphean task. It’s so widespread an issue that API standardization was number three in the list of technology challenges that need to be solved in the coming years according to one in four respondents to Smart Bear’s State of API 2016 report.
And because so many of the languages we use in IT are interpreted, changes from version to version can destroy carefully designed automation scripts and systems. Changes from one version of node.js to another can have a profoundly negative impact, from breaking a script to unexpected behavior. Standardizing on stable versions of scripting environments and languages will help minimize the impact of such changes.
And you’re still going to have to manage patches and upgrades for every underlying system powering that automation, so the fewer, the better.
3. Troubleshooting
Throwing standardization out the window means trouble for troubleshooting. This is particularly important if you’re moving to a time-to-resolution based metric for IT KPIs. The longer it takes to find the problem, the worse that metric looks. Standardization is an important component to reducing time-to-resolution. If Bob is the only Python expert on staff and he’s on vacation (and unreachable) and his script breaks, whoever is tasked with troubleshooting is going to be in for a long week. When you encourage IT to use their pet language, you severely limit the ability of others to troubleshoot and resolve issues. Even if Bob isn’t on vacation and he’s unable to find the problem, there are few who can help.
This is not an area you want to mess with. According to InitialState, it takes 30 times longer to fix a bug than it does to write one line of code. You can visualize the money slowly feeding into the shredder as you struggle to find a bug in code you’re unfamiliar with and then fix it. Not a pretty image. You can’t eliminate the cost of troubleshooting, but you can constrain it by eliminating the added time required by someone who doesn’t know the language in the first place. In production, time is money, so anything you can do to reduce time to resolution is huge.
That’s why as IT slowly embraces scripting languages, tools, and systems it’s not a bad idea to sync up with app dev. If IT standardizes on the same systems and languages (or at least some of them) you gain a legion of experts able to assist in troubleshooting and other dev-related processes like code-reviews. Because you are implementing code-reviews as a means to find the bugs before they cause trouble, right? Right?
Standardization is cited as a means to combat rising costs, and it’s certainly a key contributor to such efforts. But standardization has a variety of other benefits, too, including minimizing technical debt, reducing time-to-resolution, and simplifying day-to-day operational maintenance. Not standardizing at all certainly has the opposite effect on budgets and time by introducing complexity and bottlenecks that negate the benefits of automation and hold business back from realizing the profits and productivity it needs to grow. As you start – or continue on- your IT automation journey, remember to treat those scripts and systems more like cattle and not like personal pets. Because pets require constant, personal attention that IT can’t afford moving forward.