Implementing ITSM change management in Jira
Every software change in its essence relies on a software development process. So if software changes are a part of ITSM, this would mean that organizations need to find a way to integrate software development into the ITSM change management process. Sounds logical, right? You’d be surprised to learn how long it took teams to adopt this.
For decades, combining software development and ITSM change management processes was really difficult to implement. But in 2021, Atlassian made a brilliant and bold move to offer this in Jira Service Management in the Cloud. Keep reading to learn more about what this development means for ITSM change management processes in Jira. In this article, we zoom into the details of Atlassian’s approach to change management and show how to make it work for your teams.
Software changes used to be a struggle
In the past, applying changes to software within an ITSM change management paradigm was a big challenge. Just compare them to infrastructure changes. These could be easily applied to a theoretical model with risk calculations. This helped teams to make plans for their implementation, testing, and backout – and they discussed it all through CAB boards.
Software changes were too detailed for that. Changing 1 to 100 lines of code that isn’t going into production yet (so has no impact on Service delivery) wasn’t even considered to be a change. On the other hand, there were releases that grouped a number of changes together with manageable risks and plans.
At that time, nobody actually felt that software changes needed to be managed – especially considering that software development and ITSM toolsets weren’t integrated. Documenting such software changes as part of the ITSM regular practice was painful. We’re talking here about hours spent manually documenting changes compared to minutes spent on actual coding.
IT even witnessed a real “frameworks war” between Agile models and ITSM. Back then, people believed that while Agile didn’t require extensive documentation for every single activity performed, ITSM did. By the way, this isn’t true and, in both cases, depends on the actual scope and configuration, together with the organization’s maturity.
Why are software changes as a part of ITSM so important?
This is a key question we need to answer here. Why is it so important for software changes to become part of an ITSM change management process? What do teams stand to gain from this combination?
Here’s the primary reason: because software changes today make up for some 9598% of changes applied in IT environments. Whatever perspective you take – like the classic IMAC changes (Installation, Move and Change) typical for the barebone era of computing – they’re almost gone.
Consider this:
- How many physical servers do you have in your organization?
- How many virtual ones are hosted on top of them?
- Calculate both values times 5 since this is the average number of changes they go through on a monthly basis.
- Now calculate your value times 15 – this would be the volume of all other changes (software, database) every month.
So, how many changes are linked to the physical infrastructure, and how many are either software or IaaS changes? You get where we’re going.
The alignment of software changes as a part of ITSM is even more important in Agile environments. And if you think that there really exists a conflict between Agile models and IT Service Management, the recent developments from Atlassian show that this isn’t true at all.
To convince you further, here’s an example from The Phoenix Project, the DevOps bible that popularized the term “DevOps” and shared a wealth of insightful lessons about IT in modern organizations.
In the second chapter, one character is tasked with addressing a payroll outage that, if left unchecked, would leave employees without their paychecks. Investigating the issue becomes a real challenge when he realizes that the company didn’t use its change management processes. Instead of following them, employees contacted engineers individually to fix their problems without documenting that change.
Here’s how this snowballs into a real problem:
When so many small failures and changes go undocumented, when a large one appears on the horizon, the team has no timeline to work with or method to discover the source of the issue. This transforms a serious problem like a payroll outage into a real catastrophe.
That’s why having proper change management processes that embrace software development is so important. Employees need to be able to follow these processes but also understand why it’s crucial that they do it. This is how companies can learn from their failures in the future and have preemptive safety measures in place.
Atlassian’s approach to change management
With its development, Atlassian dethroned the old school way of thinking about ITSM – namely, that it should be bureaucratic and practically overkilled with paperwork or manual input. Instead, we get automation and integration of different data feeds and tools that are fit for purpose (utility) and fit for use (warranty).
On the other hand, the knowledge about changes that are planned, being executed, and recently implemented (whether they’re under CI/CD principles or not) is a key value for understanding their impact on ongoing, supported processes.
In other words, one needs to understand:
- The reason behind implementing the change,
- The way of doing so (or retrieving, if needed),
- The risks related to implementation (including both ways, asking: What’s the risk of implementing this change and what’s the risk of not implementing it?)
Bringing these two perspectives together, you’re bound to conclude that proper control of a change is a must, especially with the focus on deployment into a production environment, regardless of organizational policies.
Now, software changes come in different shapes and sizes. A change can mean a single line of code with no impact whatsoever to the working service, but also a massive rollout of multiple instances at a time, affecting operations worth billions of dollars.
An effective change management process will take all of that into account, diversifying the roles and respective actions accordingly to the risk of the change. The rule of splitting responsibilities is not replaceable for all the QA steps (with potentially high risk): from code review and testing to getting deployment approvals are in place, with a reason and proper rationale behind them.
What Atlassian did to enable Software Changes as a part of ITSM?
How did Atlassian manage to introduce software changes into the ITSM change management process? The solution is surprisingly simple. Actually, this is something we could expect from Atlassian, considering the company’s background in CI/CD (Continuous Integration/Continuous Deployment).
Atlassian connected Bitbucket Pipelines with Jira workflows to allow bidirectional integration between the Pipeline and workflow, at the end blocking the deployment until Jira’s workflow approval step is completed.
This seems simple. But it’s the first time we can see it actually running in integration between an ITSM tool and a Version Control/CI/CD tool.
And indeed – in extreme conditions, you can run software changes as fast as it’s shown above, in mere minutes. Naturally, things aren’t so simple in real life. Companies need to consider other factors such as compliance regulations, and the need to develop, review, test, and validate code will usually extend a process.
Still, automation eliminates all the unnecessary procedures, bringing a real-time collaboration between the development team and change approvers into the process.
Another great news is you don’t need Bitbucket pipelines to reap benefits from this feature as Jenkins, Circle CI, and Octopus Deploy are all going to work just as fine.
How to align software changes with ITSM using Atlassian solutions?
There are many ways in which teams can approach the problem of adding software changes into their ITSM change management processes.
In reality, change Management can be both simple and complex. It all depends on your needs, the availability of automation solutions, and more. And the ideas on how you could improve the ITSM process can multiply when you add every new factor.
Let’s focus on two of them.
Atlassian’s Change Calendar
The first one comes from Atlassian itself and one of the recent changes in the Cloud Service – the Change Calendar integrated into the Jira SM project.
Again, you get a simple and surprisingly powerful tool for adding software changes to your ITSM. This simple calendar view presents changes based on the Start/End dates.
You might think that isn’t exactly rocket science. It’s true – still, this functionality gives you:
- A timeline view of upcoming changes,
- The ability to split them into categories showing potential conflicts (overlapping implementation windows) or dependencies (changes in architecture required for another change).
So, at the end of the day, you get the opportunity to identify, manage, and mitigate risks related to change lifecycles.
Take a look here to learn more about the Change Calendar.
Test planning & ITSM change management
The other point is the ability to extend test planning into ITSM change management processes based on recognized test tools like Deviniti’s own TestFLO.
If it works well for a development process, it’s going to be just as good for running tests in software changes as a part of ITSM, right?
Consider this:
In highly virtualized environments, you can expect the majority of changes to be software-related changes anyway. We’re talking here about VMs, since the virtualization platform is indeed a software layer, not a barebone.
This is why all the principles applicable to software changes will be applicable to ICT changes in virtualized environments. This makes sense, right?
Naturally, you will need to simplify and extend tests, depending on the majority of variables. But still, you have them ready – so why not run them in a common, unified way?
Finally, test cases might reflect the ICT and software configuration validation. For example, if specific ports are open or closed, or if specific operations can be performed, etc. This allows to prevent or minimize human/config errors in the deployment process.
Next steps – software configuration management?
So, what’s the next step in aligning software changes with ITSM change management processes? Software configuration management is my next top pick. It refers to the ability to manage and automate environmental variables further to deploy software instances (in Iaas, PaaS, and SaaS models) with respective configurations based on the “click” or triggered by a system event.
Working prototypes and even a few more mature solutions are already in place, both growing out of and within the Atlassian ecosystem. So we’re one step ahead in commercializing and standardizing software configuration management in the ecosystem.
Wrap up
To sum up, software changes as part of ITSM are in line with the current shape of the Atlassian ecosystem. Supported by Jira Service Management and Bitbucket Pipelines (plus a few other options), they’re extendable further with the help of Jira automation.
The Atlassian platform allows sharing the implementation of the ITSM and change management processes between all team members in a team or across different teams. This facilitates communication and enables a frictionless experience of change implementation.
Was this helpful?
Thanks!
Oliwia Poświat _Deviniti_
2 comments