Suche
Wie Software neue Umsatzquellen erschließen kann

Softwarearchitektur für Innovation: Der heilige Gral

Eberhard Wolff

©Shutterstock / Sunny studio

Software ist mittlerweile in praktisch allen Wirtschaftsbereichen zentraler Teil der Wertschöpfung. Also sollte Software auch Innovationen ermöglichen. Die Frage ist, wie Software dazu beschaffen sein muss.

Um die Unterstützung von Innovationen durch Softwarearchitektur zu betrachten, muss zunächst der Begriff Innovation geklärt werden. Innovation bedeutet, dass neue Produkte und Dienste auf den Markt kommen und damit letztendlich neue Umsatzquellen entstehen. Es ist also nicht ausreichend, einfach nur eine neue Technologie zu entwerfen, sondern die Technologie muss tatsächlich Geld in die Kasse bringen.

Ebenso muss der Begriff Softwarearchitektur geklärt werden. Oft wird unter der Softwarearchitektur die Aufteilung eines Systems in verschiedene Komponenten verstanden. Das ist sicher richtig. Schon der Begriff „Architektur“ weist in eine solche Richtung. Es geht um die grobgranulare Gestaltung eines Systems, während Design und Implementierung die feingranulare Arbeit an einem System umfasst. Aber es gibt noch einen weiteren wichtigen Bestandteil der Softwarearchitekturarbeit: Die Softwarearchitektur muss sicherstellen, dass die notwendigen Qualitätsmerkmale durch geeignete technologische Maßnahmen erreicht werden. Qualitätsmerkmale werden oft nicht funktionale Anforderungen genannt. Beispielsweise kann Skalierbarkeit oder Sicherheit ein Ziel einer Architektur sein. Dann muss die Architektur Technologien wählen, die solche Ziele unterstützen.

DevOps Docker Camp

Teilnehmer lernen die Konzepte von Docker und die darauf aufbauenden Infrastrukturen umfassend kennen. Schritt für Schritt bauen sie eine eigene Infrastruktur für und mit Docker auf.

Alle Termine des DevOps Docker Camps 2018 in der Übersicht

München: 19. – 21. Februar 2018
Berlin: 14. – 16. März 2018

Was benötigt Innovation?

Um Innovation mithilfe von Software zu unterstützen, muss die Software zwei Qualitätsmerkmale umsetzten: Der Erfolg der Software muss messbar sein, und die Software selbst muss änderbar sein. Wenn eine Änderung in der Software zu einem höheren Umsatz oder zu mehr Registrierungen führen soll, dann muss diese Metrik messbar sein. Das ist wichtig, denn oft beeinflussen Änderungen Metriken gar nicht oder verschlechtern sie sogar. So behauptet der ehemalige Chef des Data Minings bei Amazon Ronny Kohavi, dass 60 bis 90 Prozent aller Ideen, die eigentlich eine Metrik verbessern sollen, dieses Ziel nicht erreichen [1]. Ohne ein Feedback durch Metriken lässt sich der Erfolg von Änderungen nicht ermitteln. Und um Maßnahmen zu ergreifen, die eine Metrik ändern sollen, muss die Software änderbar sein. Die Änderungen müssen nicht nur in der Software vorgenommen werden, sondern tatsächlich in Produktion ausgerollt werden und Nutzern zur Verfügung stehen. Nur dann können die Änderungen tatsächlich genutzt werden, Geld einbringen und Metriken erhoben werden.

Diese Aspekte stehen für einen ganz anderen Ansatz bei der Softwareentwicklung. Software kann nicht nach einem längerfristigen Plan entwickelt werden, wenn sie Innovationen unterstützen soll. Wenn beispielsweise eine Website in einem komplexen, langfristigen Projekt komplett neu erstellt wird, dann besteht diese Entwicklung aus vielen Änderungen. Diese Änderungen sollen Metriken wie Umsatz oder Registrierungen verbessern. Da aber alle diese Änderungen gemeinsam umgesetzt werden, kann man kaum noch die Auswirkungen jeder einzelnen Änderung bewerten. Der größte Teil der Änderungen verbessert aber eben nicht den Erfolg der Software. Daher ist ein umfangreiches Projekt kaum sinnvoll. An Stelle solcher Projekte müssen einzelne Änderungen treten, die sich einzeln bewerten lassen. Nur so können die nicht erfolgreichen Änderungen isoliert und gegebenenfalls zurückgerollt werden.

