icon-play icon-normal-size icon-expand icon-pause iconExit Click for search iconTarget iconCheckmark iconEngine iconTruck linkedin_icon twitter_icon arrow arrow-left arrow-right close iconWorkforce iconAudit iconEmergency icon-pin icon-dots icon-act playbutton pause-button


Episode 2: Enabling IoT Applications

Share this Video
Episode 2:  Enabling IoT Applications
Series: Making Sense of Sensor Data
Phil Ressler: Building an application starts with what we in a software company call the product management function – understanding the functional and business requirements for the application.

If you start to write code before you know what you’re writing code for, you’re not going to have a very efficient process.

Elizabeth Shonnard: Where I’ve seen a lot of organizations get into trouble with building sensored applications is first, understanding the data problem that they have to solve.

Because there are so many diverse types of sensors, they end up with sort of this mish mash of, “Okay I made a custom thing to handle this first type of device and the second one and the third one”. And by the time you’re on your eighth device type you start to have a really big integration problem and a big maintenance problem.

You’re balancing what to build and in what order so that you can address the market need as quickly as possible.

Shawn Gunn: The service that we’re providing not only aggregates data but we do the cleansing and normalization of it for our clients.

We feed a lot of their decision-making capabilities. We feed their analytics platforms, and so having this rich granular data set that’s sitting right near their cloud environment is becoming more important to their daily business use.

Phil Ressler: The verticalization for the application’s specificity that gets built into the application and into our backend services, occurs in three or four places.

First and foremost is the application itself that lives on top of the services that we are providing.

The second is an instance of our system to support an app will be verticalized, so to speak, through the rule set that determines what action we want to take when we find an exception event or a data intersection.

And a third might be the type of extensions or plugins that are used in our system to accommodate a use case.

Regardless of how customized the data intersection identification function is, schematically our system is still doing exactly the same thing.

We’re making it easy for application developers to delegate the data services to something that is standard, that they know will work, that’s scalable and will support real time operations.

They don’t have to reinvent that wheel every time they build an application.

And then we give them standard means of inputs and outputs, so that their applications are supported by everything that we automate underneath.