USP's vinden in het IoT-ecosysteem:deel 2

Met deze serie artikelen willen we niet alleen de IoT Value chain in kaart brengen, maar ook de markt/economische structuren en de veranderende dynamiek eromheen. Dit artikel is bedoeld om de zakelijke besluitvormers aan te spreken die proberen een oplossingsstrategie en USP te vinden in elk onderdeel van de waardeketen. In ons laatste artikel hebben we ons gericht op IoT-sensoren, apparaten, gateways en communicatie als onderdeel van de waardeketen. In dit artikel wij, Arpit Khosla en Praneet Thakur van IoT Australia Consulting Services duikt in IoT-platforms.

Gezien de veelheid aan manieren waarop de term "IoT-platform" kan worden geïnterpreteerd, maken we van deze gelegenheid gebruik om eerst onze visie te geven op wat een IoT-platform allemaal inhoudt. Op een hoog niveau omvat het horizontale en verticale mogelijkheden. Enkele van de mogelijkheden die als horizontaal kunnen worden gemarkeerd, zijn Connectivity Management, Device Management, Data Ingestion &Storage, Application Enablement Platform &Analytics enablement Platforms. Soms maken factureringsplatforms die end-to-end-facturering bieden ook deel uit van de Horizontal Platforms-familie. De applicaties zelf zijn meer verticaal of scenariospecifiek en kunnen daarom worden gecategoriseerd als verticale mogelijkheden. Laten we eens kijken naar elk van deze mogelijkheden vanuit de strategie &USP-lens.

Wat betreft connectiviteitsbeheer, hoewel men misschien de juiste technologie moet kiezen op basis van dekkingsbereik, beveiliging, mobiliteit, overal, schaalbaarheid, stroomprofielen en latentievereisten, maar de oplossing zelf wordt meestal verzorgd door de netwerkaanbieder. Vanuit het perspectief van de oplossingsstrategie zijn er enkele belangrijke beslissingen, zoals gelicentieerde versus niet-gelicentieerde simkaarten, simkaarten versus e-simkaarten en gesplitste facturering versus end-to-end-facturering, maar ze rechtvaardigen een ander artikel, dus we zullen in deze niet op hun details ingaan.

Evenzo vanuit het perspectief van de strategie voor apparaatbeheeroplossingen moet de maker van technische beslissingen voldoen aan de vereisten van levenscyclusbeheer van apparaten, commando en controle, monitoring, auditing, firmware-updates op. In deze context moet de beslisser niet alleen rekening houden met standaardprotocollen zoals LWM2M en OMADM, maar ook met contextspecifieke protocollen zoals OPC-UA, Profinet, Modbus en Hart enz. Vanuit USP-perspectief is er echter niet veel dat een innovator kan putten uit de functionaliteit voor connectiviteitsbeheer of apparaatbeheer.

De platformen voor gegevensopname en -opslag zijn geen vreemden voor uitdagingen van heterogeniteit, evoluerende normen en vereisten om schaalbaarheid aan te kunnen met de juiste beveiligingshouding. Vanuit het perspectief van een oplossingsstrategie is het kiezen van het juiste protocol tussen https, MQTT, CoAP, AMQP enz. een belangrijke beslissing die moet worden genomen. Meestal bieden de meeste platforms ondersteuning voor bovenstaande protocollen, maar het zijn de commercials en het gemak van integratie die de beslissing hier bepalen. Sommige platforms bieden bijvoorbeeld een reeks bibliotheken om communicatie mogelijk te maken die tijd- en moeiteinvestering voor ontwikkeling rechtvaardigen, aan de andere kant bieden andere een configuratie op basis van low-code / low-touch configuratie.

Vanuit het perspectief van oplossingsbeschikbaarheid zien we drie benaderingen. Ten eerste maken makelaars voor gegevensopname en opslagplatforms deel uit van de suite die wordt aangeboden door aanbieders van end-to-end horizontale cloudplatforms, zoals AWS &Azuur. Deze proberen de complexiteit van de installatie en het beheer van de infrastructuur, schaalbaarheid, hoge beschikbaarheid enz. te vereenvoudigen. Een alternatieve oplossing is het kopen van volledig geproduceerde platforms zoals C3IoT, Software AG, PTC . Met productized bedoelen we dat typische productievereisten rond administratie, bediening, auditing, integratie en gebruikersinterface voorgebakken zijn.

De typische derde optie is om te bouwen met behulp van open source-oplossingen zoals Rabbitmq, Eclipse Mosquito enz. Over het algemeen hebben de meeste PaaS- en SaaS-spelers vergelijkbare aanbiedingen in deze ruimte en typische overwegingen bij het maken van een keuze zijn schaal, commercieel, operationeel en doorlopend onderhoud en ondersteuning. We zien dit deel van de oplossing niet als een sterke kandidaat voor het bouwen van een kerndifferentiator of USP, bovendien met een overvloed aan beschikbare oplossingen verwachten we dat dit deel van de waardeketen concurrerend zal blijven en dus gewapend met weinig kans dat PaaS of SaaS marktmacht misbruikt . Concluderend kunnen we dit markeren als een competitieve en gecommoditiseerde ruimte, met PaaS of SaaS als de voorkeursmodus voor ontwikkeling.

