DevOps & Change Management In The Enterprise World
DevOps refers to a set of practices that emphasize the collaboration and communication between software developers and IT professionals while automating the software delivery process and infrastructure changes. It aims at establishing a culture and environment where software releases can happen frequently, and more reliably.
In the enterprise world, where legacy systems abound and the waterfall approach is still pervasive, implementing DevOps and Change Management initiatives that coexist seems like an insurmountable challenge; however, it is attainable.
This post will look at DevOps and Change Management in the context of enterprise environments, addressing challenges, methodologies, organizational implementations, and more. Specifically, I will discuss:
- Current trends in the Enterprise world
- DevOps Concepts
- DevOps vs. Continuous Delivery
- Change Management
- Software Release and Deployment Management
- Can DevOps and Change Management Co-exist?
- Introducing DevOps Into Existing Processes
Current Trends In The Enterprise World
In the enterprise world, organizations are exploring ways to deliver software more efficiently. In the areas of DevOps and Change Management, this is what the current landscape looks like:
- A large number of corporations have embarked on a transformation initiative, especially within their IT divisions. They are transitioning from waterfall to agile methodologies.
- To-date, Scrum is the most popular framework
- Companies are looking to bring continuous delivery to the forefront by implementing DevOps
- Challenges around scaling agile are still very prominent. SAFe, LeSS, and other frameworks are gaining traction
- Scaling DevOps is seen as a major challenge
In essence, the DevOps model combines continuous integration, continuous testing, continuous monitoring, and continuous delivery. These goals are supported by collaboration between developers and IT professionals and leverage a wide variety of automation tools.
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. A common automation tool used to facilitate CI is Jenkins.
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. As explained on DevOps.com, automated testing is an integral part of CT, but they are not the same:
“[A]utomated 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 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 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.
DevOps vs. Continuous Delivery
DevOps and continuous delivery are often used interchangeably because they are similar, yet they carry distinctive differences.
DevOps has a broader scope than continuous delivery and is more concerned with organizational change.
Continuous delivery, on the other hand, is more focused on automating delivery by using tools to execute various processes.
The main goal of any change management process is to ensure that changes are managed in a cohesive way that ensures there are checks and balances around user impact, corporate policies, regulatory compliance, security, etc. and to establish and support the implemented enterprise operational model. In order 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.
Release and Deployment Management
Release and Deployment Management essentially falls under the change management umbrella. It aims to plan, schedule, and control the movement of releases to test and live environments. It’s one of the primary goals of ITIL service transition.
In the most mature organizations, release and deployment manifests via a formal Change Request process. The traditional process generally involves the following steps, but may vary based on the use-case:
- Step 0: A new release or regular maintenance release has been produced by the development team. This release is scheduled to be deployed based on the release cycle or maintenance window schedule.
- Step 1: A Change Request form (analog or digital) is generated with the work order describing the change(s), impact, risks, and roll back strategies.
- Step 2: The submitted request, depending upon different business rules, is sent for review and approval up the chain of command.
- Step 3: Once approved, the operations team takes over the change request.
- Step 4: The operations team uses the deployment instructions provided by the development team to deploy the package.
- Step 5: The result of the deployment (success/failure) is reported back as part of the deployment checklist.
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.
According to CTO Jim Bird, 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.
In other words, Change Management typically follows a waterfall approach, where DevOps follows agile.
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 I give a breakdown on how enterprises can work to achieve this.
Introducing DevOps Into An Existing Process
- Enterprise is already familiar with agile concepts like fast fail, iterative approach, rolling wave planning, etc.
- Corporate culture is geared towards collaboration and fewer information silos.
- There is a desire to make an organizational change that leads to faster time-to-market in a sustainable and safe way.
Consider the Changes
Change in Delivery Mindset
There need to be changes in the delivery mindset as well as the process. 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 of:
- 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/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.
- 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
- 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 implementation is complete, document the newly achieved process as the new baseline Organization Specific Process
- Remember, every enterprise will implement DevOps slightly differently
Post-Transition: Measure Performance, Adapt, and Document
It is important to introduce feedback loops so you can measure the performance of the process. 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
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.