Too many brave pioneers seeking to transform the efficiency of their industrial infrastructure with new Industrial IOT (IIOT) applications face such daunting odds that their projects are doomed to failure before they even get off the ground. In this post I don’t want to focus on the reason why most projects fail. Instead, I want to give you a glimpse of a powerful new approach that has the potential to transform success rates and catalyze the adoption of new IIOT solutions.
The tech industry - from “the big guys”: AWS, Azure and Google – to the scores of companies that have sprung up around piece-parts of an open source stack - will tell you that success depends on how well you build, orchestrate and run your new application. They are passionate advocates of their protocols, stacks, orchestration tools and cloud platforms. In my experience these make no difference.
- IIOT is not an App nor DevOps problem. It’s a data problem.
This statement is either a tautology or frustratingly vague. Take your pick. But grant me a moment to explain it and then to point to a radically different way of solving the app problem, using data.
The “new app / orchestration / infrastructure / cloud” approach to delivering IIOT value propositions fails on many fronts:
- It’s typically impossible to write new apps for brownfield environments. Proprietary protocols, switches, sensors, runtime environments abound, and nobody wants to tinker with systems that are working. Unfortunately brownfield is what you already have, and more importantly, brownfield environments are those most in need of new intelligent solutions.
- Today’s app platforms often fail on high volume, real-time data. Developers are tempted to leverage stacks that have succeeded in consumer IOT domains. Sure, twitter is big, but its infrastructure is optimized for a “write once, read often” application architecture that is the polar opposite of industrial settings dominated by highly bursty, noisy, time-series data that “write always, reader be damned”, that has to be processed in order to make any sense, and where a real-time decision has to be made to deliver a useful response. This dichotomy is exacerbated by the naïve assumption that the stateless REST model of today’s web-services apps has any hope of coping. Every sensor output has to be written to a database before some asynchronous logic processes it to deliver a response. Good luck trying to fly a single drone with that, let alone a swarm of drones in a hostile environment.
- The priests of big-data would have you believe that IIOT problems can only be solved with the promises of their religion. Many optimization and learning problems rely on vast amounts of data stored over a decent period of time. There are sound reasons to seek optimizations on these time-scales: It is great to know that over a long period of time, a particular traffic intersection is always blocked. This is what traffic engineers need to better tune city infrastructure, or town planners need to motivate addition of new infrastructure. But it’s no use trying to route a FedEx truck through a crowded city right now, to make a guaranteed delivery. We need tools that match the time-scales of the data and application, and big-data religion won’t help.
- The success of any new project seems dependent on skill-sets – in Information Technology (IT), Operational Technology (OIT), and crucially in the application development domain where familiarity with the new paradigms - DevOps and Cloud – are crucial. Bad luck if you don’t have them. There just aren’t enough humans with the right skills available to address all the IIOT needs companies have. We need to automate the creation, deployment, scaling, operations and maintenance, and securing of new IIOT applications. How can we do that?
IIOT is “cool” but projects will continue to fail unless we automate the creation, deployment, and management of IIOT applications.
- This is a data problem we can solve - with machine learning
Learn more: Swim ESPTM