The discussion around IoT has been around since last 5 years. Take those 2020 projections to the table, and see how many have quoted them as the moment of truth for IoT. But those projections and data remained as it is in 2018 with mass adoption yet to become a reality.
As an IoT practitioner what amazes me is why only a handful enterprises and products have made it so far.
The undeniable truth about IoT is that it definitely brings huge competitive advantage to the table for consumer products and enterprises. While scaling IoT and building LPWAN networks that had more than 100,000 nodes we say more than just connectivity, we saw revolution, we saw how fast we could reduce “revenue leakage”, we saw how fast we could bring “disruption” to the table and we definitely saw business models that were never seen before.
The moment of Truth for me in IoT was when I built an LPWAN network that was more efficient than a six sigma process - That’s how powerful IoT really is!
But, let’s get to the point, what I really said before are the results. There are so many steps to actually reach there. When I take lessons from the software world, there’s something called “First mover’s advantage”, well that changes when it comes to IoT.
First movers fail, that too miserably. First movers for the most part are someone that fail and create a path for others.
So, what is it that makes adopting IoT so difficult?
Unfamiliar territory for business buyers
How many enterprises do you see that still run on managed data centers and legacy apps? Why do you think they aren’t adopting amazing next generation cloud technologies? Now put IoT at the center stage and try to understand this. At minimum there are three technologies that need closer inspect for any IoT implementation in enterprises: Cloud, hardware and wireless technologies.
Cloud has evolved and maturity is good enough to make sure that the adoption remains streamlined. But even with a mature technology, IoT use case challenges all forms of our existing cloud connectivity models.
As far as hardware is concerned, the last 30 years of manufacturing and other core engineering industries have been working, we have seen mass adoption of close sourced hardware in form of PLM and other technologies. With such a heavy industrial adoption, closed source tech has associated heavy costs even with minor pivots. This created agility issues that are difficult for industries to look through as they can’t simply throw away their entire infrastructure.
Open source tech has been influencing and driving IoT since last 3 years. But majority of our core engineering industries have largely been unaware of how open source tech works. There are potential pitfalls and immense opportunities with open source tech that software world has been extensively leveraging. But with hardwares, everything has a cost or license associated with it. With this closed nature of hardware industry, it gets difficult to customize off-the-shelf products to match with specific process or innovate on top it.
Nobody, absolutely nobody has figured this out yet. No matter what you implement can be broken down, or at least blocked to create service disruption. Internal processes being disrupted is one thing, but what’s even more damaging is your IoT product/service compromising customer’s privacy.
It was until 2015, when we shifted IoT communication security from 64 bit encryption to 128 and then to 256 bit encryption. OWASP has established some best practices and awareness around IoT security, but as I said before this has been a largely the biggest factor preventing IoT adoption in enterprises as well as consumer facing products.
Extremely painstaking product development
Lack of understanding of how IoT technologies work, how IoT product development should be done, and how the costs of product development should be controlled, etc makes IoT product development a discouraging step for many enterprises.
The technology fragmentation and lack of standardization further increases the pain that C-suites have to go through when they implement IoT programs.
For example, we were in middle of implementing a mesh network based out of Zigbee back in 2015, when we meet folks from Bluetooth SIG and nRF that hinted us towards an upcoming mesh network on nRF’s stack.
We saw the subsequent release in 2016, with an extremely easy to manage and govern stack. Point being that these technologies are evolving faster than ever, while the opportunity window seems to be shrinking as the technologies mature as well. So, it really boils down to risk vs opportunities and tons of fragmentation and vagueness ahead of it.
The way we have been building connectivity in the last 2 decades was dependent upon wireless, and built for a local-on-premise infrastructure. That had its benefits before Industry 4.0, but now things have changed.
“If you can connect it, you can improve it”
But we never built anything for low power and wireless connectivity. What we built was supposed to talk over RS232s, USB serial or PLCs.
I have met enterprises that have invested more than $20M and can’t replace even 10% of their existing investments in the next 2 years. They are stuck, stuck with legacy equipments that somehow needs to be connected.
If you have a programming experience like I do, you would straightaway think that simply by passing a serial command over USB or RS232/487 interfaces you should receive this information. But things aren’t this easy. The plant that I spoke about had 67 different devices, all have been implemented with Fortran, Cobol, Visual Basic, etc with each equipement being uniquely built. Most of the documentation was lost and the enterprise rarely knew what commands did what. It took us a month to figure that out for their behalf.
Even though we figured out all communication protocols, it was another puzzle to get through how the legacy programs actually worked. Remember, we were doing all of this without documentation. We even had the original programmers sat across the table and look at these programs. Even they couldn’t recall what they did at that time. Glad that code documentation and architectural documentation are a real thing these days.
Lack of off-the-shelf solutions to match for processes
Not each and every C-suite out there is looking towards custom hardware product development as a potential solution. With that being said, off-the-shelf solutions aren’t customizable enough to match their requirements. Not without inducing significant risks to the entire operation the C-suite is concerned with.
Take Beacon’s for example, ready made off-the-shelf beacons look good at the start, but if you are really looking to induce the battery life, implement a different routing algorithm and add more number of states, you will find them to fall short in a lot of ways.
Lack of subject matter expertise
I would personally rate this as one of the major concerns that industry executives have when they work with external or internal teams on IoT programs.
There’s a lack of understanding and product empathy in general when it comes to IoT. How many IoT vendors have you came across that talk about building automation systems and can get into specifics of HVAC?
If that wasn’t enough, the real revenue leakage in an industry comes from understanding real processes, not just blindly enabling tracking. Lack of real subject matter expertise is what prevents IoT adoption.
Well, these are some of the largest challenges that IoT faces before it goes mainstream. If you have any questions, or if you have any suggestions, feel free to drop a comment.