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 Applications

Share this Video
Episode 2:  Enabling Applications
Series: Making Sense of Sensor Data


[00:00:10] We’re really an application enabler as sensor data is ingested and third party data sources need to be aggregated to support decisions services. We are in a position to offer that to third parties so that they don’t have to build it.

[00:00:24] Building an application starts with what we in the software company called a 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.

[00:00:38] Where I’ve seen a lot of organizations kind of get into trouble with building censored 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 mishmosh of okay 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 what order so that you can address the market need as quickly as possible.

[00:01:13] The service that we’re providing not only aggregates data but we do that cleansing and normalization of the four that 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.

[00:01:33] There’s a whole slew of providers who are running hardware and storage capacity. We’d like to understand what services run what places at what costs and be in a position where we can leverage and move services around based on whatever the economics or performance requirements might be.

[00:01:50] The verticalization or the application specificity that gets built into the application and indoor backend services it occurs in three or four places. First and foremost is the application self 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 ruleset that determines what action we want to take when we find the exception of that. Or a data intersection. And a third might be the type of extensions of plugins that are used in our system to accommodate the uses 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 the wheel every time they build an application and then we give them standard means of inputs and outputs so that their application is supported by everything that we automate underneath.