The reality today is that companies are completely dependent on their IT infrastructure. Take that down and the business grinds to a halt. IT infrastructure is running the internal ERP as well as external customer interfacing applications. It does not matter anymore what sector of business your company is in (entertainment, manufacturing, services, health, transportation, education, etc.), software services are at the core.
There are no longer any stand-alone desktop applications in a business operation. Everything is networked together and backed by some type of service workflow, data storage and analytics. You might not have a formal IT division, but somebody is supporting the backend business critical systems.
One phenomenon that has occurred affecting the operational aspects of software development has been the adoption of agile methodologies by software development teams. This has greatly affected the interface between development teams and IT operations teams. Lengthy lead times before handing off of software to operations teams have been done away with. The continuous deliver model in software today is forcing a merging between operations and development teams. More and more of the overall responsibilities of operations is being shifted to the developer.
Another phenomenon that is also causing a rethinking of how IT operations are being run is the innovation of cloud IaaS and PaaS. These offerings have done an incredible job at simplifying the operational needs and making it possible to for a new IT management model referred to as DevOps to be possible. For example, there is no longer a need to run expensive secondary environments for testing and development. It can all be done on the one single platform with different staging environments that are provisioned easily by anyone.
No more walls of separation
Look at what happened when the TDD/BDD testing movements came along. Before that time, a developer would write code that was never tested and then toss it over a “wall” to a tester who would take it from there. The tester then toss the code back over the “wall” with any failures to be fixed. With TDD, developers took over the primary responsibility for testing. In some companies, testers were done away with and developers were given sole responsibility for quality. This forced developers to write better code! The “silos” that existed in organization are becoming a thing of the past.
We now see the same thing happening with IT operation responsibilities. In order to stream line with an agile process and deploy more frequently, it is advantageous to lessen the dependency matrix of people involved.
My opinion is that developers should now take over operations responsibilities. And what will be the outcome? Developers will write better code! You just cannot have a “middle-man” in the process anymore and deliver anything at a rapid pace. Who knows better than the developer how to instrument code and be able to troubleshoot problems? Again, we are moving to a consolidation of responsibilities into a new DevOps model. Evolve or be marginalized.
What Is DevOps really? Some people state that it is simply the closer collaboration between the professions of code development and IT operations. It may still work to keep separate people in charge of this, but I have seen it work with the combining of those roles into one profession and still be successful with the largest of applications.
Today, the term DevOps is more of a conceptual idea without any formal definition. For example, there are known standards in the industry such as ITIL, ITSM and MOF that define exactly the duties to be carried out. So, here is my attempt at formalizing a model that can be used to describe a formal DevOps structure.
Stay tuned for the rest of this series…