By Tom Paquin
I have always been of a mind that the most important thing that software—any software—can do is to get out of your way. Even social media platforms, cultural cancers that they are, know that their key purpose (communication) needs to be easy, accessible, and provide the necessary feedback to show that it is working (“likes”, as it were). These are the keys of solid programming, and they’re how and why we use the devices that we do in the ways that we do.
This takes on a slightly different precedence in service, wherein the goal is not just to allow the technology to make completing actions seamless, the goal is to enhance the service process while not disrupting it in any major way. Here's an example of bad software design: If, in order to build schedules, you need to have availability loadouts three weeks in advance, and can’t update them same-day because of illness, or because of a high-priority outage that just came up, then that software is worse than pen and paper, and it’s actually an impediment to your growth.
It’s incredible how many software providers don’t understand this fact, and it’s why some firms struggle to get their teams to use the technologies at their disposal in the first place.
Today, though, I don’t want to talk about the user experience of software applications. We do that all the time. I want to take this concept outside of the day-to-day utilization of software, and look at the framework of the software itself.
Because here’s the thing: Service firms are complex. They are, frequently, a mismatch of cultures, either through means of acquisitions, or organizations working alongside OEMs, or distributors, or aftermarket part manufacturers, or contingent employees, or some Frankensteinian combination of these elements. And service delivery itself doesn’t fit into a neat box. There are different tiers (telcos, for instance, balancing commercial and residential service visits), different types of workforces, and different systems employed depending on the nature of a fix, or a routine appointment, or an emergency, or a predicted event, and so on, and so on, and so on.
On a frankly more basic level, some companies simply require, perhaps for regulatory reasons, their solutions to be managed on-prem. Others have managed cloud space of their own that they want to employ. Others, still, are in a position to move to the cloud. None of these (or any other adoption permutation) are wrong, and software that supports that flexibility will be engineered to support flexibility further down the value chain as well.
Service software deployment demands flexibility. This begins with containerization.
The concept of containerization, in its simplest terms, means that software is packaged (or ‘contained’ I suppose) in a way, with all ancillary processes, that enables it to be deployed at the discretion of the end user.
Today, the way that this most commonly works is that businesses build a cloud-first product, and they’re willing to sell it to you in the cloud, managing upkeep, upgrades, licenses, and operations for you wholly. Some companies consider this “The future” and refuse to practically look beyond it, even though it’s not only “the present”, it’s our very messy present. An inherently containerized product, though—one that lives in the cloud natively—can be just as easily packaged and deployed on a home server, with the same internal structure, same APIs, and to the same effect. Or that container can be handed off to another cloud host, managed independently of the “multi-tenant” cloud instance upon which the software was built. So “single tenant” cloud hosting.
Call it containerization, or Kubernetes, or whatever you want. To my estimation, it’s really the bellwether that defines product flexibility down-the-line. Software that cares enough about your business to offer you that degree of deployment flexibility understands your business. In my experience, that means that their actual functionality will be built to contour to the shape of your actual operations, not force you to work around them.