Änderbare Software: Der heilige Gral

Um viele kleine Änderungen in der Software umzusetzen, muss sich die Software einfach anpassen lassen. Änderbare Software ist eine Anforderung in sehr vielen Projekten und eine Art heiliger Gral der Softwareentwicklung. Eine saubere Architektur und eine hohe Codequalität sind die üblichen Maßnahmen, um die Änderbarkeit der Software sicherzustellen.

Für Innovationen ist eine andere Art der Änderbarkeit notwendig: Viele kleine Änderungen, die jeweils einzeln in Produktion gebracht werden. Dazu ist Continuous Delivery [2] ein wichtiges Werkzeug. Im Mittelpunkt von Continuous Delivery steht der Aufbau einer Continuous-Delivery-Pipeline, mit der Änderungen an der Software in Produktion gebracht werden. Sie besteht aus verschiedenen Phasen: Die Commit Stage kompiliert die Software, führt die Unit-Tests aus und kann die Software außerdem einer statischen Codeanalyse unterziehen. Diese Phase ist daher weitergehend identisch mit dem, was sonst ein Continuous-Integration-Server durchführt. In der nächsten Phase geht es um die die korrekte fachliche Implementierung. Hier finden automatisierte Akzeptanztests statt. Wie der Name schon verrät, sollen sie dafür sorgen, dass der Kunde die Software akzeptiert und abnimmt. Durch die Automatisierung können die Tests häufig ausgeführt werden. In der dritten Phase stellen Kapazitätstests sicher, dass die Software die zu erwartende Last mit der notwendigen Performance behandeln kann. Auch diese Tests sind automatisiert. Schließlich wird die Software in Produktion gebracht. Das Ausrollen ist ebenfalls automatisiert, sodass keine manuellen Änderungen an irgendeinem System notwendig sind.

Rethink-IT-Survey-300x180Continuous Delivery – Wie sieht es in Ihrem Unternehmen aus?

Die Themen Continuous Delivery, Microservices, Container, Cloud und agile Unternehmenskultur sind seit einigen Jahren in aller Munde. Aber wie sieht es in Unternehmen in diesen Bereichen wirklich aus? In unserer großen Umfrage zur DevOps-Kultur haben Sie die Gelegenheit klarzustellen, ob und wie DevOps in Ihrem Unternehmen umgesetzt wird.

An der Umfrage teilnehmen

Lassen Sie unsere Leser wissen, welche Tools wirklich verwendet werden und wie agil es auf dem realen Arbeitsmarkt zugeht. Räumen Sie mit Vorurteilen und Halbwissen auf und teilen Sie unseren Lesern mit, wie bei Ihnen die einzelnen Abteilungen und Teams zusammenarbeiten.

 

Ziele von Continuous Delivery

Wesentliches Ziel einer Continuous-Delivery-Pipeline (Abb. 1) ist die Reduktion des Risikos beim Produktivstellen einer Änderung. Oft wird Continuous Delivery mit einer Automatisierung von Softwareinstallation gleichgesetzt. Die Installation der Software ist aber oft nicht der Grund, warum nicht häufiger deployt wird. Das Deployment ist oft innerhalb eines Tages möglich, und damit wären tägliche Deployments denkbar. Oft ist das Problem das mangelnde Vertrauen in die Änderungen und die Angst, Fehler in die Produktion einzuführen. Die Tests in der Pipeline reduzieren dieses Risiko. Darüber hinaus gibt es weitere Maßnahmen. So wird bei einem Blue/Green-Deployment eine komplett neue Umgebung aufgebaut, in der die Software installiert wird. Dann wird auf die neue Umgebung umgeschaltet. Dieses Vorgehen ermöglicht weitere Tests kurz vor der Produktivstellung der Software und erleichtert den Rückfall auf eine alte Version, wenn die neue Version doch nicht zuverlässig funktioniert.

Abb. 1: Wesentliches Ziel einer Continuous-Delivery-Pipeline ist die Reduktion des Risikos einer Änderung

