After spending time and effort planning and executing a server update there's nothing worse than discovering a critical business service is now down due to an unknown dependency. But this situation is all too common, even for large tech companies.
Change management is the name given to the systematic approach to any changes, be it IT related changes or organizational changes.
There are many apps on the Atlassian Marketplace to extend the functionality of Jira to specific jobs, including Insight. In this blog we will focus on some common challenges with IT related change management. We'll discuss how a full understanding of your inventory and the interconnection between assets is key to overcoming these challenges and we'll show how Jira and Insight can be used to implement the outlined strategy.
If you are already familiar with the background to change management and CMDBs, you can jump straight to how to work with Jira and Insight.
Why is change management important?
Change management is the standardization of the request, assessment, approval, and implementation of any changes to IT services. These requests may come from a proactive desire to improve services, a reactive response to an earlier incident, or due to external factors such as the end-of-life of a key piece of software.
But when changing anything, there's some level of risk and unintended consequences can happen. Gartner estimated that 85% of unplanned downtime can be traced back to some kind of change in the infrastructure. Building on that, IBM and Forrester found that unplanned downtime is, on average, 35% more expensive than planned outages due to a lack of preparation. It's critical that every organization tries to limit its unplanned downtime as much as possible.
Having a standardized process, with a high level of visibility of your inventory, means you can better understand all risks associated with a particular change. Understanding potential risks is the first step to mitigating risks and reducing unplanned downtime.
The major challenges with change management
There are many challenges when implementing a change within your IT infrastructure but here we will discuss two of the biggest and most widely cited difficulties. These points should be kept in mind when designing (or improving) a change management strategy.
The first headache comes from not fully understanding your assets and the various dependencies between them. Without this knowledge, how can you be certain that a change isn't going to have a knock-on effect?
While the concept is incredibly simple, the reality is that it can be very difficult to understand. As many of us are all too familiar with, often the information we need to get a complete overview is stored in various, difficult-to-search locations, such as multiple spreadsheets, meeting minutes, email chains and even people's heads! With this situation, dependencies can easily be missed leading to unplanned downtime.
Another major difficulty comes from the human side of things. Change is hard for many people and often they try to avoid it if they can. Also, as a user, it can be frustrating to suddenly hear through rumours that a service you use regularly is being updated without considering your or your team's needs and concerns.
That's why you often hear communication and getting stakeholder buy-in as a painful area within change management with numerous blogs covering tips to improve the process. The earlier you can start this communication the better for two reasons. Firstly, if you reach out to those affected you will get a better understanding of the risks which helps in your assessment and mitigation plan. Secondly, the more people can feel like they were involved in shaping a change the easier they will adapt to it.
However, knowing who to speak to can be tricky if, again, you don't have a detailed overview of your IT infrastructure and who is using what and where. This is where technology can help.
How can a CMDB help analyze risk and increase buy-in?
Both these crucial challenges can be significantly improved with more insight into your IT assets and their relationships. The recommended way to create this overview is via a Configuration Management Database (CMDB). CMDBs are designed to show the configuration and inter-relationships of your IT assets. Being able to understand all your dependencies means you can be confident that you're not missing anything that may result in an unexpected downtime.
But CMDBs can also help with the second challenge of getting stakeholders on board. You can move beyond IT assets and start to include less traditional assets such as system owners, departments, and job roles, and create dependencies between them and the IT assets. From this you can easily get a picture of who may be affected by a change and therefore make sure everyone required is involved in the proposed change.
While it can be time consuming to create a CMDB, the benefits vastly outweigh the costs. Trying to unify all this information from different sources at the time of a change, especially in the face of an urgent request, is difficult and can often result in a particular risk being underestimated or missed entirely.
Instead it is better to spend the time building a CMDB that can then be used for all future change requests. It has a high initial effort but it pays off time and time again with reduced down-time and increased staff productivity.
Creating a CMDB in Jira and using it in your change management process
While Jira wasn't initially designed for change management, due to its flexibility and custom workflows many companies do use it for change requests. Therefore, ideally, we need a CMDB that can integrate easily into Jira. One way to do this is with the Insight app which, amongst other things, gives you the capability to build a CMDB for better dependency visibility.
We'll discuss how you can create and integrate an Insight CMDB into Jira to help with the outlined challenges and some other important aspects of change management.
Building the CMDB
First you need to build the CMDB. As we discussed previously, building a CMDB can be tiresome at times due to the many different and scattered sources of information. To make this easier, Insight for Jira Server and Jira Data Center comes with importers for common file types including CSV and JSON.
There are also importers for other sources of configuration items and dependencies such as AWS, Azure, Google Cloud, Jamf and more. Finally there is Insight Discovery, an agentless network scanner designed to pick up assets and their dependencies (such as installed applications and network interface services) and import them directly to the Insight CMDB.
Once all your IT assets are added you can then add any non-IT dependencies such as the various departments or members of staff. For example, you could add an owner for each of your servers or add a set of assets called 'department' and link each department to the systems they use. This can be done manually or via the importers if you already have that information stored elsewhere.
Custom fields for change requests
Once the CMDB is configured you can start to use the information within a change request. As a change request is created, an Insight custom field can be used to select the main asset or assets to be changed. Once created the request can be auto-assigned to the owner of the asset (or whoever is responsible for approval) for review to reduce the time to approval.
Because the asset is linked to the Jira ticket itself, you can access the Graph View from the ticket in just a few clicks which lets you quickly see all dependencies for that asset. You can instantly see what (hardware, software, people, services etc, whatever you have set in the Insight CMDB) depends on the particular asset and in turn what will be affected by the requested change. The risk can be assessed thoroughly and the change request can proceed accordingly.
In the case of unplanned, urgent changes you can instead find the asset(s) directly from Insight and quickly understand what potential issues may occur from the change you need to make. This means once the urgent change has been made you can quickly check that all the dependencies are still working as expected and fix any resulting issues immediately rather than waiting for them to be discovered by a user at a later date.
If you have included people or teams within your CMDB you can also easily see who you need to collect input from other than the initial requester, and who you may need to inform and train on any changes that will impact them directly.
If you want a more automated process you could even set up Jira and Insight to automatically create new tasks to speak to all the teams affected or all of the owners of any indirectly affected services to ensure you're not going to miss anyone and for traceability.
Another invaluable aspect of using Jira and Insight is the reporting capabilities. As an example, you can configure a report to see a history of all changes and the specific assets involved giving you infrastructure-wide visibility on all changes which can be useful for assessing future changes and identifying root causes of infrastructure problems. Perhaps through these reports you would notice a server that keeps requiring minor changes and then you could dig down into the underlying cause.
If you incorporate the Insight CMDB into your incident and problem management processes, and with a bit of customisation, you could even match planned changes with unexpected downtime of certain assets and look for hidden dependencies, making it easier to avoid similar situations in future.
Tracking unknown changes
One tricky aspect of change management we haven't discussed yet is that no matter how excellent your change management system is, there's always the possibility of having 'off-grid' changes that occur. Perhaps someone outside of the IT department has been updating settings they shouldn't, or perhaps an IT admin made an urgent change but forgot to document it.
As we mentioned in the previous section, having a complete history of all changes can help with incident and problem management. So it's key to get as many of these hidden changes recorded as possible. This is where Insight Discovery can help again. Not only can it discover your assets but it can also be set up to run periodic scans. These scans will pick up any changes and automatically update the CMDB with the new information.
These CMDB updates can be used to trigger an automation rule related to that change. For example, you could see which asset has changed, check that there's no currently open ticket for that asset, and then either create a new ticket or send a notification to the asset owner about what has changed. There's room to add more logic to this automated process as you need.
While we may never eliminate unexpected changes entirely, the more we can capture the more we understand, and the more we understand the easier it is for us to avoid any unplanned downtime.
A great change management process is critical for any IT department. We've seen many examples of how the Insight app for Jira can help you overcome two major challenges through a CMDB that smoothly integrates in your existing or future Jira processes. By ensuring you fully understand your dependencies you can plan thoroughly for all changes, assess all potential risks, and reduce unnecessary down and costly downtime.
Insight is just one part of the huge ecosystem of apps on the Atlassian Marketplace so if you have ever thought 'I wish I could do X in Jira', chances are there's an app to do just that.
Mindville works with partners worldwide who can help customers adjust Insight and Jira to their needs. Find a partner near you.
Originally published Jun 16, 2020 8:30:00 AM