machina researchi3forum.org/.../sites/11/...emerging-iot_landscape.pdf · 12/10/2015 · wider iot...

Machina Research Strategy Report

The Emerging IoT Landscape

Jim Morrish, Chief Research Officer

December, 2015

Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10

2

Machina Research//Strategy Report © Machina Research, 2015

1 Executive Summary

The scope of this report is very wide ranging. We have sought to address, at a high level, the broad

spectrum of new issues and market and commercial dynamics that arise with the advent of the

Internet of Things (IoT).

The report starts with a discussion of the difference between emerging IoT markets and historic M2M

markets, and introduces the concept of Subnets of Things as a kind of ‘stepping-stone’ between

today’s fragmented environment for connected devices and a future environment where everything

‘just connects’. Subnets of Things (SoTs) are a powerful tool for understanding the competitive and

ecosystem dynamics that are likely to characterize our connected future environment, since they

describe subsets of devices that enjoy a ‘richer’ level of interconnectivity than is prevalent within the

wider IoT environment. Effectively, SoTs are microcosms of the IoT, but with the potential to develop

at a faster rate.

Having identified SoT data environments it is natural to then consider the potential for machine

learning within those SoTs. Until very recently, data analytics has essentially been the domain of data

scientists and data analysts. The tools that these professionals have had at their disposal have become

ever more powerful, but, until very recently, the tools have been the support act and the data

professionals have run the show. Machine learning within SoTs reverses that relationship. The

machines (or machine learning algorithms) will lead the way, and data professionals will need to

establish and implement protocols to govern the scope of any machine learning initiative. In turn,

these data professionals will be operating within some framework of delegated authority, and by this

mechanism the law and societal norms can (theoretically) be imposed on any machine learning

initiative. Relevant to the delegation of such authorities are the Domain of Influence within which the

consequences of any potential machine learning decision may have an impact, and the Event Horizon

beyond which no potential machine learning decision can have an impact.

The sources and nature of data are clearly very relevant when considering machine learning (and other

analytics and IoT applications). All data is not equal. Some data can be far more reliable than other

data, and some data may be associated with restrictions as to the use of that data. IoT application

developers will need to understand the context and provenance of data before they can build it into

their applications. This highlights a need to associate meta-data with different data streams and

potentially also to ‘watermark’ data to certify a level of quality (or to define restrictions as to how the

data can be used based on privacy, data protection, data sovereignty and so on) in a way that can flow

through to the data exhaust associated with any derivative application.

The topology of data is also relevant. Data may originate from any number of sources, but not all data

will be available in all locations. Some data may be redacted at source or may only support edge

analytics. There is a clear compromise between the load placed on communications networks and the

flexibility and scope for any machine learning initiative, and also the potential for ‘new’ IoT

applications. By corollary, a requirement for a ‘new’ IoT application may have implications for data

topology. For instance, if an application needs to operate in real time (with response times in the low

milliseconds), then it needs to be deployed locally, not in the cloud. Response time is just one

consideration of many that might have implications for the ‘location’ of application data and


3


processing. The net effect is that an evolving estate of IoT applications that draws on shared data

sources can have implications for the way in which data is collected and shared. This introduces the

concept of application agility: many applications can be configured to run in different ways (with

different elements in the cloud or locally, for instance) and it may be that for any given application

this mix needs to change over time, within an evolving IoT context. Applying this kind of thinking to

data analytics results in ‘sources’ of data, ‘streams’ of (near) real-time data in motion and ‘lakes’ of

stored data, all of which can be analyzed in different ways and for different purposes.

The evolving network of SoTs highlights an opportunity for data intermediaries: companies that

intermediate between different SoTs and allow ‘visibility’ of, and integration with, data sources

resident in different SoTs. For instance, such an intermediary may allow transparency between (say)

Vodafone’s client base SoT and Stream Technologies’ client base SoT, or between Vodafone and the

construction industry SoT. We term these intermediaries IoT Service Marketplaces (IoTSMs) and we

believe that they will take on a key role in providing liquidity within emerging IoT ecosystems.

In effect, IoT Service Marketplaces can help to expose application data to third party providers of niche

data services. This raises the obvious question as to whether that data can then be monetized. We

believe that there are three key aspects to data monetization: data usage; data processing, and data

ownership. Of these it is only data ownership that is likely to result in data monetization at a level that

corresponds to anything above a very modest level of profitability in the medium term. Ultimately

‘data’ is likely to be traded on Data Bourses, and with the support of Data Brokers, operating in much

the same way as today’s capital markets.

Having considered the potential for monetization of data, it is appropriate to consider issues

surrounding privacy and confidentiality, and how the open system described above might be best

regulated and supported. In Machina Research’s view, any discussion of a whole range of the more

fragmented and complex concepts within the IoT leads inexorably to the need for Trusted Third Parties

(TTPs), and in this report we discuss six main areas:

Privacy

Security

Data trading

Data analytics

Machine learning

SLA monitoring and other markets

In general, the recurring theme through our discussion of TTPs is the fact that the IoT introduces a lot

of uncertainty and breaks down barriers between different processes and organizations. In many cases

there are no definite answers to questions around how to manage enterprises within this new

environment, and so the role for an independent trusted third party to make recommendations and

provide certification where relevant becomes a catalyst and enabler to business development.

Finally, we touch on the particular significance of Enterprise IoT since, in most analyses of the IoT, the

role of ‘Enterprise IoT’ is underestimated. Enterprise IoT is a special case: since an enterprise can be

regarded as a potential ‘Subnet’ of the IoT, the concepts of SoTs and the IoT become one and the same

in the context of an enterprise environment. In short, every enterprise has the luxury of a single (or,

at least, a limited number of similarly motivated) owners or points of control that can stipulate that


4


necessary connections are built between different data sources to support ‘IoT’ applications. It is also

beneficial that a single entity has full ownership of the business case for any systems development,

i.e. revenues and costs fall on the same P&L. In summary, enterprises have the opportunity to realize

many of the benefits of the IoT before the advent of the true IoT. But by doing this, and when a critical

mass of enterprises start working in the same way, and to similar standards, then enterprise IoT

practices will play a very significant role in establishing the norms and standards by which the (fully

fledged) future IoT will operate.


5


2 Contents

1 Executive Summary ......................................................................................................................... 2

2 Contents .......................................................................................................................................... 5

3 Scope ............................................................................................................................................... 7

4 The definition of IoT (as opposed to M2M) .................................................................................... 8

4.1 Differences between M2M and the IoT .................................................................................. 8

4.2 The path from M2M is long and complex ............................................................................. 12

5 Subnets of Things .......................................................................................................................... 13

5.1 Subnets of Things are a natural stage of development ........................................................ 13

5.2 Putting SoTs on a continuum ................................................................................................ 14

6 Machine Learning .......................................................................................................................... 18

6.1 What is Machine Learning? ................................................................................................... 18

6.2 Challenges with implementing machine learning ................................................................. 20

6.3 The requirement for human intervention ............................................................................ 21

7 Domains of Influence and Event Horizons .................................................................................... 23

7.1 Defining Domains of Influence and Event Horizons ............................................................. 23

7.2 Defining what machines ‘can do’ .......................................................................................... 24

8 The life of data .............................................................................................................................. 26

8.1 Generating data .................................................................................................................... 26

8.2 Analyzing data ....................................................................................................................... 26

8.3 Managing data ...................................................................................................................... 27

9 Fog at the edge and application agility ......................................................................................... 28

9.1 Edge processing .................................................................................................................... 28

9.2 Application agility .................................................................................................................. 29

9.3 Sources, streams, lakes and distributed databases .............................................................. 30

10 Liquidity in the Ecosystem ............................................................................................................ 31

10.1 The emergence of IoT Service Marketplaces ........................................................................ 31

10.2 IoT Service Marketplaces will fundamentally impact IoT ecosystems ................................. 33

10.3 What kind of entity might potentially offer these services? ................................................ 35

11 Making money from data ............................................................................................................. 40

11.1 Where’s the money? ............................................................................................................. 40

11.2 How much money, precisely? ............................................................................................... 42


6


11.3 And how to extract the money? ........................................................................................... 43

12 Trusted Third Parties ..................................................................................................................... 45

12.1 TTP role in privacy ................................................................................................................. 45

12.2 TTP role in security ................................................................................................................ 47

12.3 TTP role in data trading ......................................................................................................... 48

12.4 TTP role in data analytics ...................................................................................................... 48

12.5 TTP role in machine learning ................................................................................................ 49

12.6 TTP role in SLA monitoring, and other potential markets .................................................... 49

13 The role of Enterprise IoT ............................................................................................................. 51

14 Conclusions & recommendations ................................................................................................. 52

15 Further Reading ............................................................................................................................ 54

16 About Machina Research .............................................................................................................. 55

16.1 The Advisory Service ............................................................................................................. 55

16.2 Custom Research & Consulting ............................................................................................. 57


7


3 Scope

The scope of this report is very wide ranging. We have sought to address, at a high level, the broad

spectrum of new issues and market and commercial dynamics that arise with the advent of the IoT.

Historically, ‘data’ has been associated with defined applications and has existed within a relatively

closed environment. For instance, a vibration alert on a production line machine may trigger an alarm

on the machine’s control panel, but it would be unlikely that that same piece of information would

directly influence some wider automated process. With the advent of the IoT, data takes on a new

level of significance, including the availability of (near) real time streamed data that can be built into

a wide range of IoT applications, the potential for unstructured data to be included within automated

processes and the diversity of potential data sources that can be referenced by an IoT application. This

report focusses on the implications of that transition.

We have omitted detailed discussion of Privacy, Security and Blockchains from the scope of this report,

since we expect to publish reports dedicated to these topics in the near future.

Research Stream(s)

IoT Strategies

Keywords M2M, machine-to-machine, IoT, Internet of Things, Machine learning, Domains of Influence, DoI, Event Horizons, analyzing data, analysing data, managing data, edge processing, edge analytics, fog, cloud, platforms, IoT Service Marketplace, IoTSM, API, APIs, data monetization, data monetisation, Trusted Third Parties, Enterprise IoT, SLA monitoring, privacy, security, Subnets of Things, SoTs, sources, streams, lakes, distributed databases

Companies SeeControl, ThingWorx, GE, Samsung, Vodafone, IBM, Amazon, Eclipse, wot.io, C3 Energy, FedEx, BMW, McAfee, Google, Facebook, The Weather Company, Sigfox


8


4 The definition of IoT (as opposed to M2M)

It’s relatively easy to define the Internet of Things: everything must be connected to one vast network,

rather like today’s internet but including devices. There are a few spins on this general concept,

including Cisco’s Internet of Everything (IoE) and Bosch’s Internet of Things and Services (IoTS), but

the general concept is the same. Others might regard the ‘E’ part of Cisco’s definition and the ‘S’ part

of Bosch’s to be already connected to the internet anyway, but the end result is the same.

Digging a level deeper, the IoT concept encompasses the connection of a wide range of diverse assets

to some kind of network in a way that enables the data feeds emerging from these assets to be

combined into applications, and allows for control messages to be transmitted in the opposite

direction. Potential sources of data that could be stitched into IoT applications include:

M2M applications;

M2M connected devices1;

Corporate IT systems;

Published data feeds;

Crowdsourcing;

End users;

Social media, and;

Other IoT applications.

In a nutshell, the IoT concept is really the ability to create applications that are unbounded in terms

of the potential information feeds that can be incorporated into application logic.

4.1 Differences between M2M and the IoT

Clearly, the open-ended application-centric concept outlined above is very different from the concept

of simply connecting a device implicit in M2M. In this section we explore the constituent elements of

that difference. We have summarised these in Figure 1 below, for ease of reference.

1 Strictly speaking, these are different from M2M applications


9


Figure 1: Key differences between M2M and IoT [Source: Machina Research, 2014]

The remainder of this section is comprised of one subsection for each of the key differences

highlighted above.

4.1.1 Applications

We have touched on one of the main differences between M2M and IoT already. M2M applications

are about connecting devices and the associated applications, for instance a smart meter and a smart

metering application. IoT applications are potentially far more complex, and are characterised by

complex event processing and data analysis. As mentioned above, IoT applications should not be

limited by any inability to tap into any given data feed: the domain of the IoT should be boundless and

limitless in potential. Essentially, this is a move from hardware-with-software solutions to (potentially)

software-only solutions.

4.1.2 Flexibility

A closely related difference is the flexibility of an application. Whilst an M2M application is typically

functionally specialized (dedicated) and quite inflexible, an IoT application should be more flexible in

terms of potential to evolve over time. Whilst M2M applications are (almost) deployed and forgotten

about, IoT applications should be easily maintainable and agile in terms of potential to reconfigure

application logic to include new functionality and leverage new data sources.


10


4.1.3 Architecture

In turn this highlights a difference in solution architecture. M2M applications are deployed with a

