I have always been of the mind that the most important thing that software—any software—can do is to get out of your way.
This is true of everything, from our phones, to the myriad of connected devices that have impacted our lives in various ways, and everything in between. If, for instance, a “Smart” thermostat now requires me to look at my phone to do what I previously could do by twisting a dial, it replaces convenience with complexity, and for no good reason. These are the keys of solid programming and are doubly important for technologies that we put in the hands of workers.
This takes on 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. 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 the software is worse than pen and paper, it’s an impediment.
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. 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 service 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.
This is the way that IFS cloud has built all of its service, project, and asset management capabilities. By building a cloud-first product, we’re able to sell it to companies in the cloud, managing upkeep, upgrades, licenses, and operations for you wholly. Some of our competitors stop there, but that’s not true flexibility.
Kubernetes is an open-source technology that facilitates containerization—an approach to cloud computing that makes it easier to configure systems. And here’s why you should care about it. ?https://t.co/xzBhjrAzuS
— IFS (@ifs) December 17, 2020
A containerized product—one that lives in the cloud natively, like IFS Cloud—can be just as easily packaged and deployed on a home server, with the same internal structure, same APIs, and to the same effect. If your infrastructure requires that, we are ready to meet those needs, not dictate the terms of how you interact with our product.
Alternatively, 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.
If you’re interested in digging into how this works technically check out this blog post.
Do you have questions or comments?
We’d love to hear them so please leave us a message below.
