DevOps is a movement that is underway or at least in the very early stages of infancy as a way to rid the IT world of some if not most of its silo’s. Silos have existed in Information Technology (IT) from the beginning for two reasons, the complex nature of early IT systems and because that’s the way businesses are run, for the most part. Silo’s are an easy way for Accounting to make sense of business operations, for example, marketing only does marketing activities, sales does sales, distribution does distribution, etc. So fast forward to today’s IT environment where Agile is taking hold and become more prevalent, where IT systems are becoming more complex, where news reaches the rest of the worlds in seconds not days or weeks. Large scale failures and inefficiency is becoming not only way of life, in some people’s eyes it’s the norm in IT. DevOps is an attempt to correct this: Will it succeed? Time will tell.
The Problem
In IT there is one thing that is certain and unfortunate at the same time: most projects fail. They fail to meet the triple constraints of; on time, within scope, and under budget. Some in our field have even added a fourth constraint of quality. This not to say that all IT projects that fail to meet the triple or quadruple constraints, don’t get implemented, they do. However, when you measure the success using the triple and quadruple constraints they are failures. While this seems to be an oxymoron it really isn’t, it is simply a black and white view a fail or succeed, no gray area, no kind of succeeded view of success or kind of failed.
The causes of these problems are too immense to mention here, but several are noteworthy. Let’s suffice it to say that unrealistic dates, staffing issues, non-cooperation from business to IT and IT to the business, little or no oversight and poor project management. The result is obvious, cost overruns, software that doesn’t perform as promised or meet the requirements and the finger pointing that inevitably will arise. Once this happens, distrust reigns and camps become entrenched in IT.
The Proposed Solution
DevOps is an approach that is trying to fix the problems just mentioned. The approach is fairly simple: Tear down the silos that exist between development, operations and quality. We all have experienced the silos in organizations. Development codes and throws it over to the quality group; they test the application, and then throw it over the wall to operations to deploy. Then in deployment there is either a failure immediately or shortly thereafter.
Operations wonders why it got bad code, testers say ask the developers, developer’s say it worked in the development and test environments and that the production environment is incorrect. Operations says it is not their fault, while failing to disclose the three patches they forgot to apply to development and test environments. Not only is this damaging to the groups trust of one another it does nothing to solve the core issues.
In the DevOps concept organizations cross-train the people in their groups, remove the silos, encourage more collaboration between the groups, adapt more iterative/agile approaches, give more control of environments to development and quality and automate as many processes as possible. What you create is a cross-functional team that no longer sees issues as development or operational, they see the issues and problems as a cohesive group and try to solve those problems collaboratively. While I have not covered everything that DevOps is, I will say that from my view this is a step in a positive direction.
Will it Work?
Removing the silos in any organization is always a good idea. Not only does it increase transparency in what you do, it removes the veil of distrust and inefficiency of silos. From that standpoint DevOps is bound to work and can only be successful. The one potential downside would be the possibility that you create a group that is “jack-of-all-trades master of none.” Specialization will always be needed and have experts on teams will be required. For the low hanging fruit having a group that can handle multiple issues and scenarios reduces the chance that you don’t have enough people to do the job.
Now the caveat: some silos are necessary and even some silos in a DevOps group are necessary. How can I say in one sentence it makes perfect sense and then contradict the very statement I made in the next sentence? The answer is simple. Not everyone in a DevOps group needs root access to the database server. Not every person in the DevOps group needs the System Administrator password. The security roles in most organizations are very specialized and have access to confidential information, this simply put, cannot be available to everyone. So if your security group is part of DevOps it can be in a silo, if it is external to the DevOps group it can be in a silo. Remember that common sense must prevail over the dogma of any standard, framework, group makeup, or passing fad, etc.
The Future of DevOps
I think the future of DevOps is very bright, especially with the mainstream acceptance of Agile development in the past five years. No longer can groups simply throw the work over the wall to the next group. The change and pace of development is evolving to a degree that iterations are quicker and more frequent. Couple this with the complexity of systems today and in the future, barriers and the structures that slow you down today will become the things that shut you down in the future. DevOps will continue to evolve over the next few years and reach a mature point and some point and will do so whether you are onboard or not. If there is one thing that I have learned in my twelve plus years in information technology is that things change rapidly and while you don’t have to be an early adopter of everything, you have to learn to adapt to your environment and to the changing conditions in the industry.