relatively rigid and unchanging solution architecture, whilst IoT applications are characterized by their

need for distributed and federated processing, storage and querying. In essence, when an M2M

application is deployed, software engineers have a pretty good idea of what aspects of processing will

need to take place where over the entire lifetime of the solution. Conversely, since the estate of IoT

applications is ever-expanding and individual applications are often divorced from the underlying data

feeds, different aspects of different IoT applications that may leverage the same data feeds might

most efficiently be located in different places. And the most efficient locations for different aspects of

different application processes may change as the estate of IoT applications grows. This effect is

particularly marked in the case of real time analytical requirements. For instance non real time

applications are more suited to centralized batch-processing solutions, whereas real time applications

are often better suited to distributed processing solutions.

4.1.4 Speed

It is worth emphasizing this point about speed, by which we mean potentially minimizing transmission

and processing delays to better support data analysis. In an M2M solution, ‘speed’ can be designed in

when it is needed and applications are able to support the necessary ‘speed’ requirements from Day

1. In an IoT environment, however, as demonstrated in the example outlined above, the need for

speed in the delivery and processing of different data feeds may evolve and change over time.

4.1.5 Verticals

The discussion up to now highlights a related difference between M2M and IoT: M2M applications

should be considered in the context of industry verticals and functional niches, whereas IoT

applications transcend these limitations potentially to become cross industry and cross function.

4.1.6 Context

To support this flexibility of environment, it is necessary for IoT applications to be semantically rich

and for associated contexts and ontologies to be clear. This is not the case for M2M applications,

where data generated by an application only needs to be meaningful in the context of that specific

application and within the ‘boundaries’ of a known systems environment. It is worth exploring the

concepts of semantics, context and ontologies further:

By semantics we are referring to the messages that an application generates. For example, an

application that generates a message “83F0267358” to indicate that it is necessary urgently

to send a field engineer to smart meter number 267358 is semantically poor. An application

that generates a message “send a field engineer to smart meter number 267358 (urgently)”

is semantically rich. Semantically rich environments enable third party application developers

to develop applications that draw on the data generated by multiple underlying applications

without the need to unpick the semantics of each of those underlying applications.

By context we are referring to other considerations that may make data more meaningful. In

the above example, context might include details of the utility that owns the meter and also

information regarding the manufacturer of the meter. This kind of information will help


11


prepare any field engineer and ensure that appropriate tools and spares are taken to the job,

and that appropriate parties are notified that he has accepted the job.

By ontologies we are referring to a set of meta-data that can be derived from underlying data.

For instance, temperature information potentially can be derived from certain infra-red CCTV

feeds. An infra-red CCTV feed from a room in which the heating system has broken down

contains the information required to derive a temperature profile in that room, which can be

subsequently compared to a thermostat in an adjacent room in order to derive the conclusion

that the heating in the first room must have broken down. However, temperature information

is not a standard component of the CCTV feed from the first room: without some level of

ontological alignment, it is impossible to derive any meaningful conclusions by comparing the

CCTV feed from the first room with the thermostat feed from the second room.

4.1.7 Structure

This leads to a wider point about the structure of data. In M2M, data is highly structured (and well

documented). In an IoT environment, a developer may want to include the aforementioned CCTV

feeds into an application, or crowdsourced information, or information derived from the

Twittersphere (to coin a phrase): these information sources are at best semi-structured and at worse

completely unstructured (depending to a great extent on the kind of information that the developer

is trying to extract).

4.1.8 Growth

A related difference is the speed of growth that can be expected in M2M and IoT environments. In the

case of an M2M application, growth is far more predictable. Typically a M2M solution is designed for

a specific market, or estate of assets, and can be deployed into that addressable market in a relatively

predictable way. Data generated by M2M solutions would typically grow linearly with device count. In

an IoT world, however, the estate of IoT applications is continually evolving in a way that is essentially

disassociated from the rollout of individual M2M applications and exposure of other data feeds for

potential inclusion in IoT applications. In short, the growth of data volumes, transaction volumes and

application estate in an IoT environment is driven by network effects between a diverse range of data

sources. Accordingly, growth in the IoT space (on any measure) can be expected to be more

exponential, rather than the more linear and predictable growth that characterizes the M2M space.

4.1.9 Data ownership

Lastly, it’s worth touching on the topic of data ownership. Whilst data ownership in the case of M2M

connected solutions can often be unclear, the concept of data ownership in an IoT environment is far

more complex. We will address the topics of ‘privacy’ and ‘security’ in a forthcoming Strategy Report

but, fundamentally, in the case of M2M the privacy of data can be considered within a known

landscape of application, user and regulatory requirements. In the case of IoT applications, however,

data can potentially be used for contemporaneously unforeseen applications in unforeseen locations

and for unforeseen beneficiaries. Additionally there is a question as to the extent to which any rights

over data ownership extend to the ownership of the outputs of any analyses based on that data, and

the levels of aggregation of data feeds and statistical significance of any individual data feed (or

datapoint) that might mitigate against the outputs of an IoT analysis as being ‘owned’ by the entity

responsible for the IoT application that generated the outputs. In short, considerations of privacy and


12


data ownership must transcend the ‘barriers’ that individual IoT applications constitute, to in some

way become ‘attached’ (potentially in a diluted form) to the data outputs generated by that IoT

application. And since the absence of data can also reveal information, it is likely that restrictions will

be placed on the data outputs of IoT applications by the privacy considerations of data sources that

could theoretically have been incorporated into an IoT analysis, rather than simply the data sources

that actually have been incorporated into that analysis.

4.2 The path from M2M is long and complex

The first thing to note about the Internet of Things is that it is a very different concept from M2M and

cannot simply be regarded as an agglomeration of connected devices and other information sources.

The development path from M2M to the IoT is long and complex, and it is natural that in some way

this journey will be completed in more ‘bite size’ chunks. We term these chunks ‘Subnets of Things’

and they are discussed in the next Section.


13


5 Subnets of Things

To help analyse the Internet of Things, Machina Research has coined the term2 ‘Subnets of Things’, by

which we mean an island of interconnected devices, driven either by a single point of control, single

point of data aggregation, or potentially a common cause or technology standard. In this Section, we

explore why Subnets of Things (SoTs) are a significantly more relevant concept than the Internet of

Things.

5.1 Subnets of Things are a natural stage of development

To carry the terminology further, M2M solutions can almost be regarded as ‘Intranets of Things’:

closed environments, with little connectivity outside of the device estate, or solution, in question. The

natural next step for integrating these solutions into the ‘outside world’ is to consider the integration

of such ‘Intranets of Things’ to what could be regarded as ‘adjacent’ products, services and, of course,

Intranets of Things.

At Machina Research, we think that this stage of development will be driven by common ownership

of data sources, or common cause amongst the owners of data. Examples could be a utility that builds

connections between its smart metering solution and its field force solution. The utility in question

can do this because it owns the smart meters, the field force capability and the applications that

support these capabilities and the data that those applications generate. In short, the systems,

connected device and IT environment within an enterprise can be regarded as a potential Subnet of

Things.

The key thing to recognise about these Subnets of Things is that the unique quality that they possess

in terms of the potential willingness and technical feasibility of sharing data between applications

enables them to develop far more quickly than a full Internet of Things.

A logical next step is to extend the concept to Data Communities, which we define as a community of

devices, sources of data and data owners that could potentially give rise to a Subnet of Things. An

example might be the group of intelligent buildings providers that use SeeControl’s platform, or the

group of companies that use ThingWorx’s platform.

It is clear that SoTs are a significant and critical step on the path to any future IoT. Put simply, we

believe that whilst it will be relatively easy to convince a defined group of similarly motivated people

to ‘standardise’ sufficiently to create a SoT, it will be far harder to convince everybody in IT (and

related) industries to standardise so that that SoT becomes unbounded (i.e. the IoT). We illustrate this

progression in Figure 2 below.

2 See here for the first public usage of the term ‘Subnet of Things’: http://jim-morrish.blogspot.co.uk/2013/01/subnets-of-things.html


14


Figure 2: Evolution to the Internet of Things [Source Machina Research, 2013]

5.2 Putting SoTs on a continuum

As mentioned above, we have dedicated an entire Research Note to unpicking the difference between

M2M and the IoT. Here we focus on two key dimensions of that difference. The first is scope, the

second is agility.

In terms of scope, M2M solutions are very narrow, often simply a single application. Conversely, the

IoT is open and unbounded. M2M applications are often point solutions designed to address a specific

need with limited consideration of any external environments. Conversely, a full set of relevant

standards are a prerequisite for a fully-fledged IoT: an environment where every data stream can

(meaningfully) interact with every other data stream through means of an IoT application depends on

those devices to some extent speaking the same language.

Clearly, there is a vast gulf between the two extremes represented by M2M and the IoT, with common

standards (either de facto or formal, or even simply ‘in house’) becoming established within certain

defined groups of devices, applications, data sources and users over time. At the simplest level such a

group could comprise “all Samsung consumer products”, so that (say) user behaviour could be tracked

across those devices and media and applications shared between those devices. It’s a relatively short

step to then extend such a group to allow for communications and interactions between different

enterprises within the same industry3, or, say, different manufacturers of consumer devices4.

3 For example, SITESENSR: http://www.seecontrol.com/sitesensr/ 4 For example, AllJoyn: https://www.alljoyn.org/


15


This vast territory between “M2M” and “the IoT” is characterised by a plethora of SoTs. Some of these

SoTs will overlap, some will be subsets of wider SoTs, and many may post a limited amount of data to

a wider Internet of Things.

The second key dimension is agility. M2M solutions are typically characterised by the need to provide

a point solution that is unvarying over time. The most basic M2M solutions are essentially deployed

and then forgotten about (at least in terms of any functional development or refinement). Conversely

the estate of IoT applications is a constantly evolving and morphing entity, drawing on a vast range of

data sources all of which must be ‘meaningful’ to any third party application developer.

In this case, though, a full set of relevant standards isn’t quite enough for a fully fledged IoT to exist.

To be precise, we believe that it will never be possible to completely align the ontologies5 between

different data sources so that the information (as distinct from data) provided by all devices is

comparable to all other devices: it’s simply impossible to define before the event every conceivable

type of information that every future IoT developer might potentially wish to derive from every data

source. Happily though, we should be able get quite close to defining the contemporaneous

requirements for ontological alignment at any given time, and we’d argue that that’s good enough for

the purposes of the IoT.

Again, the vast territory between the ‘fixed’ M2M solution and the multifarious-but-transparent IoT

falls to be the domain of the Subnet of Things. Partially, this is a relationship by construct: it’s only

possible to claim full agility of solutions at the point that all data sources can potentially be

incorporated into any solution, so the fact that the addressable universe for any specific solution is

less than the full IoT necessarily limits the ‘agility’ of a solution.

We summarise this perspective in Figure 3, below.

5 See Machina Research Note “What’s the difference between M2M and IoT?”, published September 2014, for a definition.


16


Figure 3: Putting SoTs on a continuum [Source: Machina Research, 2014]

We highlight the ‘texture’ of an emergent Internet of Things in Figure 4, below. In this diagram a range

of SoTs are highlighted, including:

Enterprise SoTs (GE, Samsung)

Vertical specific SoTs (Health, Smart Cities, Intelligent Buildings)

Industry SoTs (Construction)

Data community SoTs (SeeControl)

In all cases the ‘thickness’ of the red lines connecting the illustrated SoTs indicates the richness of

communications between the relevant SoTs. Clearly the overall emerging SoT environment will be far

more complex than illustrated here, but the diagram serves to highlight the relevant concepts.


17


Figure 4: Texture of the Internet of Things [Source: Machina Research, 2014]

Clearly, such an evolving network of SoTs highlights the need for data intermediaries: companies that

intermediate between different SoTs and allow ‘visibility’ of data sources resident in different SoTs.

For instance, such an intermediary may allow transparency between (say) Vodafone’s client base SoT

and ThingWorx client base SoT, or between Vodafone and the construction industry. Additionally, such

entities might effectively work as data clearing houses, connecting providers of niche services (such

as data analytics, databases or enterprise solutions) to a range of potential client SoTs. What this

highlights is the somewhat abstract concept of a market for abstraction.

Even in a hypothetical future when all communications within the IoT are standardised and all assets

can theoretically interact with all other assets we expect that the IoT will remain ‘lumpy’. For example,

the level of sharing within (say) GE will be greater than outside the organization. That’s a SoT defined

on the basis of access privileges (not what’s theoretically possible).

In fact, we’d argue that the concepts of limiting the potential for interaction between data sources in

a future IoT environment and enhancing the potential for interaction between data sources in a SoT

environment are effectively the same thing. Both of these concepts result in the Subnet of Things

being the most appropriate lens through which to consider our connected future.

