Bringing Microservices to the Service Desk

There's a term floating around the development world that the service desk can adopt. It's called microservices. In the application context, think about it like a large banking application that offers a variety of services. Just a couple of those vast number of services are getting a balance and transferring money. The idea of a microservice is that the development team can be broken up into different parts in which groups are responsible for just a small piece of the big application. In this context, one team might only be responsible for creating a service that displays the current balance for any of the accounts a customer might have. Their guidelines are that the incoming request will be an already validated user id and the output will be a collection of account numbers, types, and balances. That's it. That's all the team is held accountable to. Same with the group transferring money. Their sole purpose is to move money from one account to another. Their guidelines would be something similar.

Makes sense, right?  There are a lot of perks to this approach. Teams can quickly be productive. Large programs are reduced to bite-sized pieces that are easier to digest. Responsibilities are streamlined and simplified.

The service desk could learn from this methodology. The knowledge to resolve problems could be split into groups that specialize in correcting issues technically as well as documenting them for customer facing articles. Take a hypothetical problem:

User A needs to update Outlook from 2013 to 2016, and she'll also be getting a new laptop. She would like the following done:

• Her signatures brought over to the new machine
• A known modification to allow MAPI connections over HTTP needs to be performed
• Her view to be customized to not show a reading panel.

This could be something that is routine in many companies and completed on a fairly regular basis by either desktop support during the reimaging of a machine or the service desk on an ad-hoc basis. There might be one single KB that states how to do this. Imagine breaking it up in the separate parts such as File/Folder Support, Registry Support, and Application Support.

The File/Folder team's function is to create documentation in a common structure that explains how to create/copy/delete/edit/move files and folders for whatever reason. In this situation, they would create the documentation to support the copying of %appdata%\Microsoft\Signatures from one computer to another. They might also be responsible for creating some automation tools to do this via PowerShell.

Meanwhile, the Registry Support team creates the standard documentation that informs technicians to edit the HKEY_CURRENT_USER\Software\Microsoft\Exchange key and modify the MapiHttpDisabled name's value from a 1 to a 0. (This is an actual fix, by the way). They, as well, might also be tasked with creating PowerShell tools to automate this.

Lastly, the Application Support team would create the instructions on how to modify the Outlook view to disable the reading panel.

This is just one example of splitting responsibilities for documentation or task development. In this example, think of the benefits of the first two groups. Both groups would be laser focused on small segments of technology that are involved in a large swath of technical issues. That group would control how information is presented to both technical staff and customers alike and be tasked with automating fixes as the priorities require it. Imagine a scenario where fixes for registry changes are documented by a particular small group within your service desk and, at a certain point of need, moved on to an automated one via System Center Configuration Manager (SCCM), PowerShell, etc.

By splitting up comprehensive solutions into separate core responsibilities, your groups can become more agile for the future, more fine-tuned in the present, and finally more trend aware from the past.