Gut zwölf Jahre ist es her, als eine Reihe namhafter Softwareentwickler das Agile Manifest veröffentlicht hat. Sätze wie "Anforderungsänderungen sind selbst spät in der Entwicklung willkommen" waren Anfang des Jahrtausends eine Revolution für die IT-Welt. Über ein Jahrzehnt später ist es der agilen Idee wie vielen revolutionären Ideen ergangen: Sie ist in der Mitte der Gesellschaft, in diesem Fall in den Unternehmen, angekommen. Scrum und Sprints sind in vielen Projekten eine Selbstverständlichkeit geworden. Je nach Unternehmen, Projektgröße und Komplexität werden die agilen Konzepte mal konsequent und mal abgeschwächt angewendet. In der Regel läuft es auf eine Mischung aus agilen und plangetriebenen Verfahren hinaus. "Gezähmte Agilität" ist das dazu passende Stichwort.

Die zwei Seiten der Agilität

Agilität wirkt dabei in zwei Richtungen: Einmal nach "vorne" in Richtung Anwender, Kunden und Auftraggeber. Um diese Seite der Agilität zu managen, existieren unterschiedliche Methoden und Werkzeuge. So bietet der Interaction Room die passende methodische Unterstützung. Mit seiner Hilfe lassen sich die Hindernisse für agiles Arbeiten aus dem Weg räumen. Fach- und IT-Abteilungen können sich auf ihre Projektziele konzentrieren.

Aber das agile Konzept in der Anwendungsentwicklung wirkt sich auch in Richtung des Betriebs aus: Wenn in kurzen Abständen neue Releases auf produktionsnahen oder sogar produktiven Systemen veröffentlicht werden sollen, ist der IT-Betrieb gefordert. Während früher zwei große Updates jährlich betrieben wurden, gibt heute die agile Entwicklung die Schlagzahl vor. Im Wochenrhythmus oder sogar täglich steht eine neue Version zur Verfügung.

Der IT-Betrieb muss sich dieser Taktung anpassen. Hier kommt es zu einem Zielkonflikt zwischen Development und Operations: Beide Bereiche müssen die Anforderungen des Business schnell und sicher umsetzen. Für die einen bedeutet das, kreativ neue Lösungen zu entwickeln und zu veröffentlichen. Für die anderen, auf Basis fester Strukturen eine stabile Verfügbarkeit zu garantieren. So gesellt sich das Biz zu Dev und Ops.

Um die Situation zwischen Betrieb und Entwicklung zu entspannen, sollten die Verantwortlichen den Hebel an zwei Stellen ansetzen: Auf technischer Ebene geht es um die Automatisierung der Prozesse zur Inbetriebnahme. Auf organisatorischer Ebene um die Bildung von sogenannten DevOps-Teams, also gemeinschaftlich verantwortlichen Arbeitsgruppen, die sich aus Entwicklern und Betriebspersonal zusammensetzen.

Es kann "automatisch" besser werden

Ziel ist es, sowohl die bereitgestellte Software als auch die Entwicklungs-, Test- und Produktivumgebungen automatisiert - sozusagen auf Knopfdruck - zu produzieren und bereitzustellen. Bisher war dieser hohe Automatisierungsgrad in den meisten Organisationen nicht notwendig. Bei wenigen neuen Releases pro Jahr rechnet sich der damit verbundene Aufwand nicht. Gleichzeitig ändert sich mit großer Wahrscheinlichkeit die Struktur der Zielumgebung, wenn zwischen zwei Software-Updates mehrere Monate vergehen. Ein einmal automatisierter Prozess müsste also erneut überarbeitet und an die neuen Strukturen angepasst werden.

Deswegen wird bei solchen eher statischen Rahmenbedingungen in der IT auf "Handarbeit" gesetzt. Dabei ist jeder einzelne Mitarbeiter für den Erfolg des stark taylorisierten Prozesses von Bedeutung. Unvorhergesehene Abwesenheiten, der Verlust von Kompetenzträgern oder unterschiedlich qualifizierte Fachleute sorgen für Probleme im gesamten Prozess. Oder sogar für seinen Stillstand.