In short, we’d argue that our connected future will be more of a network of Subnets of Things than a

single Internet of Things. Today’s internet provides a clear precedent: you don’t share as much

information with your customers as you do within your organization, do you?


18


6 Machine Learning

As discussed in the previous section, a Subnet of Things can allow for extensive sharing of data within

the Subnet. This opens the door to one of the most fundamental concepts of the IoT: data analytics of

exhaust data. Specifically, this means using data that is produced by an IoT solution for a new

application that is different from the underlying solution within which the data was generated.

For instance, data provided by a congestion charging system in a city may be incorporated into a wider

traffic management system to enable the easier flow of traffic within the city overall. Alternatively,

data associated with wind turbine power generation might be mined to improve engineers’

understanding of the relationship between power generating efficiency and prevailing weather

conditions.

We would classify the first of these examples as an ‘IoT application’ (see Section 4 for further

discussion), whilst the second is an instance of big data analytics6. In previous publications7 we have

discussed the progression of IoT analytics from basic Data Analytics through Descriptive Analytics,

Predictive Analytics and through to Prescriptive Analytics.

In this section we take the next logical step and focus on Machine Learning, by which we mean the

development of algorithms that can learn from, draw conclusions from and prescribe actions based

on data and with no human input. Yes that might sound far-fetched, but it is already happening so

keep reading. We believe that machine learning will be the most fundamental change that is ushered

in by the IoT, beating even the restructuring of economies based on changed concepts of ownership8.

6.1 What is Machine Learning?

Fundamentally, machine learning entails the completely automated identification of a causal

relationship between two different datasets. We will unpick those elements in the following

paragraphs.

Firstly, machine learning has to be completely automated. Anything less than complete automation

would just be old-style (big) data analytics, potentially enhanced by some fairly sophisticated

analytical tools. The ‘secret sauce’ that separates machine learning from data analytics is the potential

for relationships between data to be established completely independently of any human interaction.

Secondly, note that the definition is constrained to the establishment of relationships, and stops short

of automated action-taking based on any identified relationships. Machine learning could trigger

automated actions, and certainly will have to in order for the concept to reach its full potential, but

6 Discussed further in this Strategy Report https://machinaresearch.com/report/strategy-report-creating-value-from-data-analytics-in-m2m-the-big-data-opportunity/ 7 Please refer to the following Research Note https://machinaresearch.com/report/five-new-priorities-transform-iot-analytics/ 8 This will be discussed further in a Strategy Report in 2016.


https://machinaresearch.com/report/strategy-report-creating-value-from-data-analytics-in-m2m-the-big-data-opportunity/

https://machinaresearch.com/report/strategy-report-creating-value-from-data-analytics-in-m2m-the-big-data-opportunity/

https://machinaresearch.com/report/five-new-priorities-transform-iot-analytics/

https://machinaresearch.com/report/five-new-priorities-transform-iot-analytics/

19


such a consequence is not necessary and should be governed by a framework of devolved authorities

(see Section 7 for more discussion on this topic).

Thirdly, it entails the identification of a ‘causal’ relationship between two datasets. This is different

from a correlation, and includes a vector of implication: ‘A implies B’ is a very different concept from

‘B implies A’ although, on a simpler level, A and B would clearly be correlated to some extent

irrespective of which way the causal relationship runs. An example may help:

If I have an old and not very reliable car and the driveway leading out my house is a steep

slope, then there may be a correlation between there being snow on the ground and me being

unable to drive my car up my driveway …

… and there may be a causal relationship between these two variables, so that if there is snow

on the ground then I am not able to drive my car up my driveway …

… however the reverse relationship (if I cannot get my car up the drive then there must be

snow on the ground) may not exist. It may be that one summer’s day my car just doesn’t start.

This is the single concept at the core of any data analysis: what can a ‘known’ set of data tell us about

something that would otherwise be ‘unknown’?

Such causal relationships do not need to be definite, and the concept of inference is very relevant. For

instance, if it’s raining then it may be less likely that fleet vehicles will overheat than if it’s not raining.

Although such an analysis could clearly be improved by also referencing data relating to time of day

(for instance, is it daytime or nighttime) and time of year (summer vs winter) and a whole range of

other variables such as external temperatures and vehicle telematics (although such information may

not be available, for instance to a city traffic manager). Additionally, extending the driveway example

above, if I can get my car up my drive then potentially I can definitely say that there is no snow on the

ground, although there may also be many times that I cannot get my car up the drive and there is no

snow on the ground (i.e. in this case, A implies B, but B may well happen irrespective of A, although at

a different level of probability).

Unsurprisingly, machine learning is an incredibly complicated area, and it is not possible to cover the

topic adequately within the context of this report. A few of the more relevant concepts not yet

discussed include:

Inductive analyses. For example, if my car does not leave my driveway one morning and sales

of ice cream are at an all-time high, then it’s probably not because there’s snow on the drive.

But it’s not certain whether the car has not left my drive because it’s broken down, or because

I walked to work instead.

Conditional dependencies. For example, the brightness of my desk lamp is related to the

position of the dimmer switch, but only if it’s plugged in.

Evolutionary algorithms, where many different potential solutions to a problem

(determination of a specific conclusion given an array of input data) are tested to find the

most accurate, from which multiple new candidate solutions are derived.

Clustering, so that subsets of a data sample exhibit a causal relationship, the challenge then

being to establish the circumstances in which that causal relationship then exists.

Orthogonal data, where two streams of data are completely unrelated (un-correlated).


20


Probably the best current example of a machine learning solution is IBM’s Watson. IBM Watson is a

technology platform that uses natural language processing and machine learning to reveal insights

from large amounts of unstructured data. Cancer diagnosis and treatment was the initial focus of the

Watson solution, and the system was ‘trained’ on a range of cancer case studies. Currently, Watson is

used as a tool to advise and support clinicians, although we understand that its decision-making

capability is on par with the best oncologists.

6.2 Challenges with implementing machine learning

There are, of course, challenges with implementing machine learning solutions. The first is a statistical

consequence of dealing with very many very large datasets: the bigger the volume of data that you

analyze, the more likely you are to find a correlation within that data. For instance, a data analyst

analyzing a vast set of data may establish that the weather in Kingston, Jamaica is correlated with

cricket scores at Lord’s. But, clearly, there can be no causal relationship behind this correlation – it’s

simply a random consequence of analyzing a vast array of different sets of data. Given an infinite

amount of time, a monkey randomly hitting the keys of a typewriter will almost certainly write the

entire works of Shakespeare9, and the same effect becomes ever more prevalent as larger and larger

datasets are analysed.

Figure 5: A monkey at work on the infinite monkey theorem [Photograph courtesy of New York Geological Society]

So, once a correlation has been established, it is crucial to then test that the correlation is, in fact, the

result of a causal relationship (and also the direction of causal implication). One way to do this is to

take a “randomly” selected10 subset of the dataset to be analyzed (say 60%) and use that as the base

data to analyze to identify correlations. Any relationships that are identified within the dataset can

then be tested on the remaining 40% of the data sample.

Another approach to testing a relationship is A/B testing, a randomized technique where two

alternative versions of something are compared. Amazon already does this to refine and evolve their

9 The ‘Infinite monkey theorem’, see here for further details: https://en.wikipedia.org/wiki/Infinite_monkey_theorem 10 “Randomly” is in inverted commas since it’s nearly impossible to truly randomly select a subset of data, and this is another potential pitfall of such analyses.


https://en.wikipedia.org/wiki/Infinite_monkey_theorem

21


ecommerce websites automatically, and in real time. Where a correlation is identified between a

certain scenario and an improved revenue result (for instance, when cross selling items) then

Amazon’s systems can automatically test refined versions of their webpages with a randomly selected

group of users to test the hypothesis (in this case that a different cross-sell approach results in better

revenue performance).

6.3 The requirement for human intervention

In the previous section we discussed some of the potential pitfalls of implementing machine learning

solutions. In this section, we focus on the actioning of any conclusions that machine learning might

generate, to highlight the need for human intervention.

A couple of examples will help to illustrate the range of difficulty of implementing machine learning

solutions:

Firstly, consider the case of a residential LAN network. It is easy to conceive of a potential

‘machine learning’ solution that first analyses what ‘normal’ looks like on the network and

is configured to cut connections to the outside internet and file storage solutions in the

case than anything ‘abnormal’ is detected. Such a solution could be quite an effective

security measure, effectively blocking a range of security threats, including ‘unknown’

threat types, rather than just instances of threats that have already been identified

elsewhere.

Secondly, consider the case of IBM’s Watson. Watson is positioned as a tool to advise

clinicians and the ultimate decision responsibility (and risk) remains with the clinician.

In the first case, the consequences of a ‘wrong’ (or overly cautious) decision are fairly minor: possibly

a little inconvenience and that’s about all. In the second case, a ‘wrong’ decision could be significantly

more inconvenient.

These two examples highlight very difficult potential needs for human intervention. In the first case,

the ‘abnormal’ situation is not particularly critical, or in need of a real time response. In the latter, a

potentially life-or-death decision must be taken.

These are two reasonably extreme examples, but the likely vector of development of machine learning

over time is that 1) machine learning analytics will get better so that human decision making will be

needed only in ever more complex scenarios, and 2) the bounds within which machines can be allowed

to operate truly autonomously (i.e. undertaking machine learning, and actioning conclusions) will be

continually evolving and expanding.

Effectively, the ecosystems that exist today to mine and analyze data will evolve to re-focus on taking

decisions as to whether or not to implement the conclusions of machine learning analyses and also to

decide how to define the bounds within which decision-making and implementing authority can be

completely devolved to machines. The requirement for human interaction in a machine learning

context will become ever more sophisticated, and the autonomy of machine learning systems will be

ever increasing.


22


This is why IBM’s Watson is positioned as a tool to advise clinicians. Clearly, in the field of oncology, a

‘wrong’ decision can have devastating effects. Therefore, recommendations and probabilities are

presented to the clinician so that the clinician can then take a better-informed decision. The ultimate

decision responsibility (and risk) remains with the clinician.

So, machine learning is something that already happens, and the key question in the field of machine

learning is really how to go about setting those boundaries within which machines can operate truly

autonomously. This is the topic that we will discuss in the next section.


23


7 Domains of Influence and Event Horizons

As is often the case with discussions of the potential for machines to operate completely

autonomously and without human interaction, we start this section by citing Isaac Asimov’s Three

Laws of Robotics, quoted as being from the "Handbook of Robotics, 56th Edition, 2058 A.D.":

A robot may not injure a human being or, through inaction, allow a human being to come to

harm.

A robot must obey the orders given it by human beings except where such orders would conflict

with the First Law.

A robot must protect its own existence as long as such protection does not conflict with the

First or Second Laws.

However, in a return to more normal form, Machina Research asserts that these laws are not sufficient

for the management of machine learning in the IoT, not by a long way.

In the following sections we discuss the need for a ‘bottom up’ approach to managing machines and

setting the boundaries within which machines can operate fully autonomously, rather than a ‘top

down’ approach. That is, we need to define what machines ‘can do’, rather than what they can’t do,

and, in this way, machine learning initiatives will remain accountable within existing frameworks of

law and established protocol.

7.1 Defining Domains of Influence and Event Horizons

Thinking back to the machine learning discussed in Section 6 it is clear that machine learning is based

on the continual testing of hypotheses. Such an approach could be adopted in terms of testing a

hypothetical relationship between two variables, or even through application of the laws of natural

selection of the evolution of algorithms over time. In many of these scenarios it is clear that the

machine in question (the one undertaking the machine learning) cannot be expected to be aware of

the full consequences of its actions. This is almost by definition, since otherwise the machine in

question wouldn’t need to experiment and is particularly the case in certain complex systems, where

the ‘butterfly effect’ dictates that a small change in the initial state of a system can result in significant

differences in a later state11.

Machina Research has defined two new terms to assist with the discussion of the effects of machine

learning. The ‘Domain of Influence’ (DoI) is defined as the Subnet of Things within which the effects

of any machine learning or automated decision can potentially have a direct (i.e. automatic) effect.

Consider the following three examples, for illustrative purposes:

In the case of pricing and cross-selling optimization by Amazon (as discussed above) the DoI is

pretty limited. Some items listed on Amazon may see an uptick in sales, some may see a

11 See, for instance, Wikipedia for further details: https://en.wikipedia.org/wiki/Butterfly_effect


https://en.wikipedia.org/wiki/Butterfly_effect

24


downturn, and the effects of a machine learned pricing optimization algorithm are unlikely to

ever extend beyond this context.

In the (hypothetical) case of timetable and route optimization by, for example, SNCF (the

French rail operator), it is clear that the upsides of machine learning could be significant and

the downsides are likely to be limited to the potential for some level of congestion. The

Domain of Influence really only extends to the scheduling of trains.

Similarly, in a traffic management context within a smart city, applying machine learning to

