Seminar IPCEI-CIS: Architektur und interoperable Cloud-Edge-Systeme

Die Referenzarchitektur ICRA liefert eine gemeinsame Sprache für verteilte Cloud-Edge-Systeme. Das Seminar zeigt, wie daraus eine konkrete Architektur mit klaren Systemgrenzen, Zuständigkeiten und überprüfbaren Qualitätsanforderungen entsteht. Die Zuordnung von Fähigkeiten zu Komponenten wird mit der Entscheidung verbunden, welche Funktionen für einen Anwendungsfall tatsächlich erforderlich sind.

Im Mittelpunkt steht ein mehrstufiger Architekturentwurf für eine Organisation mit lokalen Datenquellen und mehreren möglichen Dienstanbietern. Bestehende Systeme, Integrationsaufwand, Sicherheitsgrenzen und betriebliche Abhängigkeiten fließen gleichberechtigt in die Entscheidungen ein. Die Übungen verwenden selbst entwickelte Modelle und ausgewählte offene Schnittstellen als Anschauungsmaterial.

Lernziele

• Geschäftliche und technische Anforderungen in ein konsistentes Cloud-Edge-Zielbild überführen.
• Komponenten, Datenwege, Identitäten und Schnittstellen über Anbietergrenzen hinweg beschreiben.
• Architekturentscheidungen durch Testkriterien für Portabilität, Betrieb und Ausfallsicherheit absichern.

Seminarinhalte

1. Anforderungen und Systemgrenzen
2. ICRA als Strukturierungsmodell
3. Dienstgrenzen und Schnittstellenverträge
4. Verteilte Daten und Vertrauensgrenzen
5. Portabilität und Störfallarchitektur
6. Architekturwerkstatt und Review

1. Anforderungen und Systemgrenzen

Erhebung funktionaler Anforderungen und messbarer Randbedingungen für Latenz, Verfügbarkeit, Datenhaltung und Wiederherstellung. Trennung von fachlicher Leistung und technischer Bereitstellung. Dokumentation bestehender Abhängigkeiten und kritischer Datenwege; Festlegung des Geltungsbereichs eines realistischen ersten Architekturentwurfs.

2. ICRA als Strukturierungsmodell

Einordnung der Schichten für Anwendungen, Daten, KI, Service-Orchestrierung, Plattform, Virtualisierung, Netz und Hardware. Verknüpfung mit Föderation, Management, Sicherheit und Nachhaltigkeit. Zuordnung vorhandener Fähigkeiten zu den benötigten Funktionen und begründete Zusammenfassung von Komponenten für einen überschaubaren Pilotaufbau.

3. Dienstgrenzen und Schnittstellenverträge

Beschreibung von Operationen, Datenmodellen, Versionierung, Fehlerfällen und Verantwortlichkeiten an ausgewählten Funktionsschnittstellen. Abgleich fachlicher Anforderungen mit verfügbaren Implementierungen. Bewertung von synchronen Aufrufen, asynchronen Ereignissen und wiederholbaren Provisionierungsschritten anhand kleiner, nachvollziehbarer Beispielverträge.

4. Verteilte Daten und Vertrauensgrenzen

Modellierung von Identitäten, Mandanten, Schlüsselverantwortung und Datenflüssen. Prüfung der Folgen lokaler Verarbeitung, zentraler Aggregation und verteilter Speicherung. Entwurf von Kontrollpunkten für Zugriff, Protokollierung und Datenexport sowie Bewertung der Auswirkungen temporär getrennter Standorte.

5. Portabilität und Störfallarchitektur

Unterscheidung von neuem Deployment, Datentransfer und unterbrechungsarmer Migration. Ermittlung anbieterabhängiger Funktionen und der Voraussetzungen eines Wechsels. Ableitung von Tests für fehlende Ressourcen, gestörte Verbindungen, inkonsistente Zustände und Wiederanlauf; Festlegung akzeptabler Restabhängigkeiten.

6. Architekturwerkstatt und Review

Zusammenführung von Komponentenbild, Schnittstellenübersicht, Datenflussmodell und Entscheidungsprotokollen. Gegenseitige Prüfung anhand eines einheitlichen Kriterienkatalogs. Überführung wesentlicher Risiken in konkrete Arbeitspakete und Testfälle, damit die Architektur als Grundlage für Infrastrukturaufbau und Integration dienen kann.

Praxisworkshop

1. Anforderungen des Beispiels priorisieren und messbare Qualitätsziele formulieren.
2. Benötigte Funktionen den Architekturbausteinen zuordnen und Anbietergrenzen markieren.
3. Einen Dienstvertrag mit Datenmodell, Operationen und definierten Fehlerantworten ausarbeiten.
4. Ein Ausfall- und ein Wechselszenario durchspielen und Nachweiskriterien festlegen.
5. Den Entwurf im Review prüfen und offene Entscheidungen in Arbeitspakete überführen.

Schulungsumgebung

Die Schulungsumgebung wird vom Kunden bereitgestellt. Arbeitsplatz mit Diagrammwerkzeug, Texteditor und Browser; vorbereitete Dienstbeschreibungen, OpenAPI-Beispiele und anonymisierte Architekturunterlagen. Ein produktiver Anbieterzugang ist nicht erforderlich.

Die benötigten Softwarestände, Berechtigungen, Testdaten und Rücksetzmöglichkeiten werden vor Seminarbeginn abgestimmt und geprüft. Übungen erfolgen ausschließlich in freigegebenen Testumgebungen.