Abb. 1: Wesentliches Ziel einer Continuous-Delivery-Pipeline ist die Reduktion des Risikos einer Änderung

Ein weiteres Ziel von Continuous Delivery ist schnelles Feedback. Wenn in der Software ein Fehler ist, soll dieser möglichst schnell gefunden werden. Das ist der Grund, warum die Tests regelmäßig ausgeführt werden. So wird beim nächsten Durchlauf der Pipeline bereits auf einen Fehler aufmerksam gemacht. Ein Entwickler bekommt so bereits nach Stunden Feedback, ob seine Änderungen korrekt sind, und nicht erst nach Wochen oder Monaten. Das erleichtert die Fehlersuche. Dieses Vorgehen passt gut zu der notwendigen Unterstützung für Innovation. Denn Änderungen, die bestimmte Geschäftsmetriken verbessern sollen, können ebenfalls schnell darauf abgeklopft werden, ob diese Verbesserungen wirklich eintreten. Daher sollte auch Feedback aus der Produktion eingeholt werden. Dort sollten auch Geschäftsmetriken erhoben werden. Das kann mit denselben Werkzeugen geschehen, die auch technische Metriken erfassen – also Logging und passende Metrikwerkzeuge. Es können aber auch andere Werkzeuge z. B. aus dem Bereich Webmarketing sein.

Continuous Delivery und Innovation

Continuous Delivery unterstützt also Innovation, weil Software einfacher änderbar wird. Nicht in dem Sinne, dass die Änderung des Sourcecodes einfacher ist, sondern dass Änderungen tatsächlich in Produktion gebracht werden und für Kunden verfügbar sind. Im Wesentlichen geschieht das durch eine einfachere und zuverlässigere Produktionseinführung. Auch die Idee der Kontrolle der Produktion mithilfe von Metriken ist hilfreich, um Innovationen zu evaluieren.

Um allerdings Continuous Delivery wirklich umsetzten zu können, muss die Software und die Architektur dieses Vorgehen unterstützen. Denn eine Continuous-Delivery-Pipeline lässt sich nur umsetzen, wenn die Software dafür geeignet ist. Sie muss sich einfach deployen und testen lassen. Da die Pipeline im Wesentlichen Software testet und deployt, wird dann die Umsetzung der Pipeline einfacher. Wenn die Software in mehrere unabhängig deploybare Module aufgeteilt wird, lässt sich für jedes Modul eine eigene Pipeline umsetzen. Das vereinfacht die Umsetzung der Pipeline und ermöglicht auch einen schnelleren Durchlauf durch die Pipeline.

Letztendlich erlaubt Continuous Delivery so, Änderbarkeit von Software durch weitere Maßnahmen zu unterstützen: Die Softwarearchitektur muss dafür sorgen, dass das Deployment der Software möglichst einfach ist. Dann kann durch Continuous Delivery die Software einfacher änderbar werden (Abb. 2).

Abb. 2: Continuous Delivery bietet einfachere Änderbarkeit, wenn die Architektur die Voraussetzungen schafft

Abb. 2: Continuous Delivery bietet einfachere Änderbarkeit, wenn die Architektur die Voraussetzungen schafft

Softwarearchitektur für Continuous Delivery?

Die Frage ist nun, wie Architektur Continuous Delivery unterstützen kann. Eine Möglichkeit sind Microservices. Microservices sind eine besondere Art der Modularisierung von Software. Module dienen dazu, eine Software in kleine Einheiten zu zerteilen, sodass ein Entwickler nur jeweils ein solches Modul verstehen muss, um es zu ändern. Später werden dann alle Module zusammengesetzt und gemeinsam deployt.

Microservices wählen einen anderen Ansatz: Microservices sind Module, die einzeln in Produktion gebracht werden. Sie können als getrennte Prozesse, in virtuellen Maschinen oder auch in Docker-Containern als leichtgewichtige Alternative zu virtuellen Maschinen umgesetzt sein. Microservices lassen sich über REST oder Messaging integrieren. Sie können aber auch auf Ebene des Web-UI beispielsweise über Links zusammengesetzt werden. Schließlich ist auch die Replikation von Daten eine mögliche Form der Integration.

