You need to go one level up and look at the economic situation.
There are a lot of companies that can benefit from IoT tech, but there's this nagging little problem of the cloud layer in the middle.
Let's take the example of a fast-food chain that wants to have all of their refrigerators upload their current temperatures to a central point. (This might or might not be related to something I'm working on) Seems like a simple little technical problem for the refrigerator manufacturer, right? At the physical layer, it totally is. We can drop wifi points and 802.11b radios all over the globe and we're in business. The restaurant chain is happy - the equipment vendor has handled it all and we're on our way.
But now all that data is coming into a server somewhere. And the questions start piling up:
1) Who owns that server? The restaurant chain or the fridge maker? Is the data proprietary?
2) Who is paying for the server maintenance? Who's paying for the broadband connections in every store?
3) Who is going to write the dashboard that lets corp see the nifty graphics about system uptime? Who maintains that? Where does it live?
So should the fridge maker switch to a subscription model and rent out the units? That'll take care of the cost. But if the restaurant is renting the units, then surely the fridge maker should be on 24/7 call to service these units when they fail! Oops, now the fridge maker needs to implement a service team.
This is a holy mess. There are plenty of middlemen popping up to handle the cloud layer like Digi and Exosite. But in the end someone has to write the check and neither side wants to do it. The restaurant wants their food safety data without the added cost. The fridge maker wants to sell units and minimize the support cost.
Companies like Amazon are in a much better position because that Dash button feeds directly into their ecosystem. For the rest of the world, the world that IoT is trying to target, they're still out in the cold.
So, I've been in a variant of the situation. In my version we were the "refrigerator maker" and wanted the data for improved/faster/cheaper service since service costs were eating us alive.
We owned the data. Customers had to sign up for the system, but we got them to do it by offering a lower cost service contract if they did. Since we were a large multinational, we already had an IT department to manage the servers and lots of developers to write code and obviously an existing service team, since that was the whole reason we did it in the first place.
But here's the thing. What I really learned from being the technical lead on that project is that there are growing market opportunities for third party companies to do exactly this and take over the responsibility from the restaurant and the fridge maker. You build the hardware (it's usually pretty cheap and simple) and write the webapp/dashboard, and charge a recurring fee for the service.
It's a lot of work for a one-man shop, but I'm still toying with starting a business in this space.
There's already some competition in this space. Digi and Exosite are two examples I named. There's also Helium, co-founded by Shawn Fanning so they get a lot of press for a solution that (imo) isn't fully complete.
So what makes things more complicated is moving to the next step: two-way data. Let's say it's not a fridge now but an oven, loaded with data pushed down from the cloud by a chef at the restaurant's corporate HQ. Recipes. Holding times. Training videos. I'm not quite sure a major restaurant chain wants this data on a server out of their control. It's something I'm still trying to understand from my customers.
Doesn't the industrial/building automation industry already have solid solutions for your fridge example?
Many buildings already have sensors wired in to PLCs and it's easy to network with the PLC to record and display the signals (for which there are many existing "dashboards" - HMI packages of varying cost and ability).
I don't think it would matter much who owns or maintains the server if you're using a PLC to aggregate your signals onto the network. Many companies are paranoid and would want an in-house server. But it wouldn't be much different to use a cloud based instance.
It's true that existing automation hardware and software are obscenely expensive compared to consumer tech, to the point where renting/subscription might make sense for certain use cases. The systems sufficiently complicated, though, that independent professionals usually manage the setup and maintenance.
That's kind of the dirty little secret here, right? This technology has been around forever, it only became attractive and fashionable lately because the smartphone revolution has dropped the price of radio hardware to the point where it can be dropped into everything/anything.
So now we face the challenge of groups that want Stuttgart-Siemens-PLC functionality for Shenzen-ESP-IoT pricing. Oh yeah, and let's skip all that service contract nonsense. I mean why am I paying $20/month in service for a chip that costs $1.50?
I think you're painting it more complex than it really is. I developed just such a solution for a manufacturer. The manufacturer paid for it and charges the end users for the service and the end user pays for maintenance of the sensors and transmitters. We used a cellular technology (not wifi) from the moving things and its worldwide. And it runs on a utility cloud service similar to Amazon. It's not that hard, really.
The part of the article that addresses data interoperability and databasing on the endpoint (without cloud middleman) is important for use cases where there are ownership issues. The author would no-doubt agree that having to subscribe to a cloud-based gatekeeper middleman, to access the data on the fridge you own, is absurd and against the spirit of the internet.
There are a lot of companies that can benefit from IoT tech, but there's this nagging little problem of the cloud layer in the middle.
Let's take the example of a fast-food chain that wants to have all of their refrigerators upload their current temperatures to a central point. (This might or might not be related to something I'm working on) Seems like a simple little technical problem for the refrigerator manufacturer, right? At the physical layer, it totally is. We can drop wifi points and 802.11b radios all over the globe and we're in business. The restaurant chain is happy - the equipment vendor has handled it all and we're on our way.
But now all that data is coming into a server somewhere. And the questions start piling up:
1) Who owns that server? The restaurant chain or the fridge maker? Is the data proprietary?
2) Who is paying for the server maintenance? Who's paying for the broadband connections in every store?
3) Who is going to write the dashboard that lets corp see the nifty graphics about system uptime? Who maintains that? Where does it live?
So should the fridge maker switch to a subscription model and rent out the units? That'll take care of the cost. But if the restaurant is renting the units, then surely the fridge maker should be on 24/7 call to service these units when they fail! Oops, now the fridge maker needs to implement a service team.
This is a holy mess. There are plenty of middlemen popping up to handle the cloud layer like Digi and Exosite. But in the end someone has to write the check and neither side wants to do it. The restaurant wants their food safety data without the added cost. The fridge maker wants to sell units and minimize the support cost.
Companies like Amazon are in a much better position because that Dash button feeds directly into their ecosystem. For the rest of the world, the world that IoT is trying to target, they're still out in the cold.