The rise of DevOps movement is motivated by many things, but collaboration, automation and process have driven...
it into the mainstream.
Listen to a panel of IT directors talking about what the future of IT looks like. Almost all will touch on DevOps in one fashion or another. What's interesting is what they see as the driving force behind the movement.
For a while, some thought that the motivating factor behind DevOps was largely the idea that projects can be done more quickly when the barriers of communication are brought down. While this is still true, they also offered insight into what they saw as other driving factors behind the movement. It turns out that many of these are what we in IT struggle to achieve on a daily basis, and we may have found the central driver to help us finally get to IT nirvana.
The benefits of collaboration
Walk into any organization and the biggest complaint you often hear is that there is a lack of collaboration among folks in the same department. The database guys don't really know about what the developers are doing, the operations folks have no idea the marketing department is about to launch a massive new ad campaign that will increase website traffic three-fold, and the system engineers are unaware of the new code deployment going out tonight. Sound familiar?
At its heart, DevOps is about breaking down the walls of communication and letting people -- not just IT people, but people from all over the company -- talk and work together. Can you imagine what it would be like if someone from marketing actually came down to IT to talk about product launches and how they might affect system performance? Sound like a fairy tale? It doesn't have to be, and in some organizations it isn't.
Companies that let their employees openly communicate and collaborate see more productivity, fewer errors and quicker project turnaround time. They are no longer working in vacuums; now, they work in an environment where the right information is being dispersed at the right time.
Negativity toward this type of environment often comes from people who don't understand what the DevOps movement is trying to achieve. Some folks believe that DevOps in any flavor means that we have to ramp up entire teams filled with one or more people from every department. This not true, and studies from successful implementations have shown that the mere availability of personnel to answer questions, along with the adoption of company-wide collaboration tools, helps achieve this goal. Stop discouraging your IT folks to talk with the business and vice versa, and start encouraging open dialogue. The results will be phenomenal. After all, you all work for the same company right? We don't need to treat our colleagues like they are the competition!
Start small to make collaboration happen. Hold stand-up meetings once a week and invite everyone who has a stake. Don't worry about how many will or won't attend. Just get them in the loop and work out the details once momentum starts to build. After the first few meetings, you will find that the correct players will gravitate toward each other naturally. While there may be a few people who just want to attend for the sake of attending, it's fine. The more information you get out there, the more involvement you get and the better off you will be in the long run -- if not for this project, maybe for those down the road.
Never underestimate the knowledge and information you have in your own company.
Automation rules the DevOps nation
Think about all the tasks and IT processes that take place in your company. Now, think about all the people involved in doing them. Scary, isn't it? What's even scarier is that most of the people who are doing a lot of these tasks don't want to be doing them -- in fact, they shouldn't be doing them! Do you want someone spending three hours of every week manually transferring data, or would you rather have them spend that time thinking of how they can improve existing processes, or better yet, developing the next "big idea" for your company? I know which one I'd like!
DevOps culture helps foster the idea of automation across the enterprise by exposing the pain points, because people are free to work together to help overcome them. Automation can help not only make your processes more efficient, but also free people up to work on tasks that have far greater value to the company. Once people see how well a DevOps organization plays together, all of a sudden, they no longer want to hide behind the old way of doing things. They want to be freed up so they can join in on the latest project or work on the next big thing.
So what do we mean when we say automation anyway? We're talking about automation not only from the IT side of things but also in everyday processes that take place across the company. You don't need to start out with some expensive automation tool to achieve these goals, either. Instead, put the people who are bogged down with everyday tasks together with the people who have the knowledge to help. Then stand back and watch what happens.
Pretty soon you find that you not only have automated IT processes. That manual data transfer that took three hours? It's now down to two minutes, thanks to workload automation tools. Then you begin seeing other processes being automated.
For example, our customer service folks complained about how long it took to get replacement equipment shipped to customers. By working together as a cross-departmental group, our DevOps team was able to identify inefficiencies in the process and eliminate them. We optimized the IT infrastructure that handled return shipments and eliminated unnecessary barriers, such as identifying that every return authorization had to be approved by a manager, even though in the three years that the existing system had been in place there had not been one rejection. Waste eliminated! Time gained! Happier customers! Even happier employees! That's what real employee empowerment looks like.
Process equals progress
Just like how we identified an inefficient process in our above example, DevOps also lets teams understand, adapt and put into place new processes. While some people see this as red tape, often what happens is that when cross-departmental teams come together, they not only understand the need for processes, but they also understand that processes can always be improved.
Let's say that we have a change management process in place at our company that says all production website code must go through quality assurance, a change ticket entered and approved, and finally it must be deployed out using our standing deployment technology -- let's just call it the "ABC Deployer."
We all understand why this process is here, and nobody would argue against a sound change management process. The problem is not with the process itself but with the implementation and understanding of the process. Many development teams feel they are being forced to use the ABC Deployer for all their deployments and thus spend way too much time grumbling about it or trying to find ways around the system.
It turns out, though, that change management only cares that we use a standardized tool when we get to the production level. In development land, they can use whatever they want, as long as by the time it gets to production, they are using the standardized way. By coming together -- QA folks, change management folks, developers and other IT personnel -- and using the DevOps philosophy, the developers can see that change management was not trying to dictate to them but rather just trying to make deployments as error-free as possible. They now understand they can use whatever tool they want at their level, as long as they package it properly for the final deployment. Frustration solved! That was easy.
Cross-departmental teams often come up with better processes and methods than those who work in silos. After all, while the systems engineers may see a 2 a.m.-to-4 a.m. maintenance window as ideal and out of the way of others, the folks involved with data processing know that this window is our busiest time for communicating and sending files to our external partners and customers. By working together, they can develop the maintenance window policy, but with all the knowledge together to understand what works best for the company as a whole-- not just for one department or group.
In the end, DevOps really is a philosophy more than anything else. It's a combination of driving factors that are helping transform not only IT but also entire organizations. As the practice of DevOps evolves, don't be surprised to see the name itself change or become more of a verb than a noun. After all, when you've got something that works so well for IT, why shouldn't it be used across the whole company?
ABOUT THE AUTHOR: Robert Stinnett is a data center automation architect who works for CARFAX Inc. Stinnett has spent more than 20 years in both data center and workload automation, has experience in both the distributed and mainframe side of data center automation, and has written several white papers on data center automation and optimization. Stinnett has also been a speaker at various conferences on the subject of Enterprise automation and has written a number of public domain utilities to assist others in realizing the benefits of end-to-end automation efforts.