Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Is DevOps at odds with change management?

public://pictures/image2015-4-7 13-54-37.png
Paul Korzeniowski Blogger, Independent
DevOps speeds up application development, provides for better feedback, and more. But how do change management teams deal with the growing number of releases?
 

Change management has never been easy for developers, and the rise of DevOps is increasing its difficulty. DevOps speeds up application development, provides for more feedback, and reduces design flaws. But those gains come at price: developers and IT operations personnel now struggle to keep pace with rapidly arriving system alterations. So what are the problems and how can a company address them?

What do we mean by change management?

What is change management? Companies constantly evolve, so managers need to put checks and balances in place to ensure that the iterations impact the business positively rather than negatively. This is the essence of change management. Top level executives look at change from the top down. How much and for how long, for instance, will moving an office from Houston to Dallas impact the company? From an IT perspective, change management means that all the moving technology pieces (applications, operating systems, servers, system networks, and end user devices) need to be in sync.

Developers typically need to be sure that their new lines of code are seamlessly integrated into the organization. But DevOps can make that task more difficult. Don't get me wrong—the DevOps approach is gaining momentum because it promises to more tightly connect development and testing with system operations, and the result is more speed. Rather than painstakingly asking for new services and having operations slowly roll them out, the two groups work more closely together and automate the deployment process. This results in more new releases, faster. But dev teams need to make sure the changes map to the larger initiatives at the business level, and ideally, support the core agenda around competitive differentiation and customer retention.

Ops challenge: Speed and complexity are on the rise

Well, how fast is faster? Amazon Web Services constantly deploys software updates—new releases arrive every 11.7 seconds. Few organizations will come close to that level of speed, but as corporations embrace DevOps, the number of system changes rises, often dramatically. "Management wants IT to react to business opportunities in a timelier manner, and DevOps helps meet that desire," says Nathan Wilson, research director at Gartner.

While it meets business needs, the rapid pace of DevOps practice puts pressure on operations in a variety of ways. Companies design and test larger and more complex solutions than ever before. For instance, Microsoft Office 2013 Professional takes up about 700 megabytes of disk space and consists of billions of lines of code. Making sure that all the elements in an application work well together is a challenge for operations teams.

In addition to software changes, companies constantly morph as well. New systems are added, existing devices are upgraded, some users leave the company and should no longer be able to access the systems, and new employees begin their careers. "Many IT departments struggle to keep pace with system changes especially with mobile, social, and cloud solutions," says Mary Johnston Turner, research vice president, enterprise system management software at IDC.

Pinpointing glitches

As the volume of changes increases, so does the likelihood of human error. A DevOps team may push out 1,000 changes, 999 of which are fine, but one has a glitch and causes problems. Why does this happen, and how should we understand it?

Poor communication is often a primary source of system design flaws. DevOps has moved development and operations closer together, but the more communication required, the more individuals are involved in the process, causing new gaps to emerge along with the old ones.

Typically, a business unit and its supporting development and operations teams are involved in designing a program. These different folks own small pieces of the application puzzle, and sometimes their myopia creates ripple effects. For instance, in pushing out an update, a developer overwrote a few shell scripts for an application running at the New York Stock Exchange. "The system blew up, and trades could not be placed for an hour," wrote Bob Aiello, consultant and software engineer, and author of Configuration Management Best Practices: Practical Methods that Work in the Real World. In this case, the developer clearly lacked an understanding of how the system connected to all the other applications running in the company, and the focus on improving one application brought all the other applications down.

Changes in attitude and business processes are needed

A corporation's typical outlook toward change management is one of mild indifference. They're often more interested in adding a new widget to the user interface, and of course, developers tend to take up this challenge. They consequently lose focus on the mundane, often monotonous work involved with change management.

But businesses need to emphasize the importance of documenting and implementing changes properly, Aiello says. Traditionally, changes would be grouped and released periodically. With so many changes taking place with DevOps, developers need to be prodded to document alterations in an iterative fashion as they code and relay that data to all potentially impacted groups.

Proper documentation is needed in order to maintain compliance. Increasingly, regulations such as Sarbanes-Oxley and HIPAA (Health Insurance Portability and Accountability Act) require that companies put checks in place to better monitor the change management process. If problems arise, enterprises need to be able to follow up and have a paper trail that shows exactly what occurred. The firm also needs to verify that only authorized users accessed the systems and made any alterations. Such business processes need to be incorporated into the DevOps processes.

Currently, corporations tend to treat change management as remediation work, rather than a valuable aid to compliance traceability. After a problem arises, change management becomes a way to identify the problem. But time (often a lot of time) is needed to test theories and pinpoint issues. Does a network outage come from an update to a virus protection system, or was it a change made to a router? In today's applications, the possible problem areas range widely: system configuration, application updates, static content usage, and database updates all may play a role in development issues.

Maintaining efficiency

The more time an operations team spends probing problem spots, the less time the system (and increasingly, the business) is up and running. As a result, the group may take a quick and easy explanation of the problem rather than digging down to the more complex.

Troubleshooting can also become an item passed from one group to the next. The goal becomes to avoid blame and spend as little time as possible examining what led to the issue, but such an outlook leads to problems. Organizations need to view change management as something important enough to be addressed proactively rather than reactively.

Information overload can become another problem. In a typical DevOps scenario, dev is moving so fast that programmers have trouble keeping track of requested changes. And because change management tracking is being automated, development is tied into areas like automated load testing, delivery log analysis, automated functional testing, and configuration management. These systems try to track what is happening on the enterprise network and outline potential trouble spots—for instance, notifying the operations staff that a program has made a change to the firm's authentication system. However, so many changes are occurring that the operations staff may inadvertently overlook important red flags.

DevOps is improving the programming process and speeding up development these days. To be successful, 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. Only then will change management and DevOps be in sync.

Keep learning

Read more articles about: Enterprise ITIT Ops