8 Steps To A Successful DevOps Transition- Valutrics
The transition to DevOps can be long and difficult because it is going to involve disruption. That can mean periods of reduced productivity and increased costs, but they can be worth it. Here are eight steps to get you started in a positive direction.
DevOps is big right now. Of course, it’s tough to get the same definition of precisely what DevOps is from any two people, but in general folks agree that it uses automated deployment tools to enable continuous development, deployment, and improvement of enterprise software.
As DevOps tool vendor New Relic writes on its website, “…the DevOps movement emphasizes communication, collaboration and integration between software developers and IT operations. Rather than seeing these two groups as silos who pass things along but don’t really work together, DevOps recognizes the interdependence of software development and IT operations and helps an organization produce software and IT services more rapidly, with frequent iterations.”
That’s nice, but how, precisely, do you get from whatever it is you’re doing now to DevOps? The answer will vary from organization to organization, but in general there are some steps you can take to take you along the path.
These steps were developed by exhaustively combing the internet, looking at the stories told by those who have survived, talking to IT pros, and employing a modicum of common sense and experience.
The result is eight steps that aren’t enough to handle every detail, but are sufficient to use as a framework from which other, highly detailed, steps can be formed.
I’m curious about your experience with DevOps. Is it the system your company uses now? Are you considering it? Have you been through a DevOps transition? I’d love to know and I’m sure the community would love to benefit from your experience. Meet me in the comments section and we’ll start a conversation on DevOps, step by step.
Create A Vision
I know, “creating a vision” stinks as a way to start, but there’s a reason this one is here. Because creating a vision isn’t just about creating your perfect DevOps scenario. It’s about creating the perfect DevOps scenario that supports the business needs. A DevOps vision has to start with the business justification, or it’s doomed from the start.
A transition to DevOps is a massive change for any organization. A change that significant can’t be justified if it’s only about IT. So sit down with the business units, understand their needs, and involve them in creating the vision. You’ll end up with justification, vision, and a roadmap that has the support of the entire business — and a much greater chance of success.
Start At The Top
Remember the vision thing you were creating? Once you have it, your sales job begins, and that sales job has to start in the executive suite. You see, the transition to DevOps is going to involve disruption. Disruption generally means at least short periods of reduced productivity and increased costs. You won’t survive those periods without the support of top-level executives.
The good news is that executives tend to be very easy to understand. They want the business to work better so that it can be more profitable. Take your well-developed vision and use it to show them how it will raise profits and you should have them on your side soon enough.
Dive Into Systems Thinking
DevOps often begins with a software development group that has embraced agile discipline. That’s a great start, because it introduces the group to thinking about creating software as a system rather than simply a process. With DevOps, you’re going to take that system thinking and expand it out into the rest of the organization.
It’s important to remember that expanding the systems thinking to the rest of the organization doesn’t mean that everyone must leap on the Agile Train (though there’s nothing wrong with that). It does mean that you’re going to look at what’s actually happening around application development, deployment, and use, and figure out how to make the entire system more effective, more efficient, and less wasteful. This is where the whole “disruptive” thing really starts to come into play.
Develop Your Tools Strategy
Alright, so you’ve established the vision, gotten the executives on board, and wrapped your head around the whole “everything is part of a system” concept. Now, it’s time to look hard at the tools you’ll use to implement DevOps.
At a minimum, you’ll be selecting tools for version control, the build/deploy process, testing, and change management (which should include provisioning). There will be more tools, but these are where you start. As you start, you make sure that the tools support your processes, which then support your systems, which respond to your business requirements. Problems start when you begin your priorities from the back to the front.
There are some who like to focus on issues such as whether all your tools are from a single vendor. That’s really a tactical decision. The strategy comes in deciding the role tools will play in the process, whether you allow the tools to define the process (rather than implementing tools to support the process), and who has contact with the tools.
The key, though, is making sure that tools serve the business systems, rather than the other way around. Keep your priority chain intact and you greatly increase the likelihood that your tool strategy will be seen as a success.
Make Sure There Are Short-Term Wins
I keep coming back to the fact that the transition to DevOps is disruptive because, well, it is. Moving to DevOps means changing the way software is developed and deployed for those in business units, as well as in IT. Change makes people uncomfortable, and uncomfortable people can panic. No one wants panic.
That’s why it’s so important to build short-term victories into the transition process. There should be regular occasions to have everyone look up and say, “See? It’s working!” Those regular little victory dances will go a long way toward helping everyone be comfortable with the transition, and that comfort will help keep panic far, far away.
Invest In People
You’re going to be buying new software, you’re going to be paying to re-arrange systems, so you might start looking for ways to cut corners and keep the accounting department happy. Good luck with that. But don’t try to achieve that particular goal by short-changing training and education for your employees.
The first priority in training are your development and IT operations staffs. Their day-to-day jobs will see the biggest impact. They’re also the people who must make DevOps happen for the rest of the organization. Don’t neglect the users when it comes to training, either. Make sure that they are trained in what to expect, how to communicate, and why the whole process is ultimately going to make life so much better and happier for them and the company.
Collect Metrics From Your Tools
If you’re going to have small or large wins, if you’re going to justify all the trouble of transitioning to your executives, and if you’re going to answer the critics who inevitably say that everything was better in “the old days,” you’re going to need some metrics. What better place to get those metrics than from the tools you’re using to implement DevOps in the first place?
Not every tool will generate the kind of metrics you want or need. Insuring that your tools will give you the right kind of numbers must be part of the evaluation process for any tool set. Getting the right metrics is a strategic need, and meeting that need is absolutely the job of the tool set. Don’t be afraid, though, to look at monitoring and analytical aggregation tools — remember that the tool set is yours to define. Make sure you’re defining it to meet the needs of the business.
Embrace Continuous Feedback
Tools will help with this, but at an even lower level you must communicate the need for continuous feedback to all your employees and show them why the continuous feedback loop is necessary and useful for continuous deployment and continuous improvement.
For most organizations, embracing continuous feedback is a cultural change. We all know that changing technology is a piece of cake compared to changing an organization’s culture. Once again, this level of profound change is why you must have buy-in from executives, and must clearly communicate your vision and progress throughout the process.
There are eight steps to use in getting to DevOps from wherever it is your organization happens to be. Have you taken any of these steps? Do you think I skipped one or more critical steps in the process? I’d love to take advantage of some of your continuous feedback. Meet me in the comments and let the discussion begin.