Über unsMediaKontaktImpressum
Prof. Dr. Michael Stal 26. Mai 2020

Architektur trifft auf Digitalisierung

Lösungen für die Digitalisierung sind oft sehr komplex, speziell im Falle industrieller IoT-Anwendungen (IIoT = Industrial Internet of Things). Es handelt sich zumeist um große langlebige Systeme von Systemen mit heterogener Hardware, Cloud-Einbindung und Integration diverser Datenquellen. Noch dazu unterliegen sie stringenten Qualitätsanforderungen wie Skalierbarkeit und Sicherheit. Ohne die richtige architektonische Basis und weitere Gegenmaßnahmen entwickeln sich solche Lösungen schon kurzfristig zu Wartungs-Alpträumen.

Motivation

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 morgen schon 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, Cloudlösungen, Edge-Geräte, IoT-Knoten mit Sensorik und Aktuatorik sowie natürlich eine Internetanbindung ü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 [1]:

  • 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 bzw. 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 z. B. 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 [2]. Darauf soll nun ein genauerer Blick erfolgen:

Von großer Höhe betrachtet, besitzt MASA drei Ebenen (s. Abb. 1a):

  • Anwendungen laufen auf verschiedenen Endgeräten und greifen über APIs auf Dienste zu.
  • APIs bilden die Brücke zwischen Diensten und Anwendungen.
  • Dienste stellen Backend-Funktionalität zur Verfügung.

Dienste untergliedern sich dabei abhängig von ihrer Granularität (s. Abb. 1b) in

  • Macroservices, die Zugriff auf komplette Anwendungen offerieren, etwa auf E-Commerce-Systeme,
  • Miniservices für den Aufruf höherwertiger Funktionalität wie zum Beispiel einer Auftragsverarbeitung, und
  • Microservices für domänenspezifische Dienste wie einen Einkaufswagen.

MASA untergliedert APIs in zwei Schichten (s. Abb. 1c), wobei Outer APIs die benutzerspezifische Sicht von Anwendungen widerspiegeln. Über eine Vermittlungsschicht transformiert die Architektur Aufrufe der Outer APIs in solche der dienstspezifischen Inner APIs, um das Problem von Client-First versus Implementation-First APIs zu umschiffen.

Die MASA-Architektur stellt gleichzeitig eine ereignisorientierte Architektur dar (s. Abb. 1d), die beim Auftreten von Ereignissen in Abhängigkeit von Regeln beziehungsweise Entscheidungen bestimmte Reaktionen initiiert.

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 nunmal 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.

Offensichtlich kratzt MASA also nur an der Oberfläche. Die Frage lautet somit: Gibt es andere Optionen?

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. 2), 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 Embedded Systeme oder 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 nicht-technischen Aspekten erfolgen. In jedem Fall empfiehlt es sich, einen entsprechenden priorisierten Kriterienkatalog zu entwickeln, um daraus mögliche Alternativen abzuleiten.

Technische bzw. 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, Streaminglösungen, Persistenzlösungen, Entwicklungsumgebungen, Wartbarkeitslösungen, DevOps-Unterstützung, Testbarkeit, Transparenz, API-Management, verfügbare Datalayers, 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.

Evolutionäre Architekturen

Wie bereits erwähnt, unterliegen Digitalisierungslösungen überwiegend einem hohen Druck zu Erweiterbarkeit und Wartbarkeit. Um Evolution zu gewährleisten, gibt es verschiedene architektonische Maßnahmen:

Die Größen einzelner Architekturkomponenten sollten so klein wie möglich bzw. sinnvoll sein, um bei Änderungen immer nur kleine Teile der Architektur anfassen zu müssen.

Eine möglichst geringe Kopplung zwischen den Architekturkomponenten sorgt dafür, dass bei Änderungen die Wechselwirkung mit anderen Komponenten gering bleibt.

Architekten richten ihre Entscheidungen lieber anhand der benötigten Funktionalität in der Problemdomäne aus, anstatt anhand der verwendeten Technologien. Im Gegensatz zur Problemdomäne ändert sich die Lösungsdomäne erfahrungsgemäß wesentlich öfter. Statt auf Wiederverwendung zu setzen, empfiehlt sich eine Duplikation, um Komponenten stärker unabhängig zu halten.

Subdomänen sollten den für sie geeigneten Technologiestack verwenden, anstatt die One-Size-Fits-All-Karte auszuspielen. Um nicht mit einer unüberschaubaren Anzahl von Technologiestacks zu enden, ist die Goldilocks-Strategie sinnvoll [3]: Beispielsweise durch Vorgabe je eines Technologiestacks für kleinere, mittlere und große Subdomänen.

Zur schnellen Erkennung architektonischer Verletzungen sollten schon zur Testzeit entsprechende Fitnessfunktionen (=Testfunktionen) vorhanden sein. Eine Fitnessfunktion könnte zum Beispiel testen, ob die Implementierung ungewollte Abhängigkeiten enthält, ob sich Lizenzen von Open-Source-Paketen verändert haben oder ob Entwickler architektonische Richtlinien umgangen haben. Ein Beispiel für ein Architekturpattern, das diese Eigenschaften begünstigt, sind Microservice-Architekturen.

Da Lösungen meistens nicht auf der grünen Wiese starten können, sondern bestehenden Legacy-Code integrieren müssen, ist eine schrittweise Transformation bestehender Artefakte hin zu besserer Erweiterbarkeit vonnöten.

