Five Common Myths About DevOps

This post was originally published as “Five Common Myths About DevOps” on the Levvel Blog.

Virtually every industry is being disrupted by nimble competitors ranging from scrappy startups to established incumbents. IT departments are playing a big role in this phenomenon, either by creating the efficiencies that enable nimble disruption, or by being blamed for slowing down business transformation. DevOps, the compounding of the words “development” and “operations”, has been a popular theme among organizations looking to become more nimble. While much of the buzz about DevOps is deserved, it’s also easy for some myths to develop in such an environment.

Myth 1: DevOps is just “an IT thing”

Reality: High performing organizations leveraging DevOps practices are more than twice as likely to achieve or exceed their objectives as it relates to quantity of products or services, operating efficiency, customer satisfaction, quality of products or services and achieving organizational goals.

While it’s true that DevOps efforts are largely borne out of IT organizations, it’s important that business lines and/or product managers buy into the process. Ultimately, DevOps is designed to improve IT performance for the benefit of the broader business. In order to fulfill this mission, the entire organization must be involved. For example, many DevOps efforts have a goal of increasing the velocity of product features being delivered to production. The IT organization plays a role in that goal, but ultimately, those features are being defined by someone outside the IT organization. Product managers play a role in defining how DevOps supports their needs.

Myth 2: DevOps is only for startups; it won’t work for larger companies

Reality: 50% of organizations have current DevOps initiatives and another 21% are planning DevOps initiatives according to VersionOne’s recent survey of thousands of companies. This survey included 26% of respondents from companies with more than 20,000 people and more than half were from companies with more than 1,000 people2.

While it’s true that some early-stage companies blazed the trail to DevOps adoption, larger companies have the most to gain by developing mature DevOps capabilities. These companies have larger IT budgets and typically have more legacy technology that can create a drag on operational efficiency. By evolving their people, process and technology, these organizations stand more to gain than many younger, smaller organizations. As an example of one such benefit, a survey of organizations with an average of 44,000 employees and 2,900 IT staff realised 38% lower IT infrastructure and development platform costs per application by adopting Red Hat OpenShift, a Platform-as-a-Service tool that is used in many DevOps efforts3.

Myth 3: DevOps only works on the public cloud

Reality: The same techniques that are applied to public cloud infrastructure can work in on-premise data centers with bare metal servers, virtual hosts, or private cloud/platform-as-a-service products. For example, one of our clients saw a reduction in server provisioning time from six weeks to two hours through infrastructure automation and improved configuration management.

Public cloud is by no means a prerequisite for DevOps adoption. However, many organizations find that DevOps capabilities help with their cloud adoption strategy. In many cases, large companies use DevOps efforts as part of a broader transformational effort to evolve their legacy, on-premise data centers to more modern, private-, public- or hybrid-cloud environments.

Myth 4: There is a single right way to “do DevOps”

Reality: Much like Agile software development, DevOps is the culmination of enhanced software development methodologies, predictable delivery mechanisms, and infrastructure management processes that are supported by complementary tools and organizational structures. While organizations with effective DevOps practices share many common themes, there is no single right way. The right way for an organization to outline its DevOps initiatives must be through a transformative process that redefines how organizational objectives and business goals are met, while presenting the team with an opportunity to investigate the effectiveness of the current tools and processes, and empowering the team to make the necessary changes to either.

Business goals and organizational objectives are important because they influence how capabilities are prioritized and provides the team with the necessary insight to find and dismantle roadblocks while streamlining processes that in turn enables the team to improve on many of its key performance indicators. For example, an enterprise-focused SaaS organization that is mandated to deliver software products more quickly to production will likely make different decisions about which DevOps initiatives are tackled first, when compared to a bank that automates software quality and compliance processes as part of their online consumer banking software delivery.

Myth 5: DevOps is just about tools

Reality: DevOps initiatives that focus on tools and ignore processes and organizational considerations generally fail. While tools play a key role in enabling DevOps capabilities, the processes and organizational considerations are equally important. Teams that attempt to fix flawed processes with tools, or attempt to address cultural inadequacies through an altered process often run the risk of realizing outcomes that fall well below expectations. For example, how can a team automate a process that cannot be manually carried out?

More importantly, processes and tools must work within the organizational constructs of a company. Since companies significantly vary in their organizational structures, every DevOps initiative must include a thorough assessment of existing cultural realities, process and tools, to ensure that they don’t present additional roadblocks and increase the team’s objective to realize successful outcomes. Tools are often the most flexible part of a DevOps capability; it’s the work to adopt new or change existing processes and cultural aspects of the organization that can make or break the effectiveness of DevOps practices.

Successful DevOps efforts begin with a holistic view of people, process and technology. Once the business objectives are understood and the roadmap to achieve the target state of DevOps maturity is defined, processes can be defined (or modified) and appropriate tools can be identified. In many cases, that identification process may include the re-use of existing tools.

What Next?

If your organization has already begun the DevOps journey, it’s worth validating that these myths haven’t been embedded in your assumptions or thinking. Some organizations realize too late that they failed to account for the process and organizational aspects of DevOps. If you haven’t yet begun your DevOps journey, it’s important to start with broad organizational buy-in and understand the roadmap from your current state to the target state that achieves your goals.

Regardless of where you are in the journey, building and maintaining a business case based on improvements from DevOps capabilities is critical to success. For some ideas on how to approach a business case for DevOps, watch our screencast of the business value of DevOps to learn more. If you’ve already developed a business case and are on your journey, you may find our white paper on digital transformation informative on how these capabilities can be used to further evolve your business.

References

1. “2017 State of DevOps Report”, Puppet. 2017. https://puppet.com/resources/whitepaper/state-of-devops-report.

2. “11th Annual State of Agile Report”, VersionOne. https://explore.versionone.com/state-of-agile/versionone-11th-annual-state-of-agile-report-2.

3. “The Business Value of Red Hat OpenShift”. Carvalho, Larry and Marden, Matthew. IDC. 2016.