Die "Agilisierung" ist eine methodische, kulturelle und organisatorische Herausforderung - aber auch eine technologische. In diesem Artikel werden die Zusammenhänge und Wechselwirkungen von Agilität und Softwarearchitektur diskutiert und aufgezeigt, wie auch die Softwarearchitektur die Organisation von Entwicklungsteams, Entwicklungsprozesse und Delivery-Zeiten beeinflusst.
Agilität
Agilität bedeutet weit mehr als iterative Softwareentwicklung in kurzen Zyklen - meist Sprints genannt. Agile Unternehmen sind in der Lage, ihr Budget bestmöglich im Sinne der Wertschöpfung einzusetzen. Dazu zählt auch die Fähigkeit, kurzfristig auf Veränderung einzugehen und Planungen anpassen zu können. Agile Unternehmen können Innovationen schnell und in hoher Qualität in ihrem Markt nutzen. Seien es Innovationen für ihre Kunden oder die Steigerung der Wertschöpfung durch die Optimierung interner Prozesse. Insbesondere können sie Neuerungen nicht nur einmalig, sondern ständig in hoher Geschwindigkeit und Qualität umsetzen.
Foto: iQoncept - shutterstock.com
Im Bereich der Softwareentwicklung gibt es kleine, interdisziplinäre High-Performance-Teams, die diese zügige Umsetzung der Innovationen durch IT bewerkstelligen und verantworten. Sie arbeiten nach agilen Methoden, nutzen Scrum und/oder Kanban und etablieren agile Rollen, die typischen kritischen Aspekten von IT-Projekten Rechnung tragen - beispielsweise der Orientierung an fachlichen Anforderungen, deren Verständnis kritisch für erfolgreiche Softwareentwicklung ist.
Die Performance agiler Teams kann jedoch leicht durch organisatorische und technische Rahmenbedingungen eingeschränkt werden. Zum Beispiel durch Softwarearchitekturen, die agile Vorgehensweisen unzureichend unterstützen. Im Folgenden erläutert der Artikel den Zusammenhang von Agilität und Software-Architektur und neue Ansätze wie Microservices.
Organisation
Eine, zum Beispiel agile, Vorgehensweise beeinflusst beziehungsweise bedingt die Organisation der Personen, die entsprechend einer Vorgehensweise agieren. Gleichfalls beeinflusst und bedingt die Organisation das Resultat von Programmierung - Code - und umgekehrt. Bevor dieser Zusammenhang hergestellt wird, folgt deshalb zunächst ein kurzer Einblick in die Organisation von Code.
Organisation von Code
Software ist das Resultat von Programmierung, das heißt der Auflistung verschiedener Anweisungen, die eine fachliche, geschäftliche oder datenverarbeitende Logik umsetzen. Im Folgenden wird Software daher auch als Programm bezeichnet. Je komplexer und umfangreicher der Sachverhalt, umso komplexer ist auch die Logik und die Menge an Anweisungen, die benötigt wird, um diese abzubilden.
Je komplexer die Logik und je umfangreicher die Menge der programmierten Schritte ist, desto wichtiger ist die Strukturierung eines Programms. Dadurch kann ein Programm schnell überblickt und verstanden werden und Änderungen und Weiterentwicklungen lassen sich zügig umsetzen.
Heutige Programmiersprachen unterstützen die Strukturierung von Programmen, zum Beispiel objektorientierte Programmiersprachen durch die Möglichkeit zusammenhängende Entitäten und Methoden zu definieren, Spezialisierungen und Abstraktionen durch Vererbungsmechanismen zu beschreiben. Die Definitionen erfolgen mittels Sprachkonstrukten der jeweiligen Programmiersprache.Das heißt sie besitzen eine eindeutige Syntax und Semantik. Dadurch können sie von Hilfsprogrammen und sogenannten Werkzeugen, "verstanden" werden. Während der Entwicklung kann also die Modellierung automatisiert genutzt werden, zum Beispiel um die Verfügbarkeit vererbter Methoden zu überprüfen und die Zugehörigkeit zu Paketen/Modulen zu überprüfen.
Weitere Strukturierungsmöglichkeiten bieten Modularisierungskonzepte, die ebenfalls in vielen Programmiersprachen als Sprachkonstrukte umgesetzt sind. Dabei handelt es sich um sogenannte Module und Pakete, die verschiedene Programmiersprachen unterstützen. Sie ermöglichen die nächst gröbere Modellierung, das heißt die Zusammenfassung von Modellen oder Funktionalitäten, die in mehreren Klassen oder Prozeduren programmiert wurden.
Die Strukturierungsmöglichkeiten moderner Programmiersprachen geben dabei keinerlei Strukturierungskriterien vor. Code kann theoretisch nach fachlichen Zusammenhängen, nach Organisationseinheiten, Prozessen oder anderen Merkmalen strukturiert werden.
Organisation von Personen: Bündelung von Kompetenzen
Für die Organisation von Unternehmen besteht eine Organisationsform darin, Kompetenzen zu bündeln. Dahinter verbirgt sich Organisationseinheiten nach der Ähnlichkeit der Aufgaben und dafür benötigter Fähigkeiten zu bilden. Derartigen Organisationsformen entsprechend sind bei der Softwareentwicklung Personen mit Spezialisierungen für zum Beispiel die Entwicklung von Benutzeroberflächen, Geschäftslogik, und Datenhaltungsfragen beteiligt.
Um bei hoher Komplexität und einer großen Menge an Anforderungen an eine Software eine hohe Geschwindigkeit bei der Entwicklung zu erzielen, müssen mehrere Entwickler gleichzeitig programmieren. Es stellt sich also auch hier die Frage nach der Organisation der an der Entwicklung beteiligten Personen. Die Organisation nach Kompetenzen liegt auch für die Organisation von Softwareentwicklungsprojekten nahe.
In der Realität hat sich herausgestellt, dass tatsächlich eine Strukturierung von Software entlang der Kommunikationsstrukturen der beteiligten Organisationseinheiten erfolgt.
Das heißt, die Strukturierung von Programmcode spiegelt die organisatorische Zusammensetzung von Menschen wider. Dieses Phänomen hat Melvin Edward Conway 1968 erforscht und es trägt daher den Namen Conway's Law. Dieser Zusammenhang lässt sich dabei sowohl im Hinblick auf Unternehmensarchitektur herstellen - zum Beispiel Vertriebsabteilungen mit Vertriebssystemen, Finanzbuchhaltungsabteilungen mit Finanzbuchhaltungssoftware - als auch auf die Architektur einzelner Programme. Die verbreitete 3-Schichten-Architektur (vgl. Abbildung 1) beispielsweise lässt sich einfach auf Kompetenzen von Personen übersetzen:
Architekturebene Benutzerschnittstelle - IT-Experten für Usability, User Interface Design, Client-seitige Frontend-Entwicklung
Architekturebene Geschäftslogik - IT-Experten für serverseitige Frameworks, Application Server, Enterprise-Software-Entwicklung
Architekturebene Datenhaltung - IT-Experten für Datenbanken und Datenmodellierung
Foto: adesso AG
Anforderungen und Organisation
Software hat einzig den Zweck geschäftliche Anforderungen wirtschaftlich umzusetzen. Diesem Zweck entsprechend sollte die Zeit von der Erhebung einer wertschöpfenden Anforderung bis zu ihrer Nutzung minimiert werden. Es gilt also, den Gesamtprozess zu optimieren, den die Anforderung durchläuft:
Anforderung mit IT-Experten kommunizieren, damit diese sie verstehen und so korrekt und zügig umsetzen können.
Anforderung umsetzen, als Software programmieren
Umsetzung überprüfen (Unit-Test)
Neue erstellte Software mit existierender Software integrieren
Die fehlerfreie Integration überprüfen (Integrationstest)
Das neue Stüdk Software in Betrieb nehmen, der Nutzung zuführen
Eine Anforderung kann grundsätzlich eine oder mehrere Schichten der Architektur aus Abbildung 1 betreffen. Die Änderung des Verhaltens eines Eingabefeldes kann beispielsweise lediglich die Benutzeroberfläche, die Änderung einer Gültigkeitsregel für ein Datenbankfeld lediglich die Datenhaltungsschicht betreffen.
Häufig betreffen Anforderungen allerdings sämtliche Schichten, wie zum Beispiel die Hinzunahme eines neuen Feldes "email" für die Beschreibung von Personen. Dieses Feld wird vermutlich auf der Benutzeroberfläche angezeigt, vielleicht ist sogar die Möglichkeit der Veränderung des E-Mail-Eintrags vorgesehen, die Erlaubnis für die Veränderung ist vielleicht durch fachliche und organisatorische Regelungen bestimmt, betrifft also auch die Schicht der Geschäftslogik.
Im Falle von Anforderungen, die sämtliche Schichten betreffen, müssen die Experten der jeweiligen Schichten miteinander kommunizieren, sich abstimmen darüber, wann und wie der die jeweilige Schicht betreffende Teil der Anforderung umgesetzt wird (vgl. Abbildung 2). Natürlich bearbeiten die Teams auch nicht eine Anforderung zur Zeit, sondern mehrere Anforderungen gleichzeitig. Da die Organisation der Teams nach architektonischen Schichten und technischen Kompetenzen erfolgt, entsteht hoher Aufwand durch diese Abstimmungen.
Foto: adesso AG
Wie effizient der Prozess der Umsetzung von Anforderungen durchlaufen werden kann, hängt von der Komplexität der Anforderung ab, aber folglich auch davon, wie gut die Architektur einer Software die Umsetzung neuer Anforderungen unterstützt. Mit der Veränderung von Anforderungen, ihrem Wegfall (frühe Anforderungen) und neu aufkommenden (späten) Anforderungen umzugehen, erhebt selbst Anforderungen an die Softwarearchitektur:
Eine Softwarearchitektur, die Agilität unterstützt, muss ebenfalls agil sein.
Eine Softwarearchitektur unterstützt Agilität, wenn Veränderungen, die im Laufe der Entwicklung auftreten, möglichst agil begegnet werden können. Veränderungen können dabei fachliche Modelle und Prozesse, als auch die Umorganisation der sie umsetzenden Personen (Teams) bis hin zu der Verkleinerung und Vergrößerung von Teams betreffen.
Vertikalisierung
Die Strukturierungskonstrukte von Programmiersprachen lassen sich unterschiedlich nutzen. Es ist die Frage der Modellierung, wie sie die Realität abbilden. Zum Beispiel könnte eine Strukturierung entlang von Prozessen, von Organisationseinheiten, von fachlichen Domänen oder entlang von Architekturschichten erfolgen.
Alternativ zu der Architektur-orientierten Organisation können die an einer Software beteiligten Personen auch entlang fachlicher Kriterien, also vertikal organisiert werden (vgl. Abbildung 3).
Foto: adesso AG
Ein Team bündelt nun nicht mehr technische Kompetenzen, sondern orientiert sich entlang einer Fachlichkeit, zum Beispiel der Anforderung, Kundendaten bearbeiten zu können oder Produkte in einem Warenkorb sammeln zu können oder die Zahlungsabwicklung für einen gewissen Geldbetrag initiieren zu können. Abstimmungsaufwände können sich durch diese Organisationform reduzieren, wenn die Abgrenzung der Teams sauber, also anhand längerfristig gültiger, eindeutiger Merkmale erfolgt. Dann kann ein Großteil von Anforderungen innerhalb von nur einem Team vollständig abgearbeitet werden.
Für eine solche, vertikale Organisation ist die Definition der Grenzen und Verantwortlichkeiten allerdings ungleich schwieriger als bei der horizontalen Organisation, die nach technisch begründeten - gefühlt in Stein gemeißelten - Grenzen, folgt.
Technologische Vertikalisierung
Die technischen Grenzen zwischen Architekturebenen bleiben bei der reinen Vertikalisierung der Organisation erhalten und wirken sich aus. Veränderungen an Benutzerschnittstelle, Geschäftslogik und Datenhaltung erfolgen weiterhin gleichzeitig. Auch wenn Teams vertikal organisiert sind ist es einfach, Programmteile, die von Mitgliedern anderer Teams entwickelt und für ein anderes fachliches Ziel entwickelt wurden, zu nutzen und auch zu verändern. Dadurch häufen sich technische Schulden an, die schließlich zu erhöhtem Abstimmungs- und Kommunikationsaufwand zwischen den Teams führen und die Weiterentwicklung und Wartung der Software erheblich erschweren.
Damit die Vorteile der vertikalen Organisation nicht bei der Umsetzung, also der Programmierung, des Testens und der Inbetriebnahme durch eine Team-übergreifende 3-Schichten-Architektur eingebremst werden, ist es technisch möglich, diese Organisationsform auch architektonisch und technologisch zu manifestieren. Das Resultat dieser Architektur sind technisch entkoppelte Komponenten, die durch die Entkopplung unabhängig von anderen Komponenten entwickelt, getestet und sogar in den produktiven Einsatz überführt werden können. Jede dieser Komponenten setzt für sich die notwendigen architektonischen Schichten um (vgl. Abbildung 4). Die vertikalen werden in der Architektur daher auch als Microservices bezeichnet.
Foto: adesso AG
Unter den Begriffen Bounded Context und Domain Driven Design finden sich Konzepte, die sich mit der Modellierung solcher fachlich orientierter Komponenten befassen. Prinzipien und Theorien, die bereits vor Jahrzehnten für die Modularisierung von Programmcode erforscht wurden, wie die des Information Hiding, enthalten weitere relevante Hilfestellungen.
Agilität und Vertikalisierung
Wie in Abbildung 5 dargestellt, ermöglicht die Kombination einer vertikalisierten Organisation und Architektur eine fein-granulare Inbetriebnahme. Durch die starke Entkopplung sowohl der Teams als auch der Softwarekomponenten, für die sie verantwortlich sind, kann ein Team neu umgesetzte Anforderungen in den produktiven Betrieb bringen und zwar sobald es fertig ist, beziehungsweise nicht erst dann, wenn alle an einer gemeinsamen Code-Basis arbeitenden Teams fertig sind. Wartezeiten und Komplexitäten, die durch die gemeinsame Arbeit mehrerer Teams an einer großen Software entstehen, entfallen - zumindest für Anforderungen, die nicht fachübergreifend sind und damit auf mehrere Komponenten Auswirkungen haben.
Foto: adesso AG
Komplexität Verteilter Systeme
Die Autarkie der Teams und ihrer Softwarekomponenten bedeutet, dass das Gesamtsoftwaresystem, welches die Teams entwickeln und erweitern, ein verteiltes System ist. Anders als bei monolithischer Software, einer Software, die in einem Stück ausgeliefert wird und durch einen Prozess repräsentiert wird, kommunizieren die Komponenten über Netzwerk-Schnittstellen. Es gibt keine Verfügbarkeitsgarantie für eine Netzwerkverbindung, dieser Tatsache muss Rechnung getragen werden.
Die Komponenten müssen sich auch finden können, es werden zusätzliche Komponenten benötigt, die vorhalten, welche Komponenten unter welcher Adresse mit welchen Schnittstellen verfügbar sind. Auch die Überwachung der Anwendung wird komplexer da mehrere, über das Netzwerk verteilte, Komponenten überwacht werden müssen. Die Prozesse, die beim Starten und Anhalten des Gesamtsystems ablaufen sind komplexer. Es kann Abhängigkeiten in der Startreihenfolge geben oder Bedingungen, die für das Anhalten und Starten beachtet werden müssen.
Diese Aspekte zu behandeln bedeutet Mehraufwand, andererseits wird das Gesamtsystem dadurch aber auch robuster. Fehler in Teilkomponenten haben weniger Einfluss auf das Gesamtsystem. Zusätzlich wird die Microservice-Architektur heute durch fertige Frameworks und Bibliotheken unterstützt, so dass viele der zusätzlich benötigten Funktionen und Werkzeuge bereits zur Verfügung stehen und sich vertikale Architekturen dadurch immer schneller und günstiger umsetzen lassen.
Um Agilität durch Microservice-Architekturen weiter zu befeuern, bedarf es dabei auch eines hohen Automatisierungsgrades für Entwicklungs- und Inbetriebnahmeprozesse.
Fazit
Die Architektur einer Software kann, da sie Einfluss auf die Organisation und Methodik nimmt, agile Vorgehensweisen signifikant treiben oder aber verhindern.
Die Vertikalisierung kann eine Teilantwort auf die neuen Herausforderungen der Digitalisierung geben. Sie bietet Möglichkeiten für große Projekte, horizontal in der Organisation zu skalieren und Projektgeschwindigkeiten zu halten. Neue Anforderungen können beispielsweise durch neue vertikale Komponenten mit dafür verantwortlichen Personen hinzugefügt werden. Die Vergrößerung von Entwicklungsteams kann dadurch zu geringem Abstimmungsaufwand und mit geringer Erhöhung des Projekt-Overhead erfolgen.
Grundsätzlich ist die Architektur einer Software im Zusammenklang mit agilen Vorgehensweisen, fachlichen Gegebenheiten, Organisationsformen und Reifegraden - sowohl methodisch, kulturell, als auch technisch - zu entwickeln. Vertikalisierung ist heute eine Ergänzung des architektonischen Lösungsraums die sich aktuell in unterschiedlichen Branchen und für unterschiedliche Anwendungsfälle bewährt hat. Sie ist nicht mehr nur ein Phänomen von IT-Startups, deren Geschäftsmodelle IT-Innovationen voraussetzen. (bw)