Mitigate Debt Trap in Building a Digital Twin

Of course, there is merit in developing a Digital Twin; however, key precautions often get overlooked in the process. The implications far outweigh the advantages if it needs to be written off, directly impacting the P&L. Consequently, it becomes a missed opportunity in this competitive world.

The following are important points that require due diligence before jumping in:

1. Misalignment with Industry Standards
2. Technical Debt
3. Beyond Tech Adaptation
4. Data Debt

1. Misalignment with Industry Standards

As merit is seen in digital transformation, many standards are either developed or emerging. The Industry 4.0 guideline framework from NIST provides an excellent start, and the ISA 95 architecture offers guidelines for integrating enterprise and control systems. This applies to both continuous and discrete manufacturing industries. Key standards like CFIHOS (JIP36) asset data model standards, Digital Twin standard ISO 23247, Building Information Modeling standard ISO 19650, Material Digital Passport (MDP) system, OPC UA (Unified Architecture), NIST Cyber security guidelines are already in place, while others are still evolving. These standards provide framework to manage lifecycle of Assets, Building and Construction projects, Supply chain information exchange, IIoT connectivity best practices.

ISO 23247 architecture provides a framework to link Observable Manufacturing Elements (OMEs) to feed data through Data Collection Device Control Entities (DCDCEs) to Core Entity. Each domain then is grouped according to Functional sub-entities linked through logical groups of tasks or functions. This framework is generic enough and can be extended for either continuous or discreet manufacturing. Aligning your digital strategy with these standards helps create a strong foundation for your Digital Twin.

Any misalignment with released industry standards will become a sustainability challenge for the Digital Twin. Continuous monitoring and alignment with evolving standards are required to fine-tune existing implementations, even at the cost of effort, schedule, and investments. If this review is not done regularly, it is likely to result in significant overhead and eventual debt.

2. Technical Debt

Technical debt (also known as design debt, code debt, or architecture debt) is the implied cost of future reworking required when choosing an easy but point solution instead of a sustainable, scalable solution that requires more time to develop and mature.

Often, in the race against time, shortcuts are taken in solution architecture, leading to unrealistic expectations against existing data maturity or product limitations, which contribute significantly to overhead.

Many times, the existing technology landscape diverts you to “start from scratch” which may turn out to be a better alternative. This occurs because of the fast, ever-changing landscape in technology rollouts, coupled with challenges due to “non-backward compatible” limitations.

A technical assessment and digital strategy can help mitigate potential debt traps!

3. Beyond Tech Adaptation

In digital transformation projects, it's seen that technology comes into the "spotlight," which is flawed. A winning "trio" is a balance between people, processes, and technology at minimum. Technology often becomes a “culprit” pillar when outcomes are not as desired.

As best practice, many digital transformation projects follow design thinking principles and agile methodology. Still, adaptation challenges emerge due to "trio balance" disruption seen at the end:

• Just digitizing logics and workflows of existing work processes without optimization. This is an "old wine in a new bottle" philosophy and should be done in a time-bound manner to avoid a loss of opportunity.
• Pushback due to "comfort zone," "creation of transparency and breaking monopoly shackles," and "challenge of dependency" during rollouts. To mitigate such risks, continuous buy-ins are required not just in "process optimization" but also in "culture change." Evangelists are needed not only from the tech team but also from all stakeholders to become "digital ambassadors" to steer culture change.

Emphasis and buy-in are required in whichever manner: top-down or bottom-up.

Timely action and fine-tuning are required to avoid a debt trap.

4. Data Debt Trap

This is the most vulnerable aspect and is often overlooked. It's likely that existing deployments are "fit-for-purpose". "Know your data" is a great start point. Existing data may require a churn through the lens of "master data governance", rigorous "data quality assessment", "data reliability - single source of truth," "data duplication," and "data consolidation." Often, "dark" data segregation or cleanup may be required as these are inputs for AI based systems.

Logics often become complex when balancing data variation with technology, leading to stretching the technology to its limits. Technology needs to step up with capabilities to support "data architecture” & "data variations".

(a) Techniques like knowledge maps or knowledge graphs are available to handle data relationships and variations in data models.

(b) Techniques of data engineering need to be reviewed exhaustively based on the current data posture - be it "data mesh", "data fabric" or "databases".

A dedicated approach is required to assess linkages between 3D spatial data, structured and unstructured data, images, documents, drawings, and Lidar data. There will be large datasets from MES, SCADA or Historians which become gold-mine for AI to predict failure, for productivity & efficiency improvements. Integrating Design data with real time data from assets is the key. As they say, "Devil is in Detailing", the importance of this critical step is often undermined, and in the long run, it is likely to become a "black hole" that sucks in the Digital Twin release.

The Debt Trap mentioned above is not only applicable for Digital Twin but also for Digital Transformation. What are your thoughts on avoiding debt traps and mitigating risks?

Disclaimer: Opinions are solely those of the author in a personal capacity and do not represent the views of my employer.