the re-phasing of traffic lights to take account of prevailing weather and traffic conditions is

associated with a relatively limited DoI and may generate significant positive outcomes.

Although the mayors of (for example) Paris and Madrid may be unhappy if their cities were

selected for A/B testing12 , where a traffic management algorithm that is expected sub-

optimal is deliberately deployed in one city or the other.

However, the domain of air traffic control is really unsuitable for the application of machine

learning solutions that can potentially guide airplanes in different ways, or experiment with

landing processes and landing slot spacings, ‘to see which works best’. Clearly, in this situation,

human life could very much be at risk (even if such an eventuality is not ‘expected’ by the

machine in question).

A closely related term is the ‘Event Horizon’, that we define as the limit of the effects of any potential

machine-learned decision. Effectively, the Event Horizon (EH) is the ‘edge’ of the Domain of Influence

of any machine learned decision13.

The point about Domains of Influence and Event Horizons in the context of machine learning is that

these concepts define the set of things that may potentially be directly (i.e. automatically) impacted

by any machine-learned decision. Therefore, as long as there is nothing within the DoI associated with

a particular machine learning initiative that is particularly undesirable, then it should be appropriate

to undertake machine learning.

7.2 Defining what machines ‘can do’

Whilst it is clearly undesirable to set machines free to operate autonomously and in an unbounded

way in a future IoT environment, it can clearly be beneficial to deploy machine learning within certain

specific DoIs. The trick is to limit the scope of any machine learning initiative so that the potential for

negative outcomes is managed. Or, put another way, so that the DoI is appropriately managed. This

highlights the need to place a range of constraints on the scope of machine learning initiatives.

Effectively, machine learning has to take place within constraints that are defined by people, and

people must delegate authority to machines to take the decisions as appropriate.

For example, the first consideration when authorizing machine learning could be to identify the

possible knock-on impacts of decisions. Whoever is managing the machine learning initiative in

question should then escalate the scope of the required machine learning DoI, and scope of potential

impacts, for authorization within their organization as appropriate. In this way, people remain

12 See above for further discussion of A/B testing 13 This is, of course, a specific instance of a Subnet of Things.


25


ultimately responsible for the outcomes of any machine learning initiative and the norms of delegated

authority and legal accountability that are already established in society can apply.

For instance, consider an Amazon shelf-stacking robot. If that robot operates in a warehouse with no

humans nearby, then clearly a considerable level of authority can be delegated to that robot to

optimize its working routines. However, clearly it would be inappropriate for the robot in question to

venture outside the warehouse and into a local hospital and start practicing machine learning there.

Obviously this is a very unlikely scenario, but it does highlight the effect that machines should have

different delegated decision-making authorities in different domains. And if Amazon’s robot causes

trouble at the local hospital, then it is Amazon’s management team that will be held accountable.


26


8 The life of data

In Section 7, we discussed the application of machine learning to data, but we have not yet discussed

the actual data. All data is not equal. Some data can be far more reliable than other data, and some

data may be associated with restrictions as to the use of that data. In this section we unpick the ‘life

of data’ from creation through to incorporation into IoT applications and big data analyses.

8.1 Generating data

Clearly the first step in the life of data is generating that data. Data can be generated by an estate of

devices, by M2M (or IoT) applications and also can originate from a range of other sources (including

but not limited to internet feeds, enterprise systems and social media analysis). In fact, in the IoT

context, there is absolutely no limit to the kinds and range of data that can be analyzed. Hypothetically,

if a data stream (or data set) exists (or might exist, in a ‘known unknown’ kind of a way) then it can be

built into an IoT analysis. Clearly some data will be more real time than other data, and some data will

effectively take the form of ‘flat’ unchanging reference files. Really, anything goes.

Not only that, but any data source can potentially have ‘meta data’ added so that, for instance, a smart

meter reading becomes more than just a string of numbers: it can become a string of numbers that is

identified as a smart meter reading, and associated with a particular smart meter (and potentially user

account and also previous readings, and so on). Data can also be abstracted into better defined data

models to help with downstream analyses (see Section 10.2.2 for further discussion of simplifying the

integration of legacy infrastructure into the IoT).

8.2 Analyzing data

As outlined in the previous section, the potential for data to be ‘pooled’ into ever larger data sets to

which big data analyses and machine learning can then be applied is almost limitless. The complexity

with this situation lies in the ‘provenance’ of any particular data set.

For instance, a smart city application developer may develop an application that manages traffic light

phasing based on traffic flow. They may also draw information from a private sector car park operator

in their city and weather information from a local data feed. But what would happen to this smart city

application if the car park operator’s systems are hacked and the data feed changed, or the ‘local’

weather data feed turned out to be produced by a teenage geek who was simply relaying a public

feed? Potentially the car park information source would become useless (or at least, a new integration

would need to be built) and the weather data feed may transpire to be fraudulently gained.

The point here is that any application developer who is developing an IoT application of any

significance needs to know the provenance of the data sources that he is building into the application.


27


There are several aspects to data provenance to be considered. The first relates to security: does the

data in question originate from a secure path? Specifically, guarantees need to be given that the data

in question has been generated by the source that is claimed, and that it has not been interfered with

during its journey from point of origination. Such security guarantees could be a paid for service; our

application developer may be prepared to pay for a high quality data stream that is guaranteed not to

infringe any licensing provisions.

This suggests that datastreams need to be ‘watermarked’ in some way, or that a system will develop

where higher quality datastreams are watermarked as being fit for certain purposes, or satisfying

certain SLAs and QoS requirements. Such a scheme could be almost infinitely complex in terms of the

different kinds of guarantees that could be given for different data sources, and such frameworks are

likely to be continually evolving. We expect that this is another area in which Subnets of Things will be

relevant: certain subsets of the market are likely to develop faster than others, and the ‘standards’

that are widely accepted across the entire IoT market are likely to be relatively crude.

8.3 Managing data

Such a system of certification should not just act to promote the use of high quality data streams, it

should also act to limit the use of data streams that are subject to licensing, privacy, or other

restrictions.

This kind of certification needs to be derivative too. Our smart cities application developer discussed

above will need to attach some kind of meta data to their application data outputs defining how

reliable those outputs are, and what uses any output data streams can be put to. And certification

that applies to a given data stream should also carry forwards in some way to aggregated data sets

that include that original data stream14.

It should be noted that the development of frameworks for managing access to data is a matter of

national interest, not just commercial interest, so that national governments can make effective use

of health and smart cities data in particular. In general, however, it is likely that the development of

the kinds of framework of certification that we discuss above will be initially driven by the private

sector, and effectively by trusted third parties (see Section 12 for more on trusted third parties).

Additionally, there is likely to be a feedback loop so that the provenance and certification of data

streams can be adjusted in line with the downstream portfolio of applications that depend on the data

stream in question (and most likely in return for some level of payment).

In conclusion, however, it is likely that in certain circumstances a framework for the accreditation and

certification of data sources is likely to be a competitive differentiator, and also be something that

data owners can monetize.

14 To a great extent, this is a privacy issue and we will explore it more in a forthcoming report on privacy. It becomes particularly complex when data arbitrage is considered, where a single data stream can potentially be reconstructed from aggregated data sets.


28


9 Fog at the edge and application agility

So far in this report, we have discussed the analysis of data and the lifecycle of data. This section

focusses on the topology of data: where is it generated, where is it analyzed and where is it stored. As

ever in the Internet of Things, the answers to these questions differ from case to case, and are subject

to ongoing optimization. We focus on three key areas: edge processing; application agility and data

analysis at different locations.

9.1 Edge processing

Processing on ‘edge’ devices is a very effective way to support fast analytics and to reduce

communications traffic. However, it is not an ideal location to perform analyses that draw on multiple

data sets that are sourced from different locations, and also edge processing can have significant

consequences in terms of the cost of the remote device and the need for that device to be connected

to a power supply. We summaries the drivers for locating more (or less) processing on the remote

device in Table 1 below.

Table 1: Drivers for locating more (or less) processing on remote devices [Source: Machina Research, 2015]

Drivers for more processing on device Drivers for less processing on device

Potential for access to a better digital model of real world, enabling better detailed analytics

Faster or real time analytics

Increased processing power allows flexibility to add in other applications locally or to optimise a core application

Outputs generated by the local device can be changed and enhanced to support new applications downstream

Autonomy and resilience, lack of dependence on a connection to cloud infrastructure

Optimisation of communications traffic, since less data is sent to the cloud for processing

Increased battery life, and/ or lack of need for access to a power supply

Remote devices can be cheaper

Simplicity of the devices, and reduced potential for hardware failure

Security, particularly where local applications cannot be changed from a remote location

Cost of processing power and reduced flexibility, since providing local processing is likely to be less cost effective than could processing

Effectively, the debate around edge processing comes down to selective redacting, or intelligent

redaction at the edge: data that is deemed to be ‘useless’, or of low value, is discarded as close to

source as possible. This is how CERN (the European Centre for Nuclear Research) works15: a vast

quantity of data is generated, but only a very limited subset is processed. The trick is to identify the

15 See here for more information: http://enterprise-iot.org/book/enterprise-iot/part-i/manufacturing/11340-2/


http://enterprise-iot.org/book/enterprise-iot/part-i/manufacturing/11340-2/

29


data that ‘might’ be significant right at the edge, and to communicate that to cloud infrastructure for

further analysis, or as a process trigger.

However, as we have seen, the needs of machine learning tend to push in the opposite direction. The

more data that a machine learning process can draw on, the more successful it is likely to be. Redacting

information that is thought to be useless at the edge risks becoming a self-perpetuating scenario,

where information that is potentially very valuable never becomes incorporated into machine learning

(or big data) analyses because nobody realizes that it might potentially be valuable!

There is no ‘solution’ to this dichotomy, however many engineers that are responsible for deploying

large scale industrial solutions will draw far more information from remote devices (potentially in the

context of a test bed implementation) during a kind of ‘solution calibration’ phase, and will then

deploy a final solution with more redaction at the edge. Additionally, it is possible to build in a degree

of flexibility to IoT systems, so that processing can be centralized or distributed (or federated,

depending on the availability of spare capacity) on a relatively dynamic ongoing basis, although this

approach can increase costs.

It is also worth noting an interesting hybrid case, particularly relevant in the case of devices that are

infrequently connected. For such devices a ‘software twin in the cloud’ is relevant. For example, the

data readings associated with a local sensing device may not be stored locally, and the device may be

‘offline’ for all but a few seconds a day (or month, or more). In this case, the readings that are

associated with that device, but that are stored in the cloud, are the relevant ‘source’ of information

for any application rather than the device itself. For instance, in the case of a 4G connected fleet

management solution, an IoT application developer may build an interface between an enterprise

system and the remote device. However, in the case of a Sigfox connected fleet management solution,

it is more relevant to build a connection to Sigfox’s servers, which store periodically updated

information.

9.2 Application agility

The next dimension of topological complexity to consider is application agility, which is the ability for

IoT applications to be topographically reconfigured. For instance, a building HVAC control system

could be configured to run completely locally, completely in the cloud, or some mix of the two.

Specifically, the concept of agility relates to the ‘mix’ of application functionality between these

locations to be changed over time, as applications develop and potentially the HVAC solution in

question is stitched into a wider solution (potentially a Virtual Power Plant). A relatively simple

implementation may see almost all control functionality locally, maybe with weather feeds sourced

from the internet. As the solution becomes more complex, more functionality (in terms of optimizing

power consumption, given prevailing grid loading conditions) may be performed ‘in the cloud’.

Essentially, what has happened here is that part of the ‘functionality’ of the application has moved

from a local deployment to a remote location.

This kind of topological reconfiguration of IoT applications will be a recurring theme in the IoT.

Applications which were fit for purpose deployed as non-real-time may one day be required to

become real-time, and so deploy elements of the application logic locally.


30


From Machina Research’s perspective, this underlines the core function of an M2M platform: the

purpose of an M2M platform is to manage which elements of a process happen locally, which in the

cloud and how these two parts interface with each other. All other kinds of functionality associated

with M2M/IoT platforms are really about differentiation of a platform offering in a competitive

environment.

The business case process also introduces considerable complexity in considering application agility,

since solutions are usually built to a cost. The HVAC controller that we discussed a few paragraphs ago

may well be implemented as a relatively unsophisticated device, and, when the requirement comes

to reconfigure the underlying application so that more control and analytics are hosted in the cloud,

then the local device simply may not be able to support the new environment. To give a more concrete

example, equipping a smart meter with a Sigfox connection severely limits the potential for that smart

meter to engage in real time demand response. So the potential for application agility is likely to be

limited by business case considerations.

9.3 Sources, streams, lakes and distributed databases

The discussion in the previous two subsections highlights three kinds of data:

Sources of data, corresponding to edge analytics and real time applications.

