USPs im IoT-Ökosystem finden:Teil 2

Arpit Khosla von IoT Australia Consulting

Unser Ziel ist es, mit dieser Artikelserie nicht nur die IoT-Wertschöpfungskette, sondern auch die Markt-/Wirtschaftsstrukturen und sich ändernde Dynamiken um sie herum aufzuzeigen. Dieser Artikel richtet sich an Entscheidungsträger in Unternehmen, die versuchen, eine Lösungsstrategie und einen USP in jeder Komponente der Wertschöpfungskette zu finden. In unserem letzten Artikel haben wir uns auf IoT-Sensoren, -Geräte, Gateways und die Kommunikation als Teil der Wertschöpfungskette konzentriert. In diesem Artikel wir, Arpit Khosla und Praneet Thakur von IoT Australia Consulting Services soll in IoT-Plattformen eintauchen.

Angesichts der Vielzahl von Interpretationsmöglichkeiten des Begriffs „IoT-Plattform“ nehmen wir an dieser Stelle zunächst einmal unsere Sicht auf das, was eine IoT-Plattform alles umfasst, dar. Auf einem hohen Niveau umfasst es horizontale und vertikale Fähigkeiten. Einige der Funktionen, die als horizontal gekennzeichnet werden können, sind Connectivity Management, Device Management, Data Ingestion &Storage, Application Enablement Platform &Analytics Enablement Platforms. Manchmal sind auch Abrechnungsplattformen, die eine End-to-End-Abrechnung anbieten, Teil der horizontalen Plattformfamilie. Die Anwendungen selbst sind eher vertikal oder szenariospezifisch und können daher als vertikale Fähigkeit kategorisiert werden. Lassen Sie uns jede dieser Fähigkeiten aus der Sicht der Strategie und des USP betrachten.

Was das Konnektivitätsmanagement betrifft, muss man möglicherweise die richtige Technologie basierend auf Abdeckungsbereich, Sicherheit, Mobilität, Skalierbarkeit, Leistungsprofilen und Latenzanforderungen auswählen, aber die Lösung selbst wird normalerweise vom Netzbetreiber übernommen. Aus der Perspektive der Lösungsstrategie gibt es einige wichtige Entscheidungen wie lizenzierte vs. nicht lizenzierte SIM, SIM vs. eSIM und geteilte Abrechnung vs. End-to-End-Abrechnung, aber sie rechtfertigen einen weiteren Artikel, daher gehen wir in diesem Artikel nicht auf ihre Details ein.

In ähnlicher Weise muss der technische Entscheidungsträger aus der Perspektive der Gerätemanagementlösungsstrategie die Anforderungen des Gerätelebenszyklusmanagements, der Befehls- und Kontrollfunktionen, der Überwachung, der Auditierung und der Firmware-Updates adressieren. In diesem Zusammenhang muss der Entscheidungsträger nicht nur Standardprotokolle wie LWM2M &OMADM berücksichtigen, sondern auch kontextspezifische Protokolle wie OPC-UA, Profinet, Modbus und Hart usw. Aus USP-Sicht gibt es jedoch nicht viel, was ein Innovator leisten kann Nutzen Sie entweder die Konnektivitätsverwaltungs- oder die Geräteverwaltungsfunktionalität.

Die Datenerfassungs- und -speicherplattformen sind den Herausforderungen der Heterogenität, sich entwickelnden Standards und der Anforderung, Skalierbarkeit mit der richtigen Sicherheitslage zu handhaben, nicht fremd. Aus Sicht der Lösungsstrategie ist die Wahl des richtigen Protokolls unter https, MQTT, CoAP, AMQP usw. eine wichtige Entscheidung. Normalerweise bieten die meisten Plattformen Unterstützung für die oben genannten Protokolle, aber es sind die Werbung und die einfache Integration, die hier die Entscheidung ausmachen. Zum Beispiel bieten einige Plattformen eine Reihe von Bibliotheken, um die Kommunikation zu ermöglichen, die Zeit- und Arbeitsaufwand für die Entwicklung rechtfertigen, auf der anderen Seite bieten andere ein konfigurationsbasiertes Setup mit niedrigem Code / wenig Touch.

Aus der Perspektive der Lösungsverfügbarkeit sehen wir drei Ansätze. Erstens sind Datenaufnahme-Broker und Speicherplattformen Teil der Suite, die von Anbietern von End-to-End-Horizontal-Cloud-Plattformen wie AWS . angeboten wird &Azur. Diese versuchen, die Komplexität der Infrastruktureinrichtung und -verwaltung, Skalierbarkeit, Hochverfügbarkeit usw. zu vereinfachen. Eine alternative Lösung ist der Kauf vollständig produktiver Plattformen wie C3IoT, Software AG, PTC . Mit produziert meinen wir, dass typische Produktionsanforderungen rund um Administration, Betrieb, Auditing, Integration und Benutzeroberfläche vorgebacken sind.

Die typische dritte Option besteht darin, mit Open-Source-Lösungen wie Rabbitmq, Eclipse Mosquito usw. zu bauen. Insgesamt haben die meisten PaaS- und SaaS-Player ähnliche Angebote in diesem Bereich und typische Überlegungen bei der Auswahl sind Skalierung, kommerzieller, betrieblicher und laufender Wartungs- und Supportservice. Wir sehen diesen Teil der Lösung nicht als starken Kandidaten für den Aufbau eines zentralen Unterscheidungsmerkmals oder Alleinstellungsmerkmals, und aufgrund der Vielzahl verfügbarer Lösungen erwarten wir, dass dieser Teil der Wertschöpfungskette wettbewerbsfähig bleibt und daher nur geringe Chancen hat, dass PaaS oder SaaS Marktmacht missbrauchen . Zusammenfassend können wir dies als wettbewerbsfähigen und standardisierten Raum bezeichnen, wobei PaaS oder SaaS der bevorzugte Entwicklungsmodus ist.

