At Google’s I/O developer conference last week, CEO Sundar Pichai announced that more than two billion active Android devices are in use globally. On January 26th of this year, The Verge reported that Apple passed one billion active iOS devices in use globally, including Watch and AppleTV. Forester counts a total of 4.8 billion mobile phones in use at the close of 2016. Gartner adds 4.9 billion connected objects in IoT at the same time, with that number expected to rise to over 20 billion by the dawn of 2020. History suggests that number will be exceeded.
By any measure, the numbers associated with “the Internet of X” are unmanageably large and bound to grow vastly larger for the foreseeable future. One market response has been to cleave off “things” from people-oriented devices to treat IoT as something separate. That might make sense categorically, but from a business standpoint, what’s the difference? Sixgill started in proximity, informed by the dynamic data of people carrying mobile phones and pads, intersecting with places, known by GPS, Wifi indexes and Bluetooth. People and places. Add “things,” and what changes?
From a software standpoint, nothing.
From a business standpoint, people, places and things are all varying kinds and grades of assets. With a person on the other end of a connection, any kind of triggered response to knowledge you gain about their whereabouts, state-of-mind or immediate problems will be received by a highly intelligent asset. With a smart machine on the other end of a connection, a situationally triggered response will be received by an asset that can receive an instruction and execute. If a “dumb” sensor is on the other end of a connection, you can collect what it can report, understand its situation in the aggregate and direct the triggered response to the people, devices or systems that can execute a change, remedy or response. This is a longer way of saying that for Sixgill, there’s no IoT. There’s only IoE – the Internet of Everything.
Once we accept IoE as being the operative realm for us, our purpose and place are easy to see. Our software services combine limitless data ingestion, real-time classification, identification of data intersections and automated, triggered responses when data intersections are actionable. We started in proximity, which is just a specific data intersection, and have scaled up to help you leverage all your sensor data emitted from everything connected in your realm. From a product standpoint, these data services are a continuum and will be needed by the full spectrum of applications necessary to automate IoE. Now the only question is, why do this?
The Central Challenge of IoT/IoE is Governance
When the asset populations are very large and they are gushing data without end, the primary challenge is their governance. Governance as in awareness of what you have, where assets are, their operating state, keeping their deployment, behaviors and actions within policy. Every IoE or IoT application will require ability to acquire sensor data, analyze what’s meaningful in it, and to trigger appropriate responses automatically.
The prevailing product model for applications over the past decade or so has been full stack. The vertical application logic, UX/UI and data visualization are tightly integrated with appspecific backend services, generally supported by compute resources hosted in the cloud. These silo applications have also generally been bought on a SaaS basis, with relatively light integration options or costs.
We don’t believe this model will prevail in the realm of enterprise applications needed to leverage IoT and IoE. The technology economy is spawning a plethora of new software components and solutions to connect, automate and understand the hot category of IoT. A lot of it is fragmented. There are full-stack applications, horizontal developer tool stacks, closed architecture sensor systems, a broad variety of data services, gateways, end-points, and a dizzying array of sensor types. What restores order to this confusion is reversion to the older practice of building applications on universal data and application services platforms that perform their schematic functions to all specialized applications in mostly the same ways.
Governing IoE Requires a Baseline Data Services Architecture
Governance of IoE is a primary challenge because the numbers are so large now and will be vastly larger still, in a few years and beyond. The numbers of people and devices are so large because the devices for emitting data are so cheap. The resulting data volumes are, and will be, vast. Governing IoE is largely an exercise in capturing everything, ignoring data noise, zeroing in on relevant data intersections and push out response while it’s still relevant for a person or device to get it. What enables governance of IoE is universal data service for applications that depend on sensor-generated data. The five essential properties of a universal sensor data services platform are:
1. Limitless scalability. Sensor data is time-series data, which gets combined with a wide variety of contextual data types. The enterprise’s entrenched investment in relational data infrastructure is not optimal for scalable ingestion of time-series data and real-time processing of it. Sensor data volumes will dwarf all other data types extant, so to support the capture-everything mandate for IoE governance, the platform architecture must be of a distributed, master-slave, self-spawning type. The system must be scalable from thousands to billions to trillions of connected devices.
2. Open architecture. Universal sensor data services require any-emitter/any-data capture, documented, open APIs and easy integration with external systems.
3. Edge processing. IoE governance applications must take acquire, analyze and act on data streams in real-time. The need to generate triggered responses to specific conditions while it’s still relevant for the device or person to get an instruction means the underlying data automation system must continually attack latency in the network. Edge processing capitalizes on compute resources in local devices to slash the back and forth processing of a centralized system.
4. Portable. The data processing backbone and related functions for IoE governance applications must be platform portable between the major host services, whether AWS, Azure, Google or others, and their private cloud instances, without requiring deep integration with any platform’s proprietary aspects. Universal sensor data services must also be deployable on-premise in enterprise and government applications where regulations or security require that data be internally owned.
5. Economically viable. Vast data can drive vast costs. The compute efficiency of a universal sensor data services platform has to be cheap enough to make IoE governance applications feasible, flexible enough to make major cost drivers like data retention adjustable, and profitable enough for vendors to be able to sustain themselves and meet their capital needs.
Sixgill exists to facilitate governance of the Internet of Everything, including its hot subset of IoT. In the coming weeks we will make the case that our primary product, Sixgill Sense, is your one and only, logical, sensor data platform destination.
Govern data and govern IoE with Sixgill. Enable your IoE governance applications with the sensor data destination, Sixgill Sense.