Streams of data, including near-real-time data sets that traverse a network and

contemporaneous data analytics.

Lakes of data, which are aggregations of historical data feeds, tend to sit in the cloud and

correspond to offline scrape-and-analyze interrogation.

No longer limited to historical data analysis, the leading edge of data analytics will move to as close to

real-time analytics as possible, introducing and requiring tools such as data streaming analysis. In the

Internet of Things, data analysis will require multiple analytical approaches, and in some cases,

significant value is achieved from real-time data analytics (for example, in mission critical or life-saving

scenarios where information may guide rescue services within dangerous environments) or from

historical analysis for predictive maintenance services.

The Internet of Things generates significantly more data to be stored, and while cloud based services

have to date provided an efficient and scalable solution, developing tools to manage distributed

databases (rather than located on a single server) will become critical.

Essentially, the ideal database structure required to support (for example) off line historical analyses

is different to that required to support real time analyses. But specific datasets may be required to

support either off line or real time applications (or, more importantly, an ever evolving mix of real

time and non-real time applications that changes over time as new IoT applications are developed).

The implications that an evolving mix of real time and off line applications accessing related datasets

may have on optimal database structure is just one illustration of a wider dynamic: ever changing

application requirements in the Internet of Things will result in a need to dynamically manage the

optimal structure of associated databases on an ongoing basis.


31


10 Liquidity in the Ecosystem

M2M and IoT applications are at the core of the IoT opportunity. Every connected device must have

an associated application, and the development of those applications and the provision of supporting

capabilities (such as, for example, data analytics, data mining and other data services) represent real

commercial opportunities for a range of players. Whilst the industry has recognised that the IoT

marketplace can be highly verticalized and fragmented, few participants are yet taking the contrarian

approach of seeking out opportunities based on particular horizontal capabilities and then seeking to

differentiate on the basis of those capabilities. In this section we explore how this new and more

horizontal approach to IoT opportunities is coming into play.

10.1 The emergence of IoT Service Marketplaces

10.1.1 Introducing the IoT Service Marketplace (IoTSM)

Clearly, the evolving network of SoTs discussed in Section 5 highlights an opportunity for data

intermediaries: companies that intermediate between different SoTs and allow ‘visibility’ of, and

integration with, data sources resident in different SoTs. For instance, such an intermediary may allow

transparency between (say) Vodafone’s client base SoT and Stream Technologies’ client base SoT, or

between Vodafone and the construction industry SoT.

Figure 4 below illustrates how an IoTSM might work in practice. An IoTSM can potentially become the

default method for connecting between a vast array of SoTs, other than in the case where there is a

more fundamental reason for establishing a direct connection between SoTs. Such a scenario might

arise, for example, in the case of Samsung owning and maintaining the connections between their

consumer-facing SoTs and their internal Enterprise SoTs.


32


Figure 4: An IoT Service Marketplace function can catalyze development of the IoT [Source: Machina Research, 2015]

10.1.2 The services that a IoT Service Marketplace might offer

So far we have focused on the concept of IoTSMs supporting connectivity and integration between a

diverse range of groupings of connected devices and other data sources and consumers. However,

there is a much more interesting related opportunity: supporting connectivity and integration

between providers of IoT-related services and potential consumers. Accordingly, IoTSMs might

effectively work as data clearing houses, connecting providers of specific and differentiated services

(such as data analytics, databases or enterprise solutions) to a range of potential client SoTs. What

this highlights is the somewhat abstract concept of a market for abstraction.

Specifically, the range of service providers that might benefit from the existence of an IoTSM include:

Cloud service providers, including enabling providers of data storage (and a range of other

services) to access a host of potential clients

Analytics providers, including enabling providers of enterprise big data and analytics services

to easily access end-user enterprises

Systems integrators, which could use IoTSMs to leverage ‘productized’ solution components

with minimal integration to client-specific solutions

Application creators, who can benefit from rapid and easy access to a wide range of data

sources that can potentially be stitched into applications, and also access to potential end

user markets for their applications

Hardware companies, which can benefit from the existence of standard frameworks for

connecting their products, and also from a ‘market’ for the provision of relevant services

Data brokers, that aggregate, analyze and enhance and augment data in order to generate

value

These broad categories of service providers are illustrated in Figure 5 below.


33


Figure 5: IoT Service Marketplace scope of services [Source: Machina Research, 2015]

10.2 IoT Service Marketplaces will fundamentally impact IoT ecosystems

So far in this section we have described the basic role that an IoT Service Marketplace will play, both

in terms of mediating between different Subnets of Things, and also in terms of facilitating a

marketplace for IoT service providers. There are, however, three closely related benefits that the

advent of IoTSMs will bring. These include the potential for:

Assisting the rapid build and scaling of IoT applications utilizing diverse data services

Simplifying the integration of legacy systems infrastructure into the IoT

Sharing data within an IoTSM

Each of these is discussed in turn in the following subsections.

10.2.1 Assisting the rapid build and scaling of IoT applications utilizing diverse

data services

An IoTSM potentially offers a relatively simple route to access a wide range of value-added data

services. This could apply either to the end-users of an IoT application or to an IoT service provider or

systems integrator that would look to an IoTSM as a way to rapidly add significant depth and breadth

to its ‘bench’ of pre-integrated partners.

In turn this will allow for the more rapid development of more sophisticated IoT solutions and for

lower total development costs. For example, currently a power utility implementing a smart metering


34


solution would typically build interfaces to third party service providers on an ‘as needs’ basis. Key

partners might include:

A billing provider that can rate and generate invoice information from billing data records

An analytics provider to allow the utility greater insight into customer usage

Links to application developers – these could include third party application developers, or

developers retained by the power utility in question

Bespoke technical interfaces would need to be built to connect to each partner, and commercial

contracts agreed. This requirement results in a kind of ‘friction’ in the overall IoT ecosystem, and the

number and range of potential partners considered by the utility would be limited by this friction. This

same friction would also act to limit the scope and potential functionality of any solution that the

power utility might stitch together.

In summary, the advent of the IoTSM will herald a new level of liquidity in markets for the provision

of IoT services, allowing users of such services greater flexibility in terms of the procurement of

services.

10.2.2 Simplifying the integration of legacy systems infrastructure

One of the key aspects of an IoTSM is that it must be underpinned by a well-documented, stable and

well-managed systems environment. This is an essential capability, since the key competence of an

IoTSM is the ability to support the easy on-boarding of multiple data service providers, and also the

relatively friction-free combination of multiple data service providers to support a specific IoT

application.

An immediate corollary of this capability is that an IoTSM can potentially provide an effective route

for companies that operate legacy systems infrastructure to get ‘plugged in’ to the IoT. Firstly, an

IoTSM can provide a well-documented and stable environment to connect into. Secondly, once the

necessary interfaces have been built to connect legacy systems into an IoTSM environment, the

original legacy systems owners will immediately be able to avail of all the data services offered by that

IoTSM’s pre-integrated partners. It will also be far easier to develop new IoT-style applications that

interface (indirectly) to the legacy systems infrastructure, since these can now easily leverage all the

data streams that are exposed via the IoTSM.

Clearly, building connections to an IoTSM will not solve all the challenges that a company that relies

on legacy systems will face, but it can potentially significantly accelerate such a company’s adoption

of IoT-like solutions.

10.2.3 There is significant potential to share data within an IoTSM

On a fundamental level, an IoTSM is essentially an entity that supports data communications between

a range of data service providers and an end user (or service provider). In this central data

communication role, an IoTSM will support the flow of an extensive range of application data between

the different data service providers that contribute to a specific IoT application. And the IoTSM will

take this role in support of many clients and many IoT applications.


35


Accordingly, IoTSMs will potentially support the communication of a very wide range of application

data for a wide range of applications and users. As such, an IoTSM provides an ideal opportunity for

different data owners to begin to exchange data between applications, to combine third-party data

sources into applications and potentially to begin to trade data with third parties. The potential for

such a development can be enhanced by clients of an IoTSM opting to share more data within the

IoTSM environment than is strictly necessary for the support of the specific IoT application portfolio

operated by the client in question.

This dynamic results in IoTSMs becoming the natural environment in which data trading will ultimately

begin to gain traction.

10.3 What kind of entity might potentially offer these services?

So far in this section we have discussed the role of IoT Service Marketplaces in intermediating between

these SoTs and also providers of IoT services. Having established that there is a market opportunity

for an IoTSM-like entity, in this section we explore how such an entity might be commercially

positioned.

10.3.1 IoT Service Marketplaces market overview

In order to analyse the market for IoTSMs, it is necessary to first define an IoTSM. We use the following

definition: “an IoT Service Marketplace is an entity that intermediates and supports interconnection

between different entities within the Internet of Things”. Clearly, a very wide range of entities (or

cooperatives) can potentially satisfy this definition, including:

Communities (either open, or curated) which can act as shared repositories of standards,

APIs and policies and protocols

Sales commission based IoTSMs that may secure a ‘finder’s fee’ for arranging and enabling a

commercial relationship between two entities in the IoT

Agency type IoTSMs that invoice users of IoT-services on behalf of service providers according

to pricing agreed with such providers

Wholesale IoTSMs that agree wholesale rates for services with service providers, and are

then free to charge for those services as appropriate and according to their own pricing

structures

Value Adding Service IoTSMs that seek to differentiate by adding services on top of a

standard Wholesale positioning

Customer Facing IoTSMs that take the next step to position as a provider of solutions, rather

than as a white label provider of federated products and services

We expect that all of the IoTSMs outlined above will exist in some form, in different segments of the

future IoT market. However, it is worth highlighting some broad differences between these different

types of IoTSM.


36


Firstly, both ‘open’ and ‘curated’ community IoTSMs. These kinds of IoTSM are really the first step

beyond the model whereby companies simply publish their own APIs, and they exist essentially to

aggregate those published APIs. Whilst benefitting from low costs (potentially being free to end users)

such approaches are severely compromised by the lack of any tangible commercial proposition.

Notably, such entities lack revenues that reflect the potential liabilities associated with the use of the

services that they provide. In short, any company of significant size that uses the services of a

community IoTSM will be exposing itself to significant counterparty risks, particularly in the case that

the IoTSM in question ceases to ‘trade’. If this happens, then any solution components provided by,

or supported by, the IoTSM in question will become unsupported and may potentially cease

functioning. Such IoTSMs would be best positioned as ‘enablers of standards’ and as a portal to a

range of data service providers that are compliant with those standards, a market positioning

effectively equivalent to that which adopted by the eclipse Paho project, or by the Object

Management Group’s Real Time Publish-Subscribe Data Distribution Service (RTPS DDS) standards.

Sales commission based and Agency based IoTSMs both potentially enjoy significant revenue streams,

whilst leaving responsibility for delivery of services to other ecosystem members. As such, it is possible

for end-users to integrate larger such IoTSM services into business critical IoT solutions without

anywhere near the degree of counterparty risk as would be inherent in the case of community IoTSMs.

These types of IoTSMs enable formal contracts to be established with clients, including parameters

relating to QoS and SLAs and provision for ongoing support of services in the case that an IoTSM

provider ceases trading. However, given that sales commission and agency-style IoTSMs are

effectively simply reselling the products and services of others, whilst adding little value beyond

standardisation of interfaces, their position will be vulnerable to disintermediation or competition

from other providers. There is no ‘greater whole’ that component services are built into to drive client

loyalty and stickiness. Additionally sales commission and agency-style IoTSMs make little, or no,

contribution to simplifying the business and legal processes that a potential user must navigate when

establishing agreements with data service providers. C3 energy is a niche example of an agency based

IoTSM focussing on buying and reselling energy data.

It is worth focussing on wholesale IoTSMs, since these are the simplest to implement and the most

product-focussed of a group of IoTSMs that have some very significant advantages. First of these is

accountability. Contracts for provision of services will lie squarely with wholesale IoTSMs, allowing the

IoTSM to present a far more homogenised and simplified commercial (business and legal) proposition

to potential users. Such accountability also allows wholesale IoTSMs to disassociate the provision of

service from any particular provider. In turn this allows business volumes to be ‘steered’ to different

providers depending on wholesale rates offered. It also drives loyalty, since clients can be offered

discounts based on total spend with an IoTSM (not just the level of spend with a single IoTSM partner,

as is the case with sales commission and agency IoTSM approaches). The wholesale IoTSM approach

also allows concentration of purchasing, so driving scale benefits in wholesale costs negotiation.

Clearly the corollary of such a positioning is the requirement to operate a rating and billing engine,

and the requirement to support reasonably extensive platform functionality. wot.io is an example of

such a ‘pure play’ IoTSM.

Both VAS and customer facing IoTSM approaches augment the wholesale positioning described above

with the addition of value added solution components (for instance, systems integration or turnkey

solution development capabilities). This end of the IoTSM spectrum begins to merge with the already


