What if you could spend 50% more time on new client work? How would your business be impacted?
The 2017 State of DevOps Report found that high-performing organizations practicing DevOps spend 21% less time on unplanned and unnecessary work, and 44% more time on new work than their peers.
The goal of DevOps is to bring together resource-intensive development with efficiency-minded operations to create a departmental marriage. This brings alignment to disparate teams, opens communication channels, and automates processes.
What is DevOps and how can it positively impact your organization?
What is DevOps?
“DevOps (development and operations) is an enterprise software development phrase used to mean a type of agile relationship between development and IT operations. The goal of DevOps is to change and improve the relationship by advocating better communication and collaboration between these two business units.” – Webopedia
In other words, DevOps is a set of engineering practices that bring together engineers and developers. The goal is to improve collaboration and productivity through a set of automated processes.
What does this mean in practice?
Development without DevOps is like taking a group of people working on a project, putting them in separate rooms, and then requiring them to work on the same project individually. This is great if you want your software done by the year 2035 but it is a communication nightmare for the rest of us.
DevOps improves efficiency by tearing down the figurative walls that separate coworkers and opening two-way communication between colleagues whose work is dependent on others. The impact speaks for itself. As of 2017, 63% of organizations had adopted or were adopting DevOps as part of their process.
What are the components of good DevOps practices?
While everyone’s DevOps implementation will look different, there are core components that you shouldn’t skip.
Automated quality assurance life cycle. This is a suite of automated tests — including unit, integration, smoke, acceptance, regression, integration, and security tests — that tell you if what you’ve deployed to a new or existing environment is working and ensures that you didn’t break anything. You’ll also want the ability to roll back the system when things fail. This is a critical automation since waiting for someone to manually perform quality control takes too long and waiting for users to complain isn’t an option.
Continuous integration practices. As developers commit code, there should be an automated build process that will compile and package code in individual feature or product branches but will also merge code from multiple developers or teams and ensure it all plays well together as often as possible. If you delay integration between multiple code branches to the very end of your iteration or project, you risk creating additional technical debt and reducing quality as well as the team’s velocity.
An automated process for deploying the build process output to your application environment. In the past, operations would manually create the environment and databases, connect the clusters, and set up other necessary components for application development. True DevOps should be sophisticated enough to produce these environments or at least update configuration of these environments on the fly. This enables teams to dynamically provision virtual servers, or any environment components needed to run the application — thus speeding up the process.
System for monitoring applications. It’s important to implement telemetry within your environments to monitor and check your application’s overall health — ensuring it’s free from errors due to programming defects or misconfiguration. Even though applications or components may pass your initial unit, acceptance, and integration tests, they may still not work as expected in a live environment. This can be anything from a bug that prevents the system from properly functioning to a racing condition between two components overriding each other’s data updates.
These four components are the building blocks of a strong DevOps implementation. But, you might wonder if automation is right for you.
Implementing DevOps isn’t just about tech or process
“According to former VP of Technical Operations [at Etsy] Michael Rembetsy, in a 2015 Network World interview, they realized that when developers feel responsibility for deployment, they also would take responsibility for application performance, uptime, and other goals. Etsy now deploys over 60 times per day.” – HelpSystems
DevOps requires technology, but that technology needs to be supported by strong processes. Ensuring these processes are followed falls squarely in the hands of your staff. This means that without the support of your staff, process and technology are irrelevant.
One challenge that can block DevOps implementation is the existing culture. Operations may be used to being in control — used to manually provisioning resources, manually setting up environments, and manually setting up security in those environments. When you ask your team to implement DevOps, you’re not just asking them to use a new process, you’re asking them to change the way they work.
How can leaders help their team embrace DevOps? They need to start with their people. Employees have been trained a certain way, and their daily activities become automatic. Leaders can break the cycle through continued education. By helping both development and operation teams understand the benefit of working together, you’ll get your team on board and avoid resistance.
Another factor that impacts implementation is skill sets. Some on your team won’t have the right skills to implement these changes. This may indicate that more drastic culture changes are necessary. Although dealing with company culture can be challenging, automation is worth the effort.
Why should you automate?
When is the last time you typed an email that didn’t require some editing? It’s probably been a while, unless you just sent a thumbs up. The point is that people make mistakes. And when you’re analyzing lines of code of indefinite lengths, or hundreds of entries in an application configuration file, the possibility of making a mistake is exponentially greater.
Automation eliminates human errors and increases the speed at which software can be developed. The level of complexity for modern systems is high. People make mistakes, forget steps in the process, etc. Add to that the time it takes to go through the code of modern systems.
Automation reduces time-consuming manual labor and the risk of human error. Its value is apparent, but implementation requires support from your organization. How can you measure progress and prove the ROI of DevOps?
How can you measure DevOps implementation progress?
There are many metrics organizations use to measure DevOps, such as release frequency, error rates, and project lead time. We could go into a whole other article to discuss metrics. For now, let’s look at measuring DevOps from the business leader’s perspective.
As a business leader, you’re interested in outcomes. It’s important that DevOps help your organization achieve the goals it has set. Like reading a map, your goals are the destination, and you measure progress by checking your current standing against that goal. To that end, you can measure DevOps in three steps:
Clearly identify the goal for implementing DevOps.
Decide which metrics will be measured to determine success.
Constantly measure metrics and refine your process to progress towards the goal.
These steps will enable you to keep your bearings and understand the ROI that DevOps is creating for your organization.
Continuous measurement will create refinement and with that comes even more automation. But when does automation become too much?
Is there such a thing as too much automation?
“First, you need to understand that automation is about taking once manual processes and placing technology around them so they’re inherently repeatable. If your processes are bad or flawed, then you’re just making bad processes happen faster.” – TechBeacon
There’s no such thing as too much automation. But applying automation to inefficient processes will just make bad processes happen faster. This can result in wasted time, inefficient use of resources, and increased downtime for your applications.
To counteract these negative outcomes, businesses need to make sure their processes are ready before automating. Start by ensuring the processes you use during development are as efficient as possible. Only then should you put the appropriate DevOps tool in place.
This type of automation also requires organizational change. When you don’t get proper buy-in from your team, they can become resistant to even the smallest amount of automation. Getting them on board before automating will help them to trust the code they write and willingly participate in increasing process efficiency.
Why should DevOps initiatives fail?
“Failure is success if we learn from it.” – Malcolm Forbes
DevOps initiatives fail. This can happen due to culture backlash, siloed departments, and losing sight of business goals. But the prevalence of failure doesn’t mean your implementation is doomed. Learning what kills others’ efforts can equip your organization for success.
Failure to change company culture. It’s easy to view DevOps as a technology change, but this is only a small part of the picture. When companies overlook the culture change, they lose support for implementation. Get buy-in, talk to your people, and train your team. You’d be surprised what your team can implement if you just get them on board.
Departments remain isolated. In a survey by Tech Pro Research, they found “78% of the 1,000 IT professionals surveyed said that their organizations continue to have separate teams for managing infrastructure/operations and development.” The point of DevOps is to increase transparency and communication. Some organizations think they can implement DevOps and still cling to traditional development practices. This is contrary to the principles of DevOps. If you want to succeed, you have to fully embrace the openness DevOps provides your team.
Some forget their goals along the way. The purpose of DevOps is to help you reach a business outcome. Whether that be increased efficiency and profitability, speed to the customer, or something else. DevOps involves technology and process, but if you focus in on those too hard, it’s possible to lose sight of the big picture. Businesses must constantly measure how their efforts are helping them reach their overarching goals.
Building on bad processes. If processes are fragile and people aren’t buying in, that’s a recipe for this initiative to fail. However, this doesn’t mean you can’t implement it. Start by stabilizing the quality of your processes and then move on to automation.
There are other reasons DevOps can fail, but these are the most common. Take action and shore up your company to tackle these obstacles. This will help you automate faster, smarter, and more innovative than you originally thought possible.
Is my organization ready for DevOps?
If you read this far, you’re probably curious where your organization stands. Is it ready to make the jump, and where do you begin? Let’s look at six questions that can help you determine the readiness of your organization.
What is your goal for implementing DevOps? While DevOps can help you cut costs, this isn’t the true purpose. DevOps is designed to help you deliver customer value faster and with less risk. Ultimately, these benefits will cut costs, but without the right mindset, you may find yourself giving up when you run into implementation challenges.
Is your team on board and willing to support the change? It’s crucial that organizations educate their team on the benefits of DevOps, gain support, and create a strategy for training during implementation. Members of your team will need to be familiar with both development and operations. Make sure you’re ready to train or hire new employees as needed.
How well do your development and operations teams work together? If your teams were siloed before, you may not know the answer to this question. This point would then tie back into point two. Communication and buy-in become even more important when teams haven’t worked together in the past.
Do you have the budget to support the change? Especially in large organizations, DevOps implementation can be a radical change. When you’re making big shifts in your organization, it’s crucial that you ensure you can see it through. Otherwise, you could end up with a half-way implemented project and wasted resources.
Are you ready to measure like never before? If you want to get the most from your DevOps implementation, you need to continually analyze processes and tools. You should always be asking, “How can we maximize efficiency?”
Do you need DevOps automation services? DevOps provides many benefits for software development, but it can be difficult to implement. Organizations need to be objective and discerning when analyzing their organization’s needs.
These questions are a great indicator of how ready your organization is for DevOps. What if you answered no to one or more of these questions? It doesn’t mean that you can’t implement DevOps. Get the help of someone who understands DevOps and can provide objective feedback on your organization’s readiness.
Key points
DevOps helps engineer and developer teams improve collaboration and productivity through a set of automated processes.
For DevOps to be successful, it must be supported by strong processes and by your organization’s people.
DevOps needs to be tied to business outcomes to be properly measured and prove its ROI.
Organizations fail to implement DevOps when they try to implement it halfway. It’s not practical to try to combine implementation with traditional practices.