As the enterprise mobility landscape continues to become more complex, one of the more prevalent challenges faced by enterprises around the globe is how to ensure changes (be it logistical, new software implementations, or even a move to new office space) impact the business positively rather than negatively. Traditionally, change management processes such as Information Technology Infrastructure Library (ITIL) methods are used to effectively implement these changes. However, as DevOps initiatives have gained momentum in recent years promising more frequent and faster development, organizations are struggling to find a balance between the two seemingly conflicting goals from the different methods. One offers continuous integration and delivery, and the other focuses on following a protocol, ensuring changes integrate with larger business initiatives, and mitigating the risk of oversight.

This post will examine how DevOps and change management can coexist in an enterprise context and how the two groups can work more closely together and automate the deployment process. Furthermore, this post will address challenges, methodologies, and organizational implementations. 

 

 

Current Trends In Enterprise Management Methodology 

 

According to VersionOne’s 13th Annual State of Agile Report enterprises are continuing to show an interest in adopting Agile methodologies. In fact, 97 percent of respondents from that survey stated that they embarked on an agile transformation initiative to some degree.  Because agile promises enterprises the ability to increase responsiveness, continuous integration and frequent delivery, there has been an uptick in the number of enterprises adopting DevOps initiatives. So much so that according to the same report, 73 percent of respondents are investing in DevOps. However, As agile is typically regarded as more effective amongst smaller teams, larger enterprises are facing challenges when attempting to scale agile and DevOps initiatives successfully. 

 

DevOps 

 

DevOps is an enterprise software development term that refers to a type of agile relationship between development and IT departments. The goal of DevOps is to change and improve the relationship by emphasizing better communication and collaboration between the two. It aims at establishing a culture and environment where software releases can happen frequently, and more reliably. The DevOps model combines continuous integration, continuous testing, continuous monitoring, and continuous delivery, allowing teams to react to business opportunities in a timely manner. For example, Amazon Web Services deploys software updates every 11.7 seconds.

 

Continuous Integration

 

Continuous Integration (CI) is a development practice wherein developers integrate their code into a shared repository regularly and frequently. An automated build – typically via a Continuous Integration System – verifies the code and allows errors to be detected early. 

 

Continuous Testing

 

Continuous testing (CT) is a process that uses automated testing in order to gain immediate feedback on the business risks associated with a software release candidate. It is important to note that while automated testing is an integral part of CT, they are not the same.

Automated testing constitutes the detection process for software issues and defects prevention, whereas Continuous Testing addresses the wider challenge of improving the effectiveness of these detection sensors.

 

Continuous Monitoring

 

Continuous monitoring is the process and technology used to detect compliance and risk issues associated with an organization’s operational environment. The operational environment consists of people, processes, and systems working together to support efficient and effective operations.

 

Continuous Delivery

 

Continuous delivery describes the ability to get new features, bug fixes, configuration changes and more live and into the hands of users quickly and in a reliable, replicable way. Continuous delivery, on the other hand, is more focused on automating delivery by using tools to execute various processes.

 

 

Change Management

 

In contrast, change management is typically a more drawn-out process with long turn around times. The main goal of any change management process is to ensure that changes are managed in a cohesive way that ensures there are frequent checks and balances around user impact, corporate policies, regulatory compliance, security, etc. and to establish and support the implemented enterprise operational model. To achieve this goal, the change management process needs to determine how changes are to be managed, what techniques are to be applied, and what methodologies are to be used.

There are many valid approaches to change management, and various management techniques and methodologies that can be used to manage change; for example, project management methods such as PRINCE2, service management methods such as ITIL, management consultancy methods such as Catalyst, and many others.

 

Can DevOps and Change Management Coexist?

 

In today’s high-paced environment where customers and stakeholders expect a quick turnaround and faster release cycles, the DevOps model seems to be the way to go. However, the sequential and reactive nature of change management (especially within the areas of release and deployment) in large enterprises can negate the potential benefits of DevOps.

Whereas change management frameworks at their core are designed to deal with large-scale changes, identifying dependencies and operational risks, DevOps reverses this approach by optimizing for small and frequent changes – breaking big changes down to smaller iterative steps and automating how they are managed.

While the two may seem at odds, DevOps and Change Management can coexist. DevOps is improving the programming process and speeding up development. But for DevOps to coexist successfully with Change Management, enterprises need to be able to define the change in terms of its scope, follow the change throughout the development lifecycle, share change information with other systems and personnel, and understand how that change impacts other intersection points.