37


well-established M2M/IoT Application Platform market characterised by the likes of IBM’s BlueMix.

Effectively, these companies are IoTSMs by default rather than design: the development of a range of

data service provider partnerships is necessary in order to achieve strategic objectives, but the

development of data service partner relationships is not in itself a strategic objective. In fact, VAS and

customer facing IoTSMs may potentially outsource the provision of actual IoTSM capabilities to a

wholesale IoTSM: such an arrangement would allow VAS and customer facing IoTSMs to focus on

developing end-customer solutions, without having to provide the required underlying IoTSM

capability themselves. Potentially, systems integrators may also occupy this market positioning by re-

selling the IoTSM capabilities of a third party IoTSM.

Lastly, it is worth observing that Agency, Wholesale, VAS or customer-facing IoTSM arrangements can

potentially allow the IoTSM to access the data that flows over their infrastructure. Whether such

IoTSMs will actually be able to use and monetise such data, and the situations in which they will be

able to do so, will be governed by client contracts but, theoretically, it should be possible for such

IoTSMs to monetize customer data.

We illustrate these dynamics in figure 6 below.

Figure 6: Different approaches to the provision of IoT Service Marketplace capabilities [Source: Machina Research, 2015]

10.3.2 Specialisation within the IoT Service Marketplace market

The next question is: which types of IoTSM will prevail, and in which situations?

We have already alluded to the suitability of different kinds of IoTSM to different situations with

comments on counterparty risk. Counterparty risk is a concept which is almost synonymous with the

new and emerging IoT market: many of the best and most innovative providers are simply too small

to warrant incorporation by large companies and into mission critical solutions. The IT market of today


38


is generally characterised by client and provider companies of similar scale working together, and the

fact is that there are as yet very few behemoths at the cutting edge of the IoT space.

However, IoTSM providers with significant cashflows make for much better counterparties than IoTSM

providers without such cashflows. Additionally, IoTSMs that position themselves as wholesale

providers are likely to be able to outcompete sales commission- and agency-based competitors due

to their ability to present a more simplified commercial proposition and to ‘steer’ business to maximise

margins (and to use this capability as a negotiating tool to secure lower rates).

In general, and due to the financial and risk criteria outlined above, we believe that the centre of mass

of the IoTSM market will lie with wholesale IoTSM providers. Such providers may also establish VAS

or customer facing channels, or may engage partners to resell their vanilla, productized, IoTSM

platform with a VAS or customer-facing positioning.

However, as with all things IoT, the market is likely to remain fragmented for some time. In particular,

we expect to see many of the following plays in the market for IoTSMs:

Agency and commission based IoTSMs establishing as niche portals, with specific (industry or

functional) specialisation

Community IoTSMs that catalyse the leading edge development of specific niche markets or

propositions

Supply-side funded IoTSMs that are retained by the owners of data assets or controllers of

connected devices to incorporate those things into the IoT in terms of making these assets

available to third party devices

Resellers of IoTSM capability

Aggregators of IoTSMs (or IoTSMs of IoTSMs)

Another consideration is that IoTSMs are likely to adopt different roles within different environments.

For instance, within the context of a smart city, an IoTSM could make a significant contribution simply

by standardising and abstracting data to better enable third party developers. Meanwhile, in the

consumer healthcare industry such technical standardisation is to a great extent unnecessary (since

many aspects of data management are already standardised by the Continua Health Alliance).

Accordingly, a successful IoTSM in the consumer health space is more likely to skew towards

supporting and enabling a market for service provision, whilst a successful IoTSM in the smart cities

space may skew more towards simply supporting interconnection between devices, services and

users.

And, of course, it should be noted that every ‘orbit’ around an IoTSM with a specific specialisation, or

market positioning, itself becomes another SoT that can potentially be integrated into another IoTSM.

The advent of IoTSMs will potentially significantly improve the level of competition and pace of

development within the IoT space, mostly to the benefit of all participants.

In the longer term the role of IoTSM will evolve, placing less emphasis on the fundamental

requirement of abstraction and ‘exposing’ the data assets that are held within one SoT to entities in a

second SoT, and placing ever more emphasis on the concept of being a hub for the provision, exchange

and purchase of data services.


39


IoTSMs are likely to have a significant impact on the development of the IoT in coming years. It is likely

that IoTSMs will be at the centre of initial efforts to monetize data within an IoT context, and this is

the topic that we focus on in the next section.


40


11 Making money from data

The previous section on IoT Service Marketplaces discusses how such entities can help to expose

application data to third party providers of niche data services. This raises the obvious question as to

whether that data can then be monetized. In this section we analyse the monetization of data in the

IoT in general, focusing on three key aspects (data usage, processing and ownership) and

consequences of this analysis.

11.1 Where’s the money?

It is helpful to consider the ‘market’ for data in terms of three key constituencies, as follows:

Data usage, for instance by an entity seeking to make a new, better, or more efficient product

or service

Data processing, including the ingestion of ‘raw’ data and the application of (potentially)

complex analytics to generate refined data outputs that are directly relevant to a Data user

(see above)

Data ownership, by which we mean the ability to control the access to certain datasets

We discuss the role of each of these constituencies in the monetization of data, and implications for

the value that can be extracted, in the following three subsections.

11.1.1 Ultimately value is generated by ‘users’ of data

Clearly, given the three constituencies identified, it is the ‘users’ of data that are in a position to

actually generate some form of economic value from data. This value could be generated by using a

data feed to support a new product, or a product refinement. Equally, data could be used to extend

or enhance a customer relationship. On the costs side, a new data stream could be used to streamline

an operational process (for instance, weather information allowing for the more efficient deployment

of field force activities), or to cut out certain elements of cost altogether (for instance, where a third

party data feed can substitute for an existing data source that is generated in house).

Clearly, in all such cases, it is the entity that ‘uses’ data that secures the economic benefit of that data

usage. However, given that (by definition, for the purposes of our analysis) the ‘users’ in question do

not already own the data in question, they must procure it somehow. The question is: at what cost,

and what kind of margins does that cost allow for?

11.1.2 Data processing will be a ‘cost+’ activity

For the purposes of this analysis, data processers are the entities that provide data to end users. These

entities ingest raw data, apply business rules logic and output refined data that is suitable for usage

by data users. On first analysis, this would seem to be the constituency where value is actually created.

This is where the gold is actually gleaned from the dust.


41


However, there is no such thing as a defendable competitive differentiator in the IT space16 and, as

such, any analytical process that can be undertaken by one data processer can also be undertaken by

any number of other data processers. To be clear, and for the purposes of this analysis, we are

assuming that all such data processers have ‘equal’ or ‘symmetric’ access to raw data and solely

compete on the basis of ability to identify and apply business rules. Our assertion is that there will be

no business rule that a particular data processer will be able to develop, and that can be monetized

by a data user, but that no other data processer with access to the same input information is able to

develop. We accept that some data processers will hit on the idea to develop a new (monetizeable)

data stream ‘first’, and so be in a very good position to extract value from a data user for use of that

data stream, but, ultimately, other data processers will be able to mimic the same data stream,

assuming that they have symmetric access to raw input data.

Effectively, then, the activity of data processing becomes a ‘cost+’ activity: it is necessary, and does

assist in the monetization of data, but data processers will never be in a position to secure long term

high value cashflows from the provision of any defined data stream output.

11.1.3 Data ownership is where it gets interesting

The last element to be considered in our analysis is the role of data owners, and the potential for

owners to extract value for information.

It is important to consider the value that data owners can extract from data separately from the value

that can be generated from data. Take, for example, a hypothetical relationship between a mobile

operator and a provider of in-car satellite navigation services. It may be possible for the provider of

navigation services to package traffic information drawn from a mobile operator (that knows the

location, speed and direction of travel of all devices on their network) as a premium service, so that

subscribers can be routed around traffic jams. However, in this case, the information provided by the

mobile operator is not ‘unique’, insofar as (typically) there will be 2-3 other mobile operators in any

given territory that are well positioned to potentially provide equivalent, and substitutable, traffic

information. Therefore, it is unlikely that any mobile operator will ever generate a high (i.e. super-

normal) economic return from the provision of traffic information. Again, the provision of such (non-

unique) information is likely to be a ‘cost+’ activity.

However, as a second example, consider the scenario were a data owner is in possession of some kind

of unique (and monetizable) data. For instance, the governing authorities of a city with a connected

parking solution may have perfect information relating to the availability of every parking space in

their city. Clearly, such information could be monetizable by the same satellite navigation provider as

discussed in our previous example. However, in this case, there is only one, unique, potential provider

of the relevant information and substitute data sources (such as, for example, traffic flow information

sourced from Google Maps) are of considerably inferior quality. As such, the city authorities in

question are well positioned to auction their parking information to the highest bidder and so extract

much of the value created by the satellite navigation provider (data user).

Accordingly, data owners should be able to monetize data that satisfies two conditions:

16 Other than, arguably, positional assets such as the network effects generated by client networks


42


The data owner has monopoly control over the data source in question, and substitute data

sources are of a significantly inferior quality (or utility)

The data can be monetized by an end user

Clearly the price that can be secured for any specific data source is constrained by the relative

suitability of alternative sources of data, since end users will always have the option to use alternative

sources of data if prices of their preferred data source are too high. But the value of ‘unique’

information should ultimately be driven by the value that end users can derive from it, and the degree

to which alternative sources of data can be substituted.

11.1.4 Supernormal margins will always be the preserve of the owners of

differentiated data sources

In summary, then, data users will monetize data wherever possible, but, in the case of revenue

streams that rely on data that is to some extent ‘unique’, data owners will be in a very good position

to extract any value generated.

However, in the case where a data user can improve a business proposition through the use of data

that is not ‘unique’, then it should be expected that that end users competitors will also be able to

implement equivalent improvements to their (competing) business propositions. As such, the

competitive advantage conferred by the effective use of no-unique data will tend to be competed out

in the marketplace, and the ‘gain’ will accrue to consumers. This is exactly what has happened with

previous technology revolutions: within competitive industries, the deployment of new technologies

typically results in greater efficiency, but not in significantly increased margins.

So the ‘value’ in data really boils down to two key components: firstly a ‘cost+’ fair economic return

for those participating in a data trading relationship, and; secondly, a potential to generate

supernormal margins for the (relatively few) owners of asymmetric (or differentiated) information.

11.2 How much money, precisely?

Who knows? Seriously, nobody knows…

Think back to the example where the city authorities have ownership of all car parking space

information for a city. Clearly, the value of that data of course depends on the availability of ‘similar’

alternative data sources that can potentially substitute, and the relative quality of those data sources

for the data user application in question. However, even assuming that there are no alternative and

realistically substitutable data sources (just for the sakes of argument), then what price should be set

for access to the data in question? There are a few relevant considerations.

Firstly, our city authority will probably not want to sell a single licence to the data to a single satellite

navigation company – they’d probably prefer to sell a single ‘premium’ licence and also potentially a

degraded licence that offers access to slightly compromised data. The reason is that they want to

maintain a competitive (bidding) market for their data for when they come around to auction licence-

renewals. In fact, the number of licences and granularity and quality of information that they offer

access to, and the term of the licences, will need to be carefully assessed in the context of the


43


competitive market for parking information provision to end users (by data users, in our terminology),

if the city authority is to maximize its return. Hypothetically, the authority could offer any number of

licences to access their parking data, potentially compromised by time of day outages where

information is not provided for a full 24 hour period, granularity of location information, time delays

or time-granularity applied to data feeds and potentially interactive services.

Overall, the aim of the city authority will be to maximize long term value of their asset (parking space

information), and to do that they need to keep a range of competing bidders in the market for the

long term. They also need to price at a level that will support development of the overall market for

car parking space information whilst not leaving money on the table and taking into account price

volume elasticities and the impact that an increase in parking space data costs might have on the

volume of sales of end user solutions that utilize the data in question.

In summary, the analysis that our city authority must take before deciding how to licence access to

parking space availability information, and on what terms are incredibly complicated17. Not only that,

but the analysis is likely to change on an ongoing basis. Additionally, over time new markets may

emerge for the sale of parking space information, and these may or may not impact the competitive

market for the provision of parking space information via a satellite navigation systems. For instance,

providing the same parking space availability information to FedEx for inclusion in their fleet

management solution should probably be regarded as an adjacent market to the provision of the same

data for inclusion in more generic satellite navigation systems.

Not only that, but in the world of IoT FedEx’s application (as mentioned above) may generate new

data that supports a new premium service (for instance, setting the time for a service where a

customer drops a parcel off at a parked FedEx van), and the city authority may feel inclined to then

attempt to revise prices to take into account this new revenue stream that is predicated on ‘their’

data. Or they may prefer to have the terms of the licences that they issue for access to data specify

the purposes for which data can, and can’t, be used and so treat this ‘new’ application by FedEx as a

