machina researchi3forum.org/.../sites/11/...emerging-iot_landscape.pdf · 12/10/2015 · wider iot...
Post on 11-Aug-2020
0 Views
Preview:
TRANSCRIPT
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
3
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
4
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
5
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
6
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
7
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
8
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
9
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
10
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
11
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
12
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
13
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
14
Machina Research//Strategy Report © Machina Research, 2015
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/
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
15
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
16
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
17
Machina Research//Strategy Report © Machina Research, 2015
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?
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
18
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
19
Machina Research//Strategy Report © Machina Research, 2015
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).
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
20
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
21
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
22
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
23
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
24
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
25
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
26
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
27
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
28
Machina Research//Strategy Report © Machina Research, 2015
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/
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
29
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
30
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
31
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
32
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
33
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
34
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
35
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
36
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
37
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
38
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
39
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
40
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
41
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
42
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
43
Machina Research//Strategy Report © Machina Research, 2015
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..
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
44
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
45
Machina Research//Strategy Report © Machina Research, 2015
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/
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
46
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
47
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
48
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
49
Machina Research//Strategy Report © Machina Research, 2015
(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,
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
50
Machina Research//Strategy Report © Machina Research, 2015
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
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
51
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
52
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
53
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
54
Machina Research//Strategy Report © Machina Research, 2015
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)
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
55
Machina Research//Strategy Report © Machina Research, 2015
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]
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
56
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
57
Machina Research//Strategy Report © Machina Research, 2015
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.
Report licensed to Telefonica. Downloaded by user 'laura1.fariaaunon@telefonica' on 2015/12/10
top related