But how can this be accomplished? How do we incorporate the DevOps approach within an existing functional framework? Below is a breakdown of how enterprises can work to achieve this.

 

Introducing DevOps Into An Existing Process

 

If an enterprise wishes to introduce DevOps into an existing process the enterprise should meet the following criteria:

• Already familiar with agile concepts like fail-fast, iteration, sprint planning, etc.
• Corporate culture is geared towards collaboration and fewer information silos.
• There is a desire to make an organizational change that leads to a faster time-to-market in a sustainable and safe way.

 

Change in Delivery Mindset

 

“Change” needs to be built into an enterprise’s delivery mindset as well as processes. There are no “big bang” releases. Many organizations claim to be agile, yet still have very slow release cycles. In the DevOps model, done means released. The mindset needs to shift to a continuous process comprising:

• Code – Code development and review, more effective use of source control tools
• Build – Introduce continuous integration tools to automate the build process
• Test – Test and determine performance using automated QA
• Package – Pre-deployment activities
• Release – Change management, release deployment (Development and Operations team)
• Configure – Infrastructure configuration and management, infrastructure as code – VPC scripts for AWS, use containers, Cloud Foundry (Development and Operations team)
• Monitor – (Operations Team)

 

Change in Various Corporate Policies

 

Bring policies around security early into the development process. Consider implementing a secure software development process: add checkpoints at the development stage to promote confidence from a security perspective, security scans, penetration tests, code coverage tests, etc.

Remove corporate policies that separate development and IT operations. Get them to work collaboratively within sprints so that anticipated infrastructural changes can be set in motion within the staging environment, followed by production environments. Any processes around documentation and sign-offs can be initiated as well.

 

Change in “Change Management”

 

Turn change request management from a sequential, event-driven process to one that is outcome-driven. Rather than being reactive, it needs to become pro-active. One of the main goals of change management is to assess risks and impacts – if the confidence level of the upcoming delivery can be increased incrementally via automation throughout the various stages of development and testing, then change management steps can easily be streamlined.

 

 

Pre-Transition Checklist

 

• Baseline your current processes and procedures
  • Development processes
  • Operational procedures
  • Change Management processes
  • Project Management processes
  • Security and compliance procedures
• Conduct discovery/interview sessions to uncover and document impediments to…
  • Continuous integration
  • Continuous testing
  • Continuous monitoring
• Figure out the component candidates to address the impediments
• Design a transition roadmap using the components with clear timelines and milestones
• Re-validate that the transition roadmap addresses concerns raised by various teams and project sponsors, and highlight any concerns
  • This may require getting all stakeholders into a single room and conducting feedback sessions before building a unified view that is shared with all people concerned
• Get sign-off on the transition roadmap and publish within the Knowledge Management System so that it is available to all the relevant stakeholders

 

The Transition

 

Implement the transition roadmap step-by-step. Once a milestone is achieved, do a retrospective to assess the current state. If it’s in-line with the expected results, initiate the next step. If not, fine-tune the roadmap based on feedback and analysis and proceed further with the implementation. Maintain a time box at every stage so that the transition cadence is not lost. Once the implementation is complete, document the newly achieved process as the new baseline Organization Specific Process. Remember, every enterprise will implement DevOps slightly differently.

After the transition, it is important to introduce feedback loops so you can measure the performance of the process, adapt and document. The goals of measurement include:

 

• Understand if various personnel are able to effectively execute their duties within the new process
• Identify issues that have come up as a result of the new process. Chasing perfect process implementation is not the goal, but rather a version of the process that mitigates risk meets compliance and corporate policies, and improves time-to-market
• Make recommendations for adapting/refining the process and document the recommendations. Ideally, process improvement should follow a CSI model from ITIL, but it will depend on what kind of cadence the enterprise wants to maintain

 

Closing Thoughts

 

While there is often friction between change management and DevOps models, it is possible for the two to coexist in the enterprise world. Every enterprise will implement DevOps slightly differently, but in order for it to be successfully introduced into existing frameworks, changes must be made to the way enterprises approach delivery, corporate policy, and Change Management itself. Achieving the right balance will result in more efficient software development and delivery in a way that is both safe and sustainable. 

Keep Reading:

How to Scale Agile in Enterprise Environments

Beyond Code: A Holistic Approach to Agile App Development

Rethinking Mobility: A Business Leader’s Guide to an Agile Enterprise