‘new’ revenue opportunity.

Additionally, of course, there is the case where data that is not deemed to be ‘valuable’ in any way

may suddenly become valuable by dint of a third party developing a new and unexpected application

that relies on a new kind of data. For example, where cars are parked, and for how long, may be of

more use to a parking enforcement contractor that has developed a field force management

application.

11.3 And how to extract the money?

In any case, now is a good point to stop chasing the detail of how licences can be sliced and diced, and

make the observation that it is an incredibly complicated area in which the entities that find

themselves in possession of ‘unique’, or at least ‘asymmetric’ (and so valuable) data are unlikely to be

experts. Realistically, we think that the only way that ‘valuable’ data can be traded efficiently is via an

17 It should also be noted that the city authority’s motivations may not be purely financial, other priorities may be to reduce pollution, or improve the quality of life for citizens..


44


exchange, with valuation, packaging and licensing advice provided by companies that are expert in

those areas. We envisage such an arrangement as being analogous to today’s investment banks

engaging in commercial activity in support of capital markets exchanges, and we term these putative

future entities Data Brokers and Data Bourses respectively.

Such an arrangement may function by means of a selection of Data Brokers bidding to become

exclusive agents for the parking space information in our previous example, on the basis (for example)

of the amount of money that they expect (or commit) to generate over a certain timeframe (for

instance, 3-5 years). The data broker that secures the exclusive rights to monetize the parking data in

question then becomes responsible for all downstream licensing structuring and collection of

revenues.

From this point onwards, data licensing and trading can become incredibly flexible. For instance, a

Data Broker could sell the ‘cashflow’ associated with, for example, a per-per-use licence that they

issue to a third party and in return for a lump sum payment. Contracts with either data users or data

owners may include caps and floors on the fees payable, and it may even be possible to construct

derivative contracts to hedge against market risks. In fact, in a fully functioning market for data (as

described) it will be possible to swap cashflows, gear returns, hedge exposures to certain markets, de-

risk cashflows by pooling individual licence cashflows, etc, etc. There really is no limit to the exotic,

derivative and mezzanine structures that could be developed to support trading of data streams via

data bourses.

The topic of data trading is picked up again in Section 12, where we touch on the potential for Trusted

Third Party verification to increase the value of a data stream, and also the potential for Trusted Third

Parties to actually support data trading.


45


12 Trusted Third Parties

The previous section focused on applying unbounded commercial principles to the monetization of

data. It is therefore appropriate to consider issues surrounding privacy and confidentiality, and how

the totally open system described above might be best regulated and supported. In Machina

Research’s view, any discussion of a whole range of the more fragmented and complex concepts

within the IoT leads inexorably to the need for Trusted Third Parties (TTPs), and TTPs are the subject

of this chapter. We focus on six main areas:

Privacy

Security

Data trading

Data analytics

Machine learning

SLA monitoring and other markets

In general, the recurring theme through this section is the fact that the IoT introduces a lot of

uncertainty and breaks down barriers between different processes and organizations. In many cases

there are no definite answers to questions around how to manage enterprises within this new

environment, and so the role for an independent trusted third party to make recommendations and

provide certification where relevant becomes a catalyst and enabler to business development.

12.1 TTP role in privacy

There are two problems with privacy in the era of the Internet of Things. Firstly, the concept is almost

boundlessly complex. Secondly, privacy is a subjective concept and not all people will have the same

view on what data should be private and in which contexts.

To illustrate the first point consider the range of privacy settings for Facebook18 including settings

relating to Posts (including which friends and groups can access what), Apps (that may automatically

post updates on a user’s behalf), the User profile (where personal details may, or may not be shared).

Consider also the habit of that company to change policies from time to time in terms of how user

data is searched and displayed (for instance, in October 2015 the social network introduced an update

to its search feature allowing users to search all public posts, rather than just public posts by friends).

The advent of the IoT has the potential to increase this kind of complexity exponentially. Potentially

consumers will in future need to deal with an equally bewildering array of privacy choices associated

with any connected device, ranging from electricity meters to cars and from fridges to home alarm

systems.

To illustrate the second point around the subjectivity of privacy, imagine a ‘lost item finder’

application, with a tracking device attached to a users’ house keys. Such a solution could be very

18 http://www.techlicious.com/tip/complete-guide-to-facebook-privacy-settings/


46


helpful to someone in the habit of regularly misplacing their house keys, and most users would have

no problem with family members using the same application to locate the same set of keys. However,

if the spouse of the owner of the keys in question uses the same application and the location of the

keys transpires to be a nearby neighbour’s bedroom, then the same information is likely to be

regarded as ‘private’ by the owner of the keys.

And to underline the potential for problems to arise, it may be helpful to relate recent comments

made by a senior representative of a prominent auto manufacturer. In 2013, Machina Research had

the privilege of attending Bosch’s Connected World conference, where Elmar Frickenstein19 made a

keynote presentation and asserted his view20 that information generated by BMWs, and available to

BMW Group, was the property of BMW Group. The implication of this is clear: BMW can do whatever

it feels like with any information that may be gleaned from BMW in-car platform and other systems.

On the one hand, there are clearly things that BMW can derive from in-car systems that could be to

the benefit of all users, and also be very unlikely to infringe the privacy of any individual user (for

instance, aggregated mapping data, including road sign information). However, clearly, Mr.

Frickenstein’s perspective has the potential to make many potential BMW drivers feel

uncomfortable21.

So the management of privacy is complex, subjective and there is a significant and real risk of abuse

of privacy in the pursuit of commercial endeavours.

Machina Research’s view is that the only appropriate way to manage such a level of complexity is

through a (mostly voluntary) system of regulation by Trusted Third Parties. Consider a similar scenario

in the configuration of computer firewall software. Users don’t engage at the level of individual ports

and communications types (e.g. UDP traffic on port 24, etc), they tend to select a vendor of firewall

software that they trust (for example, McAfee), and then select from ‘high’/ ‘medium’/ ‘low’ security

options, potentially customising specific settings as needed.

We envisage a similar range of TTPs developing in the IoT space to support privacy management, so

that, for example, BMW’s treatment of user data could be ‘certified’ by a TTP (such as, for example,

McAfee). In turn, any purchaser of a BMW vehicle would potentially be able to select from different

levels of ‘privacy’ (High, Medium, Low, maybe) in return for the facility to use different services (or

use services at different price points). Furthermore, McAfee’s certification of BMW’s privacy

management procedures and policies may well be perceived as a competitive differentiator for a

customer choosing between a (privacy certified) BMW and a (potentially non-certified) Mercedes.

Of course, the counter argument runs along the lines that “everybody already shares all their

information with Google, and nobody seems to care”. However, if you could select an option so that

Google’s (or Facebook’s) use of your personal data was limited by policies set by a company like

McAfee, then you’d be tempted to take that option, wouldn’t you? The fact is though that both Google

and Facebook are near-monopolies (or, at least, benefit from extremely strong network effects), to

the extent that privacy certification is not currently relevant as a potential competitive differentiator.

19 BMW Group, Senior Vice President Electrics/Electronics and Driver Environment 20 Although, to be clear, not necessarily BMW Group’s view 21 Although there is evidence that BMW is quite careful with customer data, as discussed later.


47


12.2 TTP role in security

Security is another area that is more subtle and nuanced than generally appreciated. IoT solutions are

not either ‘secure’ or ‘insecure’, but the level of security built into a solution should be dictated by the

nature of the data to be secured and also prevailing industry norms.

Focussing first on the data to be stored, it is very clear that the ‘level’ of security that it is appropriate

to deploy to protect data relating to, for instance, a sports club membership list is very different that

the level of security that should be used to protect NASA’s control centre. These are two extreme

examples, but the level of security that it is appropriate to apply in an IoT context can be impacted by

a range of considerations, including the potential privacy of data, its commercial sensitivity and also

associated safety and physical security considerations. It is clear that the concept of ‘security’ in the

IoT is not a one-size-fits-all concept, but is a matter of defining a range of protocols that are suitable

for the application in question.

However, irrespective of the level of security that ‘ought’ to be developed for different IoT

applications, the market may dictate that some lower (or higher) level of security must be adopted to

remain competitive. The concept of lower levels of security than are appropriate should be familiar

from news stories that regularly emerge, including details of the latest security breach of private and

confidential customer information. The concept of higher levels of security than are really warranted

tends to emerge more in a B2B context, where purchasing managers want to cover themselves in the

event that any security issues arise.

In summary though, the fact is that implementing higher levels of security costs money (through the

need for better processors in devices, better communications, more software and so on) and can

compromise the user experience (for instance by extending refresh delays). Really, security levels are

simply a component of the relevant product and price point marketing mix. As a consequence, ‘right-

sized’ security should take into account the level of risk and also potential financial consequences of

security breaches (ranging from damage to brand values, risk the risk of getting sued), and consider

these in the context of prevailing market norms.

This presents a clear opportunity for a range of TTPs, firstly in terms of undertaking security audits, or

certifying any third parties to demonstrate that in-place security infrastructure is fit for purpose for

the data that they may be handling. Additionally, such TTPs could advise managers at a company

deploying IoT solutions so that managers can rely on expert external advice in terms of implementing

security solutions, thereby absolving themselves of a level of risk and also allowing for the potential

to insure against the impact of security breaches.

A close corollary to security is the concept of data provenance. Data that emanates from systems with

higher levels of security is generally more reliable than data that emanates from systems with lower

levels of security, and there may also be a role for a TTP to certify the level of reliability of data

provenance of data streams that are published into an IoT Data Bourse environment22, since ‘certified’

data sources are likely to be more valuable than ‘uncertified’ data sources.

22 Please refer to discussion of data provenance in Section 8.2.


48


12.3 TTP role in data trading

It is clear that the Data Bourse role described earlier is another potential opportunity for a TTP to

engage in the IoT space. In fact, there are two clear roles:

The TTP acting as a true exchange for data, providing a central location for the posting and

draw down of relevant information

The TTP acting in a way more akin to a DNS lookup server, and directing queries for data

directly to the providers of that data, and logging the transaction rather than settling the

transaction

Whilst the first of the above roles has the benefits of simplicity, the latter has the benefits of lower

costs, easier scalability and better speed (since data will not transit the actual Data Bourse so it will

need less actual infrastructure). The latter approach also benefits from far greater resilience in the

case of a technical outage.

It is worth noting here that TTPs that support data trading will be another example of the natural

emergence of Subnets of Things. It is easy to envisage that the ‘go to’ Data Bourse for smart city

information will be different from the ‘go to’ Data Bourse for electricity grid information?

This kind of Data Bourse role for a TTP is a natural adjunct for an IoTSM (as described above), and we

expect that many Data Bourses will emerge from that space since data bourse functionality will be

perceived as a first step into monetization of data that travels over the IoTSM.

12.4 TTP role in data analytics

Trusted Third Parties are also likely to have a role in data analytics. To explain why, it is helpful to refer

to BMW again. The following is a quote from Ian Robertson, BMW’s board member for sales and

marketing: “There’s plenty of people out there saying: ‘give us all the data you’ve got and we can tell

you what we can do with it’. And we’re saying: ‘No thank you’.” This is the flip side of the Mr

Frickenstein’s data ownership comments in Section 12.1. Even if BMW do consider data gleaned from

BMW in-car systems as ‘their’ data, they are not minded to share it.

Whilst this approach to the management of potentially private data is understandable (even

commendable), it does run counter to the IoT vision, where data from many different sources is

mashed up in a fairly free and unrestricted way and in pursuit of new efficiencies and new products.

In fact, if the majority (or even a significant minority) of companies aren’t prepared to share their data

in a speculative way in order to mine for possible new data relationships that may unlock new value,

then the development of the IoT as a whole may be seriously hampered.

From Machina Research’s viewpoint, this highlights another potential role for a Trusted Third Party:

undertaking data analytics. The arrangement would be for the data analytics company to subcontract

to the data owner (in this case BMW), and to undertake data analytics under contract to BMW. If

BMW then wanted to explore the possible benefits of mining its data together with data provided by


49


(say) Vodafone, then BMW could negotiate with Vodafone to also provide their information to the

data analytics company (which could potentially contract directly with both BMW and Vodafone).

This approach leads to IoT data analytics being performed in a closed, and retained, environment,

rather than an open environment. When a monetizable data relationship is identified, BMW and

Vodafone can negotiate directly to agree the appropriate financial flows for provision of the relevant

data.

As such data analytics companies become established, it will be possible for the analytics companies

in question to reach out and initiate similar relationships with other data owners. But the key principle

is that these TTPs will perform data analytics on a ‘retained’ basis rather than on an ‘independent’

basis. This is very different to the ‘free love’ kind of data mining that is generally associated with the

Internet of Things, where it is often envisaged that data sourced from multiple parties will be

