I was visiting a customer in Texas who had started migrating their IoT systems to Oracle. Previously, they had taken all the correct steps in designing the business models, KPIs, selecting device partners etc., but they then partnered with a boutique-consulting firm for their implementation. What they realized was that their partner was operating with different SLAs than their factory. As they scaled their implementation, they realized the lack of a fit and then decided to partner with Oracle (disclaimer: I work for Oracle).
Very often, I see certain hubris from the software world when they attempt to provide solutions with IoT. Even in our past blog posts, we have talked about creating new digital products, making the manufacturing processes more agile (like software), etc. The narrative is always that the physical world needs to catch up with the digital world.
The easiest way I give a non-MBA definition of an operating model is by making an analogy to the car. People expect the steering wheel to be round. Regardless of how innovative your “next-gen navigation bar” is, it needs to be round to be adopted by the car manufacturers and the customers.
In the same vein, the software systems providing IoT solutions have to fit the existing operating model of the factory. Here are some of the dimensions of the operating model relevant to enterprise IoT.
a) 24x7 operational – most factories operate around the clock to remain profitable. What is required from their software partners is not just customer support (which can be forwarded to untrained call centers to achieve SLAs) around the clock, but tools to track that the sensors that drive your factories are “always on” and functioning correctly. Your software partners have to provide performance-monitoring dashboards to monitor the performance of your IoT system, and diagnose faults. These faults can range from sensors getting blown, networking faults, or sending incorrect readings. Without having such controls, it is not likely the enterprises will trust their operations to IoT
b) data retention – The IT departments – and even most system integrators – rely on their trusted technical platforms to provide an IoT solution. Sure, these software partners have data retention strategies using their database management tools. However, with IoT, we have new challenges arising because:
a. IoT will produce large volumes of data arriving at a very fast rate
b. IoT data is not transactional that can be modeled in BNF. This is time-series data, and we need new data management components like columnar databases. In addition, IoT data will include video and audio feeds, which are typically not stored in traditional databases
c. IoT data needs to be persisted for long periods of time so that we can get valuable insights by comparing the real-time performance over historical period, so that we can train algorithms with rich data sets to predict future events. These historical data sets sometimes run into tens of terbytes of data. Again, the way we manage data at such scale is different than how we traditionally managed it inside a database system.
d. IoT data needs to be categorized for efficient retrieval and management. With these large data sets, indexing for quick access becomes challenging. New taxonomies for data management need to be developed to partition the data for scale, easy access, and eventual obscelence.
c) real-time availability - Sensor data needs to be available in real-time. Very often, I have seen customers doing POCs with a few Raspberry Pi systems before proceeding to a full-scale deployment. During the deployment, due to design issues with scale, we see sensor feeds take a hit in latency, causing loss of SLAs. These sensor feeds start reporting data that is too late. In many cases, valuable data alerting the operator about the state of the machines starts getting dropped. IoT systems have a networking component, and we need to track and enforce SLAs around latency, and design a system that can scale to the eventual capacity.
d) security - IoT systems need be secure. In the pre-IoT world, we could only retrieve data locally by plugging a cable into a serial port. With IoT, not only do we expose this data to the Internet, but also we also now automate more of our mission critical steps by automatically processing sensor data. To build such trust in our IoT system, it is vital that we put controls for security. For example, with Oracle’s IoT cloud service (full disclaimer: I work for Oracle) each device has to authenticate itself using strict security protocols before it is allowed to publish the data to the cloud. In our case, we treat each device requiring the same authentication and fraud controls as an operator logging into the MES system. Connecting a device to a gateway is easy – but for enterprise deployments, we have to ensure that each connection fits into the existing security operating model that has been developed for your company.
e) operational visibility - IoT systems need to provide operational dashboards. To run an enterprise 24x7, not only do we need automated alerts that are integrated with your existing notification protocols (pagers, SMS etc), but we also need to integrate operational data from your IoT systems. Too often, I have seen customers complain about requiring a different tool to monitor a new system, thus making the enterprise “unmonitoriable” . If your enteprise has standardized on Kibana dashboards for monitoring a plant, then all IoT systems should have the capability to feeds its metrics and alerts to that custom dashboard
To summarize, here is my advice for practitioners of software engineering who are engaging in the IoT world. Learn how the factory operates. Fit within its existing operating model. Then, deliver on the promises of software!