Architektur trifft auf Digitalisierung

Mit einer bloßen Zusammenstellung von Technologien ist es bei Digitalisierungsprojekten nicht getan. Selbst der Einsatz der vielversprechendsten Technologien im Sinne eines Best-of-Breed-Ansatzes kann nicht garantieren, dass die für das Problem entwickelte Lösung die funktionalen und nichtfunktionalen Anforderungen erfüllt. Noch dazu erweisen sich Technologien und Trends als sehr schnelllebig, sodass die optimale Lösung von heute schon morgen obsolet sein könnte. Deshalb gehört zu einer Digitalisierungslösung immer eine tragfähige sowie nachhaltige System- und Softwarearchitektur. Die entscheidende Frage für Projekte lautet daher: Wie genau erhalten wir eine entsprechende Architektur, die unseren Bedürfnissen genügt?

Das Spiel der Kräfte

Um die sinnvollsten architektonischen Digitalisierungskonzepte zu eruieren, sollten zunächst die Kräfte im Vordergrund stehen, die auf Digitalisierungslösungen einwirken. Bei diesen Systemen handelt es sich im Normalfall um große Systeme von Systemen, die unter anderem mobile Geräte, Cloud-Lösungen, Edge-Geräte, IoT-Knoten mit Sensorik und Aktuatorik sowie natürlich eine Internet-Anbindung über diverse Kommunikationsprotokolle umfassen. Linda Northrop vom CMU SEI (Carnegie-Mellon University Software Engineering Institute) hat für solche Systeme von Systemen die folgenden Aspekte identifiziert [Wiki]:

Dezentralisierung: Nicht nur aus Skalierungs- und Fehlertoleranzgründen müssen die Systeme dezentral funktionieren. Die Abhängigkeit von zentralen Servern ist in diesem Zusammenhang ein klares No-Go, was aber im Umkehrschluss nicht heißt, es darf überhaupt keine zentralen Dienste mehr geben.

Anforderungsproblem: Da in diesen komplexen Systemen von Systemen viele Teilsysteme und Beteiligte partizipieren, entstehen Anforderungskataloge mit einer hohen Diversität von Erwartungen, die noch dazu in Konflikt stehen können. Zusätzlich sind nicht alle Anforderungen initial bekannt oder explizit beziehungsweise offensichtlich.

Kontinuierliche Evolution und kontinuierliches Deployment: Ständiges Kommen und Gehen gehört bei industriellen Systemen zum Regelfall. Dazu zählen unter anderem Updates oder Neuinstallationen von Diensten, Anwendungen oder Firmware. Stillstandzeiten oder Wartezeiten verbieten sich, weshalb das Softwareengineering sich entsprechend darauf einstellen muss.

Panta rhei: Die einzelnen Komponenten einer großen Digitalisierungslösung weisen in der Regel eine hohe Heterogenität auf. Alte Komponenten verschwinden oder werden ersetzt, neue kommen hinzu. Zudem befinden sich nicht notwendigerweise alle Komponenten in einem konsistenten Zustand.

Erosion der Mensch/Maschine-Schnittstelle: Dank tiefgreifender Digitalisierung weicht die Schnittstelle zwischen Mensch und Maschine zunehmend auf. Maschinen übernehmen Aufgaben, die bislang Menschen vorbehalten waren. Moderne Ansätze machen zudem aus Menschen integrale Bestandteile von Digitalisierungsprozessen, um Medienbrüche zu vermeiden.

Fehler als Regelfall: Natürlich kommt es in großen, komplexen Systemen unweigerlich zu Fehlern und Ausfällen. Die Kunst der Digitalisierung besteht darin, mit diesen Situationen gekonnt umzugehen. Fällt zum Beispiel eine Maschine oder ein Dienst aus, muss das Gesamtsystem den Ausfall schnell und gut kompensieren.

Neue Konzepte für Akquisition und Richtlinien: Dezentrale, hochgradig verteilte Systeme erfordern andere Methoden, um benötigte Ressourcen zu akquirieren, als kleine zentralistische Systeme. Das gilt in gleicher Weise für Richtlinien aller Art, etwa solche bezüglich Akquisition oder solche in Hinblick auf Datensicherheit. Das Beispiel Blockchain veranschaulicht, wie sich vertrauenswürdige Transaktionen auch dezentral bewerkstelligen lassen.

