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:

1. Anforderung mit IT-Experten kommunizieren, damit diese sie verstehen und so korrekt und zügig umsetzen können.

2. Anforderung umsetzen, als Software programmieren

3. Umsetzung überprüfen (Unit-Test)

4. Neue erstellte Software mit existierender Software integrieren

5. Die fehlerfreie Integration überprüfen (Integrationstest)

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

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

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.

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.

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)