combined and cross analyzed in an almost unrestricted way.

12.5 TTP role in machine learning

Another potential role for Trusted Third Parties emerges in the context of machine learning. We

explored the concept of machine learning in Section 6, and it is clear that any fully-fledged machine

learning initiative implies devolvement of a certain level of decision making authority to the ‘machines’

in question. The obvious question is then “how much authority to devolve?”

This highlights another potential role for a TTP. It is impractical to expect the managers of any

enterprise (for example, city managers in a smart city, or the operators of an electricity grid) to be

able to take an informed decision about the levels of decision making authority that can be devolved

to machines, and in which circumstances. Such managers also have to consider the concept of risk and

accountability: in most jurisdictions in the world, managers are accountable for the decisions that they

take and, if something goes wrong, have to demonstrate that their decisions were taken with due

care.

A TTP could be well positioned to advise enterprises on the most appropriate approach to machine

learning, and guide the in-situ management team through the process of implementing and managing

machine learning solutions. Besides the expertise that such companies could clearly bring to machine

learning scenarios, there would be two key benefits for any client company: firstly, it would avoid the

need for the development of an in-house framework for the governance of machine learning and,

secondly, it would allow the relevant management team to demonstrate that any machine learning

initiatives had been deployed responsibly.

12.6 TTP role in SLA monitoring, and other potential markets

A final potential role for a Trusted Third Party lies in SLA monitoring. Today’s IT markets are mostly

characterised by SLAs relating to elements of processes (for instance, server availability), rather than

SLAs relating to end-to-end processes and data streams. This is potentially an issue in data trading,


50


where a data user that subscribes to a data stream will need to be comfortable that the SLAs

associated with that data stream are sufficient for the application that they wish to deploy (see Section

8 for more discussion of data provenance).

As a hypothetical example, the managers of a smart city may wish to integrate weather information

into their already existing refuse collection field management solution, and let’s assume that the

application is provided by a systems integrator. Clearly there are many sources of weather

information: IBM has recently acquired The Weather Company, NOAA23 has a weather feed, and so

do many websites including for example www.netweather.tv. In this example, it is fairly clear that IBM

and NOAA will be more reliable providers of weather information, but it’s not immediately clear which

would be more reliable or exactly how reliable they would be. This could be a real problem for a

systems integrator aiming to provide their client city managers with an SLA for solution performance.

In turn, it would be very difficult to attach an SLA to any data feeds that the refuse collection solution

might generate, and which could potentially be built into other applications.

It has been clear for some time that the advent of the IoT offers the potential for a vast array of new

applications to be developed, and that draw on the ‘data exhaust’ of other applications. What the

example above highlights is the IoT application developer’s need to understand the SLAs and QoS

associated with any data streams that they may potentially wish to build into an application.

Again, this highlights another role for a TTP: certifying that data streams can be assumed to be

available with a certain level of QoS could potentially catalyze the development of the IoT.

23 National Oceanic and Atmospheric Administration


http://www.netweather.tv/

51


13 The role of Enterprise IoT

In most analyses of the IoT, the role of ‘Enterprise IoT’ is underestimated. Enterprise IoT is a special

case: since an enterprise can be regarded as a potential ‘Subnet’ of the IoT, the concepts of SoTs and

the IoT become one and the same in the context of an enterprise environment. In short, every

enterprise has the luxury of a single (or, at least, a limited number of similarly motivated) owners or

points of control that can stipulate that necessary connections are built between different data

sources to support ‘IoT’ applications. It is also beneficial that a single entity has full ownership of the

business case for any systems development, i.e. revenues and costs fall on the same P&L.

Clearly, a single enterprise (or group of enterprises) can be relatively agile in its migration to IoT-like

solutions, certainly when compared to the overall development needed to create a fully-fledged IoT.

Accordingly, we expect to see many enterprises at the leading edge of the curve of IoT solution

deployment, but most likely within a Subnet of Things environment. Specifically, we expect to see

enterprises at the leading edge of development in all of the following areas:

Machine learning

Managing the life of data

Fog computing

Engagement with IoT Service Marketplaces

Data monetization

Engaging with TTPs

And since these deployments will often take place in advance of the advent of relevant standards for

a fully-fledged IoT, the best that enterprises can hope for is to implement solutions that are consistent

(or, at least, not inconsistent) with emerging standards. And it is clear that any emerging standards for

the wider IoT will be significantly influenced by the development of de facto standards within an

enterprise context. Additionally, enterprises will establish best practices and push the envelope in

terms of what is possible with the IoT, and will influence and shape the wider IoT agenda.

In summary, enterprises have the opportunity to realize many of the benefits of the IoT before the

advent of the true IoT. But by doing this, and when a critical mass of enterprises start working in the

same way, and to similar standards, then enterprise IoT practices will play a very significant role in

establishing the norms and standards by which the (fully fledged) future IoT will operate.


52


14 Conclusions & recommendations

Machina Research makes the following conclusions and recommendations:

Clearly the difference between M2M and the IoT is very significant. Whilst many participants

in the M2M space have been quick to latch on to the far more fashionable term ‘Internet of

Things’, the reality is that the journey from being an M2M provider to offering IoT solutions is

long and complex.

The concept of being an ‘IoT provider’ can be misleading. The IoT is a concept that exists

independent of any provider, and no single provider can create ‘an IoT’. The best that any

single provider can aim for is to provide services in a way that are ‘IoT compliant’, although

this would rely on the existence of standards (either de facto, or formal).

The term ‘Subnets of Things’ will be far more useful in the foreseeable future. We define

Subnets of Things islands of interconnected devices, driven either by a single point of control,

single point of data aggregation, or potentially a common cause or technology standard.

The Internet of Things will remain something of a mirage for some while yet. It is useful to

analyse and understand the implications of the Internet of Things to ensure that today’s

developments are consistent with an overall evolution to an IoT future, but the reality is that

it is the dynamics of Subnets of Things that will be far more influential for the foreseeable

future.

Ultimately, the difference between M2M and the IoT is one of approach. In an M2M world,

solutions are designed as standalone, isolated, point solutions. Any interaction with an

‘outside world’ must be specifically designed and configured. The default position for M2M

solutions is, effectively, to be a closed system. Conversely, in an IoT world, solutions will be

designed to be potentially integrated into multiple applications. The default position for IoT

solutions will be that information and data can be shared with other applications, with this

sharing capability ‘turned off’ where appropriate.

Machine learning within an IoT context is nearly a reality. We expect significant

developments in this space in the near future. Any such developments will be welcome, since

the application of machine learning to IoT data will be a transformational development for

the IoT. The potential for intelligent agents that identify correlations and implement decisions

completely in absence of human intervention ushers in the potential for (literally) previously

unimagined applications.

Machine learning will need to be well governed. The scope of any machine learning exercise

will need to be well defined and well managed on the basis of delegated authorities and with

ultimate responsibility residing with a competent human.

IoT practitioners will take a widely varying approaches to edge computing and application

agility. In this space, there is no ‘right’ answer, so different providers will take different

approaches based on the IoT application in question, available budgets and access to

hardware and data feeds. We don’t envisage that the debate around what to deploy ‘in the

cloud’ and what to deploy locally will be settled any time soon, other than in some relatively

clear and simple cases.


53


The fragmentation of the IoT environment will drive a need for data intermediaries. We

expect all kinds of middle-men to emerge in the IoT space, all justifying their existence by

combatting fragmentation within different niches.

It will be possible to make money from data. But the oft repeated statement that ‘data is the

new oil’ is somewhat of an overstatement. Some data will be very valuable, and will allow the

owners of that data to extract a monopoly rent. But the vast majority of data will be

undifferentiated in the eyes of any party that might feel inclined to negotiate to gain access

to that data.

There will be many potential roles that Trusted Third Parties can fulfil. A direct corollary of the complexity and fragmentation of the IoT is a need for the services of companies that are expert in different aspects of the emerging environment, and that are prepared to vouch for the services offered by others.

Enterprise IoT is a special case. Enterprises (and their trading partners) form natural SoTs. We

expect that much of the development and standardization required for the full IoT will take

place within an Enterprise context.

You ain’t seen nothing yet. We are in the early stages of a technological revolution. The IoT is

likely to have a far further reaching and more profound impact on our day-to-day lives even

than is envisaged within this report.


54


15 Further Reading

Machina Research recommends the following further reading:

'The M2M/IoT platforms space has evolved into a highly sophisticated environment' (July, 2015)

'The Challenges in Securing M2M and IoT' (June, 2015)

'Nurturing the maker community will benefit software vendors more than hardware' (June, 2015)

'Forecasting the Internet of Things revenue opportunity' (April, 2015)

'Five new priorities transform IoT analytics ' (March, 2015)

'Service Level Agreements in M2M and IoT' (December, 2014)

'Opportunities in Big Data for Mobile Network Operators' (December, 2014)

'Getting the most out of data in the Internet of Things' (September, 2014)

'Standards for the Internet of Things' (July, 2014)

'Why NoSQL databases are needed for the Internet of Things' (April, 2014)

'Competitive Dynamics in the M2M Platform Space' (January, 2014)

'Creating value from data analytics in M2M – the Big Data opportunity' (October, 2013)


55


16 About Machina Research

Machina Research is the world’s leading provider of market intelligence and strategic insight on the

rapidly emerging Machine-to-Machine (M2M), Internet of Things and Big Data opportunities. We

provide market intelligence and strategic insight to help our clients maximise opportunities from these

rapidly emerging markets. If your company is a mobile network operator, device vendor,

infrastructure vendor, service provider or potential end user in the M2M, IoT, or Big Data space, we

can help.

We work in two ways:

Our Advisory Service consists of a set of Research Streams covering all aspects of M2M and

IoT. Subscriptions to these multi-client services comprise Reports, Research Notes, Forecasts,

Strategy Briefings and Analyst Enquiry.

Our Custom Research and Consulting team is available to meet your specific research

requirements. This might include business case analysis, go-to-market strategies, sales

support or marketing/white papers.

16.1 The Advisory Service

Machina Research’s Advisory Service provides comprehensive support for any organisation interested

in the Internet of Things (IoT) or Machine-to-Machine (M2M) market opportunity. The Advisory

Service consists of thirteen Research Streams (as illustrated in the graphic below), each focused on a

different aspect of IoT or M2M. They each provide a mixture of quantitative and qualitative research

targeted at that specific sector and supported by leading industry analysts.

Advisory Service Research Streams [Source: Machina Research, 2014]


56


For more detail on each of the Research Streams, please see the ‘Machina Research Advisory Service

– Guide to Research Streams’ document.

16.1.1 Reports and other published content

Our research content consists of a number of broad categories of deliverable:

Strategy Reports – Extensive and in-depth reports focusing on specific key major themes in

M2M and IoT.

Research Notes – Shorter reports examining key issues and developments in the world of

M2M and IoT.

Application Spotlights – Regularly updated profiles of each M2M application. Each

Application Spotlight comprises Definitions, Drivers & Barriers, Market Analysis, Forecast and

Conclusions & Recommendations sections.

Forecasts – Many of our Research Streams include extensive market forecasts. These are

available through our online Forecast tool.

Research Stream-specific content – Some of the Research Streams have specific content

types, for instance the Regulatory Profiles in the M2M & IoT Regulation Research Stream.

Previous publications – Clients enjoy full access to our library of past publications from the

Research Stream.

Each of the Research Streams includes a varying blend of the above. For details of the specific contents

of each of the Research Streams, please refer to the ‘Machina Research Advisory Service – Guide to

Research Streams’ document.

16.1.2 Strategy Briefings

An opportunity for direct face-to-face interaction between the client and the Machina Research

analysts. Typically a Strategy Briefing will involve a presentation at the client’s premises on a theme

agreed with the client within (or closely related to) the scope of existing research.

There are no Strategy Briefings bundled as standard with any of our Research Streams. These need to

be included as separate items in the subscription.

Relevant travel costs will apply.

16.1.3 Analyst Enquiry

All clients also get direct access to our analysts in the form of enquiries about the published materials

and topics with the Research Streams to which you subscribe.

You may want to request clarification on something within the report, ask for a brief update or pick

our brains on any issue.

We provide clients with unlimited access to our analysts, up to a maximum of one hour per enquiry.

We are happy to undertake more substantial enquiries as custom research.


57


16.2 Custom Research & Consulting

Machina Research’s analysts have a wealth of experience in client-specific consultancy and custom

research. Typical work for clients may involve custom market sizing, competitor benchmarking, advice

on market entry strategy, sales support, marketing/promotional activity, white papers or due

diligence. Subscription clients are eligible to purchase our custom research and consulting services at

discounted daily rates.

For more information on Machina Research, visit our website at http://machinaresearch.com.


machina researchi3forum.org/.../sites/11/...emerging-iot_landscape.pdf · 12/10/2015 · wider iot...

Documents