Quarterly product releases and time-consuming software implementations don’t make the cut anymore, especially in IT-heavy enterprises where business success is a direct function of technology. To meet the evolving and justifiably burgeoning expectations of business, IT needs to adapt and endorse agility. Hyper automation of software development process is, hence, the present and future for enterprises. CIOs have already warmed up to the idea of enterprise DevOps as enablers of shorter time to deliver for IT. However, whereas most companies agree to the need of agility in IT, most of them are clueless about where their DevOps practices are going within a few months of initiation. Often, it’s because they are already too late in the enterprise DevOps game, and equally frequently, it’s because they do it wrong!
Several enterprises are guilty of restricting their DevOps to basic practices such as test script automation while ignoring the hard challenges of scaling the practices to span across IT. Then, companies face trouble in integrating DevOps within legacy processes and infrastructure. DevOps is here to stay, and CIOs and IT leaders would do well to be on the watch for telltale signs that they’re doing it wrong. Here are some of them.
You’re thinking costs, prices, payoffs, payback periods
DevOps is a mindset, and mindsets are not brought, they’re cultivated over time and ingrained in the culture of doing things. Many CIOs are disoriented by the conventional IT response to market-changing concepts and technologies – buy them. The “buy” approach doesn’t work with enterprise DevOps, because this concept is about a transformational change in the principles of IT management, and doesn’t even need you to buy software, technology, tools, or space. Of course, you could speed-track things by on-boarding expert DevOps consultants, but that’s basically all that you can buy in terms of DevOps. The rest of it stems from operational discipline, relentless monitoring for process gaps, and ingraining the idea of velocity in work. So, if most of your DevOps talk is about the budget, chances are you’re not doing it right.
You’re drooling over configuration management tools
Truth be told, tools are a vital part of DevOps, but then, every IT management approach needs tools. Configuration management tools attuned for DevOps help you speed-track things. Then, you can put together your own tools to automate manual activities such as code testing, server builds, deployments, etc. Automation is a vital pillar of DevOps, and you will need tools to bring that about. However, that’s not what makes DevOps successful over the long run. DevOps is about practices that let you identify areas of automation, and help you leverage existing tools to automate them quickly. The tools are the enablers, and automation is the approach. It’s the DevOps principles and practices that, mastered over time, bring about significant change in your enterprise IT’s speed to implement.
You wait for the ideal opportunity for automation
Enterprises that are already reaping the benefits of DevOps realize that every incremental effort to bring in another level of automation will make code deployments of the future exponentially faster. On the other hand, enterprises that prefer to wait for the ideal opportunity for automation of IT practices are bound to fall behind. Remember, almost every IT process is out there on the drawing board for you to automate, right from deployments to code check in, from server builds to testing. Do you find yourself stressing over code deployment readiness checks once every week or bimonthly? It’s clear; you’ve yet to hit the highway in your DevOps journey.
Your code deployments are a monthly cycle or even less frequent
Do you send new codes in production environment once a month, or even less frequently? You’ve got work to be done, and that’s what DevOps is here for. DevOps is about having developers check-in their code for automated testing as frequently as possible, followed by deployments in production equally frequently. Here’s how things work in enterprises that are mature in terms of DevOps. Developers can check in their code through series of automated precheck-in tests, followed by a round of automated production readiness checks. Then, the code goes to production servers and performs stably. The scope and accuracy of testing scripts is what enables this super agile process. Evaluate your IT processes and ask yourself – how far are we from achieving this level of continuous deployment maturity?
You’re constantly blaming developers who messed up
Blame is a shoddy aspect of IT management; unfortunately it pervades all enterprises. DevOps concept, however, is about making systems robust enough to weed out chances of production environment disruptions. Consider a scenario: A developer tests his code, gets the go ahead from automated testing, and yet the code breaks production system. The traditional IT response is to revert the code changes, send out business apology emails, and take the erring developer to task. DevOps, on the other hand, promotes the culture of shared responsibility and ideology systems improvement. Such a scenario, in a DevOps environment, would be the beginning point of analysis to understand why the automated tests were not able to account for the difference in testing and production environment, followed by effort to update the test scripts.
Your development and operations people communicate like they did before
If this is the situation, you either don’t need enterprise DevOps, or need to do it significantly better. A core tenet of DevOps is to bring down the communication walls separating development and operations personnel. It’s not about developers having drinks with operations managers, but certainly is about making both teams better, quicker, and more agile. And having convenient communication channels to manage seemingly chaotic situations around super frequent code releases.
Getting to teamwork
These are times when business and IT have to work hand in hand like they never did earlier. The single biggest grudge that business has from IT is the time it takes to get things delivered and corrected. Enterprise DevOps, done the right way, is the solution.
1 thought on “Telltale signs you are doing enterprise DevOps wrong”
how about leave shit alone ops…
fuck updates , fuck new shit. Make something that works and leave it the fuck alone