It’s surprisingly difficult to find a concise proper definition of just what exactly DevOps entails. However, I did come across this quote that seems to do a decent job, “DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology (IT) professionals while automating the process of software delivery and infrastructure changes.”
Ok, you understand what DevOps is, and what it isn’t, but why should your enterprise decide to implement it? What kind of visible change can you expect aside from breaking down the silo between two fragmented departments? In Puppet’s latest State of DevOps report, they found “High-performing IT organizations experience 60x fewer failures and recover from failure 168x faster than their lower-performing peers. They also deploy 30x more frequently with 200x shorter lead times.” Simply put, successful DevOps organizations have substantially more product releases in a shorter timeframe with fewer issues.
Before you begin, it’s important to understand some potential challenges you and your organization may face as you implement a more collaborative DevOps shift.
- Not driven top-down
This is one of the most common issues when companies try to implement DevOps in their organization. A c-level executive can’t look at the success data and mandate their company all of the sudden move to a DevOps model. This can’t be a top-down initiative.
DevOps is most successful when it’s a grassroots movement that becomes the catalyst for a culture change. In a perfect situation, DevOps best practices start with a couple developers and operations folks collaborating and building a rapport in small instances. This newfound team atmosphere gains steam and spreads naturally among both sides creating a consistent feedback process and work cadence.
- Pick the right project to get started
Most medium- and large-sized companies have a global presence with offices and employees spread throughout the globe. Obviously, this adds a significant challenge to the organic collaboration process. Whether it’s a language barrier, timezone issue, or simply office silos, the larger the organization, the harder it will be to have a fully-fledged DevOps model. This is why it’s vital to have the right tools to encourage collaboration — more on this later. It’s equally (if not more) important to begin by picking the right projects.
Along with the tools, if your DevOps organization moves in incremental baby steps, earning small, but solid wins along the way, global team members will be more aware and eager to dedicate themselves to a new work model. When both ops and devs work together, the finished product will be of a better quality with all team members feeling proud of their work. Every team member will feel more accountable, and subsequently work harder, when it’s easy to see the impact of their work.
- Rise of the cloud, new tools, and strategies
Legacy, in this case means a few things, each with their own challenges. The first and foremost is the legacy of the team atmosphere and culture. “This is how we’ve always done things.” Again, this is why it’s important to start moving to DevOps at the practitioner level rather than a company-wide mandate. People need to want to move to DevOps. Once they’ve bought into the changes, this objection likely won’t come up as much.
The second legacy issue is existing tools. If your team is relying on dinosaur tools that don’t support a rapid release cycle with more Agile principles, use this as an excuse to start the discussion of tool migration. More and more enterprises have invested (their money and trust) in the cloud and integrated products. When deciding which tools to invest in make sure to map them to your application lifecycle and they play nicely with your other tools.
- Quantifying the impact
Another common challenge we hear is internal DevOps champions are having a hard time getting management support since it’s difficult to measure the success.They show the appealing results from the Puppet survey, but how will this look in their organization?
It’s first important to benchmark your current state. Ask yourself these questions:
- How often are you releasing updates?
- How many support tickets are typically filed after a new release?
- How long is your average application issue?
- What’s the revenue and/or brand impact for each issue?
These questions will help quantify where you currently are with your release process and performance and hopefully will show where you can improve the most. Once those are identified, you can go to your management team with a list of KPIs best suited to your specific organization.
- Identifying the right toolset for the entire lifecycle
A couple of weeks ago I wrote on how to identify the best tools and how to map these to your application lifecycle. I can’t stress this strategy enough. Too often we see teams selected tools simply because they seem cool or certain teams want them, only to find out later they become shelfware for a variety of reasons.
If you’re interested in learning more about the DevOps toolkit, read our free eBook here.
