In this honeymoon period of pilots and small-scale enterprise IoT deployments it is easy to underestimate the impact of IoT at a ubiquitous global level similar to the World Wide Web. Without the use of Open Source software the Web could not exist, individual software licensing in a traditional manner, as with commercially differentiated products, is simply impossible. The Internet of Things requires the same level of ubiquitous common access in its core functions, and, as with the Web, successful use is dependent on the successful creation of Open Source based shared accessibility.
It is a fact that these initial IoT deployments will be expected during their service life to connect to, and play their role, in the global integration of billions of Devices, Assets, Sensors, and End Points. Consideration of how to exchange and interpret huge volumes of data split between millions of Services operating at a myriad of locations across the planet has to play a part in current choices.
An IoT Platform acts as an intermediary layer between the IoT Devices, or Endpoints and the Services that consume the data outputs. In simplistic deployments each sensor may be directly coupled to the consuming Service, but increasing each IoT Endpoint is connected to several services, and may not even share the same data with all of them. A heat sensor may at one threshold initiate the heating, and at a different threshold start air conditioning plant. An IoT Platform offers the sophistication in End Point management to be able to control these and other issues.
Additionally, the role must also include complex integration of Data Flows with Protocol and Network differences being assimilated before forwarding to the required/selected Service. This part of the role is more inline with the accepted definition of Middleware whereas an IoT Platform will be more focused on IoT Endpoint management, though both will share the same definitions in other respects.
The technology requirements for Web Presentation are simplistic compared to the functional Integration required for the ubiquitous interactivity of Internet of Things. No Enterprise Middleware product was ever designed for this purpose, more importantly the new generation of commercial Enterprise IoT Platforms are not intended for this task either. There is a crucial difference between ‘Public’ and Enterprise IoT Platforms, which really should be thought of as IoT Middleware.
Just like the Web there is a crucial difference between the Public domain with its ‘any to any’ ubiquitous capabilities provided by using Open Source and Standards to eliminate differentiation, versus the enterprise side, where competitive differentiation is created. Business use of the Web for competitive success is dependent on the differentiation in the higher-level functions above the presentation and transport layers, and here commercial software wins the Enterprise market.
IoT with its ever increasing range of functions, and capabilities across a multitude of sector deployments goes beyond the level of sophistication Open Source IoT Platform projects are currently aiming to provide for Public domain use. Open Source IoT Platform and Middleware projects can expect years of development to remain in tune with the capabilities of commercial software products that are constantly upgrading their capabilities with new functions.
Successful early entrant commercial IoT products that score wide spread adoption often aim to become ubiquitous by offering their core functions as Open Source. As a recent example Z-Wave, a widely adopted IoT Home Automation wireless connectivity product shipping claiming 35 million units shipped since 2005. The speed of development of Z-Wave capabilities in comparison to the various Home Automation standards groups of leading global Home Product manufacturers illustrates the difficulties of consensus standards or open source projects.
The advantages of a commercial implementation also lie in speed of reaction to problems, particularly in Security. The speed with which Z-Wave were able to add new functionality to their core product to overcome security risks from badly implemented developers extensions back in 2013 also draws attention to the difficulties facing Open Source Middleware platforms in managing constant updates.
IoT Platforms have to perform a wide variety of complex functions, these were outlines in the blog ‘What is an IoT Platform? And why does it need an AoT engine?’ In a Public Open Source IoT platform there are some very new core issues to be addressed, before any consideration of the advanced, or specialist, requirements that Enterprise IoT Platform add.
The logical architectural conclusion is that Enterprises will use a commercial IoT Platform chosen for its specific features and capabilities to gain competitive advantage in tandem with their connection to an external Open Source IoT Platform to gain ubiquitous access to the overall market.
IoT Platform are complicated if they are to offer the functionality required in serious deployments as an April 2016 a survey of IoT Startups made clear. Using information on funding released by Seed and Venture funds it was only possible to identify 14 startups aiming at the IoT Platform market. The preponderance of US based funding means that this list is incomplete as it really only covers the USA market, but it’s the comparison in numbers to the hundreds of IoT startups that were identified in the same report is revealing.
IoT Platforms are the new ‘Middleware’ without which IoT cannot scale, either in the public domain sectors, or smart cities, deployments. But then neither can IoT deployments in Enterprises succeed without their own IoT Platforms, unfortunately with different functional specifications. The low number of players and the lack of any dominance illustrate the complexity of this requirement definition conundrum.
IoT Platforms are often called the 4th Generation of Middleware following; 1) ETL - Extract, Transform and Load; 2) SOA – Service Oriented Architecture and 3) Enterprise Service Bus; and iPaaS – Integration Platform as a Service. The lack of a defining name and functionality description makes classification of 4th Generation IoT Platform/Middleware products very difficult!
As it is difficult to do much about naming conventions, it is better to concentrate on defining the key functions using the headings below defining fundamental core capabilities;
- IoT Endpoints; connection management at scale is challenging, but the real task is to provide IoT Endpoint Integration. Though this might be considered the most important fundamental requirement, it’s poorly addressed in most IoT Middleware/Platforms as the ‘final mile’ challenge of diversity of devices, protocols, network types, etc. requires wide ranging expertise in development. IoT Endpoint Management adds the requirement for data flow management as well as the usual physical connection management. (see blog iot-and-network-connectivity-management-or-aot-and-data-flow-management-network)
- IoT Asset Management; an extension of IoT Endpoint management is the maintenance of an ‘Asset Register’ for all connected IoT devices. The Asset Register provides all the necessary details on the IoT Endpoint from Security Privileges to definitions of Data provided; as well as critical contextual details on the Endpoint such as location, functions, etc. required as background data for intelligent processing of ‘events’. (see blog – new one on Assets that also includes connectitivy issues)
- Security; at the first level defined by points 1 & 2 above there should be encryption and spoof detection in the connection. Supporting this function in small cheap battery powered sensors is almost impossible so the IoT Platform Middleware has to act as a ‘gatekeeper’ for the connected Endpoints. The ‘flat network’ map of connections requires reordering into series of virtual secure data networks aligned to different groupings; Enterprises, Activities, Services, Apps etc. Beyond these fundamental tasks it is possible to identify a huge number of desirable capabilities that will be included in time.
- IoT Protocols; due to the range of vastly differing requirements that IoT Endpoint devices introduce that are unlike the demands of IT devices new specialized protocols have appeared. These cover all aspects of protocols from communication to payload and as multiple endpoints using different protocols may have to be aligned to orchestrate an event an IoT Platform must be able to freely integrate both IoT Endpoints with Apps, Services and traditional Databases. (see blog https://www.constellationr.com/blog-news/final-mile-part-2-complexity-io... )
- Data Flow Management; a significant part of the value of IoT is to ‘read and react’ with an optimized response in near real time. This requires an IoT Platform/Middleware to quite literally read a continuous data stream to determine forwarding actions as well as contextual alignments and relationships with IoT Asset or other forms of Stored Data. This is distinctly different from many forms of Data Analytics, which perform deep analysis on batches of data. (see blog https://www.constellationr.com/blog-news/challenge-final-mile-asset-digi...)
- Message Management; is recognized in traditional Middleware as a core activity to overcome differences in latency and time stamps to ensure messages are processed in the correct order due to the transactional nature of the data. IoT message management is less concerned with the rigid structure and more concerned with dynamic flexibility of Service to accommodate extreme variation in volumes of message as event trigger and reactions create sharp changes in volumes.
- Real Time Integration; The dynamics of the constantly changing environment of IoT contrasts directly with the stable fixed connections of a traditional Middleware solution. IoT Endpoints may physically, or virtually, connect and disconnect, and even when connected will create dynamic changes in data flows. Add Data Flow Management as to where and how the incoming stream will be directed into orchestrated Services integration to understand why previous generations of Middleware bear little resemblance to IoT Platforms/ Middleware. (see blog https://www.constellationr.com/blog-news/iot-where-two-or-even-three-pos... )
- Other Features; are being added to the minimum working capabilities of IoT listed above as increases use of IoT introduces new Business solution requirements. Two examples are more interaction between various forms of AI and the IoT platform to increase the intelligence of ‘read and react’; and the need for dynamic recognition and registration of embedded IoT Devices. Any IoT Platform/ Middleware will need to be designed and implemented in a manner to be upgraded whilst still working in a non-stop manner as well as support graceful fail over.
The above eight functions represent a demanding, but nevertheless fundamental set of basic requirements for the evaluation of IoT Platforms/Middleware. Amazingly many Platforms are weak on the core task of Endpoint Connection, Asset Registration and Associated Security management. None of these capabilities are currently present as a significant capability in any of the following Open Source projects listed below. Instead the focus has been on Middleware integration for public domain deployment. The listed commercial Enterprise Platforms are more attuned to the necessity in an Enterprise deployment to handle more sophisticated management and control capabilities.
When considering commercial IoT Platforms it is difficult to analyze the entire market as there are many small relatively invisible players, but only nine IoT Platforms seem to claim IoT Endpoint management. Three of these originate from Industrial Automation, three from major IT vendors, which in each case creates a natural focus on working with the existing markets of the vendors. This leaves just three Startups aiming to provide a full independent Enterprise IoT Platform with sophisticated features that will support heterogeneous deployments.
NB. The focus on the characteristics of IoT end point connectivity management and integration management of resulting data flows removes many well-known IoT solutions from contention. Many big name and well-known IoT products/services may provide some ‘connection management’, but this is to deliver their prime purpose of a direct Business valuable outcome. The choice to separate in this manner is to identify the difference between using Platforms/ Middleware as ‘infrastructure’ from Services that provide direct business value and make use of Infrastructure functions. Many IoT Business Solutions do offer some degree of Connectivity management, but only to gain data flows for their processes, not to offer Heterogeneous infrastructure for other Services.
The list below is in alphabetical order and does not intend to suggest any ranking, those selected offer both significant scalability and ambition for the role, and been the subject of Constellation Research Clients queries. It is not meant to be an exhaustive list, but to draw attention to the features of a selected group of Platforms/Middleware products as a means of defining the necessary capabilities. A wider listing with characteristics of a large number of products that lay claim to being Platforms can be found at http://www.postscapes.com/internet-of-things-platforms/
Five Open Source IoT Platform Projects
HortonWorks (linked with Apache NiFi)
Kaa
microServicesbus.com
Apache NiFi
OpenRemote
Three IoT Platforms developed from Industrial Automation/Telecoms
Bosch IoT Suite
Ericsson Device Connection Platform
Plat.One IoT & M2M (by SAP)
Three Major IT Vendors
AWS IoT Platform (includes 2lemetry)
IBM Watson IoT Device Cloud
Cisco IoT Cloud Connect
Three IoT Platforms Developed for Enterprise Use by Startups
Summary;
The whole business case for IoT Technology adoption rests in the accessibility of new data by managing connections to an immense new range of new Devices. Specifically business value lies in the collection and integration of the data to drive a new level of competitive Services and responses. Both endpoint connectivity and data integration require extensive Middleware functionality supported by a new generation of ‘IoT Platforms’.
However there is a distinctive difference between the Middleware that provides the undifferentiated ubiquitous Open Source Platform/ Middleware to interconnect ‘Public’ IoT endpoints, and the requirements of an Enterprise. Commercial IoT Platforms/ Middleware are required to be rich in capabilities to create competitive differentiation as to how an Enterprise ‘reads and reacts’ to opportunities through orchestration of its IoT Assets, and Smart Services.
Enterprises should follow the Open Source IoT Platform initiatives to gain access to as many sources of data as possible whilst recognizing that their own deployment of a Commercial IoT Platform is essential to gaining the competitive advantages that IoT enables in Digital Business.
