In my previous article, I covered the Data Structure aspect of the Digital Twin. Today, I would like to extend that topic further and provide more practical insights. For the purpose of our discussion, I propose to think about the Digital Twin as the Data Proxy. What do I mean by the Data Proxy? That is an abstract way of accessing various types of data. Let’s take the current state of the monitored equipment as an example.

My take on the IoT 2023 review by IoT Analytics: The IoT market has matured, and the hype cycle is over. That is actually a good thing. Cloud providers’ layoffs in the IoT domain prove that there is no one-size-fits-all IoT solution. That is also a good thing. Fired IoT professionals will design and build specialized offerings solving particular needs. Public cloud providers offer generic IoT capabilities, far from working out-of-the-box solutions.

In my previous article, I introduced the concept of Digital Twin. The state of a Digital Twin (DT) relates to data gathered from sensors and external systems. That setup ensures automated, up-to-date digital representation of monitored entities. Today, I would like to focus on the Data Structure aspect of DT. Designing that Data Structure is an iterative, manual process. We extend the Data Structure to improve the functionalities provided by DT.

Digital Twin is a virtual representation of a physical device. It consists of Data Structure, Logic, and Visualization (in my opinion, an optional part of the Digital Twin). We use sensors to gather data about the monitored device and store obtained information using the Data Structures of Digital Twin. We can get additional information about the device from External Systems and also store it using the Digital Twin’s Data Structure.

Proof of Concept (PoC) is a very misleading approach, and I strongly recommend avoiding it. Let me explain. PoC makes the project team focus on the technology and verification of the technical feasibility of some solution. That mindset is one of the main reasons for failure in the IoT domain because: We lose the objective (technology is not the end goal of any IoT deployment). We lose time (contemplating various technical solutions can take infinite time without producing any outcomes).

What is the ultimate advice I can offer as the Internet of Things Advisor and Trainer? Do not deploy an IoT system… … because everyone is doing so, … because that is the way to stay relevant, … because people say that you will fall behind. A poorly designed and implemented IoT solution… … won’t modernize your enterprise, … will cost you time and money, … will harm your operations.