Not all software development and delivery teams have embraced the DevOps approach to software development and delivery. But it’s striking how many have, and it’s even more striking how successful many adopters of DevOps have become. While some of the practices and technologies associated with DevOps are still immature, small teams have nevertheless evolved from basic agile development techniques to a more comprehensive engagement with their company’s overall IT capabilities. Businesses are seeing happier customers, and they’re beginning to see bottom-line results.
Teams that have enjoyed this kind of success may well find themselves in the spotlight of upper management, the kind of spotlight you want. The question is, what’s next? The front office wants more. How should DevOps teams in large organizations—teams that have had success on pilot projects, for example—replicate their success across the business?
There are several approaches you can take to scale DevOps as you expand the number of DevOps implementations.
First steps toward DevOps at scale
It’s not uncommon that when enterprise DevOps efforts are successful, the people who achieved that success get inundated with requests for new projects, applications, and infrastructure. With only so many hours in a day, existing staff is not likely to be able to take on more work; the only option is to expand that capability, but how?
It’s not as simple as dividing the new work into one new team per project. When an organization wants to expand DevOps capability across more, and potentially larger, projects, the best first step is to create a process and workflow that can be repeated by multiple teams. Another key to expansion of DevOps is to ensure that the early initiative proves the benefits in time savings, cost savings, business results, etc. As a broader effort gets underway, teams will have clearer expectations with these established measures for effectiveness.
I’ve seen enterprises borrow from mobile software teams or web operations shops that have demonstrated successful, faster deployments or efficient infrastructure management. The point is, wherever there is agility and the beginnings of DevOps within the organization, that’s where it’s best to start normalizing and standardizing.
Support from the top
Whatever source of success you find within a large organization, a vital component to workable growth of DevOps practices is heavy backing by management and leadership, including C-level executives. This level of involvement from the top of the organization showcases a radical change in software development within the enterprise compared to a few decades ago, and even more recently for many large companies.
DevOps itself represents this shift. Fortunately, we’ve begun to see top-down adoption of DevOps, with C-level executives among the biggest champions of DevOps technology and methodology. Absent this backing from leadership and central IT, DevOps efforts will be difficult; spreading efforts throughout the organization will be even more difficult. But when all stakeholders work together with shared results, it becomes much easier to embrace the changes.
For example, I have seen incentives such as bonuses or rewards for developers, IT operations, lines of business leaders, and other DevOps stakeholders that depend on the performance of all teams. Enterprises today are also more likely to have a center of technology excellence, a technology review board, or a similar body of internal technologists charged with ushering in new technology and methodology such as DevOps. This is one place you will find the champions of DevOps, and they often end up leading the implementation or expansion efforts.
Note that DevOps change is not so radical to software developers, who have been exposed to agile and lean practices, open-source software, transparency, and collaboration. But it is radical to IT operations professionals, who are used to focusing on things such as stability and security over time and responsiveness. This is another reason why leadership is critical: to bridge the dev and ops divide and to have DevOps champions and those with experience leading the effort. Otherwise, you may wind up with efforts that are DevOps in name only.
Understanding the 'stakeholder spread'
In the early days of DevOps, the focus was on getting development teams (including testers) to work more effectively with their operations counterparts. But after early successes in software delivery, the range of stakeholders in DevOps outcomes broadened to include security teams, as well as database administrators and line-of-business leaders. This tendency for DevOps to accrue an increasing variety of functions, from both the technical and the fiscal sides of the business, is one way to understand the success of DevOps as an operational model. Security, for example, used to be somewhat incongruent with the original tenets of DevOps, which centered only on getting code out the door rapidly. Today, the trend has evolved in the enterprise; we see security incidents such as Heartbleed or Shellshock actually driving increased interest in DevOps, since it illustrates both the need and the benefits of being more responsive.
At a practical level, it’s a lot better to be able to update machines and systems in a matter of hours and be covered than to get paged in the middle of the night and jump into triage mode. DevOps is about speed, but it’s also about readiness, whether it’s for the next mobile device, the next application feature, the next data set, the next security incident, or any other development.
Tools and metrics for scaling DevOps
Teams that have embraced the growing set of DevOps-related technologies over the past few years—Puppet, Chef, Docker, Jenkins, etc.— face a different set of challenges as they scale DevOps practices.
Metrics should be first on the agenda. Organizations should proceed on a proof-based model, taking on only those DevOps initiatives that illustrate measurable goals, provable time, cost, or other advantages. The benefits and the practices may change as metrics based on release cycle time or cost savings transition to metrics focused on business results or competitive advantage. Naturally, this latter set of metrics may be less simple and harder to prove, but organizations will discover how their competitive metrics can also be gauged.
Some organizations that have grown their DevOps implementations have standardized on one particular tool or set of tools, but most enterprises use a mix of technologies. DevOps is not necessarily a tool chain, given the variety of tools, infrastructures, and use cases. It is more of a toolbox, with the right tools for automating and gaining efficiency on different jobs and processes.
The main frameworks and tools that tend to be a part of enterprise DevOps implementations today are things such as GitHub, Jenkins, Chef, Puppet, Ansible, and Salt. These tools are mostly about simplifying, automating, and tracking infrastructure management and software release processes. There is some crossover with more traditional enterprise IT operations tools and approaches such as ITIL, but these other technologies are more prominent. The most effective DevOps implementations in the enterprise and at scale are the ones that have leveraged newer tools and frameworks and moved on from traditional tools and best practices, including SAFe.
Containers have also proved useful in cutting developer onboarding time and boosting developer productivity and speed, but they are also more disruptive to the IT operations side of the house. As with any DevOps technology, enterprises should start with small projects, prove benefits, and expand efforts appropriately.
Find what works for your culture
Increasing the profile of a DevOps effort can help to get the broader buy-in required to spread the effort, but it is best to wait until the initial team or teams get it right. An important aspect of DevOps is the acceptance of failure and the response to failure. Rather than breaking down the dev-test-production routine, a failure in DevOps should be something that is rapidly addressed and solved. Thus, it might be best to get through some of the failures first, not only to demonstrate this acceptance of failure, but also to demonstrate the eventual success of the implementation.
Enterprise organizations need to be focused as much, or more, on migration and modernization of existing applications and services as they are on net-new, “cloud-native” applications and services. Thus, new technologies, methodologies, and processes must intersect with and integrate with existing technologies, methodologies, and processes. This also includes people, and this can be an effective way to usher DevOps adoption without alienating existing workers.
The following chart illustrates how DevOps requires that team members take on several different roles while at the same time showing how DevOps pulls in a variety of other stakeholders, from C-level executives and security personnel to line-of-business teams and divisional leaders.
Source: 451 Research
The fact is that individuals and teams in the enterprise are given broader responsibility for software releases, and IT operations is among the drivers of DevOps in the enterprise. As implementations scale, enterprises must include more of their people and teams in DevOps collaboration efforts to truly reap the rewards of speed, efficiency, responsiveness, and other advantages.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