Beispielsweise kann in einer E-Commerce-Anwendung die Registrierung ein eigener Microservice sein, der das UI im Web anbietet, die gesamte Logik implementiert und auch die Daten hält. Eine Änderung in der Registrierung lässt sich vollständig in diesem Microservices abbilden und mit einem einzigen Deployment in Produktion bringen. Für Continuous Delivery hat das mehrere Vorteile. Die Umsetzung der Continuous-Delivery-Pipeline ist wesentlich einfacher, weil ein Microservice eine relative kleine Einheit ist, die außerdem getrennt von anderen Microservices in Produktion gebracht werden kann. Eine Continuous-Delivery-Pipeline ist für eine solch kleine Einheit einfach umzusetzen. Ansätze wie Blue/Green-Deployment sind wegen der geringeren Größe der deploybaren Einheiten ebenfalls einfacher möglich. Ebenso ist die Integration anderer Systeme kein so großes Problem, weil ein Microservice weniger andere Systeme integriert als wenn das gesamte System deployt wird. Der Durchlauf durch die Pipeline ist schneller, weil es für einen Microservice weniger Tests gibt als für das gesamte System. Und auch das Risiko eines Deployments ist geringer: Nur jeweils ein Microservices wird deployt. Alle anderen bleiben unverändert und können daher auch nicht plötzlich Fehler enthalten.

Microservices zur Skalierung von Agilität

Aber Microservices vereinfachen nicht nur Continuous Delivery. Sie unterstützen auch Agilität. Das Ziel agiler Softwareentwicklung ist, Software schnell in Produktion zu bringen. Beispielsweise durch vierzehntägige Iterationen, in denen neue Features geplant und umgesetzt werden. Aus der Produktion geht dann Feedback zurück in die Entwicklung.

Für ein großes komplexes System ist dieses Vorgehen alleine schon schwer zu realisieren, weil das Deployment aufwendig ist. Ebenso ist es schwierig, das Feedback tatsächlich zu erheben. Außerdem muss für das gesamte System eine gemeinsame technische Basis ausgewählt werden. So muss die Programmiersprache und auch die verwendeten Libraries für das gesamte System vorgegeben werden. Und ein Release umfasst immer das gesamte System. Also müssen Releases und Technologien für das gesamte System koordiniert werden.

Je mehr Personen an der Entwicklung des Systems beteiligt sind, desto schwieriger wird die Koordination. Die Arbeit aller Entwickler muss in einem Release zu einem sinnvollen Ganzen zusammengestellt werden. Ebenso muss die technische Basis zwischen allen Entwicklern koordiniert werden. Schon das Update einer Library als Bugfix kann bedeuten, dass irgendwo Fehler auftauchen, weil es zwar bestimmte Fehler behebt, aber vielleicht andere neu einführt.

Architektur und Organisation

Laut dem Gesetz von Conway gibt es eine Beziehung zwischen Softwarearchitektur und der Organisation, die die Software erstellt. Das Gesetz besagt, dass die Kommunikationsstrukturen in der Organisation der Architektur entsprechen. Das ist eigentlich logisch. Wenn zwei Teams oder Entwickler zusammenarbeiten, werden sie eine Schnittstelle in der Architektur definieren, um so die Zusammenarbeit zu organisieren. Umgekehrt muss eine Schnittstelle in der Architektur zwischen verschiedenen Teams oder Entwicklern abgestimmt werden.

Das Gesetz von Conway wird oft als eine Begrenzung der Architektur interpretiert: Ein Team kann nur solche Architekturen umsetzten, die seiner Organisation entspricht. Wenn beispielsweise ein UI-Team, ein Backend-Team und ein Datenbankteam aufgesetzt werden, dann wird die Software diese drei Schichten aufweisen.

Microservices nutzen das Gesetz von Conway, um die Architektur an der Organisation auszurichten. Das System besteht aus Microservices, die jeweils von einem Team verantwortet werden. So stellt die Organisation sicher, dass die Architektur umgesetzt wird. Die Teams müssen dann für jede Komponente UI, Backend und Datenbank umsetzen können. Solche Cross-funktionalen Teams sind aber auch aus Sicht der agilen Softwareentwicklung wünschenswert, damit die Teams möglichst unabhängig voneinander arbeiten können.

