Question: With all the talk of how effective DevOps is, why is it not more widely used as an IT organizational methodology?
On paper, the concept of the development and operations part of an IT organization working in concert is wonderful. In fairness when a company makes the effort to encourage the organizational changes that need to be done, the productivity gains, velocity and quality improvements of the IT systems more than make up for the pain of the organizational changes. However the effort of making that transformation is often far more fraught with technical obstacles and political stumbling blocks than many over-stretched IT organizations is capable of handling. Fortunately with proper guidance there are Agile and organizational transformational techniques that can be used to overcome the issues.
Often the reasons why these transformations are not as successful as they could be fall into three categories:
Organization, Political and Business Issues – Anyone who has ever worked knows that organizational issues are the most deep-seated and difficult to overcome. The old boys’ networks and entrenched ways of thinking are sometimes insurmountable roadblocks. There are several methods to address these issues, but in all cases strong sponsorship and support from the executive ranks is essential for a successful creation of a DevOps mindset in an organization. One way to influence the change is to take a page out of the old organizational change playbook; create an organization that aligns with the desired outcome. In one large enterprise the solution to the resistance to changing from the old IT operational mindset was to reorganize the entire IT organization so that the development and operations groups reported into the same structure. The manager of both groups was a strong believer in the need for DevOps to support the company’s multi-million dollar cloud initiative. By forcing the groups to work together in Agile Swarms, they were able to build the trust and skills needed to bring about the organizational transformations.
Outsourced IT Business Model – Yup, you read that correctly. For all the touted benefits of outsourcing, and I will agree that there are many, agility and organizational transformation is not one of them. The outsource vendor is motivated to manage risk by eliminating as many unknowns as possible. Like traditional IT operations the easiest, but no always the best way to accomplish this goal is by minimizing changes in the environment. This encourages rigid thinking and highly delimitated roles. It isn’t always that the work is off-shored that causes problems. Often the issues are related to poor project management, unclear articulation of the team goals, and a disconnect between the purchaser of the services and the vendor. One company is mostly using American labor, but they are so stuck in their ways that they are just starting to think about breaking down the barriers between the functional groups. Another is having an IT meltdown on the operations side of the house which is causing them major headaches. Communications issues across the organization and between the vendor and the customer in this mixed shop are behind much of the conflict.
Staff Skills – This is an often overlooked aspect behind the failure of DevOps initiatives, the skills and working habits of development and operations people are typically wildly divergent. Developers often work on new projects, so are typically more willing to take risks, work with underdeveloped and/or buggy code and generally are not very concerned if things break along the way. They know that breaking things is just a routine part of the development process. On the other hand, IT operations people are paid to keep systems running as smoothly as possible. They are often held to strict SLA’s so they take five-nines seriously. One way to keep an environment stable is to introduce change as little as possible. IT operations are famously resistant to changing code on the fly or introducing other things that might cause them to be paged in the middle of the night when the systems have a hiccup. Who can blame them really? This defensive mindset can be addressed by applying newer architectures and technologies that are tolerant of component failure – the automated deployment and designed to fail architectures. Once it is demonstrated that a failure of a component is not a catastrophe, just one more expected event that has no immediate impact on the systems, the next logical step is to build processes that allow continuous incremental changes to the systems. Encouraging a set of shared standards is a good way to develop DevOps processes across the organization. For one enterprise this meant building a service catalog of standard images for the developers use with all the commonly used tools. The developers given the option of using either a pre-built applications tools platform or building a custom one took the easier path. Standard tools problem solved.
About the Author
Beth Cohen, Cloud Technology Partners, Inc. Transforming Businesses with Cloud Solutions