Application Enablement-Plattformen und Analytics-Plattformen können ebenfalls in den Bereich der horizontalen Plattformen eingeordnet werden. Diese Plattformen ermöglichen es Ihrer Lösung, eingehende Daten in Echtzeit oder im Batch / geplant zu verarbeiten. Dies unterscheidet sich von der Datenaufnahmeplattform, da hier nicht alle Plattformen ähnliche Funktionen haben. Als technischer Entscheidungsträger bewertet man normalerweise die Fähigkeit zur Durchführung von Analysen und maschinellem Lernen, Visualisierungsanwendungsentwicklung und Hosting-Funktionen. Erweiterbarkeit durch Integrationen und API-Aufrufe sind eine weitere zu berücksichtigende Dimension. Diese Integration kann mit Umgebungen erfolgen, die monolithisch oder auf Mikrodiensten basieren, Cloud- oder On-Premise-basiert sind.

Einige dieser Lösungen betreten auch den Edge-Bereich, insbesondere für die Edge-Analyse. Sobald der Entscheidungsträger die Anforderungen aus der Perspektive der obigen Dimensionen kennt, kann er sich erneut eine der drei Optionen PaaS-Angebote von Azure &AWS oder Open Source-basierter Build ansehen. Angesichts der Tatsache, dass der Bedarf an Edge- oder Fog-Computing schnell wächst und als der am stärksten wachsende Bereich gilt, ist es für den Lösungsdesigner fast obligatorisch, auch eine klare Edge-Strategie zu haben. Im Edge-Raum könnte man sich Lösungen wie Intel ansehen Movidius-basierte Chipsätze und Edge-Appliances von Dell aus Hardwaresicht und Azure IoT Edge, AWS IoT Greengrass, Software AG Edge Appliance aus Softwaresicht. Im Analyse- und Anwendungsbereich müssen beim Befolgen des dritten Build-Ansatzes Technologien wie Kaa, HDFS, Kafka, Nifi, Mongo DB, Nginx usw. zusammengefügt werden, um eine robuste IoT-Lösung zu ermöglichen.

Insgesamt müssen wir uns aus der Perspektive der Lösungsstrategie der Tatsache bewusst sein, dass SaaS-Player im Analytics-Bereich mit optimierten Lernalgorithmen differenziert werden sollen. Dies schafft die Möglichkeit, dass SaaS-Spieler die Marktmacht später am Tag missbrauchen. Der Entscheidungsträger im Geschäft muss sich auch des Zeit- und Investitionsaufwands für den Build-Ansatz bewusst sein, der möglicherweise nicht der in diesem Bereich entwickelten Differenzierung entspricht. Daher glauben wir, dass der bevorzugte Ansatz hier PaaS für Application Enablement- und Analytics-Engine-Funktionalitäten ist.

Als nächstes folgen die vertikalen spezifischen Anwendungen. Die Lösungsersteller rufen in der Regel verschiedene Funktionalitäten aus dem obigen Katalog der IoT-Plattformen auf, um das Ende der Anwendung zu erstellen. Zum Beispiel könnte die Anwendung in einer Umgebung entwickelt werden, die von der Application Enablement-Plattform bereitgestellt wird, indem Daten von der Datenaufnahmeplattform gesammelt und daraufhin eine Visualisierung auf den von Analytics-Plattformen gewonnenen Trends und Erkenntnissen entwickelt wird. Wenn die Erkenntnisse, die durch dieses kontextbasierte End-to-End-Stitching des Ökosystems generiert werden, ein Problem lösen, dann weiß man, dass ein Wert geschaffen wurde und die Lösung dadurch mit einem starken USP ausgestattet wird.

Dies ist der Bereich, der mit einem relativ viel größeren Business-Objektiv untersucht werden muss. Die Entscheidungsträger müssen beurteilen, ob die Anwendung wertvoll, selten, unvollständig nachahmbar und nicht ersetzbar ist. Aus Sicht der Marktstruktur ist dies ein Bereich, in dem man seinen eigenen Markt definieren und das Monopol genießen kann, daher ist ein Neuaufbau, möglicherweise unter Verwendung von Open-Source-Umgebungen, ein bevorzugter Ansatz. Darüber hinaus erwarten wir aus geschäftlicher Sicht eine hohe Kundenbindung in diesem Bereich, daher ist die Zeit hier von entscheidender Bedeutung, und je früher man mit der gewählten Lösung auf den Markt gehen kann, desto höher sind die Chancen, den USP zur Skalierung zu nutzen.

Insgesamt scheinen aus Sicht der USP-Entwicklung die vertikalen spezifischen Anwendungen mit den zugrunde liegenden angepassten Analysen am besten geeignet zu sein. Aus Sicht der IoT-Plattform-Lösungsstrategie haben wir zwar Empfehlungen für PaaS oder SaaS für die Datenaufnahme, PaaS für Anwendungen und Analysen und Open Source-basierte Builds für vertikale spezifische Anwendungen gegeben, aber wir wissen die immense Bedeutung des Kontexts zu schätzen, der alle Entscheidungen bestimmt. Wenn der Kontext eine schnelle Markteinführung mit Unterstützung einer dedizierten Forschung und Entwicklung erfordert:Saas könnte eine optimale Entscheidung sein. Daher können alle oben genannten Faktoren als allgemeine Richtlinie verwendet werden, aber jeder Anwendungsfall braucht seine eigene Jury und seine eigene Entscheidung.

Die Autoren dieses Blogs sind Arpit Khosla, Gründer von IoT Australia Consulting Services und Praneet Thakur, Berater von IoT Australia Consulting Services