No Jitter On Air: Getting IoT into the Communications Mix

Whether inside frozen yogurt machines or chicken gizzards, you just never know where you might find Internet of Things sensors, as communications evangelist Andrew Prokop, with Arrow Systems Integration, reminded us in last week's No Jitter On Air podcast, "IoT & the Communications Workflow." That's interesting to think about, but even more so is dreaming up ways to make the data those sensors generate part of a communications workflow.

True to his title, Prokop has been busy building demos and advocating for IoT-communications integrations, internally and externally.

On the IoT side, Prokop uses the Arrow Connect platform, which lets IoT sensors communicate with gateways. The gateways, in turn, pass that IoT data to a cloud application that wraps the data in services while exposing RESTful Web services APIs, he explained. An API might pull all the IoT sensor data for a given timeframe, for example. Communications come into play once parsing and analysis of that data has taken place. Does the sensor data trigger a call into the contact center, an email, or an SMS alert?

To build the workflows, Prokop has used the Avaya Breeze development platform and other drag-and-drop programming tools. In one example, he talked about the need for a yogurt shop to know whether bacteria is growing in its self-serve machines (yuck!). Internal sensors could monitor temperature and humidity, and when environmental conditions are ripe for bacteria growth, automatically shut the machine down and schedule a maintenance visit.

Naturally, Prokop encourages enterprise IT professionals to consider IoT as they evaluate their next business communications system or contact center. He shared a good working list of pointers during the podcast, as follows:

• First evaluate the openness of the backend contact center or communications solution. Can you add new data types easily? And, specifically for the contact center, would you be able to add an IoT channel, just as you would for voice, email, or SMS?
• Understand how you're going to deal with the data sensors produce. What tools are you going to use for parsing and analyzing the data? Do you want to work with the APIs on your own, or use a drag-and-drop tool for building your workflows? Do you want to layer in an artificial intelligence engine, like IBM Watson?
• Just as you look for openness of the communication/contact center system, you need to look for an open IoT platform, too. "You want to take a good look at the APIs that any potential IoT solution exposes, and the data those APIs give you access to," he said.
• Look at the bidirectional path between the IoT and communications platforms. "How do I reach out to the platform, and how does the platform reach back to me? Does it send me Web services calls the same way that I'm sending it Web services calls? Does it have a rules engine that I can put on top of the IoT data that, again, will allow me to trigger events in the cloud or data backend that allow my workflows to kick in and do what they're supposed to do?"
• In terms of openness, how easy is it to add new sensor types? This is important to know for the case where you come up with a new idea, for example, wanting to "put a sensor in the gizzard of a chicken," Prokop said. "Nobody has ever done this before, so I create this device. How do I get that into the platform? It's not enough to just have a sensor that produces data; it has to come into the platform because otherwise those workflows -- which are way down the line -- how do they get access from this information that's coming from the chicken's gizzard?"

In a word... or three... Prokop summarized: "Openness, openness everywhere."

Click on the player below to hear some more examples and other advice Prokop has to share on binding together the IoT and UC worlds. Who knows what ideas might come to mind as you listen.

Follow Beth Schultz and No Jitter on Twitter!
@Beth_Schultz
@nojitter