Wenn Updates aber nicht im Abstand von Monaten, sondern mehrmals pro Woche, täglich oder bei jedem Freischalten neuen Quellcodes durch den Entwickler veröffentlicht werden sollen, müssen die IT-Betriebsprozesse grundlegend überdacht werden. Jetzt sind Installationsroutinen gefragt, die permanent prüfen, ob veränderte Software in Betrieb genommen werden kann. Die Schlagworte "Continuous Integration" und "Continuous Delivery" beschreiben die Idee dahinter sehr plastisch.

Im Gegensatz zu ersten Ansätzen der Automatisierung bietet die aktuelle Continuous-Delivery-Werkzeugpalette heute vielfältige Möglichkeiten: Das reicht vom Adressieren heterogener Infrastrukturen bis zum automatisierten Bereitstellen von Umgebungen und deren Integration in die vorhandene IT-Infrastruktur (beispielsweise mit Softwarelösungen wie "Puppet" oder "Chef"). Zum Content Delivery gehören auch Tools für die Umsetzung von Monitoring- und Logging-Mechanismen für das automatisierte Testen, das Verwalten von Softwarekomponenten (zum Beispiel "Nexus") und das Orchestrieren des gesamten Prozesses (zum Beispiel "Jenkins"): von der Verfügbarkeit neuen Quellcodes bis hin zu der Inbetriebnahme des entsprechenden Softwareupdates in der Produktivumgebung.

Wie stark Prozesse von einem höheren Automatisierungsgrad profitieren können, zeigt ein Beispiel aus der Versicherungswirtschaft: Bei einem größeren Konzern mussten bislang für die Inbetriebnahme eines Partnersystems zirka zwei Tage veranschlagt werden. Ein relativ langer Zeitraum für ein Softwaresystem, das in der Aufruf-Hierachie eher auf einem unteren Rang liegt. Hinzu kam die Fehleranfälligkeit des Prozesses, ausgelöst durch den hohen Anteil manueller Arbeitsschritte bei der Implementierung. Der Einsatz einer Automatisierungslösung reduzierte den Zeitaufwand um fast 98 Prozent: In weniger als einer Stunde steht das neue System jetzt - bei einer deutlich geringen Fehlerquote des Prozesses - bereit. Die Abbildung "Inbetriebnahme des Partnersystems" zeigt wie diese automatisiert wurde.

Automatisierung wirkt sich an mehreren Stellen positiv auf den Gesamt-Prozess aus. So werden Fehler vermieden, die durch die unterschiedliche Konfiguration von Entwicklungs-, Test- und Produktivumgebungen entstehen. Da diese Fehlerquelle entfällt, wird die Fehlersuche insgesamt erleichtert.

Die Automatisierung des Inbetriebnahmeprozesses verändert die Rolle des IT-Betriebs und die Anforderungen an diesen. Der IT-Betrieb wird zunehmend zu einem Entwicklungsprozess - nämlich des Prozesses zur Entwicklung von Infrastruktur inklusive der darin befindlichen Umgebungen. Das verbirgt sich hinter dem Schlagwort "Infrastructure as Code". Automatisierung bedarf einer formalen Beschreibung der Umgebungen, typischerweise ausgedrückt in sogenannten DSLs (Domain Specific Languages = domänenspezifische Sprachen, beispielsweise angepassten Programmiersprachen) der Automatisierungswerkzeuge.

Die Bereitstellung von Infrastruktur wird zu einem Prozess, der mit den gleichen Methoden und zum Teil sogar den gleichen Werkzeugen unterstützt werden kann wie die Softwareentwicklung. Beispiele dafür sind die Versionierung von Code für die Infrastruktur oder das Entwickeln von Design Patterns für bestimmte Infrastrukturaufgaben wie das Aufsetzen eines Webservers.

Um neue Software schneller, sicherer und fehlerfreier zu veröffentlichen, ist Automatisierung nur ein Ansatz. Auch der passende organisatorische Rahmen, innerhalb dessen Entwicklung und Betrieb zusammenarbeiten, hilft dabei, die gestiegenen Anforderungen an die Geschwindigkeit zu realisieren.