Have you heard of the term ITSM? Do you have some vague understanding of it being some kind of service desk process? Well, there’s more to it than that. Learn what ITSM is and how it impacts you as a software developer in this article.
In this article, we’ll have a look at what ITSM is, and how it’s used in an organisation. There are plenty of other sites out there that are focused on ITSM so we won’t go into too much detail. However, as you’re a software developer, I’ll explain how it’s relevant to you and what you can do with it to improve your career.
What Is ITSM?
ITSM stands for Information Technology Service Management. According to the definition on SysAid, it is:
“The implementation and management of quality IT services that meet the needs of the business. IT service management is performed by IT service providers through an appropriate mix of people, process and information technology. See also service management.”
https://cdn.sysaid.com/wp-content/uploads/What-Is-ITSM.pdf
Let’s break this down.
- Quality IT services – whatever the IT department provides, it needs to be good quality.
- Meet the needs of the business – it needs to be helpful and satisfy the requirements and needs of the business.
- People, process, and information technology – it’s not all about servers and software. People and processes are involved too.
ITSM aims to manage IT services across the company, not just in “silos” or in different business units.
It’s also related to ITIL, as ITIL is one framework of performing ITSM.
That’s all well and good. The IT department would have support and management teams who look at this. How does it impact you as a software developer?
What Do Software Devs Need To Know About ITSM?
As a software developer, you’re likely working on projects to develop systems or make changes to existing systems. Or, you’re working in an application support role where you resolve defects on existing systems.
In both cases, it’s good to know about ITSM.
There are a few areas you should know about:
- Understanding how the incident management process and support process works
- If you work in support, understand the importance of the issue
- If you raise the incident, understand how support works
- Think long term with your development
- Documentation can help
Let’s look at each of these in more detail.
Understand the Incident Management & Service Desk Process
Sometimes, as a developer, the incident management and service desk process is kind of like a “black box”, to use a software term. It can be something that you initiate by raising an issue and wait for a response, without any idea of how it works on the inside.
Fair enough, too. You might think you don’t need to know how the support process works. You just want to know how to raise issues, how to track them, and that they get resolved.
However, it’s important to understand, even just at a high level.
Why do I say this? It can help the organisation as a whole. It can also help you do your job better, and help the support teams with getting things done. You’ll know what kind of requests to raise, where they go, and the timeframes for getting resolutions.
If You Receive Support Issues
If you’re a developer that works on the application support side of the issue, then your approach to ITSM would be different. You would be the one receiving the requests, either from other developers or from business users.
This is how I started my career. My first role as a software consultant was application support for an Oracle-based system. Every day, we received requests to look into problems or to run reports or to fix defects.
Over time, I began to learn how this process worked. I understood the difference between each type of request. I understood what was being asked, and how to ask for more information if needed.
Most importantly, though, I learnt to understand the business side of the issue. This helped with understanding the priority, understanding why they were asking for something, and the impact on the business if the issue was not fixed.
For example, an issue might be discovered that causes 5% of transactions to fail to be sent to another system. What’s the impact? As a support developer, you might need to go into a system and retrigger them, which may take 30 minutes per week. To you, it might not be a big priority. However, to the business, these transaction failures might cause delays in getting data to other systems, delays or incorrect information being provided to customers, extra manual work by people to make temporary fixes, lower customer satisfaction, loss of revenue, or any range of factors. From the business side, it could be a big issue.
So, understanding the business side is probably the most important thing you can do when it comes to ITSM as a recipient of these support issues.
If You Raise Support Issues
What if you’re a developer who is on the other side – one that raises support issues?
This is quite common. You can also be both – a developer who supports one system, but raises issues with another.
In any case, you’ll be raising issues with a system. To improve the way you do your work, it helps to understand this “black box” of ITSM as it can improve your job and your career. There are many reasons and ways that learning about ITSM can improve your career. SysAid has also written an article on ITSM tips in general, but there are some I’d like to add that are relevant for software developers.
If you can learn about the process for raising support issues, problems, and change requests, then it can help you do your job better.
If you know about the different teams involved and what they do, it can help to understand where requests go and can help your requests get done faster.
If you know what kind of work that the support teams do for each type of request, you will know what kind of information to add into the request.
As you can see, there are a few areas you can learn more about, which can improve your efficiency at work for this role.
Think Long Term With Your Software Development
As a software developer, we’re often under pressure to get things done by a certain date and of high quality. This balance between quality and time is something we all face. It can sometimes mean that the quality drops, to get things done on time, or to make things simpler.
However, when you’re developing software, and even designing it, it’s better to think long term. You probably knew this already, but another justification you can make is that it helps the support process.
The support teams who work on resolving defects as part of the ITSM process will be handling your software in the future, once it is implemented. The more issues it creates, the more work they will have to do, and the bigger impact it will have on the business. So, consider that writing good quality code will make things easier for the business in the long term.
Try to avoid applying “band-aid” fixes, which are temporary fixes or those that are low quality, just to get something done.
This is something you probably knew about already, but when presented to the rest of the team in this light, it may convince them that quality is important.
Documentation Helps
Another factor to consider is the importance of documentation.
Sure, your design may have been documented at the start and your code is commented, but when your software is implemented, it needs to be supported. Documentation of the software and of your changes can help with that.
The kind of documentation that I’m referring to is:
- System design: how your system or component works internally
- Code commenting: comments within your code for others to read
- Interface specifications: how this system talks to other systems, which can be very useful for the support teams.
All of this documentation can help the support team in diagnosing and fixing any issues that are found in the software. It can also identify which issues are done by design of the system, or are actual defects.
So, ITSM can be good to know as a software developer, whether you’re working on projects or in application support. There are a few areas you can learn about, as they help to improve your work and the organisation in a small way.