Door Igor Lenskii, Chief Product Marketing Specialist bij IoTellect.
De markt voor IoT-platforms is volwassen genoeg om tientallen opties te hebben, en onvolwassen genoeg dat veel ervan helemaal geen platforms zijn. Het kiezen van de verkeerde ontploft meestal niet tijdens de implementatie. Het komt later naar voren, wanneer de marges krimpen, projecten vastlopen en de overstapkosten al te hoog zijn.
Na jarenlang te hebben gekeken naar systeemintegrators, OEM’s en bedrijfsteams die deze keuze maakten (en er soms diep spijt van hadden), heb ik een selectiechecklist van twintig punten samengesteld. Maar voordat je ze alle twintig doorloopt, zijn hier vijf valkuilen die projecten en zakelijke relaties blijven vernietigen. Dit zijn geen randgevallen. Het zijn patronen.
Valkuil 1: u evalueert een dashboardbouwer, geen platform
Een leverancier laat je een gelikte demo zien. Mooie grafieken, overzichtelijke gebruikersinterface, gegevens die van een MQTT-makelaar naar een tijdreeksdatabase stromen, en enkele waarschuwingen bovenaan. Ziet eruit als een IoT-platform, toch? Dat is het niet. Een dashboardbouwer waarop een MQTT-broker is aangesloten, is geen IoT-platform. Een tool voor apparaatbeheer met een webinterface is dat ook niet. En een enkelvoudige verticale oplossing, opnieuw verpakt als iets ‘generieks’, is waarschijnlijk de ergste overtreder: het ziet er overtuigend uit totdat je iets buiten die ene verticaal probeert te doen.
Voordat u iets anders evalueert, moet u ervoor zorgen dat het platform het absolute minimum dekt: multi-protocol connectiviteit (niet alleen MQTT/HTTP), bidirectionele apparaatcontrole, gestructureerde hiërarchische datamodellering, gebeurtenisgestuurde verwerking met correlaties en analyse van de hoofdoorzaak, native visualisatie, API-gebaseerde integraties en een beveiligingsmodel dat verder gaat dan TLS en wachtwoorden.
Als er zelfs maar één hiervan ontbreekt, is het geen enterprise IoT-platform. Het is een component waar nog vijf componenten omheen nodig zijn, elk met zijn eigen integratiekosten, onderhoudslasten en faalpunten. Loop vroeg weg.
Valkuil 2: “MQTT en REST” is geen connectiviteitsstrategie
Deze is bedrieglijk eenvoudig. MQTT en REST werken prachtig voor moderne sensoren en schone API’s. Het eerste project stroomt, iedereen is blij. Dan komt het tweede project met industriële PLC’s, Modbus, OPC UA en zelfs oudere seriële protocollen. Het platform kan geen verbinding maken met de helft van de apparaten en het team zit vast.
Zelfs als u vandaag slechts één oplossing bouwt, denk dan aan morgen. Uw volgende klant of branche zal vrijwel zeker apparaten meenemen die geen MQTT spreken. En als voor elk niet-ondersteund apparaat een dure gateway of de professionele services van de leverancier nodig zijn om te integreren, zullen uw marges bij elk nieuw project eroderen.
Wat u eigenlijk nodig heeft, is brede industriële protocolondersteuning die zowel IT als OT omvat, een SDK- of driverframework dat u zelf kunt gebruiken, en de mogelijkheid om aangepaste protocoladapters te bouwen zonder telkens de leverancier te moeten bellen. Gateway- en edge-connectiviteit moeten onderdeel zijn van de deal, en niet een apart product met een apart prijskaartje. Als het platform u vastlegt in “Alleen MQTT/REST”, selecteert u een beperking en geen platform.
Valkuil 3: Zwakke datamodellering: de stille margemoordenaar
Datamodellering is onzichtbaar tijdens demo’s en komt meestal pas aan de oppervlakte als er al echt geld op tafel ligt.
De meeste platforms bieden een vorm van ‘apparaatdubbels’ of ‘digitale tweelingen’, in wezen een platte structuur waarbij elk apparaat eigenschappen en misschien wat metagegevens heeft. Dat werkt voor het monitoren van dashboards. Het werkt niet voor echte IoT-oplossingen waarbij je een hiërarchie nodig hebt: Bedrijf → Fabriek → Werkplaats → Productielijn → Eenheid, of Gebouw → Verdieping → Zone → Kamer → Sensor. Dit zijn geen cosmetische lagen. Ze definiëren hoe gegevens stromen, hoe toegangscontrole werkt, hoe waarschuwingen zich verspreiden en hoe operators daadwerkelijk met het systeem omgaan.
Vraag expliciet: ondersteunt het platform een formeel, platformbreed datamodel? Kunt u visueel aangepaste bedrijfsobjecthiërarchieën ontwerpen, en niet alleen platte apparaatlijsten? Kunt u parameters, bewerkingen, gebeurtenistypen en dynamische object-naar-object-bindingen definiëren? Is dit herbruikbaar in projecten?
Hier is een praktische test die ik altijd aanbeveel: doe de demo van het platform en probeer uw daadwerkelijke activahiërarchie op te bouwen. Niet het voorbeeld van de verkoper. De jouwe. Als het langer dan een dag duurt en je je nog steeds ongemakkelijk voelt, heb je het antwoord.
Wanneer de datamodellering zwak is, verandert elk project in ontwikkeling op maat. Je codeert wat configureerbaar moet zijn, dupliceert wat moet worden geërfd, en elke nieuwe klant vermenigvuldigt het probleem in plaats van de oplossing opnieuw te gebruiken. Dit is de manier waarop SI’s uiteindelijk geld verliezen aan projecten die er in de voorstelfase winstgevend uitzagen.
Valkuil 4: Implementatie alleen in de cloud is een tijdbom
Cloud-native is geweldig. Alleen cloud is een ernstig strategisch risico, vooral in de industriële IoT-, telecom- en overheidssectoren. Een aanzienlijk deel van de zakelijke klanten kan of wil hun operationele gegevens niet in een publieke cloud plaatsen. Nutsbedrijven stellen eisen aan de gegevenslocatie. Fabrikanten willen alles achter hun firewall. Telco’s moeten het platform in hun eigen datacenters laten draaien. Dit is geen nicheprobleem; het is de realiteit voor de meeste industriële toepassingen.
Als het platform alleen in de cloud van de leverancier draait of slechts één publieke cloudprovider ondersteunt, heeft u een plafond aan uw klantenbestand gesteld. En de belofte van de leverancier “we zullen later ondersteuning op locatie toevoegen” zou u geen enkele troost moeten bieden. Overdraagbaarheid van cloud naar locatie is een architecturale beslissing die vanaf de eerste dag bestaat of een fortuin kost om achteraf aan te passen.
De checklist ligt nogal voor de hand: implementatie op locatie, private cloud, meerdere publieke clouds (niet alleen AWS of Azure), hybride architecturen, agnostische werking van cloudproviders en edge-implementatie. Verplicht voor elk serieus industrieel, telecom- of MSP-georiënteerd bedrijf.
Valkuil 5: De Edge-Cloud Frankenstein
Deze val is bijzonder vervelend omdat hij zich achter mooie glijbanen verbergt. Een ‘edge-oplossing’ en een ‘cloudplatform’ die naadloos samenwerken. Op papier. In werkelijkheid zijn dit vaak twee afzonderlijke codebases – soms afkomstig van twee afzonderlijke acquisities – die via API’s aan elkaar zijn geplakt.
De praktische consequentie is pijnlijk: wat voor de cloud is gebouwd, wordt opnieuw opgebouwd voor de edge. Het team onderhoudt twee platforms in plaats van één, heeft twee sets vaardigheden nodig en voert twee implementatiepijplijnen uit. Overdraagbaarheid van code tussen edge en cloud blijft eerder een slide-deck-fantasie dan een technische realiteit.
Wat je nodig hebt is fundamenteel eenvoudig (en verrassend zeldzaam): dezelfde codebase op het hele edge- en centrale platform, dezelfde ontwikkeltools, geen ‘herschrijven voor edge’-vereiste. Wanneer een model, een dashboard of een waarschuwingsregel die in de cloud is ontworpen, zonder aanpassingen op een edge-knooppunt kan worden geïmplementeerd, is dat echte edge-cloud-compatibiliteit. Al het andere kost je maanden per project.
Vraag de leverancier rechtstreeks: “Is uw edge-product dezelfde software als uw cloudproduct?” Als het antwoord uitdrukkingen bevat als “lichtgewicht versie” of “naadloze integratie tussen onze twee producten”, weet u waar u mee te maken heeft.
Deze vijf zijn nog maar het begin
Platformselectie heeft meer dimensies dan connectiviteit en implementatie. Denk aan de volwassenheid van leveranciers, de gereedheid voor AI (ja, het is 2026 en MCP-servers en ontwikkelingsagenten maken nu deel uit van het gesprek), beveiligingsarchitectuur, prijstransparantie en de ongemakkelijke vraag wat er gebeurt als de leverancier verdwijnt.
De belangrijkste conclusie: de platformkeuze bepaalt uw winstgevendheid, schaalbaarheid en reputatie voor de komende jaren. Zwakke platforms hebben de mogelijkheid om stilletjes de marges te vernietigen voordat iemand het merkt.
Ik heb een uitgebreide IoT-platformselectiechecklist samengesteld die het volledige plaatje bestrijkt. Het is ontworpen als een praktisch ja/nee/misschien-instrument: als er te veel vakjes niet zijn aangevinkt, loop dan weg.
→ Lees de volledige IoT-platformselectiechecklist (editie 2026)
