One of the entry points for many companies to the industrial internet of things is via the software team. That software team is often driven by a lead developer who has a “full stack” of software technologies to deploy, making him or her, by default, a domain expert. He, or she, may also be a “systems integrator” or “network administrator.”
“The map is not the territory, the word is not the thing it describes.”
Alfred Korzybiski
Those default concepts bring a misconception, management may not know about until much, much, later (…or maybe, never). IIoT is not software. It is deployed in the real world by real people. IIoT relies more on radio-telephony, than it does on IT. IIoT holds commonalities with oldstyle (1970s), PCB soldering, electronic engineering. Most of the time management is too time poor to investigate further and delegates this “technical stuff” to technical teams.
Software is a part of the skillset, but so too is safe climbing, physical inspections and knowing what adhesive sticks best. IIoT installations are focused on real world results that subsequently become virtualized on dashboards or desktop PCs.
When we discuss hardware, we have to note that the weather changes, even in the most arid desert. When we position a transmitter or receiver, we have to understand that we cannot just use anybody’s roof. When we talk communications technologies, we need to discuss “latency” and “frequency” of data transmissions.
Your ability to partner with others is a big part of IIoT. Your devices will need to work with different types of production line, industrial interface and hardware design. You will need to develop economies of scale. There is not yet a “one size fits all” plug & play module, which does not require batteries, that works across most industrial applications. Although Raspberry Pi or Arduino are good as mini PCs and edge devices, overall project scope is usually bigger than this.
The central pillar of an argument for partnership sits on how an IoT vendor interacts with the marketplace. Most of the time a client comes with a “big idea” and you have to tactfully discount most of the gimmicky stuff to get to what is workable, practical and possible, within technical and financial constraints.
Even if the design works (concept) and the installation (installation) goes like clockwork, you still need an accessible power source (energy) to schedule (networking tools) exactly what type of data (data points) you need, from where, and then train (training) your team to use those information technology assets (storage) correctly.
In software one of the big questions is whether to outsource, insource, or do the job yourself with your in-house team. Within IIoT the domain knowledge and practical skillset is so diverse that you should conservatively discount doing it yourself, unless you have the core resources of Microsoft or Google. When the decision is Microsoft OS to Microsoft peripheral or REST API to google app, then the path is clear and well signposted, inside it’s virtual environment.
That is not to say that there is no place for “Go Small, but Go now.” There decidedly is a space for this approach. It helps your team develop an understanding of what can be done and gives them fluency for progressively bigger projects. The flip side is management in large companies cannot (usually) get executive buy-in for small, incremental, steps. Bravado, chutzpah and buzzwords light the path to zombie projects, a hill of mismatched hardware and the sucking quicksand of recriminations, swallowed by a quarterly report.
