By Jeff Lucchesi
DevOps started out as a necessity for development and IT Operations to collaborate on rapid deployment and better efficiency in operating and supporting the product. With products in the high tech world changing rapidly, keeping up with the engineering organizations has proven to be a challenge for CIOs.
In the last few months, we have seen IT lose control to the Engineering organizations because of the failure of IT to re-think how they work and show true value on the product side of the house. By the time a CIO realizes they have issues with supporting the engineers, the wheels are already in motion at the executive levels to move it away from IT. Once again, the CIO loses the opportunity to show true value on the product side of the house.
A common, misinterpretation of Dev Ops is that it’s a technical term. For example, “If I have the right amount of skilled technologists who know automation tools, I can be successful in operating the group and show value” was one comment I heard. Ah, no…DevOps isn’t a technology nor does it apply to running services just in the cloud. It is a completely different approach and philosophy to the operation that most traditional IT organizations are not structurally set up to support. So what needs to change in order to be successful?
First, the need to restructure is essential. Many IT organizations structures are still set up as if they were supporting the business in the 1990’s. That is a topic for another day but if you aren’t ready to completely re-structure the group, then the DevOps function needs to be separated from your core operation so it can innovate, be flexible and above all move at the speed of light. This is transformational work and vastly different from the “stabilizing” mentality of the 1990’s. Without this core redesign, DevOps will continue to threaten the existing organization. Once the function is performing well, the need for large infrastructure organizations will shrink rapidly (another subject and at another time). It needs to be an independent body.
Second, it is collaboration, not a technical solution. Throwing technology at this new endeavor will not fix the problem. Adding technology which isn’t backed by good, repeatable processes will only speed up errors and cause problems faster. Take the time to partner with the engineers to work on the processes and methodology to make sure they are not “heavy” and lead with automating as much of the work as possible. Remember, one of the objectives here is rapid deployment so previous operational processes are not going to work here.
Third, is a shared goal. The objectives between engineering and operations need to be the same so there isn’t competing goals which exists in older models. Tie the objectives into their comp/bonus plan so both parties either fail or succeed together.
There are no guarantees these steps will lock down the structure for the CIO but it will position you to partner with engineering correctly and upping the odds of success.