DevOps vs. ITSM
Based on a recent post on Pipelines, I received some questions from an old coworker on how DevOps affects ITSM(IT Service Management). As some background on this, there is a lot of debate on how these methods fit together.
ITSM has been an industry standard for a long time and is used to ensure proper change management and tracking of systems and incidents. Many aspects of ITSM, like the service desk, are not really impacted by DevOps. The most impacted area is change management on Systems and Infrastructure; this is what I am looking at here.
DevOps is an approach where the Development and Operations team are integrated into one area of responsibility and the focus is on automating processes. DevOps is typically complimented by Agile development methods.
As DevOps is being implemented in government departments, it is creating a conflict with the existing ITSM methods and processes. The root of this conflict is that ITSM is typically implemented in government through approval processes on Systems and Infrastructure changes; this can be via Change Advisory Boards(CABs) or through lower level processes(Release Processes, RFCs, etc.).
DevOps/Agile creates the following challenges:
- The release process is automated and the approvals should be delegated to the areas of expertise. What I mean by an area of expertise is that instead of a central board(typically comprised of senior managers) overseeing a large number of applications , it should be the product owner of the solution(the business team ) and the IT Solution team. This will allow for an improved process as this level understands the release better.
- DevOps/Agile will change the frequency of software delivery. With the support of automated processes, it becomes easy and more productive to release a feature at a time. This means that instead of releases every quarter(maybe even 6 months or year) teams will tend to move to weekly or even daily releases. This creates an issue for the CAB in that instead of four releases a year per application(which is already a struggle for the CAB to keep up on), they will be facing sixty or more. This becomes unmanageable if the CAB is a blocking process. They may need to approve 100 changes a day. The CAB will not have time to examine these in any depth and will be relegated to a rubber-stamping team.
So, how to we make these two methodologies play well together?
The first item to be aware of is that moving to DevOps/Agile inherently lowers the risk of software releases. Instead of building for 6 months and implementing 30 features that will have conflicts, they can release weekly and release two features at a time. This makes the risk much lower as there are fewer changes. It is also easier to correct any issues with the automated processes.
This drop in risk changes how we need to manage change. ITSM tools are aware of this and are adapting. They are working on models where risk assessments are done on changes and only changes above a certain risk level will require approval. This creates the ability to have tiers of changes by risk and only inform the CAB when the risk is high. Newer ITSM products can automate these assessments to only show the risky changes.
Another tricky issue is how to keep a CMDB up to date with the move to automated Infrastructure. This can be done by adding the updates to the PipeLine. ITSM products are beefing up their integration capability to work with these types of products. Here is an example of BMC's integration: https://www.bmcsoftware.ca/it-solutions/bmc-helix-integrations.html
I am sure that we can figure out a way to integrate these to only make important changes bubble up to the right level but it will take some trials. Should be interesting.
Thanks for reading and feel free to leave a comment.
