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 .

 

Honour the Cornerstones to Cross the Chasm in IoT –  From PoC to Production  Roll Out .

While we are all submerged with data on IoT and the kind of disrupting impact IoT would be bringing with it in the coming years the ground realities are sobering .

To bring home the points as per reports from reputable sources like IoT World and  IoT Analytics show that approximately 7,700 Enterprise IoT projects have been initiated in the since early 2013  – with a large number of projects still in pilot / development phase of the lifecycle. Out of that more that 40 % of the projects (3000) have been initiated in 2016.The key point here is 75% of the projects have not gone beyond the Proof of Concept stage and possibly have been abandoned. This sort of negates the hype on IoT .

There seem to be a handful of projects which are deemed as successful and have gone mainstream. For example, connecting remote industrial equipment (e.g., Rio Tinto’s self-driving trucks in the mining industry) or smart irrigation systems in a Smart City (e.g., Barcelona’s Smart City Initiative) are examples of successes few and far .

While we may argue that the history is still young with a data being collected for the last 3 years  it is imperative to harvest the lessons learnt and utilize them as we embark on ambitious projects and keep the nay sayings at bay .

If we have to “ Cross the Chasm “ we need to understand the why , what and how .

  1. Why are IoT Projects different from other projects in the IT world ?
  2. What are the phases of a typical IoT project  and hurdles to go past ?
  3. How to address these challenges early on ?

1. Why are IoT Projects different from other projects in the IT world ?

a. Multiple technology layers call for multiple skill sets .

On a high level there are 5 major layers of an IoT solution including one cross-layer: Device, Communication, Cloud Services, Applications, and Security.

Developing end-to-end IoT Solutions involves multiple layers that need to work in symphony across disparate technologies. It can be a quite a  struggle to craft viable business plans and implement, integrate, and manage a mix of different and complex IoT technologies, endpoints, platforms, back-end systems and data.

A typical IoT team skill sets will range in the following areas – embedded systems , cloud architecture,  application enablement , data analysis , security design  and base end system integration .One can observe the diversity in competency required .

b. Security and Privacy concerns limit the  business use case driven projects .

In a recent report on IoT based projects, Gartner mentions, “The lack of a compelling business case is a major impediment to growth for enterprises. It remains almost as big an issue as security and privacy. We believe that this is not so much because of a lack of a business case rather that the business cases have yet to be discovered.” This discovery could be muted with the overwhelming issue of security and privacy. This type of concern may not be there in other IT projects given that the exposure to the outside world is a controlled and measured one.

2 .What are steps one goes through in an IoT project and the hurdles that need to be acknowledged and addressed to take the projects to production?

To get the best Return on Investment (ROI) from an IoT initiative, the following 5-step-process has proven as a suitable framework for IoT projects. The steps which are followed would typically be :

  • Business Case Development
  • Build vs. Buy Decision
  • Proof of Concept
  • Initial Pilot Rollout
  • Production  Deployment

a. Business Case Development ( the selection of right use case is critical )

IoT world can be simplistically split into the B2C and the B2B . In the coming years we would see the B2C world would be dominated by the the triumvirate of Apple , Google and Amazon who have the direct access to the consumer in multiple ways . This blog would limit itself to the enterprise (B2B) .Typically; the business case for IoT is handled by a cross-functional team ( business development , leadership and technology ) .It can be a fairly straightforward process if each one takes the roles and responsibilities designated to them . But companies often suffer from insufficient collaboration across the disciplines involved, reversal of roles or a plain lack of focus when it comes to defining the returns of investment .

b.Build vs. Buy Decisions ( it would depend on the budgets allocated and the overall strategy )

As the area is new and evolving approaches could be of two types . In organizations which have got wedded to particular vendor partners they may want to “try out “ Iot business use case on a  the vendor platform. For example is an enterprise is on SAP the business use case could be tried out with SAP . However in enterprises where IoT is under the Center of Excellence ( CoE ) or the Innovation Council with a distinct budget allocated , the approach may be to work on Open source development platforms to “play with “ till a solution of sort emerges.

c. Proof of Concept ( Moving from –“you do not know what you do not know to now you know what you do not know” )

This is an important phase which could decide on Go-No Go for the project The PoC phase is designed to validate a few key points, not every single detail. The best practice has been to just start with 1-5 scenarios or feature designs that matter the most to the customer’s business. In this phase we move from “you do not know what you do not know” to now you know what you do not know “ . Achieving a proof of concept in a specified period of time  can be crucial to sustain top-level management support.

d.Initial Pilot Rollout ( dealing with multiple scenarios while discovering surprises )

Once the concept is proven, it is  time to evolve the scenarios and be ready for surprises on the field . The  IoT solution can be integrated into the broader organization. A big challenge at this stage involves the training of a select group of enthusiastic employees to use the system and preferably at a client location.

e. Production Roll Out

At this point, as the IoT solution is deployed to thousands of devices the manageability and scalability and interoperability with security of the overall systems becomes a key aspect of the overall success.

3.How do we address the challenges early on ?

Crossing the chasm from PoC to Production deployment is something which is key to defining the success . As pointed out 75% of the IoT projects are languishing at PoC stage and have now seen a roll out of sorts .

Now that we are 3 years into having projects in IoT being identified in the enterprise world what are the lessons learnt and how can we “Cross the Chasm”.

a.Choosing the Right Business Use Case :

Gartner’s survey of organizations that have already implemented IoT shows that it has been largely Business Use cases around  internal operations  relating to —improved efficiency, cost savings and enhanced asset utilization—versus the external IoT benefits of enhancing customer experience or increasing revenue would be low hanging and potentially easy to manage with success . Reasons are not hard to find as the case would be in a controlled environment with less security risks and integration challenges.  Two examples  in the B2B world would be connected asset management and connected logistics . BCG has come up with a good research (Winning IoT Jan 2017 ) on this topic as can be read .

b.Managing IoT Security effectively

In September 2016, the world witnessed its largest ever IoT botnet attack through Mirai and more recently Wannacry is another sorry examples of the vulnerabilities we are exposed to caused by  the swathe of poorly protected IoT devices.

Knowing the possible threat ( STRIDES Threats Model ) and addressing the same would be the best way to make a robust beginning .

c.Minimizing  Interoperability Issues.

Given that the IoT architecture is a multilayered one , the issue of interoperability has to be tackled at the Device to Device layer , Device to Server layer and Server to Server Layer .

Device to Device ( Physical )   layer – how bits are transmitted/received over the medium. What radio technologies are supported? For example,  Bluetooth, WiFi, 802.15.4, Cellular, variations of LPWAN or alternatively Ethernet.

Device to Server (Networking) layer –   how the data packets are securely transported from device to cloud. What technologies are required to route data through your networks?

Server to Server (Application ) layer – how the data is taken in and used in your applications. Which open lightweight protocols are supported? For example, MQTT, AMQP, CoAP, Restful HTML, DDS or web-sockets optimized for bursts of small amounts of data.

Integrating manageability functionalities will give the benefit of bringing in scalability to the solution.

Protocol translation at the development stage would play an important role in building interoperability.

Conclusion:

These are early days of IoT projects, the enthusiasm is high, the technology layers are evolving. To accelerate the pace of the evolution and to be cautiously optimistic in our approach it is imperative that we look at these cornerstones which have been gleaned through the leanings of the early adopters. Let us learn from these and prepare well to succeed emphatically.