Avoiding the ‘Technical Debt’ Trap – IndustryWeek

Manufacturers had to pivot quickly when the COVID-19 pandemic hit. Some manufacturing sectorssuch as paper, personal care products and pharmaceuticalshave experienced significant demand spikes during the crisis. Other sectors, such as the clean energy industry, have seen major declines, which could result in bankruptcies and debt obligations, according to a PwC report.

The pandemic exposes another type of debt that Ive observed as manufacturers respond to similar disruptions and other unexpected market shifts. Its called technical debt. Programmer Ward Cunningham coined the term in the early 1990s to describe a scenario in which people deploy software using the fastest, easiest code available with little regard for future technology needs.

This can occur when manufacturers quickly launch an IoT program without considering their future scalability needs. They may bring in coding experts who can get a system up and running fast but lack foresight into operational demands that could require future system changes.

Custom coding may work for more traditional IT integrations, such as the linking of ERP and CRM systems. But manufacturing plants are not static environments. Products change, assets need to be replaced and volume varies. With custom coding, each adjustment to operational technologies requires the need for a programmer to clean up the code.

A single digital model, on the other hand, uses metadata to create a standard representation of assets or systems that are being measured--eliminating the need to write custom scripts for individual assets, processes, products or systems. It can help maximize the value of an IoT investments.

Moores Law of People

In 1965, Gordon Moore, co-founder of chipmaker Intel Corp., predicted that the number of components the semiconductor industry could place on a computer chip would double every year (later revised to every two years). The theory became known as Moore's Law. I recently had a conversation with industry consultant Charlie Gifford, who referred to the rate of attrition within programming departments as Moores Law of People.

He said that within 18 months of a release of a product, the whole team, or at least half of the team, is gone and cant tell you what they wrote, so you end up with a dead product, an unmaintainable product in a production environment.

Adding to the frustration is the loss of skilled engineers due to retirement. The lack of knowledgeable professionals capable of interpreting existing code can leave manufacturers frustrated because the new programmer needs to rewrite the entire script, as its not portable or reusable.

Contextualized Data at the Edge

The need for standardized data modeling has become more urgent in recent years as manufacturers move toward cloud-based analytics. At HighByte, we call this an object-oriented approach. It involves the use of common models to integrate and manage information coming from multiple sources without the need for custom scripts.

Over the years, youve likely accumulated different equipment models from various vendors, possibly located in different facilities. To fully leverage the value of IoT, you need the ability to view and analyze information from these disparate systems without having to rewrite code for each system or subsystem. Remember, the purpose of connected systems it to increase operational efficienciesnot bog you down in endless days of data analysis.

A centralized model with contextual data available near the edge reduces complexity and can ultimately lead to more usable data.

How Object-Oriented Approach Works

Imagine two pumps operating at two different facilities. The assets likely generate similar data, such as temperature and flow, but with different names. Without a standardized model, a user would create two long lists of data for each asset, send it to the cloud and then match the data by their individual tags to create a virtual twin.

Its a manageable process for two pumps, but it becomes much more challenging if a manufacturer is trying to analyze data from hundreds of pumps across multiple sites. The ability to create a data model of an asset or process and combine it with other data sources allows manufacturers to scale quickly because any changes to the digital twin will happen seamlessly and automatically.

It becomes even more powerful when that data model is located near the edge. The ability to create a data model of an asset or process and combine it with other data sources allows manufacturers to scale quickly because any changes to the digital twin will happen seamlessly and automatically. As BenBlanchette, a former senior director at Georgia-Pacific, once told me: It doesnt take much imagination to realize if I can put data in context at the site before it got to the cloud, it would save me a lot of maintenance in the future.

Future Data Modeling Considerations

If you dont get your IoT implementation right at the outset, it can be the ball and chain that slows you down. Once a custom code is in place, its difficult to change.

You also need to pay close attention to the solutions youre deploying. Larger cloud service providers that specialize in consumer or back-office applications are not always ideal for industrial IoT deployments. They often think about IoT as creating new data streams by adding sensors to equipment. But, as Blanchette notes, many manufacturers already had those capabilities in place for decades. The reality, he said, is that most manufacturers were already collecting lots of data before the advent of IoT. It was just that the structure of the data was put together based on what we were going to do with it 30 years ago.

Data modeling doesnt necessarily deliver new data points but can help manufacturers take existing, siloed data and extract more value from that information. A single, unified model for delivering and interpreting data has the potential to future-proof IoT investments and deliver more value from those investments as operations evolve.

John Harrington is chief business officer, Highbyte.

Read more here:
Avoiding the 'Technical Debt' Trap - IndustryWeek