The DevOps operating model is a partnership, and, like any partnership, the participants need to move a little to find a solution that benefits everyone.
Because operational folks tend to focus on controlling change, they are in many ways the opposite of development groups, which embrace change. Over many years, IT operations professionals have seen both good and bad results from changes to software. While changes are usually more positive than negative, it's easy to remember a time when a change created a problem and easy to forget when everything went right. It's the ops team that deals with the consequences, so this history has soured operations teams on change.
Logic would dictate that operations should move to the middle and work seamlessly with the development teams. However, logic falls short in changing minds when it comes to the fear of outages and upset customers.
It's more than just outages. Operations teams deal with configuration control and IT infrastructure library (ITIL). The change itself isn't always bad, but ITIL creates a longer change process. Simple changes can mean mountains of paperwork that can require more effort than the change itself. While paperwork and process shouldn't be the sole reason to stop a change to the DevOps operating model, organizations must account for these hours and learn the real cost of changes.
Bad releases and concerns about configuration change lead operations teams to pump the brakes on changes, but maybe it's time to look at shifting the entire process.
Part of this process will include operations accepting additional changes -- that is part of the DevOps operating model. However, you can still control changes. The key to success is embracing change -- but at a pace you can work with. Ops is, after all, a gatekeeper, and not every change needs to be pushed forward immediately.
Operations staff can assist development teams to establish a schedule for changes, something that will help both groups. While this sounds ideal in concept, it works only if operations can reduce the change-management process. The sheer number of steps for quality and control that ITIL demands simply doesn't fit with what the DevOps operating model is trying to accomplish. Something has to give, and, in this case, it will be the fine detail of ITIL.
Oddly enough, reducing ITIL steps won't upset many ops folks. It means less paperwork. Managers who pushed ITIL as a way to help control and prevent problems, however, may resist. The key question is: Will management be OK with streamlining the operations process to facilitate DevOps?
Conversations with management about DevOps are often difficult. Managers feel pressure to move fast, but they also don't want to lose process and change control. Development and operations groups must communicate with management to decide what should be changed or removed to improve the process. It won't be easy, but all sides will have to give a little.
The good with the bad
The move to a DevOps operating model might spur panic, but the opportunity to reduce mundane processes will only benefit operations. You should look at this as an opportunity to reduce monotonous steps, embrace change and empower the business. Just remember not to go too far. Do not negate the benefits of change management and control just to streamline processes.
Will a true ITIL process still fit your organization after you create a DevOps environment? Probably not. But how many organizations ever had a true ITIL process to begin with?
The journey to a DevOps operating model is about how development and operations teams can work together to benefit the company, and this can look different depending on your applications and customer base. DevOps will be worth the effort when all teams understand the needs and concerns of each group -- including management -- and there's balance that allows this new team methodology to succeed.