When some of us think of change management, our definition involves every aspect of change—from technology, people, and process to the impact on customers and systems. Axelos listened to the feedback and responded. In this article, and at Atlassian, we refer to it as change management.
What does matter is your approach. Start with healthy teams and the right culture, and your organization is on the right track to create an effective change management practice. Historically, release management has bundled changes together, presenting them to customers as a package. Traditional release management upholds rigid project management standards and can create friction in shipping valuable updates to customers, leading to frustration among teams that adhere to Agile principles. We can reimagine release management for the DevOps context.
Shifting away from its traditional project management function, release management should become about integration and automation. It starts by bringing code pipelines into a secure system that incorporates automated review where possible and provides tracking and oversight. This can break down the siloed approaches of the past and provide a frictionless path to production. Modern organizations have a couple of critical and competing expectations for their IT team.
First, they expect stable, reliable services that ensure the organization is productive and able to meet end-user expectations. Second, the IT team needs to implement regular service updates to enable the organization to adapt to constantly changing security, cost, and business requirements.
Failure to do either can result in dire consequences. Inability to maintain reliable service can cause massive damage to productivity and costs. For some web-based services, that number can be dramatically higher.
Deploying changes too slowly could result in employees defecting to work in places with less clunky systems or your customers sending their support and dollars to other organizations that provide them more value. So, how are you supposed to manage these conflicting needs? A change management practice enables your organization to ship updates while ensuring stability and mitigating risk.
Change management helps accomplish change in the following ways:. Standard changes are low-risk, commonly repeated, and pre-approved. For example, adding memory or storage is a standard change. Replacing a failing router with an identical working router is a standard change. Creating a new instance of a database is a standard change. All of these changes are common and follow a well-defined process. For many companies, standard changes are a prime opportunity for automation.
For example, upgrading to a new content management system is a normal change. Migrating to a new data center is a normal change. Performance improvements are normal changes. However, some argue that ITIL is too much about processes.
Change management helps to define a formal way of requesting changes. It also helps assess the risk of a change request. The DevOps team needs to know how a new change will impact the current IT services. For that, you need to employ agile change management.
The DevOps team will probably decide to first deploy this service to a test or separate environment to further assess the impact. It puts an extra workload on your DevOps team. After all, they have to learn about the whole change management process. Change management requires that every change request comes with documentation about the possible outcomes, risks, and benefits.
This helps the DevOps team keep track of all changes and formally document them. Besides that, change management also defines how the DevOps team has to communicate changes. This is an opportunity for them, as it forces them to learn how to speak to all affected departments. You can see why it can be hard to get an emergency change approved in a timely manner.
Considering this, change management can be a threat to existing IT services. Especially for DevOps, automation is king. Therefore, we could come up with a new change request that restricts any employee from using SSH to the servers.
This would mean that the DevOps team has to come up with ways to automate every aspect of their pipeline and daily tasks. So you try to consult the logs for this specific service. Instead of SSHing into the server, you force users to use a log aggregation tool that offers better functionality for searching and filtering logs.
For that reason, the change request should allow for an occasional SSH into the servers. But the DevOps team should think of ways to automate this exception. In another example, a DevOps employee notices that their server is running out of memory. According to the new policy, they want to avoid manually allocating more storage space. He should use the APIs many cloud providers expose to first get notified when a server is using almost all of its available storage space. Almost any problem can be automated.
By doing so, the DevOps team will gradually save more time by automating most of its tasks. The biggest mistake I often see in change management is that company leaders often fail to involve managers in the process to embrace, promote and facilitate the changes that need to happen.
Want to install a new printer? Add a new domain controller? These proactive changes focus mainly on offering new products or services.
This adds value to your organization through cost-savings or more efficiency. Is your security breached and do you need to patch one of your servers in a hurry? Reactive changes mainly involve resolving errors like these. With Change- and Release Management, this process becomes more smooth and efficient. Why this matters? Because every change you make to your infrastructure could lead to bugs or problems.
And this in turn leads to your services being disrupted. It also leads to downtime of your systems, and reduced productivity of your service desk staff.
In fact, poor change management could lead to lots of incidents, even major incidents. Change Management safeguards your services against any of these unnecessary errors. And if an error does occur? Thanks to the software, you can easily trace all changes and pinpoint where things went wrong. In addition to minimizing the impact of disruptions to your services, there are a number of benefits:. In IT Change Management there are three distinct classes of change: standard changes, normal changes and emergency changes.
The YaSM service management model includes a process for managing changes that is a good starting point for organizations that wish to adopt ITIL 4. Change Management seeks to minimize the risk associated with Changes, where ITIL defines a Change as "the addition, modification of removal of anything that could have an effect on IT services". This includes Changes to the IT infrastructure, processes, documents, supplier interfaces, etc.
Normal Changes are often further categorized as Major, Significant or Minor, depending on the level of risk involved. Organizations should define these types of Changes and the required Change Authorities in their Change Policy. Change Management will then record, analyze and approve or reject the Change.
For certain types of Changes, a formal Change evaluation takes place by the Change Evaluation process and is documented in a Change Evaluation Report. Organizations should streamline Change Management and avoid unnecessary bureaucracy by using the full Change Management process only for a small number of significant Changes. Effectiveness and efficiency of Change Management can be improved, for example, by.
ITIL 4 refers to "Change enablement" as a service management practice see above. Change Management Support. Assessment of Change Proposals. Assessment and Implementation of Emergency Changes. Change Assessment by the Change Manager. Change Assessment by the CAB.
0コメント