Durch Microservices können diese Teams tatsächlich weitgehend unabhängig voneinander Features in Produktion bringen, da Microservices unabhängiges Deployment erlauben. Wenn der fachliche Schnitt der Microservices gut ist, kann auch die Implementierung weitgehend unabhängig erfolgen. Zusätzlich kann jedes Team technische Entscheidungen eigenständig treffen (Abb. 3).

Abb. 3: Durch Microservices können Teams unabhängig voneinander Features implementieren und technische Entscheidungen treffen

Abb. 3: Durch Microservices können Teams unabhängig voneinander Features implementieren und technische Entscheidungen treffen

Wie schon erwähnt, sind Microservices Prozesse, virtuelle Maschinen oder Docker-Container. Also kann jeder Microservice in einer anderen Programmiersprache auf einer anderen Plattform implementiert sein. Es ist daher nicht notwendig, den Teams Technologien vorzuschreiben. Natürlich kann man dennoch die Technologiewahl beschränken, aber die Architektur erzwingt das nicht. Wenn die gesamte Anwendung nur ein Prozess ist, müsste die technische Basis weitgehend festgelegt sein. Im Falle von Java müsste sogar die Version jeder Bibliothek genau definiert werden, weil nur eine Version einer Bibliothek in einem System genutzt werden kann.

Globale Vorgaben für das gesamte Projekt stellt die Makroarchitektur dar. Dazu zählt beispielsweise das Kommunikationsprotokoll, beispielsweise REST oder Messaging. Nur wenn das Protokoll einheitlich ist, können tatsächlich Module zusammenarbeiten. Betriebliche Aspekte wie Monitoring, Deployment oder der Umgang mit Logs können ebenfalls Teil der Makroarchitektur sein. Das beschneidet die Freiheit der Teams kaum, reduziert aber den Aufwand beim Betrieb erheblich, da einheitliche Lösungen genutzt werden können. Die Mikroarchitektur sind jene Entscheidungen, die jedes Team selbst treffen kann. Dazu können die Programmiersprache und die Plattform gehören.

Microservices ermöglichen es, den größten Teil der Entscheidungen in den Teams als Teil der Mikroarchitektur zu treffen. Das unterstützt die Selbstorganisation und erlaubt den Teams, ungewöhnliche Wege zu gehen und neue Technologien zu nutzen, ohne sich mit anderen Teams zu koordinieren. Das sind natürlich gute Voraussetzungen, um innovative Konzepte umzusetzen.

Fazit

Ein wichtiges Fazit ist, dass Software nicht nur durch hohe Codequalität und saubere Architektur änderbar ist. Eine Continuous-Delivery-Pipeline erreicht ebenfalls eine bessere Änderbarkeit, weil durch Tests und automatisches Deployment Änderungen einfach in Produktion gebracht werden können. Die Änderbarkeit der Software ist aber nur ein Grund, warum Continuous Delivery gut zu Innovation passt. Ebenso wichtig ist, dass Continuous Delivery eine Auswertung des Erfolgs in der Produktion ermöglicht. Das ist für Innovation wichtig, denn nur der Erfolg gegenüber dem Kunden zeigt, ob eine Änderung wirklich eine echte Innovation ist.

Microservices unterstützen Continuous Delivery, weil sie Software in unabhängig deploybare Komponenten aufteilt. So lassen sich Continuous-Delivery-Konzepte wesentlich einfacher umsetzen. Außerdem erlauben Microservices den einzelnen Teams, Änderungen unabhängig von den anderen Teams in Produktion zu bringen und auch eigene, unabhängige technologische Entscheidungen zu treffen. Das erlaubt mehr Experimente und damit eine einfachere Umsetzung innovativer Lösungen.

Geschrieben von
Eberhard Wolff
Eberhard Wolff
Eberhard Wolff ist Fellow bei innoQ und arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater, oft an der Schnittstelle zwischen Business und Technologie. Er ist Autor zahlreicher Artikel und Bücher, u.a. zu Continuous Delivery und Microservices und trägt regelmäßig als Sprecher auf internationalen Konferenz vor. Sein technologischer Schwerpunkt sind moderne Architektur- und Entwicklungsansätze wie Cloud, Continuous Delivery, DevOps, Microservices und NoSQL.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.