Why is it that, after so many years, there’s still a prevailing IT conflict between Development and Operations, especially in relation to changes being promoted to Operations?
It wasn’t always that way. In the early days of virtualization, the Development organization tested and then promoted change in virtual environments. Operations then worked it out and brought controls to bear. With the cloud, the same controls have started to appear, but there’s far greater business demand for innovation, differentiation and delivery of capabilities to help maintain competitive advantage.
And there are other differences, too. In most organizations, Application Development has dealt directly with the business and felt the brunt of the pressure to perform. But in today’s resource strapped environments, everyone is aware of the business cadence, and is feeling the heat.
So why is there still such a conflict between Development and Operations? For one, there’s a fundamental metric difference between the two groups. The Development organization is often compensated on code completion for a requested business change. The Operations team usually has site reliability as a major component of its performance. So one group is paid for change while the other is paid to reduce the change impact and the supporting operational processes, including change review, release management and back out strategies.
Given the rate at which new code has to be put into production, we can’t have a formal change advisory board for everything. But some changes do require a formal review process because of the risks and potential business impacts.
A primary imperative in this era of continuous change is therefore to understand exactly where to accelerate delivery with the fully automated introduction of new code into the production environment and where to enforce more formal change management processes. To do this, we need to classify systems into logical groupings that incorporate all relevant change-related attributes – including delivery cadence, risk tolerances and system type (i.e. systems of innovation, systems of differentiation or systems of record) Based on these attributes, we can implement the most appropriate change process for any given piece of code.
In other words, business agility isn’t just about adopting ITIL and/or DevOps in some global or undifferentiated way. It’s about applying best practices from both in a context-intelligent way – so the business can become more agile while simultaneously getting even better at mitigating IT-related risk.
Let’s think about demand for a moment. All demand is not created equal. If we are driving innovation, looking for rapid change, delivering on a mobile device with consistent and continual updates, DevOps is more often than not the correct philosophy.
When we are adding capabilities to an ERP system, which is considered a system of record, we’ll make changes in a structured manner with multiple groups. So cultural change management will be critical, and therefore the use of good process as defined within ITIL is more appropriate. (Systems of Record will be updated on a scheduled process and these systems will typically have a long lifecycle in terms of organizational value.)
Of course, there is also Systems of Differentiation–applications that enable unique company capabilities and have a medium lifespan of three or more years, but require constant renewal or reconfiguration to meet changing business practices or customer demands. Depending on the use and phase of the lifecycle, these applications will typically use DevOps at the beginning of the lifecycle and as they become subject to more structure and rigor.
Most organizations today are realigning priorities to better leverage IT investments with business objectives and new technologies. In the area where I work, we are planning to double our investment in Systems of Innovation. This is where DevOps excels. It can improve the value stream with greater frequency of delivery and focus on the feedback loop, which should extend across the entire life cycle of the solution to provide insight and value.
For instance, closed loop feedback delivers insight into the performance of a recent configuration updates, including critical information to assist in shaping future products in areas such as usability while minimizing education requirements.
One of the key components of DevOps is the concept of integrated tool chains across the life cycle. An associated success factor is automating as much of the complete cycle as possible, with the objective of accelerating the change velocity — not just to improve speed but to improve reliability and auditability. Doing this with an end-to-end perspective in mind, however, requires combining the individual technologies in a manner that facilitates what the financial services industry refers to as “straight through processing.”
Like all things in IT, the key to success is having the correct people. This area is often overlooked. The best DevOps-oriented team members won’t just be technically adept—they’ll be looking to innovate and advocate a culture of value to the business. If the issues associated with culture and people aren’t effectively addressed, technology investments won’t deliver the desired value.
In an attempt to drive change velocity and innovation, DevOps could be for you. But remember, it’s not a panacea. It is a philosophy, a piece of the puzzle. It can’t do it all.
Share your thoughts in the comments section below.
Latest posts by Robert Stroud (see all)
- Is DevOps Destroying the Wall Between IT and the Business? - July 24, 2013
- Do You Have the Correct Plays in Your Playbook to Drive Your Business? - April 23, 2013
- Lokesh Jindal Talks about the “Business of IT” - April 12, 2013