Why innovation lives or dies on Its data foundations ?

Look at the two houses above the waterline and you would happily move into either one. The first is a tropical dream: flowers on the terrace, warm light in the windows, a little lighthouse on the roof. The second is a calm stone villa beside a white lighthouse. Both make a great photo.

Now look below the surface. The first house stands on rotting stilts, lashed together with rope and patched with whatever was at hand. The second rests on a stone foundation with braced pillars, anchored to the seabed. One will survive the next storm. The other is a nightmare waiting to happen.

Innovation works exactly the same way. Above the waterline sit the dashboards, the apps, the AI pilots and the launch events. Below it sits the data: where it comes from, how it is structured, who owns it and whether anyone can trust it. Great innovation is a dream to showcase and a nightmare to run, unless the data underneath holds.

Innovation hubs: built for the photo or built to last?

Many companies now run an innovation hub, a lab or a digital factory. Their job is to test new ideas quickly and show what is possible. That is valuable, but it creates a trap: the hub is judged on what it shows, not on what it leaves behind.

A proof of concept can run beautifully on a clean extract, a handful of sensors and one enthusiastic site manager. Then comes scale-up. The data arrives from twenty sites, three vendors and two legacy systems, each with its own formats, timestamps and gaps. The pilot that looked like the villa turns out to be the hut on stilts.

The hubs that deliver lasting value treat data as part of the product from day one. They ask early questions that are less glamorous than the demo:

1. Where will this data come from in production, not in the pilot?
2. Which standard or data model will we use, so the next use case can reuse it?
3. Who owns data quality once the hub team moves on?
4. How will operations teams trust the numbers enough to act on them?

An innovation hub that answers these questions is not slower. It simply builds the foundation once, instead of rebuilding stilts for every new idea.

Logistics: a TMS is only as smart as its data

A Transport Management System is the visible house of modern logistics. It plans routes, consolidates loads, selects carriers, tracks shipments and settles freight invoices. Add telematics, temperature sensors and smart locks, and the promise is a real-time view of every truck and every pallet.

Below the waterline, the reality is often messier. Addresses are entered three different ways. Carrier status codes do not match. GPS pings arrive late or not at all on rural roads. Proof of delivery is a photo in a WhatsApp group. The TMS still produces a dashboard, but planners stop trusting it and go back to the phone and the spreadsheet.

The strong foundation in logistics looks less exciting but works every day:

1. Clean master data: customers, sites, products and carriers defined once and shared across ERP, WMS and TMS.
2. Standardised events: pickup, departure, arrival and delivery mean the same thing for every carrier and every country.
3. Reliable telematics: devices, connectivity and gateways chosen for the actual road network, with buffering when coverage drops.
4. Closed loops: delivery data flows back into planning, invoicing and customer service without retyping.

When these pillars hold, the TMS stops being a reporting tool and becomes a decision tool: dynamic routing, accurate ETAs, lower empty miles and freight audits that pay for themselves.

Energy: DLMS/COSEM as the stone foundation

In energy, the house above the water is easy to recognise: customer apps, prepayment top-ups by mobile money, outage maps, loss-reduction dashboards and, increasingly, AI for load forecasting. Utilities and DSOs invest heavily in these, and rightly so.

But every one of these services depends on the meter data underneath. A smart metering programme that mixes proprietary protocols, inconsistent OBIS codes and unsynchronised clocks builds its grid of the future on wooden stilts. Each new vendor needs a new driver. Each new use case needs a new data cleaning project. Billing disputes rise, and the business case slips away.

This is why DLMS/COSEM matters far beyond the protocol specialists. It gives every meter the same language: a common object model (COSEM), standard identifiers (OBIS codes) and a common application protocol (DLMS), whatever the communication layer underneath, whether PLC G3-OFDM, RF mesh or cellular. In practice, it means:

1. Interoperability: meters from several manufacturers can be read by one head-end system, which protects the utility from vendor lock-in.
2. Comparable data: an energy register, a load profile or a tamper event means the same thing across the whole fleet.
3. Security by design: authentication and encryption are built into the standard, not bolted on afterwards.
4. Reusable foundations: the same data feeds billing, prepayment (for example with STS tokens), loss analysis, outage management and planning.

A DSO that gets this layer right can then add new services quickly, because the pillars are already in the seabed. One that skips it will keep repairing stilts.

Industry and mining: where OT meets IT

In manufacturing plants, mines and building management systems, the same pattern repeats. The visible layer is the digital twin, the predictive maintenance alert or the energy performance dashboard. The hidden layer is the meeting point between operational technology (PLCs, SCADA, sensors, meters) and information technology (ERP, MES, cloud analytics).

That meeting point is where many projects quietly fail. Tags are named differently on each line. Timestamps come from clocks that drift. Historians keep data that nobody outside the plant can reach. Cybersecurity is handled by firewall rules added in a hurry. The result is a beautiful twin of a factory that does not exist.

Industrial companies that succeed treat OT/IT convergence as civil engineering, not decoration: a clear architecture, an agreed data model, secure gateways and a governance that both plant engineers and IT teams accept. Only then can energy, logistics and production data be combined into decisions that save real money.

The four pillars under the lighthouse

Whether the house is a TMS, a smart metering platform or a factory twin, the stone foundation rests on the same four pillars.

1. Standards: use open, recognised standards wherever they exist: DLMS/COSEM in metering, common event models in logistics, open industrial protocols on the shop floor. Standards are what let the next use case reuse the work of the last one.
2. Architecture: design how data travels from the field to the decision: devices, connectivity, gateways, head-end or platform, and the business applications on top. Make security part of the design, not a final checklist.
3. Governance: name owners for each key dataset, define what "good quality" means and measure it. Data management is a management discipline before it is a technical one.
4. Field reality: test the foundation where it will actually live: in the substation, on the rural route, in the dusty mine. Data that only works in the lab is wooden stilts with a fresh coat of paint.

None of these pillars will ever appear in a launch video. All of them decide whether the launch is still running two years later.

Build below the waterline first

The next time a project is presented with a beautiful dashboard, ask to see what is underneath. Which standards does it use? Where does the data come from in production? Who owns its quality? How does it behave in the field?

At Strat & IoT, this is where we spend most of our time, from smart metering and DSO transformation to logistics, industrial performance and IoT architecture, across Europe, West Africa and India. We help organisations design the foundation first, so that innovation can be showcased with confidence and run without nightmares.