You’ve likely heard the buzzword, ‘DevOps’, tossed around -- boasting higher quality code, faster time to market, and continuous innovation. But, is DevOps for every team and organization?
As managers and executives, we know that the business environment in which we operate is rarely perfect. Team members are frequently inherited, constant training on the latest module is required, and budgets are often miscalculated. Many of these conditions contribute to delayed launches, subpar user experience, and unhappy business stakeholders. All in all, not a winning combination.
Knowing this, I’m sure you’ve been scouring the industry for the right solution. You’ve likely heard the buzzword, ‘DevOps’, tossed around -- boasting higher quality code, faster time to market, and continuous innovation. But, is DevOps for every team and organization? I’m not so sure... In fact, to help you assess the opportunity, I’ve put together 4 compelling reasons why your enterprise shouldn’t invest in DevOps:
1. Good enough is good enough
Some might argue that velocity is the most important yardstick to measure the success of agile software development teams. But, I like to subscribe the philosophy “if it ain’t broke, don’t fix it”. The real-time visibility DevOps offers for pipeline performance and management of multiple, in flight, projects might seem like a value add, but really, transparency and tracking is so overrated. Wouldn’t you agree? I prefer to look at successful project planning, collaboration, and team cohesion as a happy accident – too much transparency ruins the magic!
2. Thinking now is better than thinking big
Visibility into multiple ongoing projects can only lead to confusion. Better than moving multiple priorities forward is putting on the blinders and building something exactly as planned. While the capability to visualize all of your teams’ software pipeline performance exists, thanks to tools like CloudBees Jenkins, won’t all that access just keep you up at night? Better keep it simple and focus on one thing at a time – even if that means falling behind on other deployments and priorities.
3. The first idea is always the best idea
While some might suggest that mid-course correction and the ability to pivot when challenges arise is crucial to good technical leadership, shouldn’t we be focusing on validating the initial technical investment by committing to and executing the original plan? You may have heard the term “technical debt” floating around. This refers to the additional work that arises from taking a code “shortcut” to implement easy to run code instead of the best overall solution. The practice of DevOps reduces technical debt by embracing a shift in behaviour that ensures better quality code using automated testing and smaller, testable deliverables. While this may sound great on the surface, this practice works against the time tested strategy of “throwing good money after bad”. From our perspective, once you’ve already spent the time, money, and energy on code that works well enough, all you really need to do is to keep fixing it when it breaks, instead of cutting your losses and salvaging a floundering project. So, while DevOps best practices may pay off in the long run, it’s like they always say, bad habits are hard to break – so why try?
4. The Cloud may be the way of the future, but you’re sure Mainframe is making a comeback.
Without a doubt the Cloud has enabled IT organizations to spin up resources faster than traditional on-premise technology and solutions. But, do you really want to deal with a platform that enables continuous delivery, community resources, and access to growing partnerships? Won’t all of this access and collaboration just create extra work? Introducing culture change through innovation tools may contribute to a larger culture of innovation, but isn’t that just a lot of change and work for you? For example, DevOps on Azure not only offers training and webinars, but also solutions in their marketplace, like the CloudBees Jenkins Platform. With the arrival of commercial cloud services, experimentation, exploratory work, and collaboration has boomed – but, shouldn’t we be locking our doors to safeguard the company stockpile, no matter how dated it is?
Yup. Just one more reason that DevOps isn’t for you and your enterprise business.
***
You’ve likely realized that this article was written as a satire. At Architech we strongly believe in the power of a well implemented DevOps practice and we know our clients benefit from this approach. Wondering how DevOps can help you achieve your broader business objectives? We’re here to help! Reach out to us at info@architech.ca to start the conversation that will revolutionize the way your enterprise does business.
