The Problem With Purchasing DevOps
For the next time you're pitched a tool that claims to make your process certifiably DevOps.
Join the DZone community and get the full member experience.Join For Free
The IT domain is an extremely new addition to the cumulative total of professions in the world.
The success of IT-based companies and career successes of its practitioners naturally garner a lot of attention. It is only recently that large enterprises have begun to consider their IT shop as anything other than a mere cost center that sits there and sucks up highly-coveted funding. Many leadership teams understand that they have to “do better” with regards to their IT practices, but the definition of "better" is not clear, much less how to get there. Companies are desperate to modernize their IT shops, looking for change from within, adopting best practices across the board and throwing middle management at every buzzword they can find.
On the surface, this all makes sense. After all, if a business needs a physical building to conduct operations, you say “I want a building here, Mr. General Contractor, please make it to these specifications, and here’s how much money I have to make it happen.” Then, usually, it just happens. Sure, the budgets and timelines may be in flux, but ultimately there’s a reasonably clear plan, and all the steps to get to the goal of having a functional building are known in advance and can be planned for.
IT isn’t like this; in fact, it’s practically the antithesis of the idea that known inputs provide known outputs. The introduction of unknowns naturally creates confusion and frustration; individual contributors are mad that they’re getting told by management to adopt [insert new industry concept/tool here] with no roadmap provided, and less budget than it would take to actually do anything truly transformational.
One of the terms I’ve heard thrown around more often than I’d like is “DevOps.” Now, DevOps could be replaced with just about any other buzz-wordy term that floats about in the IT domain, for instance: Agile, Big Data, DevSecOps, Containerization, even “older” terms like "cloud" that to this day don’t mean much to non-IT people. This makes it extremely hard to bridge the gap between business goals and drivers, on the one hand, and IT practices and tools, on the other. Desperate to get a handle on IT modernization, management flits from practice to practice, tool to tool, over and over again in an endless effort to reach "IT nirvana." And by golly if we could just have DevOps we wouldn’t have to worry about anything, right? The image I always get when I hear these types of efforts coming from leadership teams is a well-meaning, but clueless person writing out a check for “DevOps.” “One DevOps, please!” this nameless executive says, throwing the check across the table. The expectation is that, once I pay this money, once I simply purchase DevOps, I’ll have what I want and my IT shop will be more stable, people will be happier, I’ll get a fat bonus because stuff will be better; granted, I have no idea what better entails, but better is the focus.
This is a trap!
It’s certainly a great sales and marketing gimmick that many companies that sell tools or consulting services can take advantage of: “If you purchase [insert thing here] then you, too, can have DevOps!” This is the equivalent of eating a kale salad for lunch one day and declaring that you’ve suddenly gotten healthy. Organizational health is just like bodily health. It requires constant vigilance and care. Purchasing a home gym won’t get you healthy, just like purchasing a new tool won’t get you DevOps. It’s a lifestyle change, it’s a total paradigm shift, and many organizations are simply not prepared to make that shift. At least not overnight.
Here’s the part that sucks: just like getting healthier, you have to start small, and you have to stick to your regimen. There are multiple ways to start on this journey and each organization will be different. But the overarching theme across all DevOps transformations is that you have to identify which area/team/project/product/etc. is doing the most DevOps-y stuff, and work with them to get better at operating under a DevOps mindset, come up with plans to upskill those employees and spread those learnings to other parts of the organization.
Typically, it’s usually easy to find at least one person or team that’s preaching DevOps from the mountaintops in an IT department, and if you don’t have that, it’s probably time to find one. After that, the road to organizational health is nebulous. Perhaps you have long-standing architects that still advocate for bare-metal builds, running custom-compiled binaries because “it’s more secure this way.” Perhaps most people in the org understand the best practices and have an idea of where the org should go, they just haven’t taken full advantage of the existing toolset and knowledge base. Regardless, there’s varying levels of change you’ll need to prepare yourself for. If an organization is so set in its ways that change has been repelled time and time again it may be time to completely toss the pieces in the air and see what happens when they come back down.
Before you go down the re-org route, it’s important to understand what it is your future IT organization looks like. What does DevOps mean to you? For instance, when everyone says, “We’re doing Agile,” what does that actually mean? Do you just want your teams doing Agile, doing DevOps, or is it better to say that you want your teams to be faster to market, produce better quality products, and have more fun at work doing so? I’d say it’s the latter.
DevOps is a toolkit to utilize to foster and maintain this type of transformation, it is most certainly not a product you purchase.
The conclusion here is that your journey to DevOps won’t be realized through a purchase; whether of tools or people. Tools and people certainly have a place in this journey, but be wary of anyone that says, “You’ll have DevOps if you start checking boxes on this list." DevOps, much like other industry terms is a methodology, a mindset. Getting help on how to be successful on that journey can be an accelerant to change. Employees want to work in a healthy organization, and many of them already know that they, too, “want DevOps.” They want to work in a DevOps-styled shop, and maybe they even know some of the steps of how to get there. Often, it’s difficult to take the feedback of these employees as they’re often individual contributors who are telling you to completely change the way the entire IT org operates. Working with a knowledgeable outside firm to help you figure out what that game plan needs to be can be helpful. Regardless, your focus should be on starting small, identifying where the good individuals and teams are, and enabling them to light the fire elsewhere in the org.
Contino is a leading global DevOps and cloud transformation consultancy with global clients such as Allianz, Lloyds, Barclays, Adidas and HM Government.
Opinions expressed by DZone contributors are their own.