An automotive parts supplier near Bursa installed temperature and vibration sensors on its production line last year. The sensors work, the data flows — but it never reaches the ERP system, never triggers the maintenance schedule, never updates the quality management module. The technician on the floor still fills in paper forms and keys the readings in manually. Return on investment cannot be calculated because the process chain is broken. This pattern repeats itself across dozens of Turkish manufacturing SMEs: money is spent on IoT hardware, yet value never materialises because integration is missing.
The technical name for this problem is protocol and platform fragmentation. The industrial IoT landscape today runs on dozens of communication protocols that are not fully interoperable: MQTT, AMQP, CoAP, Modbus, OPC-UA, Zigbee, Z-Wave and more. Each protocol is optimised for a specific scenario — MQTT for low-bandwidth sensor networks, OPC-UA for heavy industrial equipment integration, BACnet for building automation. The difficulty is that a single factory floor typically hosts equipment from multiple manufacturers, each supporting its own preferred protocol. Without a shared language, these devices operate in isolation.
Platform fragmentation adds a second layer to this challenge. Major technology vendors are racing to build proprietary IoT ecosystems, each with its own API structure, data model and preferred connectivity protocol. When an SME commits to a particular platform, integrating devices that platform does not natively support requires additional middleware — developed in-house or purchased from a third party. When this middleware is left out of the initial budget, the project’s stated cost covers only a fraction of the real expenditure. A pattern that surfaces repeatedly in consulting engagements: integration costs end up two to three times the cost of the hardware itself.
Ecosystem strength is the most decisive criterion in standard selection. Open standards reduce single-vendor dependency and enable a more flexible architecture over time. OPC-UA stands out in this regard: it defines both the security layers and the semantic model for machine-to-machine communication, bringing equipment from different manufacturers into a common data structure. MQTT finds wide application in low-power sensor networks; its publish-subscribe architecture and minimal footprint make it well suited for remote monitoring. No single protocol covers every scenario, however, which means most real-world deployments combine multiple protocols — and that compounds the complexity of the integration layer.
Future-proofing goes beyond protocol selection and demands an architectural perspective. A platform chosen today may lose active development support within three years, or may fail to scale as the company grows. The practical way to manage this risk is abstraction: placing a data bridge between the device layer and the application layer isolates upper-tier business applications from changes in the underlying protocols. From an ERP integration standpoint, this is essentially the same ‘middleware logic’ that Turkish companies have already internalised through e-Invoice and e-Ledger compliance — applied now to the IoT domain.
In practice, the most persistent obstacle is not technical but organisational. Who owns the IoT project in an SME — IT, production engineering, or an external system integrator? Without a clear answer, accountability gaps open up. Raw sensor data goes unprocessed, maintenance teams miss alerts, and the ERP inventory module never reflects real-time consumption. The technical infrastructure exists but is not connected to the business process. A further complication: warranty and support contracts from different device vendors typically do not cover integration failures, leaving maintenance costs unpredictable and unbudgeted.
For an SME executive evaluating an IoT investment, the central question should be: how will these devices communicate with our existing ERP, MES, or quality management system, and at what cost? Hardware price is not the deciding factor — integration cost and the long-term sustainability of that integration are. Favouring open standards with broad ecosystem support reduces platform lock-in risk. The pilot should be scoped to a single production line or a single process; only after measuring integration cost and operational benefit should a scale-up decision be made. If devices do not communicate, data is generated but value is not — and return on investment cannot be calculated. Standard selection is therefore not an IT decision; it is a strategic business decision.
This article was originally written in Turkish by Gökhan MERCANOĞLU on June 20, 2016 and has been automatically translated into English and other languages using machine translation.