soccer dad, technologist
Over the past two years, I have spoken with technical folks, salespeople, and executives at more than 100 IoT-related companies, and I have learned two things: 1) IoT is huge, 2) almost everyone defines IoT differently.
In this article, I share what I have learned about IoT platforms and one way to categorize and think about them.
IoT is much more expansive than what most of us think of as the traditional Internet. It is growing faster too. There are more devices, protocols, security concerns, RF frequencies, architectural components, services, data, and related products. IoT is massive and broad.
As such, the term ‘IoT Platform’ is really too broad to be useful to most people. I outline an example IoT platform below, but, in some regards, the concept of an ‘IoT Platform’ is about as meaningful as an ‘Internet Platform’ circa 2004. In fact, IoT has a lot more moving parts.
One of the most challenging parts of many IoT projects is managing the hardware devices. This primarily means safely provisioning, maintaining and updating sensors and edge devices. Accordingly, much of the IoT literature (and many new products and startups) is centered around the communication between cloud-based UIs, edge devices, and sensors — MQTT, security keys, OTA firmware updates, RF frequencies, et al.
Consider the value chain chart below I created which shows where some common IoT technical components fall on their life cycles. Components on the lower left of this graph are changing so rapidly it is hard for IoT platforms to manage them consistently.
One of the most important jobs for an IoT platform is to make it easy to provision, update, and manage lots of devices and to keep everything secure. As you will see, platforms have a long way to go in this regard and the reason lies in where these activities fall on their life cycles.
Once the data makes it past the edge and into the cloud, however, IoT projects become more familiar (in theory; more about this in a minute). Data flows to an API endpoint and is stored in the cloud (typically). So a platform should help stream and load potentially massive amounts of data into a data store and facilitate the retrieval of this data. Since AI and machine learning can be important to IoT solutions, platforms should also implement algorithms wherever they are needed (edge, cloud, device, client). Finally, creating and managing dashboards or ‘Single Panes of Glass’ can be an important part of an IoT project. Platforms should help connect dashboards to data.
There are many other components and activities too but those are some common ones.
It is still early for IoT platforms. For example, there are no Industrial IoT platforms in the Gartner Magic Quadrant yet. And according to Gartner’s Hype Cycle for Emerging Technologies, IoT platforms have just passed over the Peak of Inflated Expectations and are careening towards the Trough of Disillusionment.
As bad as that sounds, now is actually the best time to select your IoT Platform if you are thinking strategically and want to gain a competitive advantage. Otherwise, it’s the worst time. Entering a highly fragmented and confusing market with inflated expectations and no strategy does not bode well.
In other words, if you are an early adopter, proceed with care but don’t expect an IoT platform to do much on its own without a lot of time and effort. If you’re a laggard, by the time you’re reading this, you can just ask your Amazon Robot to build your platform for you.
The IoT market is complex and highly fragmented. However, the cloud market which has the most influence over the IoT value chain is not fragmented. The top 3 cloud service providers (CSPs) comprise around 80% of the market by revenue run rate (CR3 is 0.792). This creates an interesting dynamic which I discuss later.
This market fragmentation means that the components and products that make up any particular IoT solution are highly sensitive to that project’s specific requirements. The best components available to build one system will likely vary widely from those available to build another. This will not always be true, but it is true today. As an example, below is a value-chain graph I did which includes the companies/products that are being considered for one large industrial IoT project. This graph is 10 months old and 30% of it is already outdated for the project.
If we define an IoT Platform as anything on which you can build and operate an IoT Solution, then at this high level of abstraction, there are basically two platform categories:
*CSP — Cloud Service Provider
**most IoT platforms are built/focused on cloud infrastructure even when they have on-prem options; many IoT platforms claim to support multiple CSPs even when they have a partnership with one CSP
The three largest cloud servicer providers are Amazon, Microsoft, and IBM. These (3) providers comprise almost 80% of the market and have a $52 billion revenue run rate (Dec 2018). Each CSP offers its own IoT platform:
Other notable CSPs — Oracle, Google, and Alibaba — also offer IoT platforms.
Next, there are IoT Platforms that are built on top of CSP infrastructures. There are hundreds of these platforms and they are offered by large and small companies alike. Consider the following IoT platforms and the CSPs with which they have partnered:
Industrial IoT Platforms:
Some other specialized IoT Platforms:
Smaller, specialized IoT Platforms:
CSP IoT Platforms offer a broad and highly flexible set of services and components which can be used to build almost any IoT solution. If you have the time, budget and resources, CSP platforms offer the basic building blocks.
Specialized IoT platforms are supposed to accelerate time-to-market and serve as outsourced expertise in verticals and specific applications. The smaller, specialized IoT platform companies tend to operate in a few verticals and are focused on products whereas the larger, specialized IoT platforms, such as GE Predix and Siemens Mindsphere, offer market-level platforms geared towards entire industries, such as Industrial IoT Platforms.
If platforms were Legos, CSP IoT platforms would offer small Lego bricks
and specialized offerings would offer pre-assembled sets of legos.
That’s the theory, at least. In reality, it doesn’t work like that. First, the CSPs keep changing the legos. More on that in a minute. Second, specialized IoT platforms are not sufficiently tailored to verticals to offer many advantages. They are too general. Often, they are developed around specific needs for one or two large clients and then marketed as platforms when actually they are simply applications built with typical CSP stacks that can be extended through development efforts for your project. Basically, they just code your project for you using the similar ideas and architectural components they used to develop the initial codeset. It has to be like this right now. You will see why in a minute.
CSPs control the IoT value chain and are disrupting the companies built on top of them. For example, at re:invent in November 2018, Amazon announced a new time series database called TimeStream. Time series databases handle loading and reading IoT data better than generic databases. Before TimeStream, if you wanted a time series database on AWS, it would have been necessary to run a third-party product, such as Prometheus, on EC2 (Linux) in AWS and manage it yourself. (TimeStream is only currently available in early release; Jan 2018)
In 2018, I spoke with more than 30 companies who had built their specialized IoT platform on AWS. Most of these companies use MongoDB, DynamoDB (a fully managed AWS NoSQL database), or AWS RDS (mostly Postgres, MySQL, or Oracle). Some of the people I spoke with, even technical folks, had never heard of a time series database. Others complained that AWS did not offer one and that AWS IoT Analytics was too much of a black box to develop around. Either way, most vendors ended up writing complicated logic in the code to compensate for the lack of a time series database.
The TimeStream announcement immediately obviated large swaths of these IoT platform architectures and, at the same time, made it easier for new platform entrants to enter the market. This is what’s known as cloud service providers moving up the stack. It is highly disruptive to companies built on top of CSPs and their customers. It is something you should be aware of when you are selecting your IoT Platform. The CSPs will continue to encroach on specialized platforms.
Some executives I have worked with intentionally treat third-party software as a black box and ignore the components that comprise it. The software is treated as a financial asset, such as a truck or a warehouse, that has a cost, utility, depreciation or operational expense, and can be readily replaced with a quantifiable amount of money, time and internal resources. In my experience, this approach can work well for commoditized software solutions, such as HR, sales, and accounting systems, but it is not the best way to approach IoT platforms right now.
Emerging technologies, such as IoT platforms, should be treated more like strategic partnerships than assets or commodities because time and expense predictions for technology projects, in general, are abysmal. (I wrote about this in a previous post.) For emerging technology projects, they are worse than abysmal. If you can’t quantify expenses accurately, then it doesn’t make sense to treat third-party software as an asset. The salvage value is usually negative anyway.
As CSPs continue to move up the stack, dependent platforms will be forced into a smaller and smaller technical arena. At the same time, it will become easier to implement IoT solutions on CSP platforms. This means the value of a specialized IoT platform, if it exists at all, will be in vertical expertise. Fostering this relationship can help create a complementary asset that helps protect and grow your long-term IoT initiatives.
The end. There will be a second article. See here.
Want to chat more / have an interesting proposal? Contact me at email@example.com