The potential of DevOps is clear, according to proponents who say it helps dedicated teams of development and operations staff quickly deliver innovative software with a minimum of errors. But few experts say implementing DevOps is easy, especially for large and established enterprises that must manage fundamental cultural changes and reformulate legacy programming practices.
Organizations on a DevOps journey may encounter a host of stumbling blocks, ranging from mistrust among those being asked to do their jobs differently to questions about how to accurately gauge whether the new approach is actually delivering business value. Fortunately, an implementation plan that focuses on overcoming five common challenges can smooth the way to DevOps success.
There’s a lot of talk in the DevOps community about building empathy across developer and operation teams. Organizations are told to create this Kumbaya feeling. Others talk in terms of openness, inclusivity and complexity.
But in the beginning, mistrust about DevOps may be more common than camaraderie, particularly in large enterprises that have undergone other reorganizations in recent years. One flashpoint is the misconception that DevOps is just a way to expand the workloads of developers by adding operations responsibilities to their jobs. In fact, DevOps is really about making developers responsible for the code that they write and making operations people responsible for how well that code runs.
Organizations can overcome this and other sources of skepticism by highlighting DevOps wins as they materialize and making sure staff members inside and outside the IT department see the results. Promoting successes prevents people from proclaiming DevOps as “just a bunch of buzzwords.”
Organizations shouldn’t implement DevOps just because it is trendy or because of how it can improve IT operations. The catalyst for change should be fueled by business drivers. “You should only go through this turmoil in the organization because there’s something fundamental about your development process that isn’t working for your business,” says Gary Gruver, president of Practical Large Scale Agile, a consulting firm. “That requires business executives to define what it is that isn’t working and use those business objectives to justify the work required for DevOps.”
DevOps works best when teams consistently create and deliver new iterations of software. But legacy processes, while in place for important reasons, can create roadblocks that thwart modernization efforts. For example, systems designed to evaluate new software for security risks can create delays.
Traditional security checks typically rely on manual, offline scanning processes. The review may provide an essential protection for the business, but manual checks may take weeks to complete, depending on the complexity of the code. In a DevOps world, delays this lengthy aren’t acceptable, but that doesn’t mean organizations must cut corners when it comes to security.
The automation of security scanning provides an antidote. Instead of relying on a slow, discrete process, DevOps teams use an application scanning service that automatically evaluates source code as it’s being written. “At IBM, security scanning is part of the delivery process,” says Daniel Berg, IBM distinguished engineer and chief technology officer for DevOps tools and strategy. “We see reports that tell us if we’ve introduced any security concerns. If we have, the process won’t allow us to go beyond that stage in our delivery cycle until we’ve addressed the problem.”
The scanning service is part of the toolset within IBM Bluemix, a platform-as-a-service solution for DevOps environments.
Security checks aren’t the only processes that may interfere with DevOps success. Analyzing whether changes create legal issues is another common safety check, Berg says. “Organizations need to re-evaluate all of their policies in the light of this delivery model,” he adds. “If you’re delivering on a daily or weekly basis, the sheer pace of change requires you to fully automate these areas.”
In the software world, it’s difficult to manage by metrics, because it’s hard to measure productivity. “The answer is to set short-term objectives – figure out what you think you can accomplish within a set period of time, and hold your teams accountable,” Gruver says.
For example, a DevOps team may be responsible for launching a new e-commerce server within a set timeframe. “Schedule a meeting at the end of that time to discuss what worked and what didn’t work,” Gruver adds. The goal is to create a process for continuous improvement as organizations develop best practices that can ensure the success of subsequent DevOps efforts.
Organizations new to DevOps may be tempted to jumpstart the endeavor by hiring experienced outsiders to staff the new teams. But experts discourage fast-tracking in this way. Instead, organizations need to develop their own people first by enabling them to achieve some early successes.
New hires may be experienced in DevOps, but they can quickly clash with the current workforce because they can be perceived as threats and they likely don’t understand the unique culture of the organization. Efforts to promote greater collaboration, a key tenant of DevOps, are defeated as a result.
A better strategy is to identify motivated individuals within the current lineup of developers and operations staff. Combine them within a single team and instruct them to improve one, relatively low-profile application. From there, the team can take on bigger jobs and serve as a model for how others can succeed with DevOps.
An exception to the admonition against outsiders is third-party consulting help. This type of assistance can help you quickly figure out what processes and procedures you’ll have to change to be successful.
To read more about the latest developments in IT, check out CDW’s Experts Who Get IT blog at blog.cdw.com.