Blog/News/Resources

Most enterprise DevOps transformations fail for this one reason

Search amazon.com for books with the keyword “devops” and you’ll have 970+ to choose from.

The value of adopting DevOps methodologies are quite clear, the potential benefits are touted by the experts and some organizations have seen results from their project. Yet… DevOps has been around for over 10 years, so why aren’t there more firms who have successfully transformed the SDLC across their development teams?

There’s a fundamental element to the software developer tool-space that is preventing widespread success.  Most DevOps transformations grow organically, starting with the individual developers using opensource tools. Success is seen and rewarded, more tools are added and then the work commences on making these tools work together. Meanwhile other teams in the organization are performing similar work in different contexts, but there is limited standardization.  Complex hand-offs between teams proliferate…so time is spent patching tools together and bottlenecks in the process persist.

Gartner cites that by 2023, a staggering 90% of DevOps Initiatives will fail to meet business expectations for one reason or another.  What’s missing here? Let’s step back and look at “Digital Transformations” outside of the software development space. Pick a line of business and you’ll see a common thread.

  • Human Resources – Workday or SuccessFactors is implemented
  • Sales and Marketing – Salesforce.com, or MSFT Dynamics is implemented
  • Procurement – Ariba or Coupa is implemented

You get the picture, there’s a central self-service platform. But why does this matter?

A transformation project with one of these platforms requires budget for consulting and software, plus dedicated internal resources. Which in turn, requires one or more executives to sponsor this project. The project needs to be in alignment with what the organization has identified as strategic initiatives and the platform needs to align and support the envisaged future state value stream. Otherwise, that executive may have some tough questions to answer…one of which may be “what are you seeking in your next role/company?”, if the project doesn’t show measured success.

Back to our DevOps transformation, the nature of the DevOps opensource tool-space market enables projects to progress without being tied to a strategic initiative and executive sponsorship, but the true value to the organization cannot be realized until this alignment is achieved.

Project prioritization, adequate resource allocation, budget and change management practices are all dependent on having proper executive sponsorship. The DevOps transformation projects not aligned with one or more strategic initiatives will lack these additional key areas (funds, resources, proper change management) and most likely die on the vine, or persist in perpetuity while failing to meet the core business objectives and measures by which the initiative was originally implemented to address.

Guide-Rails is a unique solution to consider, it is a platform that not only assists with a DevOps transformation project but provides a simplified and standardized approach for long-term success across diverse runtime environments. One location with a common view, the ability to integrate with complimentary solutions (like Slack, Veracode and Jira) and the valuable data/metrics for proper visibility.

 

 

Next posting – once your DevOps transformation pilot is properly aligned with the organization’s strategic direction, how do you align incentives and measure progress to fuel enterprise wide expansion?