The Amara’s Law and the  Anatomy of Business Use Cases in IoT

Last week we had an interesting debate on what use cases we need to work on and across which industries . In the animated discussion, someone asked a quiz question – “What is Amara’s Law?”

It turned out that American Scientist Roy Amara came up with an interesting view and an easy to understand law –“While we overestimate the short term effect of technology, we underestimate the long term impact “. I feel in the world of IoT this law is fascinatingly relevant .

The hype surrounding IoT puts pressure on managers to monetise the investments being made in IoT in organization. The buzz descends on  coming up with business use cases which could be winners by honing their effectiveness on an  IoT Platform build or bought. The linkage between the identified use case and their deployment on the chosen IoT platform is a significant one to shorten the time to market.

For the sake of completeness, a Business Use Case is essentially a business process  flow or sequence of steps of a business activity which impacts the organization within and the exco-system it works in . Most of the time the Business Use Case is the precursor to build an IT solution  ( an IoT solution in this post !!)

Why are IoT based solutions are distinctive and diverse?

IoT solution design is quite different from typical IT solutions in that it bridges ( through communication media , internet ) the Physical Computing (also termed as Operations Technology (OT) with sensors, actuators and communication devices, and the Digital Computing  with data, analytics, workflows, and applications( also terms as Information Technology ( IT) . The diversity of use cases and operational requirements creates an array of IoT Endpoints, communication protocols, data management, and analytics technologies, as well as corresponding deployment topologies.

The real value which can be derived from a select Business Use Case in IoT comes from turning data into insight, and making it actionable to drive smarter operations.

Despite the diversity, there is a level of commonality across use cases that can illustrate the anatomy of IoT solutions.The use cases essentially fall into four broad areas of Monitoring , Control , Automation and  Analytics leading to predictive management . Taking a layered approach in describing the anatomy helps identify relevant services and technologies from the things-level all the way up to IoT apps.

How do we decide on the appropriate use case?

I have attempted to bring out a few key parameters to be assessed as we decide on this. This will help us go beyond the IoT hyperbole, but when technology pundits claim that the Internet of Things (IoT) can change everything and help us to sift out the frivolous gimmicks like Wi-Fi enabled toothbrushes from the consideration sets of the Use Cases . So let us discuss the following :

  1. What makes industries  IoT Use Case Friendly ?
  2. What type of Data Availability would enrich an Use Case to be pursued ?
  3. What is the expected Business impact and Return of investment?

What makes  Industries  IoT User Case Friendly ?

Industries which are  inherently Sensor Driven –This  not hard to guess .These would be   the first ones to be IoT user case friendly . Inputs from Intel and Cloudera could be referred to which document that Automotive , Energy (Utilities) ,Healthcare ,  Manufacturing , Retail , Buildings , Homes  and Transportation are the leaders in making IoT work in core business processes  . Given that the key capability of Machine to Machine communication (M2M ) already exists as something native to these industries and M2M communications rely on sensors within the device itself, and the networks that connect devices together makes M2M IoT enabled .

So what are the major omissions? Media, Finance are the two major industries. I would rate Homes and Healthcare to be a “median” case .

Industries which are  less sensitive to Data security and Privacy-  This is a major challenge that is not set to go away any time soon. Network security is a huge bone of contention when it comes to data security and data protection. For example, one of the advantages of the IoT for healthcare is the ability to collect medical data in real-time from devices such as wearables, to monitor patients’ health – particularly those with ongoing conditions such as diabetes or hypertension. This medical data is therefore extremely sensitive, security needs to be at a level where external threats are not able to access and steal data records within the network It can be said about the Finance industry as well on the similar lines. It is not a surprise that Financial sector will be a late adopter of IoT based initiatives. ( reports from Deloitte )

What type of Data Availability would enrich a Use Case to be pursued ?

The promise of IoT is derived from the potential access to data from a variety of sources . These would be massive volumes of data of intermittent data stream generated from a variety of sources and the data is  predominantly tume series .Data could be in real time streams or in batches , diverse in data structures and schemas . Culling out the signals from the noise of data is something which makes IoT program an effective one .

Hence  it is imperative that the marriage of physical computing and digital computing should be a near perfect one . To gain the benefits from the IoT Program the need to make use of the usage data ( from users )  , telemetry data ( from sensors and remote end points )  , contextual data ( from enterprise applications like ERP , CRM ) and ambient data ( weather , traffic etc ) to work on concert to provide the insight to act upon . Hence the selection of a right business use case is imperative for the success of the IoT program and if the use case can work on the standard layers of a typical IoT platform that would be an ideal situation to be in.

ToT programs are expected to essentially help address business functions which are in the realm of Monitoring , Control , Automation and last but not the least in bringing in predictability in actions through analytics . If we believe that the real value of ioT would be generated though predictive analytics and with it the attendant benefits , then the use case should be decided based on the following five questions which we need to pose ourselves with respect to data :

  1. What kind of data is needed ? The question which we need to ask something specific like: “I want to know whether the device would fail  will fail in the next X days if the temperature remains at Y degree centigrade .
  2. What are the measures we care and what data can provide that ? If we want to predict things such as failure at the component level, then we have to have component-level information. If you want to predict a door failure within a vehicle , we  need door-level sensors and  and the data aggregated from them . It’s essential to measure the data that we care about.
  3. Is the data accurate ? It’s very common in predictive maintenance that we want to predict a failure occurring, but what we may be actually predicting through the data may not a real failure. For example, it may be predicting fault. If we have faults in the dataset, those might sometimes be failures, but sometimes not. So we  have to think carefully about what we are modelling, and make sure that that is what we want to model.
  4. Is the data connected enough? : If we have significant usage information—say maintenance logs— but we do not  have other identifiers that can connect those different datasets together say from sensors, context ( from enterprise apps )  and ambience ,  then we are not doing justice to the analysis .
  5. Do we have enough data ? In predictive maintenance in particular, if we are modeling device   failure, we  must have enough examples of those device  failing, and the context and circumstances they are failing in .

What is the expected Business impact and Return of Investment?

It is a general expectation that once we embark on an IoT project IoT based insights  is expected to provide new view of  functionalities , revised capabilities and feature based differentiations .These could result in creating the right business impacts. Certain use cases could be more compelling  with a higher financial payback than others .Use cases focussed on Fuel , Energy and Labor savings have shorter payback periods and provide significant financial paybacks .

So as use cases are decided  the benefits could be defined to fall under :

  1. Internal Benefits – which help the internal organization operations . These use cases would focus on Safety and Security , Asset Optimization , Resource Conservation and expenses reduction .
  2. External Benefits – which contribute to the ecosystem in which the extended organisation works in .The Use cases would be providing improvement in well being, enhancing customer service and engagement , identifying new revenue streams .

From our experience , as IoT based project implementation would have to go through a life cycle , and its success would breed bigger success , it would pay to look at internal benefits in the early days and then branch out to the external benefits . The number of variables to control is lesser in the former and the chances of success are brighter .

Concluding Notes:

So to get the necessary short term effect to justify the investment in IoT and to keep an eye on the long term impact in the organization the right selection of Business Use  Case could be a critical one .Amara law has its notable influence on the Anatomy of the Business Use case in IoT !!

 

 

 

 

 

Who owns the Machine Generated Data in IoT – Men or Machine?

The other day we were discussing and debating on a solution to be designed to meet the sensing needs for access, temperature, and humidity for some devices which form part of a networking infrastructure ecosystem. The idea was to build an IoT based system for monitoring and control.

The design discussions veered around the ability to collect data from the sensors and the types of short range communication protocols which could be deployed.Questions and clarifications were raised if we were compliant to use short range communication protocols in sensitive areas as customer Data Centres which are like owned and that they may be custodians of data of their end customers.

The hidden perils of data acquisition and data ownership reared its head which needed to be addressed as we moved forward.

The data which is acquired by sensors is essentially Machine Generated Data (MGD).This post will  dwell on the subject of data ownership of MGD as follows :

  1. Sensors ( Data Acquisition and Communication )
  2. Machine Generated Data
  3. The Lifecycle of the MGD and the Ownership Paradigm
  4. Who should be the owner of the MGD?

Sensors (Data Acquisition and Communication):

In the IoT ecosystem, the physical computing frontier is managed by the Sensors .Sensors essentially include three fundamental functions:

  • The act of sensing and acquiring the data
  • Communication of the data through appropriate protocols to communicate their readings to internet cloud services for further aggregation and trend analysis
  • The activity is energized by power supply,

The additional functions would include processing/system management and user interface.

The Digital Computing part comprises the IoT application. This is determined by the types of sensors, cloud connectivity, power sources, and (optionally) user interface used in an IoT sensor device.

When making physical measurements such as temperature, strain, or pressure, we need a sensor to convert the physical properties into an electrical signal, usually voltage. Then, the signal must be converted to the proper amplitude and filtered for noise before being digitized, displayed, stored, or used to make a decision. Data-acquisition systems use ADCs (analog-to-digital converters) to digitize the signals with adequate signal conditioning.

Sensor data communication to the cloud can be done in multiple ways from wireline to wireless communication of various complexities. While wire line communication has some important benefits (such as reliability, privacy, and power delivery over the same wires), wireless communication is the technology that is the key catalyst in the majority of IoT applications that were not previously practical with wired systems. Reliability, channel security, long range, low power consumption, ease of use, and low cost are now reaching new levels, previously thought infeasible

Some examples of recently popular IoT wireless communication types: Wi-Fi, Bluetooth Low Energy (aka Smart), Zigbee (and other mesh 802.15.4 variants), cellular, LPWA (Low-Power, Wide-Area network variants: Ingenu, LoRaWAN, Sigfox, NB-LTE, Weightless), and Iridium satellite.

  1. Machine Generated Data (MGD)  :

Sensor data is the integral component of the increasing reality of the Internet of Things (IoT) environment. With IpV6, anything can be outfitted with a unique IP address with the capacity to transfer data over a network. Sensor data is essentially Machine Generated Data. MGD is that is produced entirely by devices/machines though an event or observation.

Here we would define human-generated data, what is recorded is the direct result of human choices. Examples are buying on the web, making an inquiry, filling in a form, making payments with corresponding updates on the database. We would not consider the ownership of this data in the post and would be limiting our post to MGD.

  1. The journey of the MCD and the Ownership Paradigm:

The different phases exist in the typical  journey of Machine Generated Data .

Capture and Acquisition of Data– This is a machine or a device based function through signal reception.

Processing and Synthesis of the Data – This is a function which ensures enrichment and integration of Data

Publication of the Data – This is done by expert systems and analysts who work on exception management , triggers and trends .

Usage of Data – The action which need to be taken on the processed and reported information is used by the end user .

Archival and Purging of Data – This function is essentially done by the data maintenance team with supervision.

Now let us dwell on the Ownership Paradigms.They range from the origination of data , adding value to the data through make over , monetising of data through insights generated. Interestingly, let us explore if there is any conclusive method for determining how ownership should be assigned. A number of players may be involved in the journey of the data (e.g. the user, hardware manufacturer, application developer, provider of database architecture and the purchaser of data, each having an equal lay of the claim in different stages of this journey )

  1. Who should be the owner of MGD :

Let me share the multiple and conflicting views  :

The owner of the device which records Data .In essence, the owner of machine-generated data(MGD), is the entity who holds title to the device that records the data. In other words, the entity that owns the IoT device also owns the data produced by that device.

But there could be a  lack of clarity if the device is leased rather than owned.. When real-world constructs such as lease holdings of (say servers) come into play, it indeed gets complex and even murky

The owner is the user of the Data :The other dimension is data may be owned by one party and controlled by another. Possession of data does not necessarily equate to title. Through possession there is control. Title is ownership. Referred to as usage rights, each time data sets are copied, recopied and transmitted, control of the data follows it. There could be cases where the owner of the device could be the user of the data.

 The maker of the Database who essentially invests in aggregating, processing and making the data usable is the owner of the Data :This has a number of buyers of this paradigm . The owner of a smart thermostat does not, for example, own the data about how he uses it. The only thing that is ‘ownable’ is an aggregation or collection of such data provided there has been a relevant investment in carrying out that aggregation or collection (the individual user is very unlikely to have made that investment). The owner here could be the Home automation company. The value which could be generated though this investment could be producing market intelligence, exploiting the insights form data to build market presence and differentiation,

The purchaser of Data could be the owner of the Data: An auto insurance company could buy the  vehicle generated data ( from the makers of automobiles )  and could design a product for  targeted offerings to specific market segments based on say driving behaviour patterns  and  demographics  .This may not be as easy as this seems – refer the url  :  http://joebarkai.com/who-owns-car-data/ which states that the owner of the vehicle and not the maker of the car owns the data collected from the electronic data recorder.

The value chain of who owns the data can be a complex one with multiple claimants. As one aggregates more sources it just gets more complicated. A good example is in the making of smart cities. The sources of data can be from multiple layers and operational areas . City authorities would be making the effort to make use of the data in areas of waste management , traffic congestion , air pollution etc . So does the city authority own the data?

My personal take is , if someone in the MGD value chain is making the data usable  for  a larger good , and  in the process may monetize the data to cover the investments , that entity deserves to  be the owner of the data  as that is where value is generated .

 

The Integrity and Intrigue of IoT Platforms

 

The last count on the number of IoT Platforms which are jostling for space in the crowded IoT market place is 460 . There are analyst reports galore which explain the features and benefits of these platforms.

For an IoT platform to be called as a comprehensive, mature and end to end it has to have the 8 components with reasonable feature and technology depth which make an IoT platform.

To know what these 4 layers are which constitute 8 components. Let us get down to the basics of a typical IoT platform.

Hardware ( Device )  Layer :

  1. This is where data is produced.
  2. This includes the physical devices with their in-built microprocessors, sensors, actuators and communication hardware.
  3. This layer makes the devices “smart”.
  4. The 2 components which go with this layer are :
    1. Connectivity and Normalisation
    2. Device Management

Communication Layer :

  1. This is where data gets transported.
  2. This part of the technology infrastructure ensures the hardware is connected to the network, via proprietary or open-source communication protocols.
  3. This layer gives the data from devices the “expression”
  4. The 2 components which go with this layer are :
    1. Networks/ Infrastructure
    2. Communication Services

Software Backend Layer ( Cloud Services Layer )   :

  1. This is where the data is managed.
  2. It manages the  connected devices and networks while  providing  the necessary  the interface to systems in the eco-system  (e.g., ERP-system).
  3. This layer provides the “knowledge”
  4. The 2 components which go with this layer are :
    1. Database ( RDBMS and noSQL ) for storage and orchestration
    2. Processing , Rules Engine and Events Management

Applications Layer :

  1. This is where data is turned into value.
  2. In the application layer, IoT use cases get presented to the user (B2C or B2B).
  3. This layer is responsible for the “actions” to be taken.
  4. The 2 components here are
    1. Data Visualization and Analytics
    2. External Interfaces( APIs) to third-party systems ( like ERP )

The cross layer is Security layer which cuts across the 4 layers as mentioned.

The nub of the issue is ,  companies just providing cloud storage  or data security or running a CRM software or connectivity management claim to be an IoT platform .

75 % of the IoT platforms which are currently in the market provide connectivity management pretty well which is essentially the communication layer.

This is borne by the figures which are as below:

  1. IoT platforms themselves will not be revenue earners , but they can definitely facilitate revenue growth when they are put in a business context .The total revenue generated through IoT platforms in 2015 is $ 330 Mill and is expected to grow to $ 1.168 Bill in year 2017 ( as per reports from IoT-Analytics ) . Of the 460 platforms which are there only 7 % of the platforms generate $ 10 Mill or above .
  2. McKinsey report says that $11 Trillion is the business value which can be generated through the implementation of IoT programs and that would mean through productivity gains, efficiency of operations and the like .
  3. The fact that 12.5 bill things would be connected by 2020 also makes communication layer with connectivity the strongest contributor to the IoT platform companies.

So what are the parameters one should look at when accepting an IoT platform as a platform in the truest sense of the word (with integrity)?

The assessment of a platform could be considered to fall in two broad areas .They would be:

  1. Depth across the Layers for a Horizontal IoT Platform
  2. Vertical User Specific Industry Focus ( B2C or B2B )

The Depth Across the Layers for a Horizontal IoT Platform would cover:

  • Application Enablement
  • Device Management
  • Cloud Storage
  • Analytics Platforms
  • Connectivity

Currently 75 % of the platforms are in Connectivity layer ( as per IoT-Analytics report )

Vertical User Specific Industry Focus ( B2C or B2B focus )

  • Consumer – Home, Lifestyle , Health , Mobility
  • Business – Retail, health , Energy ,Smart Cities , Manufacturing , Supply Chain , Public Services

The leader here are Energy and Manufacturing (falling under IIoT ).

Next time one comes across an “IoT Platform” one needs to be suitably  intrigued to check the integrity of that claim!!