Sramana Mitra: So you are trying to transmit data from those devices into a centralized cloud environment for debugging, technical support, or customer service?
Joel Young: Yes. It even extends to consumption and auditing purposes.
SM: Are those devices then spitting out information that you are putting into the Salesforce.com cloud?
JY: The devices tend to spit out a lot of information. We store that in long-term storage within the iDigi device cloud.
SM: Do you have your own public cloud where device information is being stored, and do you then give access to the administrators of the devices in your clients’ organizations?
JY: Yes. That is the iDigi device cloud I was talking about. But there are many application frameworks that might use that data, Salesforce.com being a nice example for various reasons. Imagine data stored: you do not want to store massive amounts of data in something like Salesforce.com. It will cost you a fortune, and they are not designed or engineered for it. What you want to do within Salesforce.com is trigger events based on critical information that comes in.
Imagine a workflow for an air compressor, for example. You are getting data for the air compressor, and you know there are certain thresholds that show the machine is malfunctioning. An instance of malfunction triggers a message based on that workflow and a rule into the Salesforce.com service cloud, which might automatically open a case. The data that comes in from the air compressor would be stored on iDigi, but it gets pushed to Salesforce.com only in the case of a critical event. The person logged in might see an alert and then take action. That person might then need to query back through the iDigi device cloud down to the device to get additional information. Maybe he or she needs to actuate something, like remotely resetting the air compressor. It might not be able to take appropriate action, so the person would need to dispatch a technical representative. Another possibility is that the person contacts the customer to inform them that the machine is malfunctioning.
SM: This illustrates perfectly what I am looking for. Use cases are always something that I ask for when I do these interviews. This is one way cloud computing is impacting how your device business is being serviced effectively.
JY: Yes. We go out and look for business process problems, and then we consult with customers to bring solutions for those customers. If they are a Salesforce.com customer, it is natural to go with Salesforce.com. If they are not, they might need a separate custom web app, and we will do that.
We have another customer who is not related to Salesforce.com for whom we manufacture equipment to monitor vending machines. Their business problem was that the people who were collecting the coins were keeping a little for themselves. Also, when the machine would go down, they didn’t know. They estimated they were losing 25% of their revenue because of these two issues. We provided a solution that would count the coins when they went in – these were old fashioned vending machines, not the modern kind that accepts credit cards. This system would count the coins and notify whether there was a malfunction. The information went through a Digi cloud with a very simple program that counts the coins, so when it came to collecting the coins they knew exactly how many they were supposed to deliver. Also, alarms went off when the machines malfunctioned.
What was fascinating about this problem is that it turned out to have a very simple solution. But it was complex for a company that didn’t have the attributes and capabilities. You have to know cellular, you have to have some way of pushing data into a cloud, and then you have to be able to provide that access. Then you have to be able to do it in a low-cost way because you can’t put an expensive service into a coin-operated vending machine that makes $12 a day.