Applicatie-enablementplatforms en Analytics-platforms kunnen ook worden gecategoriseerd in de horizontale platformruimte. Deze platforms stellen uw oplossing in staat om inkomende gegevens realtime of batch-/gepland af te handelen. Dit verschilt van het gegevensopnameplatform, omdat hier niet alle platforms vergelijkbare mogelijkheden hebben. Als technische beslisser evalueert men gewoonlijk de capaciteiten van het uitvoeren van analyses en machine learning, ontwikkeling van visualisatietoepassingen en hostingmogelijkheden. Uitbreidbaarheid via integraties en API-aanroepen zijn een andere dimensie van overweging. Deze integratie kan plaatsvinden met omgevingen die gebaseerd zijn op monolithische of microservices, op de cloud of op locatie.

Sommige van deze oplossingen duiken ook in de Edge-ruimte, speciaal voor edge-analyses. Zodra de beslisser de vereisten kent vanuit het perspectief van de bovenstaande dimensies, kan hij opnieuw kijken naar een van de drie keuzes PaaS-aanbiedingen van Azure &AWS of op Open source gebaseerde build. Aangezien de behoefte aan edge- of fog-computing snel groeit en wordt beschouwd als het meest groeiende gebied, is het voor de ontwerper van de oplossing bijna verplicht om ook een duidelijke Edge-strategie te hebben. In Edge-ruimte zou men kunnen kijken naar oplossingen van bijvoorbeeld Intel Op Movidius gebaseerde chipsets en edge-apparaten van Dell vanuit hardwareperspectief en Azure IoT Edge, AWS IoT Greengrass, Software AG edge-apparaat vanuit softwareperspectief. In analyse- en applicatieruimte moet men, terwijl men de derde benadering van build volgt, technologieën zoals Kaa, HDFS, Kafka, Nifi, Mongo DB, Nginx enz. aan elkaar koppelen om een ​​robuuste IoT-oplossing mogelijk te maken.

Over het algemeen zijn we vanuit het perspectief van oplossingsstrategie van mening dat men zich bewust moet zijn van het feit dat SaaS-spelers in de analyseruimte naar verwachting zullen worden gedifferentieerd met geoptimaliseerde leeralgoritmen. Hierdoor ontstaat de mogelijkheid dat SaaS-spelers later op de dag misbruik maken van de marktmacht. De zakelijke beslisser moet ook op de hoogte zijn van de tijd en investeringen die nodig zijn in de build-aanpak, die mogelijk niet overeenkomen met de differentiatie die in deze ruimte is ontwikkeld. Daarom zijn we van mening dat de voorkeursbenadering hier PaaS is voor Application Enablement &Analytics Engine-functionaliteiten.

De volgende in de rij zijn de verticale specifieke toepassingen. De oplossingsbouwers zullen doorgaans verschillende functionaliteiten uit de bovenstaande catalogus van IoT-platforms aanroepen om de end-to-applicatie te bouwen. De applicatie kan bijvoorbeeld worden ontwikkeld in een omgeving die wordt geboden door het Application enablement-platform door gegevens te verzamelen van het data-opnameplatform en daarop visualisatie te ontwikkelen bovenop de trends en inzichten die worden gedolven door Analytics-platforms. Het is wanneer de inzichten die worden gegenereerd door deze end-to-end contextgebaseerde hechting van het ecosysteem, een probleem oplost, dan weet men dat er waarde is gecreëerd en daarmee de oplossing bewapend met een sterke USP.

Dit is het gebied dat moet worden onderzocht met een relatief veel grotere zakelijke lens. De besluitvormers moeten beoordelen of de toepassing waardevol, zeldzaam, onvolmaakt imiteerbaar en niet-vervangbaar is. Vanuit het perspectief van de marktstructuur is dit een gebied waar men zijn eigen markt kan definiëren en monopolie kan genieten, vandaar dat een geheel nieuwe opbouw, mogelijk met gebruikmaking van open source-omgevingen, een voorkeursbenadering is. Bovendien verwachten we vanuit zakelijk perspectief een hoge plakkerigheid van klanten in deze ruimte, dus tijd is hier van essentieel belang, en hoe eerder men met de gekozen oplossing op de markt kan komen, hoe groter de kans dat de USP wordt benut om op te schalen.

Over het algemeen lijken vanuit een USP-ontwikkelingsperspectief de verticale specifieke applicaties met onderliggende aangepaste Analytics de meest geschikte kandidaat. Vanuit het perspectief van een IoT Platform-oplossingsstrategie hebben we echter aanbevelingen gedaan voor PaaS of SaaS voor gegevensopname, PaaS voor toepassing en analyse en op Open Source gebaseerde build voor verticaal specifiek toepassingsperspectief, maar we waarderen het immense belang van de context die alle beslissingen drijft. Als de context een snelle time-to-market rechtvaardigt met ondersteuning van een toegewijde R&D:Saas kan een optimale beslissing worden. Daarom kunnen alle bovenstaande factoren als algemene richtlijn worden gebruikt, maar elke use-case heeft zijn eigen jury en zijn eigen beslissing.

De auteurs van deze blog zijn Arpit Khosla, oprichter van IoT Australia Consulting Services en Praneet Thakur, adviseur van IoT Australia Consulting Services