The emergence of Data Service Exchanges: liquidity for the IoT 1 Executive Summary M2M applications are at the core of the M2M 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 M2M marketplace is highly verticalised 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. We expect that this more-horizontal perspective on M2M markets will become a dominant theme. Up until now the M2M market has been dominated by industry behemoths. As smaller players enter the market they will naturally look for ways to differentiate by developing specific capabilities. The mass market phase of M2M (and IoT) adoption will be characterised by a more differentiated horizontal first approach. Data Service Exchanges (DSEs) are the entities that will provide the liquidity required to make such a market function. Data Service Exchanges will allow niche providers to easily plug-in to larger and less differentiated service providers (and vice versa). This will usher in a phase of development of the IoT that is characterised by the establishment of an ecosystem of differentiated data service and platform players. Ultimately, products are better than services in the IoT market, and the market will be strengthened when participants play to their strengths. In this, we seek to provide a new perspective on the Internet of Things, characterising it as a network of Subnets of Things. From the perspective of this network of Subnet of Things (SoT) characterisation of the IoT, it is clear that a market opportunity exists for a new kind of data service exchange player. 1.1 Subnets of Things will characterize the IoT 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 1. 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. Current day 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, adjacent Intranets of Things. At Machina, we think that this stage of development will be driven by common ownership of data sources, or common cause amongst the owners of data, and will be characterised by integrated islands of connected devices and other data sources, which we could term Subnets 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 companies engaged in ARM s mbed environment, or the group of companies that use Stream Technology platform. But to move from these Subnets of Things to a full Internet of Things environment will be a difficult step. It will involve aligning data points from a huge range of data sources, ideally at an individual user, or individual device level. This ushers in a range of privacy and standardisation issues. Establishing a fully-fledged Internet of Things will be far harder than establishing simple Subnets of Things. 2 For reference, our definition of the difference between M2M and the IoT is detailed in the Note What s the difference between M2M and IoT?, published September 2014.
1.2 The emergence of Data Service Exchanges Clearly, such an 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 Technology client base SoT, or between Vodafone and the construction industry SoT. This kind of data service exchange functionality has long been a feature of the M2M marketplace, with service providers, systems integrators and platform providers often establishing their own bench of pre-integrated niche data service providers, each contributing specific differentiated capabilities. The fundamental change that is emerging in today s IoT marketplace is the emergence of pure-play DSEs (for example, wot.io) focused on productizing DSE capabilities as much as possible, and positioning these as a standalone differentiated proposition rather than a support act to some other primary business focus. As we have often opined, products will win over services in a fast growing and highly competitive and fluid environment such as the IoT. Clearly, each DSE will have its own corresponding SoT, defined by the commercial relationships that the DSE is engaged in at any given time. Building on the examples that we have mentioned thus far, there will be a wot.io Subnet of Things, which could include any (or all) of ARM s mbed SoT, Stream Technology SoT, Vodafone s SoT and the construction industry SoT identified above. Ultimately, DSEs 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 a DSE include cloud service providers, analytics providers, systems integrators, application creators, hardware companies, and data brokers. There are three closely related benefits that the advent of DSEs will bring: n DSEs will assist the rapid build and scaling of IoT applications utilizing diverse data services by offering a relatively simple route to access a wide range of value-added data services. n DSEs will simplify the integration of legacy systems infrastructure into the IoT through provision of a well-documented, stable and well-managed systems environment. n DSEs wil enhance the potential to share data due to the DSE s unique positioning as a communicator of data between a range of data service providers. 1.3 What kind of entity might potentially offer these services? In order to analyse the market for DSEs, it is necessary to first define a DSE. We use the following definition: a Data Services Exchange 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: n Communities (either open, or curated) n Sales commission based DSEs. n Agency type DSEs. n Wholesale DSE providers. n Value Adding Service DSEs. n Customer Facing DSEs. All of these different potential kinds of DSEs are discussed in the following. We also examine how Subnets of Things will characterize the future IoT environment, and how the emergence of Data Service Exchanges is an obvious next evolutionary step once the concept of Subnets of Things has been identified.
2 Subnets of Things will characterize the IoT 2.1 Introducing Subnets of Things 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 2. 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. Current day M2M solutions can almost be regarded as Intranets of Things : closed environments, with little connectivity outside of the device estate, or solution, in question. For example many homes now have connected smart meters, but the data that these produce is generally used for a single purpose (analysing, pricing and billing power consumption). Likewise, the information generated by fleet tracking systems are generally used to better manage a fleet. And so forth. There are very few situations in which information collected for one purpose is used for a really different purpose, although there are some (for instance mobile operators selling location information to train operators, so that those operators know how many people are on their trains). 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 and services and, of course, adjacent Intranets of Things. At Machina, we think that this stage of development will be driven by common ownership of data sources, or common cause amongst the owners of data, and will be characterised by integrated islands of connected devices, which we could term Subnets of Things. For example, it is not hard to envisage an emerging subnet of things around a smart city: local authorities would often have access to data relating to congestion charging, public transport, parking space availability, air pollution and potentially a whole range of other data sources. It would not be hard for a local authority to analyse these data sources in such a way as to generate conclusions that are informed by multiple information sources. Similarly, a local health authority (or health insurance company) will clearly have access to information derived from multiple sources, and will clearly be incentivised to mine that information to gain new understanding of illnesses. Qualcomm s 2Net M2M health platform (designed to support connected healthcare solutions from many different manufacturers) may potentially be another example. 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 companies engaged in ARM s mbed environment, or the group of companies that use Stream Technology s platform. The key thing to recognise about these Subnets of Things is that the unique qualities 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. But to move from these Subnets of Things to a full Internet of Things environment will be a difficult step. It will involve aligning data points from a huge range of data sources, ideally at an individual user, or individual device level. This ushers in a range of privacy and standardisation issues. Establishing a fully-fledged Internet of Things will be far harder than establishing simple Subnets of Things. 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 1, below. 2 For reference, our definition of the difference between M2M and the IoT is detailed in the Note What s the difference between M2M and IoT?, published September 2014.
Figure 1: Stepping stones to the Internet of Things Internets of Things Intranets of Things M2M applications and enterprise solutions as standalone propositions Subnets of Things M2M applications and enterprise solutions as propositions within an enterprise or functional solution IoT applications and enterprise solutions as propositions deployed within a specific data community IoT applications and enterprise solutions that can seamlessly share data 2.2 How to characterize Subnets of Things Here we focus on two key dimensions of the difference between M2M and the IoT. 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 industry, or, say, different manufacturers of consumer devices 3. 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 ontologies 4 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. 3 For example, AllJoyn: https://www.alljoyn.org/ 4 See Machina Note What s the difference between M2M and IoT?, published September 2014, for a definition.
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. This characterisation of a SoT is illustrated in Figure 2, below. We highlight the texture of an emergent Internet n An OEM SoT, highlighting the likely extent of connectivity within the organization between consumer-facing and internal systems and applications n Vertical specific SoTs (Health, Smart Cities, Intelligent Buildings) n Industry SoTs (Construction) n Data community SoTs, illustrated below by power management, although such SoTs can be expected to be the most numerous and fragmented In all cases the thickness of the red lines connecting the illustrated SoTs indicates the richness of communications between the relevant SoTs. Figure 2: Putting Subnets of Things in a continuum n Open n Everything can connect to everything IoT n Cross enterprise n Cross manufacturer n Within enterprise n Multiple devices from a common manufacturer Scope Subnets of Things n Point solutions n Standalone connected devices IoT Fixed parameters Agility Context and ontologies Diversity of assets Semantic richness of Things in figure 3, below. In this diagram a range of SoTs are highlighted, including: n Enterprise SoTs associated with commercial (and non-commercial) enterprises of all forms Clearly the overall emerging SoT environment will be far more complex than illustrated here, but the diagram serves to highlight the relevant concepts.
Figure 3: Texture of the Internet of Things [Source Machina ] Enterprise SoT Smart Cities SoT Heath SoT Construction industry SoT OEM [Consumer] S0T Power Management SoT OEM [Enterprise] S0T Intelligent Building SoT
3 The emergence of Data Service Exchanges 3.1 Introducing the Data Service Exchange (DSE) Clearly, such an 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 Technology client base SoT, or between Vodafone and the construction industry SoT. Figure 4 below illustrates how a DSE might work in practice. A DSE 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. Figure 4: A Data Service Exchange function can catalze development of the IoT Enterprise SoT Smart Cities SoT Heath SoT Construction industry SoT Data Service Exchange OEM [Consumer] S0T Power Management SoT OEM [Enterprise] S0T Intelligent Building SoT
3.2 The services that a Data Services Exchange might offer So far this has focused on the concept of DSEs 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, DSEs 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 a DSE include: n Cloud service providers, including enabling providers of data storage (and a range of other services) to access a host of potential clients. n Analytics providers, including enabling providers of enterprise big data and analytics services to easily access end-user enterprises. n Systems integrators, which could use DSEs to leverage productized solution components with minimal integration to client-specific solutions. n 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. n 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. n 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. Figure 5: Data Services Exchange scope of services [Source: Machina ] Cloud service providers Analytics providers Systems integators Application creators Data Service Exchange Hardware companies Data brokers
4 Data Services Exchanges will fundamentally impact IoT ecosystems So far in this white paper we have described the basic role that a Data Service Exchange 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 that the advent of DSEs will bring. These include the potential for: n Assisting the rapid build and scaling of IoT applications utilizing diverse data services n Simplifying the integration of legacy systems infrastructure into the IoT n There is significant potential to share data within a DSE Each of these is discussed in turn in the following subsections 4.1 Assisting the rapid build and scaling of IoT applications utilizing diverse data services A DSE 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 a DSE 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 solution would typically build interfaces to third party service providers on an as needs basis. Key partners might include: n A billing provider that can rate and generate invoice information from billing data records. n An analytics provider to allow the utility greater insight into customer usage. n 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 a DSE 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. 4.2 Simplifying the integration of legacy systems infrastructure One of the key aspects of a DSE is that a DSE must be underpinned by a well-documented, stable and well-managed systems environment. This is an essential capability, since the key competence of a DSE 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 a DSE can potentially provide an effective route for companies that operate legacy systems infrastructure to get plugged in to the IoT. Firstly, a DSE can provide a well-documented and stable environment to connect into. Secondly, once the necessary interfaces have been built to connect legacy systems into a DSE environment, the original legacy systems owners will immediately be able to avail of all the data services offered by that DSEs 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 DSE. Clearly building connections to a DSE 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.
4.3 There is significant potential to share data within a DSE On a fundamental level, a DSE 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, a DSE 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 DSE will take this role in support of many clients and many IoT applications. Accordingly, DSEs will potentially support the communication of a very wide range of application data for a wide range of applications and users. As such, a DSE 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 a DSE opting to share more data within the DSE environment than is strictly necessary for the support of the specific IoT application portfolio operated by the client in question. This dynamic results in DSEs becoming the natural environment in which data trading will ultimately begin to gain traction.
5 What kind of entity might potentially offer these services? So far in this white paper we have discussed the emergence of Subnets of Things, and the role of Data Services Exchanges in intermediating between these SoTs and also providers of IoT services. Having established that there is a market opportunity for a DSE-like entity, in this section we explore how such an entity might be commercially positioned. 5.1 Data Services Exchange market overview In order to analyse the market for DSEs, it is necessary to first define a DSE. We use the following definition: a Data Services Exchange 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: n Communities (either open, or curated) which can act as shared repositories of standards, APIs and policies and protocols. n Sales commission based DSEs that may secure a finders fee for arranging and enabling a commercial relationship between two entities in the IoT. n Agency type DSEs that invoice users of IoT-services on behalf of service providers according to pricing agreed with such providers. n Wholesale DSEs 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. n Value Adding Service DSEs that seek to differentiate by adding services on top of a standard Wholesale positioning. n Customer Facing DSEs 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 DSEs 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 DSE. Firstly, both open and curated community DSEs. 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 DSE will be exposing itself to significant counterparty risks, particularly in the case that the DSE in question ceases to trade. If this happens, then any solution components provided by, or supported by, the DSE in question will become unsupported and may potentially cease functioning. Such DSEs 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 Dad Distribution Service (RTPS DDS standards. Sales commission based and Agency based DSEs 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 DSE services into business critical IoT solutions without anywhere near the degree of counterparty risk as would be inherent in the case of community DSEs. These types of DSEs 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 a DSE provider ceases trading. However, given that sales commission and agency-style DSEs 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 DSEs make a little, or no, contribution to simplying the business and legal processes that a potential user must navigate when establishing agreements with data service providers. Whilst C3 energy is a niche example of an agency based DSE focussing on buying and reselling energy data. It is worth focussing on wholesale DSEs, since these are the simplest to implement and the most product-focussed of a group of DSEs that have some very significant advantages. First of these is accountability. Contracts for provision of services will lie squarely with wholesale DSEs, allowing the DSE to present a far more homogenised and simplified commercial (business and legal) proposition to potential users. Such accountability also allows wholesale DSEs 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 a DSE (not just the level of spend with a single DSE partner, as is the case with sales commission and agency DSE approaches). The wholesale DSE 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 DSE. Both VAS and customer facing DSE 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 DSE spectrum begins to merge with the already well-established M2M/ IoT Application Platform market characterised by the likes of IBM s BlueMix. Effectively, these companies are DSEs by default rather than design: the development of a range of data Figure 6: Different approaches to the provision of Data Services Exchange capabilities 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 DSEs may potentially outsource the provision of actual DSE capabilities to a wholesale DSE: such an arrangement would allow VAS and customer facing DSEs to focus on developing end-customer solutions, without having to provide the required underlying DSE capability themselves. Potentially, systems integrators may also occupy this market positioning by re-selling the DSE capabilities of a third party DSE. Lastly, it is worth observing that Agency, Wholesale, VAS or customer-facing DSE arrangements can potentially allow the DSE to access the data that flows over their infrastructure. Whether such DSEs 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 DSEs to monetize customer data. We illustrate these dynamics in figure 6 below. Open community Curated community } n Free to end users n Counterparty risks Sales commission Agency Wholesale VAS Customer facing } n Revenues n But risk of disintermediation n Or tactical use n Competition from niche providers n Accountability n Simplified commerical proposition n Billing requirement (and some!) n Bulk breaking/scale advantages n Rate negotiations n Pricing structure flexibility n Ability to direct business n Data, ownership (at least, intermediation)
5.2 Specialisation within the Data Services Exchange market The next question is: which types of DSE will prevail, and in which situations. We have already alluded to the suitability of different kinds of DSE 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 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, DSE providers with significant cashflows make for significantly better counterparties than DSE providers without such cashflows. Additionally, DSEs that position 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 DSE market will lie with wholesale DSE providers. Such providers may also establish VAS or customer facing channels, or may engage partners to resell their vanilla, productized, DSE 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 DSEs: n Agency and commission based DSEs establishing as niche portals, with specific (industry or functional) specialisation n Community DSEs that catalyse the leading edge development of specific niche markets or propositions n Supply-side funded DSEs 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 n Resellers of DSE capability n Aggregators of DSEs (or DSEs of DSEs) Another consideration is that DSEs are likely to adopt different roles within different environments. For instance, within the context of a smart city, a DSE 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 DSE in the consumer health space is more likely to skew towards supporting and enabling a market for service provision, whilst a successful DSE 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 a DSE with a specific specialisation, or market positioning, itself becomes another SoT that can potentially be integrated into another DSE.
6 Conclusions It is clear to us that the IoT space will be characterised for some time by Subnets of Things, typically driven by either a single point of control, single point of data aggregation, or potentially a common cause. Where there is business case justification, connections and interfaces will be built between different sources of data and between different owners of data. Over time these connections will become more and more numerous, assisted by the development of standards (de facto, or actual) and Subnets of Things will emerge. Whilst developing applications that draw on a range of data sources from within the same SoT will become easier over time, the connections between different SoTs will remain far less developed. Specifically, the range of potential clients for any putative provider of IoT services will remain fragmented in terms of technologies, standards and protocols. Into this gap will step a new kind of provider in the IoT space: the Data Services Exchange (DSE). The role of a DSE is to abstract out all of the fragmentation that exists in the IoT and also to facilitate the provision of a wide range of IoT data services. Some DSEs will focus on abstracting out technical fragmentation, whist others will focus on abstracting out both technical and commercial fragmentation. Clearly no DSE will ever be able to abstract out all of the fragmentation in the IoT space, but this is the main basis on which DSEs will compete at least initially. The advent of such DSEs 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 DSE 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. DSEs are likely to have a significant impact on the development of the IoT in coming years.
7 About Machina Machina 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: n Our Advisory Service consists of a set of Streams covering all aspects of M2M and IoT. Subscriptions to these multi-client services comprise Reports, Notes, Forecasts, Strategy Briefings and Analyst Enquiry. n Our Custom 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. 7.1 The Advisory Service Machina 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 Streams, 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. 7.1.1 Reports and other published content Our research content consists of a number of broad categories of deliverable: n Strategy Reports Extensive and in-depth reports focusing on specific key major themes in M2M and IoT. n Notes Shorter reports examining key issues and developments in the world of M2M and IoT. n Application Spotlights Regularly updated profiles of each M2M application. Each Application Spotlight comprises Definitions, Drivers & Barriers, Market Analysis, Forecast and Conclusions & Recommendations sections. n Forecasts Many of our Streams include extensive market forecasts. These are available through our online Forecast tool. n Stream-specific content Some of the Streams have specific content types, for instance the Regulatory Profiles in the M2M & IoT Regulation Stream. n Previous publications Clients enjoy full access to our library of past publications from the Stream. Each of the Streams includes a varying blend of the above. 7.1.2 Strategy Briefings An opportunity for direct face-to-face interaction between the client and the Machina 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. 7.1.3 Analyst Enquiry All clients also get direct access to our analysts in the form of enquiries about the published materials and topics within the subscribed Streams. 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. 7.2 Custom & Consulting Machina 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, visit our website at http://machinaresearch.com