Emergentes Verhalten: Das Ganze ist mehr als die Summe seiner Teile, speziell wenn es sich um ein hochkomplexes Zusammenspiel von Systemen handelt, bei denen sich nicht jedes Verhalten deterministisch planen lässt. Stattdessen basieren Systeme von Systemen auf lokalem Verhalten und auf lokalen Regeln, aus denen sich im Gesamtsystem emergentes Verhalten ergibt.

Die Eierlegende-Wollmilchsau-Architektur

Eine naheliegende Lösung könnte theoretisch darin bestehen, eine Standardarchitektur für die Digitalisierung zu entwickeln. Diese böte die Möglichkeit, als Blaupause für Digitalisierungsanwendungen zu dienen. Tatsächlich existieren solche Ansätze bereits. Einer davon heißt MASA (Mesh App and Service Architecture) und stammt aus der Feder von Gartner Research [Gar].

Auch wenn die MASA-Architektur brauchbare Konzepte enthält, lässt sie sich nicht ohne erheblichen Aufwand umsetzen. Zum einen bietet der Vorschlag keine echte Architektur, sondern „lediglich“ Konzepte und Strukturierungsvorschläge. Architekten müssen MASA sowohl auf ihre konkrete Problemdomäne als auch auf die beabsichtigte Lösungsdomäne abbilden. Eine Digitalisierungslösung für Züge hat nun mal andere Anforderungen als eine Lösung für Fabrikautomatisierung. Zum anderen sind die eingeführten Konzepte sehr generisch, lassen daher konkrete Umsetzungsdetails vermissen. Anders ausgedrückt, existieren schier unzählige Möglichkeiten, MASA umzusetzen, egal ob auf der Problemdomäne oder auf der Lösungsdomäne.

One-size-fits-all durch Ökosysteme

Eine weitere Alternative ist das Verwenden eines herstellerspezifischen Ökosystems, wenn die daraus resultierende Abhängigkeit sich mit den eigenen Zielen verträgt. Zu den möglichen Herstellern gehören große Unternehmen für Internet- und Geschäftsanwendungen wie Amazon (s. Abb. 1), Alibaba, Google, Microsoft, SAP, IBM und Oracle, Chiphersteller à la Intel oder ARM, und Industrieunternehmen wie Siemens oder GE. Jedes der genannten Unternehmen fokussiert sich natürlich primär auf die eigenen Kundendomänen, beispielsweise Intel auf verteilte eingebettet Systeme und Siemens auf die Industrie. Mittlerweile verschwimmen die Grenzen aber immer mehr.

Wenn die Herstellerabhängigkeit kein Problem darstellt, kann die Auswahl des passenden Ökosystems nach diversen technischen und nichttechnischen Aspekten erfolgen. In jedem Fall empfiehlt es sich, einen entsprechenden priorisierten Kriterienkatalog zu entwickeln, um daraus mögliche Alternativen abzuleiten.
Technische beziehungsweise inhaltliche Facetten können zum Beispiel sein

• das funktionale und nichtfunktionale Profil der eigenen Problemdomäne und
• die gewünschten Paradigmen und Technologien auf der Lösungsseite wie Cloud-Computing, Serverless-Computing, Integration bestimmter Software- oder Hardwarekomponenten, Support für Container und deren Orchestrierung, KI-Lösungen für Datenanalytik, Bildanalyse oder Sprachverarbeitung, Streamingund Persistenzlösungen, Entwicklungsumgebungen, Wartbarkeitslösungen, DevOps-Unterstützung, Testbarkeit, Transparenz, API-Management, verfügbare Data-Layers, unterstützte Standards wie OpenShift, zu integrierende Hardwarearchitekturen.

Zu den nichttechnischen Aspekten zählen unter anderem:

• Kosten von Entwicklung und Betrieb,
• Standardisierung der vorhandenen Lösungen,
• Strategie des Herstellers,
• Größe des Herstellers sowie seine Erfahrung,
• Governance-Richtlinien,
• Customizierbarkeit des Ökosystems,
• Flexibilität des Herstellers,
• Lernkurven,
• Success Stories anderer Kunden,
• Kundenservice und technischer Service,
• SLAs und KPIs.

