How Do You Solve a Problem Like DevOps? — Part 1
Adopting DevOps in the enterprise introduces more and more issues around culture, tools, and adoptions. How to you begin to solve these problems?
Join the DZone community and get the full member experience.Join For Free
There is a rhythm and proper flow to achieving DevOps in the enterprise. In order to acquire, satisfy and retain customers in today’s software-driven economy, large enterprises are being tasked with releasing software updates faster than ever before. Increasingly, the maturity, speed, and quality of the software delivery processes have become a key differentiator and competitive advantage for businesses today. DevOps emerged to help organizations improve their software delivery and better address the challenges put on IT by the business to accelerate software releases. How are technology leaders conducting and directing their business’ DevOps transformation to make sure they’re on the right track?
The Hills Are Alive with the Sound of DevOps
It’s no surprise that DevOps has vaulted into the mainstream — through plenty of new services and tool offerings, and captivating experience reports highlighting the successes and ROI of IT transformation journeys. DevOps is now considered a necessity for the survival and competitive advantage of today’s software-driven organizations.
The goal of DevOps seems straightforward — accelerate the delivery of better software to end customers as effectively as possible, while mitigating the risk of software releases. The bridging of the gap between Dev and Ops has trickled to bridging gaps and busting silos between other groups in the organization – such as between Information Security and Dev, or the Business and the Software Production organization. These changes in the organization’s culture and “Geist” have sparked quite an interest, particularly as they manifest in how large enterprises — seemingly more traditional and slow-moving — change the way they conduct business, and how it affects their bottom line. It truly shines a light on the importance of breaking down the walls between the business functions and fostering empathy and a shared goal between the groups in order to benefit as a whole. Henry Ford might’ve said it best — “If everyone is moving forward together, then success takes care of itself.”
Dev teams were initially quicker to adopt DevOps practices, as they were eager to find ways to get their code into production faster. Ops were traditionally more hesitant to adopt DevOps, seeing increased velocity and speed as potential business risks. Today, the DevOps movement, born out of grassroots efforts that started with Agile and the Development organization, has matured from a bottom-up initiative to also being a top-down, company-wide effort. As we start seeing a shift toward DevOps becoming an organization-wide initiative — championed both at the executive and team levels — the discussion expands and matures from being focused on limited teams’ “DevOps song and dance routine” and their successes to wanting to scale these benefits across the entire organization. This means scaling DevOps while ensuring organizational governance and controls.
Once the initial benefits of DevOps rollouts have been established, organizations start honing in on what’s next for DevOps in the enterprise: standardization, system-level visibility, organizational control, and security/compliance. For the highly complex and large-scale enterprises trying to make monumental shifts in their digital business, the time to reign DevOps in has begun.
Striking the Right Chord
Large enterprises face unique challenges as they adopt DevOps, particularly diversification in the software delivery process while keeping an enterprise view on governance and risk. When optimizing software delivery processes, these large and often geographically dispersed organizations are supporting numerous distributed teams, distributed infrastructures, and multitudes of (inter-dependent) applications and product releases. In addition, the overhead of regulatory and security requirements, support for legacy systems, a wide variety of tools, complex internal processes, and the risk and cost of failed releases all further compound these challenges.
So what balance do technology leaders need to strike? How can companies enable product innovation and fast delivery, while adhering to business principles that maintain a much-needed level of industry compliance, security, and fiduciary duty to their shareholders? How do you solve a problem like DevOps in the Enterprise? Just as every organization’s software delivery pipeline is different, DevOps adoption and rollout are different as well, taking into account the various teams’ dynamics, unique software delivery requirements, and organizational constraints. The common things among all DevOps transformation stories are a continued investment — and continuous improvement — along the 3 axes of DevOps adoption: People and Culture, Processes, and Technology/tools.
As part of investing in cultural change and implementing the right tool chain and processes, enterprises increasingly realize that it is imperative to achieve end-to-end visibility and management of their entire software delivery pipeline — from code check-in all the way through release to Production. This not only enables getting all team members across the organization come together around a shared goal and contribute to your “pathway to production”- but also enables standardization, re-use across teams, and the ability to pin-point the status of each software release or task along the pipeline in today’s increasingly complex software organizations.
To improve developer productivity and resource utilization, and to enable enterprise-scale, cross-project visibility and shorter time to market — organizations are working to automate and orchestrate the entire tool chain across the end-to- end delivery pipeline. “Automate All the Things” is a key tenant to any DevOps or Continuous Delivery initiative, and is becoming a requirement to achieve quality, compliance, speed, and efficiency – at scale.
This article originally appeared on DevOps Digest
Opinions expressed by DZone contributors are their own.