Get around the biggest disadvantage of DevOps: Cost
DevOps is expensive -- maybe too expensive. So, how can you slash the price tag? Instead of diving into a full culture shift, adopt only the processes that benefit your business.
When it comes to IT, there will never be a shortage of new structures and cultures -- and it seems that something new comes along every few years. I remember the big push for ITIL -- and, now, it's DevOps.
The challenge for IT isn't just alphabet soup by way of ceaseless acronyms. It's how these elements and changes affect IT groups. IT has always been fairly flexible to match the ever-changing nature of technology, but many of these terms originate outside of IT and managers attempting to ascribe labels and conditions on IT groups. The raw structure of many formal frameworks -- ITIL, for example -- is staggering in its demands for both human resources and overall costs.
This demand leads many companies to pull only parts of a new structure and fit them into IT ecosystems where it makes business sense and still has an impact. This large cost disadvantage of DevOps might indicate a cheaper option: piecemeal adoption.
DevOps comes with a price tag
DevOps, by definition, is a collection of practices that combine software development with IT operations to shorten lifecycles and support continuous delivery at high quality. While this sounds exciting, it also sounds complex and expensive -- and, well, it can be.
Additionally, DevOps only works for certain software applications; most organizations aren't committing multiple releases per day -- such as businesses in finance or healthcare verticals, for example. The types of applications in use need to drive the organizational conversation about DevOps adoption. But whether it is or isn't the right fit, there are a few things to take away from the conversation.
The description of DevOps never goes into detail about how to accomplish these tasks -- which is, arguably, another disadvantage -- but that ambiguity is where IT organizations can find a few concepts that suit a business need, without taking the full DevOps plunge. While there are several steps that occur in the full DevOps stack, let's highlight two key areas that can have a substantial impact: version control and automation.
The types of applications in use need to drive the organizational conversation about DevOps adoption.
Version control
Version control tools and techniques have changed over the years, but their basic premise hasn't. When you make a change, you increment a revision letter or build number and document the change. It sounds deceptively simple, but it answers the one question that plagues IT when something breaks: What changed?
But version control is not change control: Version control is about documenting and tracking changes. Change control is about managing the change via approval steps on documentation.
DevOps, on the other hand, is about agility and shortening that time window. Change control can be a barrier to speed, depending on the duration of the approval process. Replacing change control with version control enables that additional agility and speed, while retaining accountability and documentation, but without pauses for the documentation approvals.
Some people argue this method adds an element of risk. But the system that halts progress to review documentation might involve non-IT professionals who don't understand the proposed change's full scope and effect. IT orgs must ensure the paperwork is correct, regardless of the workflow in place, but, ideally, eliminate unnecessary delays for inexperienced reviews.
Automation
There are very few tasks and workflows that don't benefit from automation. Quality control and software releases are two such processes -- and not just via the oft-cited speed improvements. When it comes to software testing and release, consistency is the pivotal aspect that makes the process move along -- and speed is an added benefit.
Introducing variables can produce unexpected results in testing, which then delays deployment. A solid, consistent testing plan enables IT teams to narrow the scope and filter that data based on the single change in question. These testing results are a direct representation of the change and nothing more, which reduces the inclusion of random or irrelevant data.
Taking a more targeted, piecemeal approach to DevOps can enable staff to wear multiple hats in the efforts. Changes, such as revision control, are not so large that they impact the overall existing workflows.
A significant disadvantage of DevOps is ambiguity; as a concept, it covers a lot of ground. With anything that large or complex, it's never an exact fit for IT organizations. The right alternative to wholesale DevOps is to pick out the pieces ideal to a business; a la carte cherry picking is an acceptable decision in an ever-changing IT industry.