Während sich Architekten um technische Aspekte kümmern, sollten Produktmanagement, strategische Ebene und Entwicklungsleiter die nichttechnischen Fragen klären.
Passt die ausgewählte Herstellerlösung zur eigenen Strategie und zum eigenen Anforderungsprofil, ist aber nur ein kleiner Teil der Arbeit getan. So müssen Architekten immer noch die architektonische Umsetzung der Problemdomäne leisten. Und diese Arbeit ist bekanntlich alles andere als trivial. Doch dazu gleich mehr.

Muster-Lösungen

Um eine Architektur für industrielle IIoT-Systeme zu erstellen, gibt es mittlerweile Systeme diverser Softwarepatterns. Ein Pattern liefert bekanntlich eine bewährte Lösung für ein häufig wiederkehrendes Problem in einem bestimmten Problemkontext. Diese Lösung muss sich schon in mindestens drei voneinander unabhängigen Anwendungen bewährt haben. Natürlich darf es sich um kein triviales Problem handeln, dessen Lösung mühelos ableitbar ist.

Der große Vorteil von Patterns beziehungsweise Mustern liegt in ihrer Konkretheit. Sie geben im Gegensatz zu UML- oder Sys-ML-Diagrammen konkrete Hilfestellung, wie sich im Detail einzelne Probleme aus der realen Welt lösen lassen. In Abbildung 2 finden sich beispielhaft Mustersysteme, die in Bezug auf Digitalisierung relevant sind:

• IIoT-Foundation umfasst grundlegende Muster für Betrieb (Operations), Energieversorgung (Power Management), Messwerterfassung (Sensing) von verteilten IoT-Knoten sowie für Edge-Computing (Edge Nodes).
  
• Clouds und Services adressiert Probleme aus dem Kontext von Cloud-Computing und Diensten beziehungsweise Microservices.
• Smart Systems enthält Patterns für die Einbindung von KI-Algorithmen.
  
• Decentralized Systems gibt Hilfestellung für Dezentralisierung

Eine Warnung vorab: Weder geben die abgebildeten Kästen alle relevanten Patternsysteme wieder noch sind sie in sich vollständig. Das ist dem Größenrahmen eines Artikels geschuldet. Vielmehr sollen sie einen Eindruck verschaffen, welche Muster heute bereits existieren.
An dieser Stelle sollen einzelne Muster exemplarisch zur Sprache kommen. Die ersten vier stammen vom Stuttgarter Institute of Architecture of Application Systems [IAAS] und adressieren das Internet der Dinge, während sich das fünfte, Command and Query Responsibility Segregation [CQRS], (nicht nur) für dezentrale verteilte Systeme eignet [Fow11]. Zu guter Letzt folgt ein Muster für die Integration von KI-Komponenten.

Für die IoT-Muster und CQRS finden sich am Schluss des Artikels entsprechende Quellenangaben.

Device Gateway
Problem: Mehrere IoT-Knoten mit limitierter CPU-Geschwindigkeit und limitierten Kommunikationsmöglichkeiten brauchen gelegentlich Verbindung zum Netzwerk.

Lösung: Ein lokaler Edge-Knoten mit entsprechender CPU-Power und mit Netzwerkverbindung fungiert als Gateway (s. Abb. 3). Er nimmt Kommunikationsanfragen von den benachbarten IoT-Knoten über Low-Power-Protokolle entgegen und führt stellvertretend deren Kommunikation mit dem Internet durch.

Beispiel: In Zügen eines Schweizer Bahnunternehmens findet sich pro Waggon je ein Beacon, dessen Aufgabe es ist, mit den Mobilgeräten der Passagiere im Waggon zu interagieren. Es gibt einen zentralen Server im Zug, den Gateway, der für die Beacons über das Internet mit zentralen Backend-Diensten kommuniziert. Das geschieht zum Beispiel, um das Ticketing durchzuführen.

Device Shadow
Problem: Einige Geräte sind wegen eingeschränkter Funktionalität oder aus Stromspargründen häufig offline. Wie lässt sich mit diesen Geräten trotzdem zu jeder Zeit interagieren?

