IT-Architektur
Checkliste für eine IoT-Referenzarchitektur
- Die Referenzarchitektur ist ein Guide für eigene Entwicklungen sowie eine Checkliste für IoT-Lösungen von Anbietern.
- Die Referenzarchitektur erlaubt einen neutralen und auf die Anwenderbedürfnisse ausgerichtet Blick auf kommerzielle Lösungen.
Diese Referenzarchitektur (RA) soll einerseits helfen, eigene IoT-Lösungen zu bauen und sie andererseits bei der Bewertung kommerzieller IoT-Lösungen unterstützen. Die Referenzarchitektur ist beides, Guide für eigene Entwicklungen und Checkliste/Bewertungstool für IoT-Lösungen von Anbietern. Außerdem, so die Wahrnehmung des Workstreams, habe ein Anbieter immer eine Herkunft und einen Schwerpunkt. Deshalb brauche es eine neutrale, an den Anwenderbedürfnissen ausgerichteten RA, um kommerzielle Lösungen auch in ihrem Aufbau und ihrer Funktionalität beurteilen zu können.
Fünf Prinzipien der IoT-Referenzarchitektur
Da die Teilnehmer des Workstreams bereits vielfältige eigene Erfahrungen mit IoT-Lösungen und Plattformen gesammelt haben, wurden diese vor der Entwicklung der eigentlichen Referenzarchitektur zu fünf Prinzipien verdichtet, auf denen die RA aufbaut:
1. Unternehmensübergreifend für Ökosysteme: IoT-Lösungen machen nicht halt vor Unternehmensgrenzen. Deshalb ist die RA so aufgebaut worden, dass sie dank API-Management, Integration und Connectivity übergreifend in verschiedenen Ökosystemrollen funktioniert.
2. Anbindung an die Enterprise IT: IoT-Lösungen funktionieren nicht losgelöst von der "klassischen" Enterprise IT. Deshalb muss eine IoT-RA dieses Zusammenspiel berücksichtigen. Wichtig war den Teilnehmern der Arbeitsgruppe vor allem, die Weiterentwicklung der klassischen IT im Zuge der fortschreitenden DigitalisierungDigitalisierung zu berücksichtigen. Da digitale Geschäftsmodelle bei weitem nicht allein über IoT-Lösungen abgewickelt werden können und sollten, sondern auch in der Enterprise IT, muss sich diese den neuen Anforderungen anpassen. Deshalb entwickelt sich die Architektur der klassischen IT ebenfalls weiter und sollte künftig auch Elemente der IoT-Architektur aufweisen. Alles zu Digitalisierung auf CIO.de
3. Inkrementelle Umsetzung der RA: Die Teilnehmer wollten eine Referenzarchitektur schaffen, die sowohl die Elemente enthält, die für Pilotprojekte gebraucht werden als auch solche, die für unternehmensweite IoT-Vorhaben eine Rolle spielen.
4. Schlankheit: Die RA sollte ausschließlich Elemente enthalten, die wirklich für eine IoT-Lösung benötigt werden. Alles, was nur "nice to have" ist, sollte die RA in einem ersten Schritt außen vor lassen.
5. Wiederverwendbarkeit: Die realisierte Architektur auf Basis der RA soll mit wiederverwendbaren Elementen eine möglichst große Zahl von IoT-Anwendungsfällen auf der Unternehmens-Roadmap unterstützen.
Aus diesen Prinzipien haben die Workstream-Teilnehmer folgende Vorgaben für die praktische Arbeit mit der Referenzarchitektur formuliert:
Vorgabe | Erklärung | |
1. | Um eine möglichst hohe Wiederverwendbarkeit sicherzustellen, sollte sowohl in der Edge-Schicht als auch in der Integration-Schicht so wenig wie möglich spezifische Business-Logik oder vendor-spezifische Technologie einfließen. | Ohne festgelegte Business-Logik lassen sich die Devices und ihre Daten nahe der physikalischen Ebene mit Sensoren oder Aktoren für viele verschiedene Dinge einsetzen. Wenn die Mustererkennung in einem Geldauszahlungsautomaten allerdings nur Euro erkennt, kann der Automat nur für die Ausgabe von Euro verwendet werden. |
2. | Im Bereich Monitoring und Infrastruktur sollte besonders großer Wert auf Wiederverwendbarkeit gelegt werden. | Monitoring oder Netzwerk sind IoT-Service agnostisch und sollten deshalb auch für alle Services funktionieren. |
3. | Bei den Edge-Devices und Gateways sollten möglichst wenige Varianten zugelassen werden, ohne die Fähigkeit zu verlieren, neue Devices und Gateways adäquat einsetzen zu können. | Je größer der (unnötige) Variantenreichtum, desto komplexer geraten Schnittstellenmanagement, Betrieb und Monitoring. |
4. | Streaming-Verarbeitung sollte gegenüber Batch-Betrieb der Vorrang gegeben werden. | Für sehr viele IoT Use Cases müssen Daten schnell transportiert und analysiert werden. Ideal ist dann eine Auswertung nahe Echtzeit, wie Streaming das erlaubt. |
5. | Für alle Lösungsbereiche gilt Cloud First. | Das verbessert Skalierbarkeit, Sicherheit, Modularität, Interoperabilität, Integrierbarkeit und Widerstandsfähigkeit. |
6. | Überall dort Standards einsetzen wo möglich und wo angebracht. | Standards machen Systeme tendenziell weniger komplex und bieten tendenziell mehr Unabhängigkeit von einzelnen Lieferanten. |
7. | Offene APIs sollten gegenüber vordefinierten und spezialisierten Plattformen bevorzugt werden. | Spezialisierte Plattformen fördern den Vendor-Lock-in, APIs nicht. Professionelles API-Management macht die zusätzliche Komplexität beherrschbar. |
8. | Vendor-Lock-in gilt es zu vermeiden. | Anwenderunternehmen mit ausreichend eigenem Know-how und eigenen Capabilities sollten zu starke Abhängigkeiten vermeiden, weil sie sonst gerade in Bezug auf neue Technologien und die Umsetzung neuer IoT Use Cases entscheidend gehemmt werden können. |
9. | Daten als Vermögen und wertvollen Rohstoff betrachten. | Daten sind das Ausgangsmaterial für jedes IoT-basierte Geschäftsmodell. Sie sollten daher wie jeder andere wertvolle Rohstoff bewirtschaftet werden. |
10. | Bandbreite muss optimal genutzt werden. | In der IoT-Welt ist Connectivity Trumpf. Hohe verfügbare Bandbreite bedeutet große Verarbeitungsgeschwindigkeit. Diese ist jedoch nicht immer notwendig. Oft sind andere Anforderungen entscheidender. Für die Kosten bspw. ist entscheidend, genau zu wissen, wann welcher Service wie viel Bandbreite benötigt. |
11. | Es muss Security by Design gelten. | Gerade im IoT-Bereich, in dem sich physikalische Welt mit virtueller Welt verbindet, gelten zwar höchste Sicherheitsanforderungen, gleichzeitig lässt das Sicherheitsniveau gerade im physikalischen Bereich zu wünschen übrig. Diese Schwachstellen lassen sich nur einengen, wenn Security von Anfang an berücksichtigt wird. Die RA sieht hierzu diverse wichtige Funktionen vor. |
12. | Software ist wichtiger als Hardware | Im Zeitalter von Cloud, DevOps und Zero-Code-Entwicklungen eigentlich eine Binsenweisheit, aber wenn es um Priorisierung von Investitionsentscheidungen geht, gibt diese Einsicht Orientierung. |
Die Architektur steht auf drei Säulen
Die Architektur steht auf den drei vertikalen Säulen Edge-, Integration- und Enterprise Tier. In diese quasi eingehängt werden die säulen-übergreifenden Ebenen Infrastructure-Management, Monitoring und Engineering. Hinzu kommen ein Security Layer, ein API-Management, ein Third Party Ecosystem- und ein Netzwerk-Layer (siehe Grafik).
Foto: CAB Lab
In der Edge-Säule befinden sich die digital erweiterten (zum Beispiel mit Sensoren und Aktoren ausgestatteten) physischen Dinge, ihr Monitoring, das sie betreffende Infrastruktur-Management sowie die entsprechende Connectivity, welche die Devices mit dem Integration Layer verbindet.