IIoT projects should be small and fast, learning as you go
Published on : Friday 08-10-2021
Stephen Mellor, Chief Technical Officer, Industry IoT Consortium.

Today, most industry stakeholders are aware of the many benefits of IIoT, yet are wary of joining the revolution. What could be the reasons?
There are several. Every company is different, of course, but I would say that risk is a major factor.
Let’s say you are a decision-maker in a large industrial company and I tell you that I can improve your efficiency by 5% using this hot new technology. What would your reaction be? You would probably think about up-front costs and ask about return-on-investment. You’d also want to know where this technology has been used before (and as Geoffrey A Moore pointed out in Crossing the Chasm, my answer had better be “in your competitor’s plant, in the same industry”). Then you’d ask about time: How long will it take to implement? And how much production time will be lost? Then you’d ask about the possibility of failure. If my (technologist’s) answer is that there’s 0.5% chance things will go dreadfully wrong and your plant will be down for a week, would you be willing to take that risk? And would your boss? How much do you value your job?
Faced with these kinds of odds, caution is in order. And that caution—while entirely reasonable—will make you wary of joining the revolution.
What are the challenges manufacturers face in adopting IIoT solutions?
Apart from caution, organisational culture is an inhibitor. Large industrial companies are used to making large bets over decades. For example, Airbus invested €25B in the A380 programme over the thirty years since the project was conceived and it has not made a profit on it. The average factory is nineteen years old. IIoT is not like that. You cannot make one big bet because the technology is evolving fast and we (collectively and individually) don’t know enough. Instead, IIoT projects should be small and fast, learning as you go. This runs counter to an organisational culture of big bets over decades.
Culture also plays a role in deployments. Operational technology specialists are extremely safety conscious—as they should be. That means that safety and compliance checks must be carried out and quality cannot be Job 2.0 (or even Job 1.1). You have to be safe. You also have to be compliant with regulations and protocols in your industry and your jurisdiction. Pharmaceutical companies, for example, spend 25% of their budgets on compliance. These things take time, so an annual update is more the scale we’re talking about. Meanwhile, my phone will probably update itself twice in the time it takes to write this short article.
Is the manufacturing sector, especially the SMEs, constrained by the paucity of system integrators?
Not really. IIoT systems tend to involve multiple technologies, and no one company or provider can deliver them all, let alone excel at them. (Don’t eat at a restaurant that has more menu items than chairs.) Consequently, there is a need to partner. This was a key driver of the founding of the Industry IoT Consortium (then the Industrial Internet Consortium) in 2014. The founders understood that they couldn’t do everything. SMEs will need to learn how to partner to build IIoT systems anyway. Why pay a system integrator?
One reason, of course, is to offload the responsibility and focus on your core competence. But that has disadvantages, particularly around the learning that you need to do as you incrementally improve your systems. And you do need to learn, because otherwise the revolution will come back and bite you.
Experts believe lack of skills is one of the main reasons for low adoption. How true is this?
Well, if experts believe it, who am I to argue? But I’m going to, anyway.
While there is obviously some truth to this, I don’t believe it to be the main reason. Rather the reasons outlined above, viz., caution in bringing these technologies into industrial companies is the main reason. It is for this reason that the Industry IoT Consortium is presently working to reduce the risk and grease the path to adoption. Specifically, we are working to identify pain points in industry (industrial companies have to tell us—we’re not experts in all the different industries) and then match them up with digital transformation enablers—the technologies that make up the industrial internet and thus enable transformational outcomes across industries, such as over-the-air updates, machine learning, deep learning, big data, ubiquitous connectivity and cheap sensors and actuators. Each digital transformation enabler can be described and examples provided per the template below.
We then relate them to patterns, “a general, reusable solution to a commonly occurring problem in software architecture within a given context. Architectural patterns are similar to software design patterns but have a broader scope.” These are abstract designs for using the digital transformation enabler in the context of an industry.
In the Indian context, IIoT should actually resonate more with the solutions for brownfield plants, yet the response is slow.
Brownfield plants have additional constraints over greenfield plants. Some I have mentioned above (downtime, loss of production, etc). They can also be difficult to instrument properly (though a lot can be done with existing sensors and some modelling of the real world being sensed). They may be more difficult and dangerous to work with, an existing oil well in the ocean rather than one being assembled in the factory, for example. Taken together, these are powerful barriers to adoption. Personnel in an existing plant may be reluctant to participate in changing how they work.
How can the manufacturing sector overcome these hurdles and arrive at a holistic approach?
Well, that’s the US$32.3T question. Apart from the many topics raised above, companies should start to learn. What technologies can help improve production? How can we get more visibility on operations? These are not “sexy” technologies; but they are lower risk. As we become more comfortable in using these technologies, we can build up expertise in a Centre of Excellence that can apply its accrued wisdom across the company. In time that will spread—in many ways.
First, and most obviously, the technology will become more trusted and more familiar. That will help reduce nervousness about its use. Second, the people will become accustomed to it. It is easy, as a production manager on the factory floor, to believe that this new-fangled technology will put you out of a job. (This has been a common refrain since the industrial revolution. No, it puts you into a job where you can do more, with less.) This is a key learning from our several testbeds—you have to win the trust of the people on the factory floor. Third, you will change the organisational culture. Managers will become more accustomed to taking short-term (low) risks to gain increased production at lower cost.
You also need to develop a catalog of up-and-coming projects that you can undertake. You can cost them (roughly) and prioritise them, putting them onto a timeline. As each project is completed, you can recost and reprioritise so that the projects with the biggest returns are done first as you continue to learn.
Over time, this could lead to new business models and new products and services will emerge. They will enable you to leverage more of what you make and provide better quality more cheaply.
Go for it!
Stephen Mellor is the Chief Technical Officer for the Industry IoT Consortium, where he aligns groups for business, technology, trustworthiness and industry for the Industrial Internet.
He is a well-known technology consultant on methods for the construction of real-time and embedded systems, a signatory to the Agile Manifesto, and one-time adjunct professor at the Australian National University in Canberra, ACT, Australia. Stephen is the author of Structured Development for Real-Time Systems, Object Lifecycles, Executable UML, MDA Distilled and Models to Code.
Stephen was Chief Scientist of the Embedded Software Division at Mentor Graphics, and founder and past president of Project Technology, Inc., before its acquisition. He participated in multiple UML and modelling-related activities at the Object Management Group (OMG), and was a member of the OMG Architecture Board, which is the final technical gateway for all OMG standards. Stephen was the Chairman of the Advisory Board to IEEE Software for ten years and a two-time Guest Editor of the magazine.