Digitale Architektur
Überflüssig oder Erfolgsgarant?
ca. 11 Min. Zeitbedarf
Architektur für die „Digitalisierung“
Neue oder geänderte Prozesse wird sie mit sich bringen, die Digiatalisierung, ja sogar „sich stetig ändernde“. Agil und flexibel muss alles sein. Braucht man da eigentlich noch Architektur? Die will ja immer mit Weitsicht geplant sein. Geht Architektur überhaupt zusammen mit agilen Prozessen?
Ja, auf jeden Fall, sagen wir! Dieser Artikel zeigt wichtige Elemente auf, die Architektur auch im agilen Umfeld formen kann und sollte. Zudem zeigt er einige Architekturaspekte auf, die erfolgreiche Digitalsierungsinitiaitiven auszeichnet.
Fokus, Fokus und … FOKUS!
Über die Bedeutung der KLarheit des Zieles, das es zu erreichen gilt, habe ich in aderen Artikeln bereits geschrieben und lässt sich anderorts [1] viel lesen. Nur auf Basis einer einigermaßen knokreten Vision lässt sich auch zielgerichtet eine Architektur entwickeln.
Die typischen Digitalisierungsarchitekturen setzen auf einheitliche Prinzipien. Es ist jedoch nicht immer sinnvoll, alle Prinzipien gleichzeitig anzustreben, bzw. umzusetzen. Vielmehr gilt es – wie bei der Modernisierung eines älteren Gebäudes – behutsam die bestehenden Elemente aufzugreifen und zielgerichtet auf das gewünschte Neue auszurichten. Dennoch existieren einige zentrale Muster, die unbedingt bedacht werden sollten, da ihre Gestaltung erhebliche Auswirkungen hat:
- Micro-Service-Architekturen
- Ereignisorientierung
- Digitale Zwillinge
- Cloud-basierte Umsetzung
Die folgenden Abschnitte stellen diese zentralen Aspekt kurz vor und geben Hinweise, wie sie sich umsetzen lassen.
Micro-Service-Architekturen
Modern ist es, Micro-Service-Architekturen zu entwickeln. Aber ist es auch immer sinnvoll?
Um diese Frage zu beantworten, sollte man sich zunächst klar machen, welches Ziel erreicht werden soll. Die Vorteile einer Micro-Service-Architektur (MSA) liegen vor allem in der Geschwindigkeit, die sich durch paralleles Arbeiten an den Services erzielen lässt und ihrer einfachen Skalierbarkeit. Für große Teams (200+ Entwickler) sind solche Architekturen notwendig, um effizient und schnell Ergebnisse zu liefern.
Jedoch gibt es eine MSA nicht ohne Preis. Sie stellt sehr hohe Anforderungen an das Design und die Umgebung!
Ein ganz wichtiges Erfolgskriterium einer MSA ist der richtige Schnitt der Services. Ist der schnitt zu fein angelegt, erhöhen sich die Komplexität und folgend die erforderliche Inter-Service-Kommunikation unnötig. Ist der Schnitt zu grob gewählt, entstehen die Vorteile nicht.
Um dieses Dilemma aufzulösen, ist eine sehr gute Kenntnis der fachlichen Materie erforderlich. Gerade in neuen Geschäftsfeldern ist das jedoch selten der Fall. Hinzu kommen aufgrund der Verteilung extrem hohe Anforderungen an das Logging und Monitroing, um Fehlersuche und -behebung effizient durchführen zu können.
Micro-Service well-architected
- SERVICE CONNECTOR:
Um externe Dienste wie Logging und Monitoring aufzurufen, bietet sich die Entkapselung mit Hilfe eines Connectors an - REPOSITORIES:
Der Dienst sollte über seine eigenes Persistenz-Management verfügen. Abbildung auf den Aufgabenträger ist dann fast beliebig. ACHTUNG! Kann bei hoher Skalierung zum Engpass werden - RESOURCES/ API:
Um Dienste nach Außen bereitzustellen, ist ein API (REST) bereitzustellen. Ideal, wenn dieses hausinternen Best-Practices und Versionierungsregeln folgt. - UI-FRAGENTS:
Richtig entkoppelt wird es erst, wenn der Dienst selbst sein UI bereitstellt. Hierzu sind sinnvolle Snippets und „Seiten“ bereitzustellen, welche sich in ein beliebiges UI einbinden lassen. ACHTUNG! => Interaktion mit Rechten und Rollen klären! - DOMAIN LOGIC:
Der eigentliche, fachliche Inhalt des Service.
Aufgrund der schier endlosen Menge an Gestaltungsmöglichkeiten sind falsche Schnitte – also eine „suboptimale“ Verteilung der Domain Logic auf die einzelnen Services – eher wahrscheinlich, als eine optimale. Natürlich lassen sich falsche Schnitte korrigieren, allerdings kann eine nachträgliche Anpassung auch mal so viel Re-engineering erfordelrich machen, dass das nachträgliche Herauslösen eines Services aus einer zwar monolithischen jedoch bereits im Ansatz modularisierten Architektur günstiger wäre.
Wenn gleichzeitig die Entwicklungsmannschaft nur zwei oder drei SCRUM-Teams umfasst, kann eine MSA ihre Geschwindigkeitsvorteile kaum ausspielen. In einem solchen Kontext wäre in einer technischen Risiko-Abschätzung eine prototypische Realisierung in einfachen, klar identifizierbaren Modulen einer MSA vorzuziehen.
Neue Anforderungen lassen sich dann schneller integrieren, Design spielt weniger Rolle und steht auch „weniger im Weg“. Ist in einer späteren Phase das tatsächlich benötigte Verhalten und die Abhängigkeiten der Geschäftsobjekte schon klarer, besteht immer noch die Möglichkeit, einzelne Services auszugliedern.
Technologie sollte immer nur Mittel zum Zweck sein! Technologischer Ehrgeiz allein bringt selten Geschäftserfolg
Dies soll jedoch nicht als Abgesang auf eine MSA verstanden werden. MSAs bergen noch viele weitere Vorteile. Durch Entkopplung und Separation of Concerns lassen sich auch komplexe Sachverhalte in handhabbare Pakete schneiden, schrittweise Bereitstellung durch sukzessives Anreichern mit Diensten wird möglich und insbesondere die Skalierbarkeit gewinnt.
Unsere Erfahrung zeigt, dass der Anspruch, eine MSA sinnvoll und vorausschauend zu entwickeln erheblich für ihren Erfolg ist. In einem Shop-Umfeld, wo alle Prozesse bekannt sind, mag das auch gut umsetzbar sein. In einem unbekannten Kontext mit ersten Pilotkunden, ist es mit hoher Wahrscheinlichkeit nicht das richtige Startdesign.
Setzen Sie in Ihrer Digitalisierungsinitiative auf die richtige Architektur für die gegenwärtige Aufgabe?
Ereignis-orientierte Architekturen
Ein weiteres, wichtiges Paradigma ist das Ereignis-orientierte Design. Zwar gibt es Messaging als Integrationstechnologie bereits seit vielen Jahren, jedoch findet die Ereignisorientierung erst in den letzten 5-10 Jahren vermehrt Eingang in das Design von Enterprise-Systemen.
Genaugenommen ist diese stringente Entkopplung ein wichtiges Element gut strukturierter Micro-Service-Architektur. Leider wird Micro-Service jedoch oft nur als kleinteilige Service-Orientierung und als Zerschlagung von „monolithischen“ Anwendungssystemen verstanden. Die inhärente Entkopplungsforderung – die Forderung nach der Service-Autonomie – geht verloren. Stattdessen entsteht ein Service-Meer aus sich gegenseitig aufrufenden Diensten.
Aber zurück zu dem zentralen Paradigmenwechsel: Es geht um den Wandel vom Request-basierten zum Ereignis-orientierten Design.
Der Unterschied liegt im Steuerfluss: In einem Request-basierten System muss entweder der Vorgänger den Nachfolger kennen oder es muss eine status-behaftete Instanz geben, welche die Teilnehmer kennt und den Prozessablauf sicherstellt. In nachstehendem Order-Beispiel bildet der Order-Service diese Klammer. Der Warenkorb-Dienst ruft den Order-Service auf und übergibt ihm einen Warenkorb. Der Order-Service prüft die Bestellung und gibt dem Warenkorb ein OK oder nicht-OK zurück. Im OK-Falle beginnt er die Versorgung der Order (speichern mit dem Order-Storage-Service und die Bestellbestätigung mit dem Notification Service. Damit übernimmt der Order-Service die Orchestrierung des Order-Flows.
In den ereignisorientierten Systemen liegen die Funktionen stärker entkoppelt vor. Sie kennen Ereignisse, auf die sie reagieren. Ein beliebiges Quell-System stellt Ereignisse mit Hilfe eines Publish-Subscribe-Mechanismus zur Verfügung. Konsumierende Funktionen oder Systeme lauschen auf die für sie relevanten Ereignisse und prozessieren diese nach Auftreten.
Diese Entkopplung erleichtert das bedarfsgerechte Skalieren einzelner Funktionen und reduziert die Notwendigkeit, zentrale Steuerungslogik vorzuhalten. Es muss kein zentrales Gestirn geben, welches alle Zustände kennt. Das erleichtert die Entwicklung und reduziert Engpässe.
In vorstehendem Beispiel würde der Warenkorb-Service die Bestellung auf eine Queue schreiben (oder streamen) und dann warten, ob eine entsprechende Bestätigung auf der Good-Order Queue auftaucht. Der Order-Service hört auf der Order Queue und nimmt jedes neue Element auf, prüft es und schreibt es beispielsweise anschließend in Abhängigkeit der Prüfung entweder in eine Good-Order-Queue oder eine Bad-Order-Queue. Der Order Storage Service sowie der Notification Service lauschen beide an der Good-Order-Queue und reagieren, wenn neue Elemente erscheinen. Ggf. mag der Warenkorb-Service auch auf die Bad-Order lauschen, um festzustellen, wenn eine Order nicht erfolgreich angenommen wurde.
Es liegt auf der Hand, dass sich hierdurch der Order-Service erheblich vereinfacht. Auch muss keiner der Dienste mehr etwas über die anderen Dienste wissen, geschweige denn, sie aufrufen.
Die Verteilung so entkoppelter Einheiten sowohl aus organisatorischer als auch technischer Sicht wird erheblich einfacher. Auch lassen sich die Dienste natürlich einfacher skalieren. Nimmt die Anzahl der Orders auf der Order-Queue zu, lassen sich mehrere Instanzen des Order-Service erzeugen, um die Orders schneller abzuarbeiten.
Gleichzeitig wird es erforderlich, den Überblick über das Gesamtsystem zu behalten. Wer abonniert welche Events? Wer hört worauf?
Digitale Zwillinge gestalten
Ein weiteres, elementares Konzept der Digitalisierung ist die Dopplung der realen Welt. Dabei erhalten die Handlungsobjekte der Realität eine digitale Repräsentation. Dieses Modell erhält die aus der Messinfrastruktur gelieferten Ereignisse. Somit kann der zentrale Service (Regler) den Zustand der natürlich-weltlichen Zielsystems (Regelstrecke) verstehen und entsprechende Steuerimpulse für das Zielsystem oder dritte Systeme generieren.
In unserer Beratungsrealität stoßen wir immer wieder auf Lösungskonzepte, die sich weit entfernt von dieser Konzeption bewegen. Wichtige Handlungsobjekte finden keine eigenständige Repräsentation sondern sind nur als Attribute anderer Objekte, zumeist Kundenobjekte, abgebildet. Traditionelle Objekte, die schon immer abgebildet wurden, bestimmen die Modelle.
Kürzlich haben wir die Architektur eines Kreditkartenanbieters betrachtet, der neben dem bisherigen Geschäft mit Legitimationen neue Geschäftsoptionen sucht. Im bisherigen Modell steht der Vertrag mit dem Kunden und die Zahlungsbeziehung im Mittelpunkt. Die Kreditkarte richtet sich vor allem an Logistikunternehmen und bietet spezielle Limit-Funktionen an. Neben der Kreditkartenfunktion entwickeln sich nun weitere, speziell auf Spediteure zugeschnittene Service-Leistungen.
Bei der Neugestaltung der Anwendung wurde im ersten Anlauf genau das Konstrukt abgebildet, das bereits in den Altsystemen befindlich ist. Dabei bildete die vertragliche Kundenbeziehung den Fokus. Denkt man das Geschäft jedoch von der Kundensicht aus, sollten die Handlungsobjekte des Kunden im Fokus stehen: Die Zugmaschinen, die Hänger mit ihren Kapazitäten, die Touren, Reparatur- und Maintenance-Prozesse, ggf. sogar die Fahrer.
Um später ergänzende Services anzubieten, wäre es erforderlich, diese Objekte und ihren Zustand abzubilden. Über die große Zahl an vergleichbaren Objekten (kundenübergreifend) lassen sich Erkenntnisse und Service-Muster erkennen, aus denen sich neue Mehrwertleistungen generieren lassen. Dazu sind jedoch im ersten Schritt Datensammelung und Verhaltensanalyse erforderlich. Die digitalen Zwillinge bilden die Container für die gesammeltenEreignisse und damit die Grundlage, um entsprechende Analysen zu ermöglichen.
Zusammen mit den ereignisgesteuerten Systemen lassen sich neue Zwillinge in ein bestehendes System ergänzen und in das Geschehen einbinden. Auf Basis von Complex Event Processing-Technologie – oder neuerdings Event-Streaming-Analysis – lassen sich unterschiedliche Ereignisströme kombiniert auswerten. Somit kann der Leser eines oder mehrerer Ströme laufend Kennzahlen und Verhältnisse ermitteln und Abweichungen von vorgegebenen Intervallen oder Näherungen in Geo-Positionen erkennen und daraus wiederum neue Ereignisse generieren, welche dann (steuernde) Folgeaktivitäten auslösen.
Der LKW-Anhänger wird nicht in der Realität smart, aber seine digitale Repräsentation erhält die Intelligenz, sich anhand Streckenprofil und Ladung zu melden, wenn es Zeit für den Reifenwechsel wird. Dies wiederum lässt sich entweder eigenständig als Service monetarisieren, oder es bietet die Option zusammen mit einem Service-Partner entsprechende Reparatur- und Austausch-Services anzubieten.
Ist Ihre Organsiation bereit für die digitale Transforation? Lesen Sie mehr über unser digitales Reifegradmodell
Cloud-basierte Umsetzung
Bei allen diesen Vorhaben ist Geschwindigkeit ein erhebliches Erfolgselement. Einerseits ist der First-Mover-Advantage nicht zu unterschätzen. Wenn die neue Leistung nah bei den bisherigen Gewohnheiten der Kunden liegt oder tatsächlich einen relevanten Mehrwert darstellt, wird der erste Anbieter eine ganz andere Wahrnehmung und Deutungshoheit über zahlungspflichtige und kostenfreie Dienstteile erhalten, als der Nachahmer.
Gehen wir noch einmal in das 365FarmNet-Beispiel. Dabei war es ein ganz wesentliches Ziel, welches auch einen enormen Druck auf das Projekt ausgeübt hat, die neue Lösung möglichst umfänglich auf der Messe Agritechnika vorzustellen. Bis zur Messe war zum Startzeitpunkt noch gut 6 Monate Zeit.
Dennoch konnten wir bereits zur Messe die Software-as-a-Service-Lösung liefern. Sicherlich sind es immer mehrere Faktoren, die einen Erfolg ausmachen und es lässt sich nicht auf die Technologie alleine reduzieren. Jedoch hat es uns erheblich geholfen, von Anfang an auf Cloud-Ressourcen gesetzt zu haben. Die Möglichkeit, eine komplette Umgebung skriptbasiert mal eben neu aufzusetzen, altes Zeug wegzuwerfen, anstelle es zeitintensiv neu aufzubereiten oder für Performance-Tests teure Server in großem Umfang einzukaufen und aufzubauen, hat nicht nur immense Arbeit sondern auch Zeit und Ressourcen sparen geholfen.
Inzwischen sind die Dienste noch um ein Vielfaches mächtiger geworden. Alle relevanten Bausteine einer Architektur lassen sich als Dienst beziehen. Das erlaubt es nicht nur, das Team Oberkante technischer Service auf die differenzierenden Aspekte zu fokussieren: Service-Schnitt, Logik, Fachlichkeit. Es vermeidet auch gleichzeitig das Verlieren in technischem Kleinklein, das so hochkomplexe Umgebungen mit sich bringen. Einen Kubernetes-Cluster dynamisch skalier- und konfigurierbar einzurichten, an eine Deployment-Strecke anzubinden und zu dokumentieren, ist trotz aller Beteuerungen keine Kleinigkeit. Das nimmt auch bei Profis schnell mal 2 bis 4 Monate in Anspruch. Wer einen Cloud-basierten Dienst nutzt, erhält diese Leistungen frei Haus.
Diese Geschwindigkeitsvorteile schlagen sich nicht nur in der Laufzeit nieder. Das macht sich auch im Bereich der erforderlichen Kompetenzen bemerkbar. Wo ein selbstbetriebenes Umfeld eine Hand voll Experten für Infrastruktur bindet, kann eine Cloud-basierte Lösung von der Anbieterexpertise profitieren.
Wohl bemerkt: Cloud ist keine Einbahnstraße. Sobald sich ein Dienst wirtschaftlich bewiesen hat, lässt es sich immer noch überlegen, wie man aus der Cloud wieder herauskommt. Bestes Beispiel hierfür ist Dropbox. Die Firma ist jahrelang weltweit auf Basis von AWS expandiert. Erst als sie 2016 einen erheblichen Marktanteil erstritten hatte, sind sie auf eigene Ressourcen umgezogen.
Die Nutzung von Cloud-Diensten erhöht also nicht nur die Flexibilität, sie schützt auch vor technischer Verliebtheit, spart Kapazitäten und reduziert somit auch bei hohen flexiblen Kosten die Gesamtkosten.
Technologie-Hypes vermeiden
Ganz oft begegnen wir Vorhaben, die sich mit neuen Technologien übernehmen. Man möchte etwas Neues machen und will gleich alle Fehler der Vergangenheit vermeiden, denn jetzt wird es richtig gut. Und dann werden die neuesten Technologien gewählt, deren Verhalten unbekannt oder schwierig abschätzbar ist und die alle noch nicht vorhandenen Probleme schon lösen könnte. Gut gemeint ist jedoch in der Regel oft schlecht gemacht.
Anstelle sich auf den betriebswirtschaftlichen Mehrwert zu fokussieren und schnell eine erste, am Markt überprüfbare Lösung zu entwickeln, wird eine möglichst moderne Architektur gewählt, die viele technische Risiken mit sich bringt. Im Ergebnis geht viel Zeit mit Technologiemanagement ins Land, ohne, dass kundenrelevante Features entstehen.
Wer zum Mond fliegen will, sollte auf bewährte Technologie setzen. Das erhöht die Chance, anzukommen.
Dieses Vorgehen wird auch durch veraltete, technologie-unerfahrene Zielvorgaben wie „Möglichst hohe Wiederverwertung“ oder „Das muss beliebig skalierbar sein!“ begünstigt.
Diese ist weder effizient noch zielführend. Stellt sich mit den ersten Kundentests heraus, dass sich die Idee nicht hinreichend monetarisieren lässt, sind alle Aufwände für die große Infrastruktur vergebens. Lieber im Zweifel das Wachstum gezielt dosieren oder durch zusätzliche Lösungen managen, als eingangs zu viel Energie in am Ende ungenutzte Technologie investieren! Der Spruch „Think big but start small“ ist wahr! Wir haben selbst über die Jahre viel eigenes Geld und Zeit in eigene Unterfangen investiert, weil wir diesen Hinweis nicht hinreichend berücksichtigt haben.
Es spricht weder aus Architektur- noch aus betriebswirtschaftlicher Sicht etwas dagegen, am Anfang einer Geschäftsidee, zunächst ein eher traditionell ausgerichtetes, einfaches System zu entwickeln. Mit dieser Auffassung konfrontiert, stehen Architekten auf Kundenseite regelmäßig die Haare zu Berge stehen: „Wir wollen etwas Modernes, etwas Cooles bauen, nicht so einen verstaubten Mist!“, bekommt man gerne mal an den Kopf geworfen. Das ist technisch sicherlich ambitioniert, zu einem Zeitpunkt, da der Bedarf noch unklar ist, jedoch betriebswirtschaftlich extrem fragwürdig.
Fazit
Die vorstehenden Ausführungen zeigen, wie essentiell Architekturentscheidungen für den Erfolg einer Digitalisierungsinitiative sind. Es mag merkwürdig von einem Architekten klingen, aber die Technologie ist dabei zunächst weniger die Herausforderung als betriebswirtschaftlicher Fokus und Zielsetzung.
In einer sich zunehmend durch Unsicherheit und Veränderung kennzeichnenden Welt, wird es nicht mehr möglich sein, langfristige Versuchsanordnungen zu gestalten und Produkte im stillen Kämmerlein auszumodellieren. Wettbewerb, ein hohes Potential an Innovationskraft und viel investitionswilliges Kapital fordern bestehende Unternehmen heraus und das frühzeitige Besetzen von Handlungsfeldern.
Das Internet und die Konformität der Suchalgorithmen reduzieren den Raum für zweite und dritte Plätze, „The winner takes it all“-Spiele gewinnen an Bedeutung, womit Geschwindigkeit zum zentralen Erfolgselement wird.
Agiles Vorgehen ist daher zwingend erforderlich, um schnell zu sein. Eine entschlossene Zielsetzung jedoch auch, da auch Agilität Ziele und Visionen benötigt, um erfolgreich zu sein.
Die EACG verfügt über das Wissen und die Erfahrung, um die essentiellen von den weniger relevanten Aspekten einer Digital Transformation-Initiative zu unterscheiden, die Initiative entsprechend ressourcen-schonend zu konzipieren und fokussiert aufzusetzen.
Dabei liegt unser Anspruch darin, schnellstmöglich den Business Case am Kunden zu beweisen und erst im Nachgang die Technologie für das marktfähige Produkt rechtzeitig bereitzustellen. Die einzigartige Kombination aus tiefem betriebswirtschaftlichen und technologischem Verständnis sowie der Wille ein Projekt von Konzeption bis Realisierung zu begleiten sind unser USP.
Stehen Sie noch am Anfang einer Digitalisierungs-Initiaitive oder haben Sie bereits erste Schritte unternommen?
Dies ist der vierte Artikel einer Reihe von Artikeln zur Digitalien Transformation. Bisher erschienen sind:
In Kürze erscheint DIgital Finance – zur Finanzierung von Digitalisierungvorhaben.