Lösung: Das System enthält Schattenobjekte, eines für jedes Gerät, dessen Zustand es persistent im Backend ablegt (s. Abb. 4). Aufrufer kommunizieren mit dem Schattenobjekt statt mit dem echten Gerät. Sobald das Gerät online geht, synchronisiert es sich mit seinem Schattenobjekt, nimmt dort gespeicherte Aufträge entgegen, führt diese aus, und legt seinen neuen Zustand persistent ab. Geht das Gerät offline, setzt es ein entsprechendes Flag im Schattenobjekt.

Beispiel: AWS IoT [AWS] speichert persistente virtuelle Versionen jedes angeschlossenen Geräts.

CQRS (Command-Query-Responsibility-Segregation)
Problem: In konventionellen Architekturen verwenden Entwickler das gleiche (CRUD-)Datenmodell zum Abfragen und Aktualisieren von Datenbanken. In dezentralen, verteilten Systemen führt diese Vermischung von Verantwortlichkeiten zu hoher Komplexität. Stattdessen laufen Lese- und Schreiboperationen oft asymmetrisch ab.

Lösung: Beim CQRS-Modell gibt es unterschiedliche Modelle für Lesen und Schreiben (s. Abb. 5). Datenbank-Kommandos sind aufgabenzentriert statt datenzentriert. Sie landen asynchron in einer Warteschlange, aus der sie das Zielsystem entnimmt und einer synchronen Verarbeitung zuführt. Bei reinen Abfragekommandos kommt es zu keiner Änderung der Datenbank.

Eine noch stärkere Isolation lässt sich durch physisches Trennen der Lesedaten von den Schreibdaten erzielen, was aber eine Synchronisation erfordert, indem beispielsweise das Schreibmodell bei Änderungen Ereignisse veröffentlicht. Durch diese Segregation können beide Modelle auch unterschiedliche Skalierungsanforderungen erfüllen. So gibt es im Normalfall wesentlich mehr Lese- als Schreibanfragen.

Beispiel: Bei der Konfiguration von CT-Scannern mittels Scan-Protokollen kommt CQRS zum Einsatz.

Es sind in diesem Artikel zwar nur ein paar Muster beschrieben, aber die Beispiele verdeutlichen, welche Vorteile Architekten erzielen, wenn sie auf entsprechende Muster-Systeme zurückgreifen. Das Rad neu zu erfinden, ist nicht sinnvoll, wenn erfahrene Experten für Teilprobleme oder ganze Subdomänen schon entsprechende Lösungen entwickelt haben. Die Patterns erleichtern den Entwurf einer Digitalisierungslösung jedenfalls signifikant.

Neben diesen spezialisierten Mustern eignen sich natürlich auch die bekannten Softwaremuster aus der Patternswelt für die Anwendung in Digitalisierungskontexten. Einen Überblick über Aktivitäten und Informationsquellen finden interessierte Leser auf der Webseite der Patterns-Community [hill].
Bisher standen architektonische Aspekte im Vordergrund, aber Digitalisierung hat auch Auswirkungen auf Entwicklungsprozesse.

Kurzer Prozess

Nicht nur SaaS-Lösungen erfordern eine schnelle Umsetzung von Wartungs- und Evolutionsaktivitäten, sondern generell alle Lösungen für industrielle Automatisierung mit kurzen Zykluszeiten. Ein agiler Entwicklungsprozess ist dabei nur eine Seite der Medaille. Die andere Seite besteht aus dem zeitnahen Umsetzen von Änderungen, zunächst auf Test- und Entwicklungsumgebungen, schließlich auf der Produktionsumgebung – also alles im Sinne von DevOps. Dadurch reduzieren sich Lead-Times und Cycle-Times signifikant (s. Abb. 6).

Mittels A/B-Testing lassen sich Hypothesen prüfen, etwa die, ob Anwender einen neuen Dienst häufig oder selten nutzen. Feature Toggles erlauben das gezielte Ab- oder Hinzuschalten von Funktionalität. Auch dem agilen Prozess gebührt besondere Aufmerksamkeit. Der darf sich nämlich nicht nur auf Entwicklungstätigkeiten beschränken, sondern muss sich über die gesamte Organisation erstrecken (s. Abb. 7) von der Strategieebene, über die Produktebene bis hin zur Entwicklungsebene. Andernfalls bleibt die agile Entwicklung im starren Korsett einer klassischen Organisation gefangen. Aus strategischen Entscheidungen leitet die Organisation agil Änderungen ihrer Produkte oder Lösungen ab, deren Umsetzung in verschiedenen agilen Projektteams erfolgt.