Dafür gibt es verschiedene Strategien: Architekten könnten zuerst die Transformation der Low Hanging Fruits angehen, also der Subsysteme, die sich am leichtesten umformen lassen. Eine andere Option ist, mit der Transformation von Artefakten zu beginnen, die den höchsten geschäftlichen Wert besitzen. Schließlich könnte die Wahl auf solche Subsysteme fallen, die bereits vorher die meisten Probleme verursacht haben, weil sie zum Beispiel ungenügende Testabdeckung oder viele andere Baustellen enthalten.

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 Mustern liegt in ihrer Konkretheit. Sie geben im Gegensatz zu UML- oder SysML-Diagrammen konkrete Hilfestellung, wie sich im Detail einzelne Probleme aus der realen Welt lösen lassen. In Abb. 3a 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 bzw. 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 [4] und adressieren das Internet der Dinge, während sich das fünfte, CQRS, (nicht nur) für dezentral verteilte Systeme eignet [5]. Zu guter Letzt folgt ein Muster für die Integration von KI-Komponenten, welches der eigenen Erfahrung des Autors entsprungen ist.

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. 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. 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 speichert persistente virtuelle Versionen jedes angeschlossenen Geräts.

Device Wakeup Trigger

Problem: Bei bezüglich der Energieversorgung limitierten Geräten nutzen Entwickler häufig den Schlafmodus der Microcontroller, um Energie zu sparen. Was aber soll passieren, wenn eine wichtige Anfrage ein solches schlafendes Gerät erreicht?

Lösung: Es sollte Servern möglich sein, eine Nachricht über einen Low-Energy-Kommunikationskanal an das Gerät zu senden. Sobald eine solche Nachricht eintrifft, wacht das Gerät automatisch auf und etabliert eine Kommunikation mit dem betreffenden Server.

Beispiel: Es gibt verschiedene Protokollimplementierungen für LTE und UMTS, die ein solches Vorgehen implementieren.

Rules Engine

Problem: Während der Laufzeit erhalten Systeme viele Nachrichten von Geräten und anderen Komponenten, auf die sie unterschiedlich reagieren müssen.

Lösung: Alle eintreffenden Nachrichten laufen zunächst durch eine Rules Engine, in der Anwender abhängig von Nachrichten-Metadaten gewünschte Aktionen definieren können, die zur Laufzeit somit automatisiert ablaufen. Auch externe Daten können übrigens an der Regelauswertung beteiligt sein.

Beispiel: Node-Red und IFTTT enthalten entsprechende Ansätze, die sich zum Beispiel mit der Action Engine von IBM IoT Real-Time Insights kombinieren lassen.

Während die bisher genannten Muster hauptsächlich den Betrieb von IoT-Geräten adressieren, spielt CQRS in dezentralen Systemen eine wichtige Rolle, obwohl es sich nicht ausschließlich auf solche Systeme beschränkt.

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. 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.

KI-Agenten

Problem: Bei der Integration von KI-Komponenten wie Künstlichen Neuronalen Netzen findet oft keine Trennung zwischen Inferenz und Datenverarbeitung statt. Dadurch lässt sich das eine nicht vom anderen trennen, wodurch Änderungen der Funktionalität mit großen Aufwänden verbunden sind.

Lösung: Durch Abkapselung der KI-Funktionalität in einer Blackbox entstehen Agenten, die sich nur über fest definierte Schnittstellen aufrufen lassen. Die Aggregation, Bereitstellung und Vorverarbeitung der Eingabeparameter erfolgt ebenso wie die Bereitstellung und Verteilung der Ergebnisse über das Pipes-&-Filters-Pattern. Dadurch ist eine Segregation von KI-Inferenz und Datenverarbeitung möglich, sodass sich Änderungen des einen nicht auf das andere auswirken. Zudem lassen sich in Projekten die Rollen besser trennen, indem für die Bereitstellung der KI Wissensingenieure und für den Entwurf der Datenverarbeitung Architekten Verantwortung erhalten.

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, macht keinen Sinn, 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 Patternwelt für die Anwendung in Digitalisierungskontexten. Einen Überblick über Aktivitäten und Informationsquellen finden interessierte Leser auf der Webseite der Patterns-Community [6].

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.

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.

Als erster Schritt beim Entwurf von Digitalisierungslösungen bewährt sich Domain-Driven Design. Dessen Muster und Strategien ermöglichen die Entwicklung einer einheitlichen Sprache zwischen den verschiedenen Beteiligten (Ubiquituous Language) und eine geschickte Aufteilung der Problemdomäne in Subdomänen (Bounded Contexts), sowie deren Abgrenzung und Beziehung.

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. 10) 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, z. B. Projektleiter, Architekten, Entwickler, Tester und 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 sollte, 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 Problem- und 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 [2]. 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 z. B. 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 macht daher keinen Sinn, Digitalisierungsaktivitäten zu verzögern und währenddessen auf ein Silver Bullet zu hoffen.

Quellen
  1. Wikipedia: Linda Northrop: Ultra-large-scale Systems
  2. Gartner: MASA Architecture
  3. Wikipedia: Goldilocks principle
  4. IoT-Patterns des Stuttgarter Institute of Architecture of Application Systems: Internet of Things Pattern
  5. Martin Fowler: CQRS
    Microsof: CQRS
  6. Webseite der Patterns-Community

Autor

Prof. Dr. Michael Stal

Prof. Dr. Michael Stal beschäftigt sich bei der Corporate Technology der Siemens AG mit Software- und Systemarchitekturen, Digitalisierung und KI. An der University of Groningen hält er Vorlesungen und betreut Doktoranden.
>> Weiterlesen
Das könnte Sie auch interessieren

Kommentare (0)

Neuen Kommentar schreiben