A few months ago, I was called in to discuss an IoT business case with the leadership of a prospect that had been waiting—patiently, they told me, but impatiently, I could tell—for their home build connected asset program to deliver on its promise. The use cases were well-defined. The ROI model looked compelling on paper. And yet, somehow, the data still wasn’t flowing the way it needed to. Their engineers were buried.
I asked a simple question: “How long has your team been working on getting the data ready to use?” There was a pause. Then: “About eight months. Mostly on mapping and transformation.”
Eight months. On plumbing.
That conversation stays with me because it captures something I see repeatedly in IoT programs—a hidden tax that almost never appears in the original business case, but ends up consuming a disproportionate share of time, budget, and organizational patience. My colleague Tal Dunne recently wrote about exactly this problem from an engineering perspective, and he got it exactly right. But I want to make the case to business leaders directly, because this is not just a technical problem. It is a strategic one.
The Cost That Never Makes the Slide Deck
When organizations build the business case for IoT, they model the value: predictive maintenance, educed downtime, new service revenue, and energy savings. The numbers are real and, in most cases, achievable. What rarely makes the slide deck is the cost of preparing the data to deliver those numbers.
Here is the reality: IoT devices do not speak a common language. Two temperature sensors from different vendors will report the same value in different formats, with different field names, at different precisions, sometimes embedded in completely different data structures. Before any of that data reaches a dashboard, an analytics model, or an AI application, someone must bridge that gap.
In most organizations that someone is an engineer, o or a team of engineers, writing code one parser at a time.
This would be manageable if your IoT estate were static. It never is. Every new device type, every new vendor, every firmware update introduces fresh inconsistencies. The transformation scripts multiply. The maintenance burden compounds. What started as a discrete project task becomes a permanent engineering overhead—a tax levied on every IoT initiative, forever.
I have seen programs where this overhead consumes 30–40% of total implementation effort. I have seen timelines extended by months because onboarding a single new device type required weeks of custom development. I have seen business cases that looked bulletproof on paper collapse in practice because the engineering team was perpetually firefighting integration issues rather than building the capabilities that create value.
This is the hidden tax. And for most organizations, it has been invisible for too long.
Why We Accepted It
The reason this cost has been tolerated is that, for a long time, there was no alternative. Devices are heterogeneous by nature. Data is messy by design. Making it consistent was engineering work, and engineering work takes time. That was simply the price of admission.
The industry tried to address this through standards—common protocols, unified data models, platform-level normalization. These efforts helped at the edges but they did not solve the underlying problem. Every standard still expects data to arrive in a specific structure. Every platform still requires data to conform to its model. The preparation work never went away; it just migrated from one layer to another.
So, organizations adapted. They hired more integration engineers. They built internal tooling. They accepted longer implementation timelines as normal. They wrote off the transformation overhead as an unavoidable cost of doing IoT at scale.
The problem is that this acceptance has a compounding effect. The longer it takes to onboard a new device or data source, the slower the organization learns. The slower it learns, the slower it captures value. And in a competitive environment where the speed of insight is increasingly a differentiator, this is not a neutral position. It is a strategic disadvantage that accumulates quietly, quarter by quarter.
What Has Changed
Dunne’s article describes a genuine shift in how this problem can now be approached—and I want to make sure business leaders understand what it means for them.
The core insight is this: when an IoT platform has a well-defined model of what data should look like—what a temperature measurement is, how assets and devices relate, what units and timestamps are expected—and when AI is grounded in that model, the gap between raw device data and usable platform data can be bridged automatically. Not eliminated. Not magic. But bridged with AI assistance rather than handcrafted code.
Instead of an engineer inspecting a raw payload and manually writing a transformation script, the system understands the intent. A device sends a field called tmp_c100—temperature in centidegrees, a common embedded systems convention. Instead of someone spending days deciphering that and writing conversion logic, you describe what you want: “convert to standard Celsius.” The system interprets the intent, generates the transformation, and applies it. The engineer’s role shifts from writing code to reviewing and validating the result.
From a business perspective, this changes three things that matter enormously.
The first is onboarding speed. What previously took weeks of engineering effort can be reduced to hours or days. That is not an incremental improvement. For organizations managing dozens or hundreds of device types, that is a structural change in the economics of IoT deployment.
The second is scalability. The traditional model breaks down as device diversity grows, because every new variation adds to an already complex maintenance burden. An AI-assisted model does not have the same scaling constraint. The system’s ability to interpret and align new data does not degrade as the estate grows.
The third is organizational resilience. Transformation logic that lives in AI-assisted mappings aligned to a semantic model is far easier to govern, adapt, and evolve than a sprawling library of custom scripts maintained by engineers who may no longer be with the organization. When a device vendor changes their payload format—and they will—the response is refinement, not reconstruction.