Entwicklungsteams sollten dabei auf gute Durchmischung der Rollen achten, zum Beispiel Projektleiter, Architekten, Entwickler, Tester, DevOps in jedem Team. Passiert dies nicht, kommt es unweigerlich zu Wartezeiten, etwa zwischen Entwicklung und Betrieb. Es kristallisiert sich als idealer Ansatz heraus, wenn jedes Team die volle Verantwortung für eine in sich abgeschlossene Funktionalität übernimmt, beispielsweise einen Microservice oder ein Subsystem.

Amazon setzt übrigens in diesem Zusammenhang auf die Zwei-Pizzas-Strategie, wonach die Teamgröße so bemessen sein soll, dass alle Team-Mitglieder mit zwei großen amerikanischen Pizzen gut gesättigt werden können.

Zusammenfassung

Das Entwickeln von Digitalisierungslösungen für die Industrie obliegt stringenten Rahmenbedingungen und Anforderungen, etwa was die Zykluszeiten, Heterogenität und Komplexität der Problemund Lösungsdomänen betrifft. Das Ganze steigert sich um Größenordnungen, sobald Produktlinien mit ihren hohen Commonality/ Variability-Anforderungen ins Spiel kommen.

Allgemeine Architekturmodelle wie MASA geben den Architekten zwar entsprechende Konzepte in die Hand, kratzen aber nur an der Oberfläche. Herstellerspezifische Ökosysteme wiederum bieten alles aus einer Hand, führen aber zu Vendor-Lock-ins und bisweilen zu ökonomischen Herausforderungen. Zudem erweist sich die Qual der Wahl bezüglich des am besten geeigneten Ökosystems als echte Herausforderung, der sich nur durch Anwenden eines priorisierten Kriterienkatalogs begegnen lässt.

In allen Fällen bleibt der eigenen Organisation die Aufgabe, die eigene Problemdomäne sauber und agil zu modellieren und zu betreiben, wofür sich entsprechende Methoden wie Domain-Driven Design, DevOps und Scaled Agile Prozesse eignen.
Für das Architekturdesign an sich existieren entsprechende Softwaremuster zum Beispiel für Dezentralisierung, Edge-Computing, Cloud-Computing, Künstliche Intelligenz, Interaktion von IIoT-Komponenten, Sicherheit und vieles mehr.

Die inhärente Komplexität solcher Systeme von Systemen bleibt also gleich, aber zumindest lässt sich die unabsichtliche Komplexität (Accidental Complexity) durch gezielten Einsatz der genannten Methoden und Technologien minimieren. Es ist daher nicht sinnvoll, Digitalisierungsaktivitäten zu verzögern und währenddessen auf eine Silver Bullet zu hoffen.

Literatur und Links

[AWS]
Amazon AWS Architektur,
https://aws.amazon.com/de/architecture/

[CQRS]
https://docs.microsoft.com/de-de/azure/architecture/patterns/cqrs (Microsoft)

[DDD]
Eric J. Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison Wesley, 2003

[For17]
N. Ford, R. Parsons, P. Kua, Building Evolutionary Architectures: Support Constant Change, O‘Reilly, 2017

[Fow11]
Informationen zum CQRS-Muster,
https://martinfowler.com/bliki/CQRS.html (Martin Fowler)

[Gar]
Gartner MASA Architecture,
https://www.gartner.com/en/documents/3980382/masa-how-to-create-an-agile-applicationarchitecture-wit

[hill]
https://hillside.net/

[IAAS]
IoT-Patterns der Universität Stuttgart,
https://www.iaas.uni-stuttgart.de/publications/INPROC-2016-46-Internet-of-Things-Patterns.pdf

[Sie]
Siemens MindSphere Architektur,
https://developer.mindsphere.io/concepts/concept-architecture.html

[Ven18]
G. Veneri, A. Capasso, Hands-On Industrial Internet of Things: Create a powerful Industrial IoT infrastructure using Industry 4.0, Packt Publishing, 2018

[Wiki]
https://en.wikipedia.org/wiki/Ultra-large-scale_systems