Im Februar 2001 fand eine Gruppe von Software-Entwicklern in einem Hotel in den Wasatch-Bergen in Utah zu einem Gedankenaustausch zusammen. Ihnen allen gemeinsam war ihre Unzufriedenheit mit den schwergewichtigen Methoden, mittels derer SW-Projekte realisiert wurden. Sie litten unter dem Eindruck, zu viel ihrer Zeit auf Themen wie Prozess- und Toolmanagement, umfassende Dokumentation, Vertragsmanagement und Planupdates zu investieren, statt das zu tun, wofür sie eigentlich angestellt waren, nämlich um qualitativ ausreichenden Code zu schreiben, der einfach auf ändernde Anforderungen ausgerichtet werden kann. Im Laufe dieses Wochenendes ist aus dem Häufchen Entwickler die Agile Alliance entstanden mit dem Auftrag, die Grundlagen der agilen SW-Entwicklung zu definieren und zu pflegen.
Agile Softwareentwicklung kam nicht über Nacht
Damit wurde einem Industrietrend ein ideologisches Gerüst (und ein knackiges Schlagwort) geschenkt, der sich schon in den Neunziger Jahren angekündigt hatte. Die Grundlagen einer service-orientierten Architektur, die gemeinsame Arbeit an Entwicklungswerkzeugen, das Teilen von Artefakten im OpenSource-Verfahren, die Publikation von Architekturstandards für hoch skalierbare Umgebungen durch Marktplayer wie Amazon, Facebook und Google, die kostengünstige Anmiete von performanten Rechner- und Speicherinfrastrukturen in der Cloud: Innert weniger Jahre wurde ein Ökosystem geschaffen, welches es Entwicklern erlaubte, sich in zuvor nicht gekannter Weise von den Fesseln „schwerer“ SW-Entwicklung zu befreien, und zwar sowohl hinsichtlich der Kapitalbindung des Entwicklungsprozesses als auch bezüglich der Fähigkeit, kollaborativ die Qualität des geschriebenen Codes zu erhöhen – und wenn sich dann doch ein Codefehler in die Produktion geschlichen hatte, diesen innert kurzer Zeit zu beheben.
Software-Defined löst proprietäre Infrastrukturen ab
Diese Flexibilität und Agilität wird für immer breitere Kreise in der IT interessant. Bereits seit einigen Jahren sehen sich Anbieter von traditionellen IT-Infrastrukturen durch das Phänomen des „Software-Defined“ herausgefordert. Gemeint ist dadurch, dass Mehrwertdienste klassischer IT-Infrastruktur von der eigentlichen Infrastruktur abstrahiert und durch einen Software-Layer angeboten werden, der seinerseits nicht auf teuren Spezialkomponenten basiert, sondern auf Commodity-Infrastrukturen, die industriell in sehr hoher Stückzahl und identischer Qualität hergestellt werden können. Sind Anpassungen z.B. an der Datenreplikation zwischen mehreren Standorten nötig, können diese Anpassungen in der dafür eingesetzten Software vorgenommen werden, ohne dass davon die darunterliegende Infrastruktur beeinflusst wird.
Noch viel besser ist es natürlich, wenn die geschriebene Business-Software gar nicht auf Datenreplikation angewiesen ist, sondern selbständig ihre Last über eine Vielzahl von Nodes verteilen kann. Und auch hier sehen wir moderne Software-Architekturen, die sich von der Erwartung des perfekten, immer verfügbaren Servers emanzipieren und ihre Resilienz durch Einbezug einer unendlichen Menge von Knotenpunkten selbständig organisieren.
Software isst die Welt auf
Und so wird wahr, was Netscape-Gründer Marc Andreesen in einem Leitartikel des Wall Street Journals im August 2011 beschrieben hat: Software is eating the World, und zwar sowohl auf der Erbringer- als auch auf der Bezügerseite einer Informatikleistung. Gemäss der Webseite statista.com verwenden 1.9 Mia Benutzer im Jahr 2015 soziale Netzwerke, und 2018 sollen es bereits 2.8 Mia sein. Somit werden IT-basierende Leistungen nicht nur für die „Digital Natives“ zur Selbstverständlichkeit, sondern für breite Bevölkerungsschichten. Vor diesem Hintergrund hat die Marktforschungsfirma Vanson Bourne im Auftrag von Intel und EMC Ende 2014 bei 3800 IT-Entscheidern abgefragt, welche Kundenerwartungen sie in den kommenden zehn Jahren als Musskriterien zur erfolgreichen Geschäftsausübung sehen. 55% aller Befragten nannten die Erwartung auf IT-basierende Services sehr schnell zugreifen zu können, an erster Stelle, dicht gefolgt vom Anspruch, die Leistung jederzeit (53%), von einem beliebigen Endgerät aus (50%) und unter Wahrung einer personalisierten Endbenutzererfahrung (47%) konsumieren zu können.
Digital Natives drücken ihre Erwartungen einer ganzen Industrie auf – und umgekehrt
Fassen wir zusammen: Durch technologische und soziale Veränderungen bilden wir eine Konsumentenschicht heran, die IT-Services zu einem festen Bestandteil ihres Lebensstils macht – und diese ohne Einschränkungen konsumieren will. Gleichzeitig erlauben uns Fortschritte vor allem in der Anwendungsentwicklung, aber auch im Hosting von IT-Leistungen, diese Erwartung auch zu befriedigen. Das eine Phänomen bedingt das andere, und gegenseitig beschleunigen sie sich fortwährend, rein theoretisch bis der Grenznutzen einer IT-Leistung für die Konsumentenschicht erreicht ist, was alleine aufgrund des Bevölkerungswachstums auf unserem Planeten so schnell nicht der Fall sein wird.
Aus ökonomischer Sicht gesehen begünstigt diese Entwicklung agile kleine Unternehmen, die nicht das Gewicht vergangener IT-Jahrzehnte mit sich schleppen müssen. Etablierte Unternehmen dagegen sind gezwungen, nur schon aus regulatorischer Sicht einen substantiellen Anteil ihres IT-Budgets für die Aufrechterhaltung des Status Quo auszugeben – Geld, das für Neuentwicklungen fehlt. Ein Unternehmen wie WhatsApp muss nicht eine Abwärtskompatibilität über Jahre sicherstellen wie eine klassische Telekom-Unternehmung, ein Transportdienst wie Uber kümmert sich wenig um veraltete Technologien in Taxizentralen.
Zuviel Leergewicht – etablierte Unternehmen sind herausgefordert
Als entsprechend schwerfällig wird die traditionelle IT von den „neuen Wilden“ wahrgenommen, und das ist an sich nicht Schlechtes, ist es doch die Mission eines IT-Betriebes, die ihr anvertrauten Leistungen möglichst ausfallfrei zu erbringen. Die Methoden zur Sicherung der Resilienz in einem traditionellen Rechenzentrum interessieren Business- und Anwendungsvertreter, die auf der Basis neuer Technologien Leistungen entwickeln, herzlich wenig, und ganz im Sinne des agilen Manifestes suchen sich den Weg des geringsten Widerstandes, um die Erwartungen ihrer Konsumenten möglichst schnell zu befriedigen. Nicht oft führt der Weg über Cloud-Provider, was die traditionelle IT erneut vor technische und Compliance-Herausforderungen stellt, wenn es darum geht, diese neuen Anwendungen mit Daten aus den Stammanwendungen zu beliefern – und Daten der neuen Anwendungen in die Heimsysteme zu integrieren.
IT-Betrieb im Zielkonflikt: Agil oder stabil?
So ist denn der IT-Betrieb mit einem Zielkonflikt konfrontiert: Zum einen soll er von den agilen Teilen der Unternehmung als zuverlässiger und engagierter Businesspartner wahrgenommen werden, um die unkontrollierte Abwanderung von Business-Services in die Cloud zu verhindern. Zum anderen dürfen die dürfen die Strukturen, die zur Stabilitätssicherung traditionell programmierter Anwendungen etabliert worden sind, nicht einfach in einem Anflug von Aufbruchstimmung über Bord geworfen werden. Dass die vielerorts im Einsatz stehenden Prozess-Strukturen der IT Infrastructure Library (ITIL) von Kritikern als zu rigide betrachtet werden, heisst nicht, dass auf sie ganz verzichtet werden muss. IBM-Forscher David Norfolk schrieb in einem vielbeachteten Beitrag bereits 2012, dass das logische Model von ITIL einer agilen IT nicht grundsätzlich entgegenstehe; was aber dringend revidiert werden müsse, seien Umsetzungsmodelle, die die Messlatte für rasche Veränderung unmöglich hoch legen – natürlich aus dem Verständnis heraus, dass ein Fehler, der sich in die IT-Produktion geschlichen hat, frühestens nach sechs Monaten auch korrigiert werden kann.
DevOps – mehr kultureller Wandel denn Einführung neuer Technologie
Die Bemühungen, den IT-Betrieb flexibler zu gestalten und auf agile Entwicklungsteams abzustimmen, werden gerne unter dem Begriff „DevOps“ zusammengefasst. Wie bei jedem Buzzword wird auch dieses gerne in Anspruch genommen, um neue Technologien an den RZ-Mann resp. die RZ-Frau zu bringen, von NoSQL über Puppet bis zu ServiceNow erstreckt sich das Spektrum der Produkte und Dienstleistungen. Was DevOps jedoch vor allem auszeichnet, ist ein kultureller Wandel in der Zusammenarbeit: Verbesserung der Kommunikation, Förderung des gegenseitigen Verständnisses, verstärkte Integration und nicht Abgrenzung der Prozesswelten und Aufbau und Pflege von Arbeitsbeziehungen über die traditionellen Silos hinweg. Das Umdenken lässt sich sehr anschaulich bildlich beschreiben: In einem traditionellen Rollenbild sieht sich der IT-Betrieb als Bollwerk von Konstanz und Stabilität, das seitens der Anwendungsentwicklung unter konstanter Attacke ist. Die Dynamik der Veränderung, die die Entwicklung in die Betriebsfestung bringt, gilt es zu zähmen durch mehrere Verteidigungsringe, die ein Entwicklungsvorhaben mit formalen Kriterien belasten, deren Erfüllung zwingend notwendig ist, um in die heiligen Hallen der IT-Produktion vorgelassen zu werden, wo wenige Eingeweihte dafür sorgen, dass die heilige Flamme nie erlischt. Ein Anhänger der DevOps-Kultur würde hingegen die IT-Leistungserbringung als einen integrierten Produktionsprozess beschreiben, der ähnlich einem Industriebetrieb mit einer Business-Idee einen Anfang nimmt, welche sich in Software-Code niederschlägt, der wiederum eine Reihe von Qualitätstests durchläuft, bevor er durch den IT-Betrieb der Kundschaft zur Verfügung gestellt wird. Förderband statt Bollwerk. Industriezeitalter statt Mittelerde – das ist DevOps.
Entlehnungen bei den Prinzipien der Lean Production
Für die industrielle Betrachtungsweise spricht auch die Tatsache, dass sich sowohl die agile SW-Entwicklung als auch DevOps gerne bei den Prinzipien der Lean Production. Dabei handelt es sich um eine Optimierungsmethode für industrielle Produktionsbetriebe, die zwei Ingenieure – Taiichi Ohno und Eiji Toyoda – in den 40er Jahren des vergangenen Jahrhunderts für den japanischen Autohersteller Toyota entwickelt haben. Die Legende geht, sie hätten sich bei der Ausarbeitung ihrer Thesen von Supermärkten inspirieren lassen, insbesondere von deren Eigenschaft, von einem Konsumgut eine relativ kleine Menge bereitzustellen, die durch den Kunden nachgefragt und in kurzen Zeitabständen durch den Supermarkt geprüft und wieder aufgefüllt wird. Im Rahmen ihrer Arbeiten identifizierten die beiden Ingenieure sieben Bereiche, in welchem Verschwendung anfallen kann: Überangebot, Wartezeiten, Transportverluste, Perfektionismus, übergrosse Lager, umständliche Arbeitsschritte und Qualitätsfehler.
Am Einfachsten in die Welt der agilen Software-Entwicklung übernommen werden können die Bereiche Wartezeiten, Perfektionismus, umständliche Arbeitsschritte und Qualitätsfehler. Diese Bereiche können auch am Einfachsten mit Technologie gezähmt werden. Ein Provisionierungssystem, das Entwickler auf Bestellung automatisch mit virtuellen Servern ausstattet, Entwicklungstools, die Schritte zur Qualitätsprüfung bereits fix eingebaut haben – die Vorteile für einen agilen Entwicklungsprozess liegen auf der Hand. Auf der kulturellen Seite des Kataloges sind eher Massnahmen anzusiedeln wie die Daily Standup Meetings, sehr kurze Treffen, an welchen jedes Mitglied der Produktionsstrasse einer IT-Leistung Auskunft erteilt, was er bis dato erreicht hat, was er sich als nächstes vorgenommen hat und welche Hindernisse ihm im Weg stehen. Auch Visualisierungsmethoden wie die des Kanban (japanisch für „Anzeigetafel“) lassen sich sehr gut im Entwicklungs- und Betriebsprozess gemeinsam verwenden, geben sie doch auf einfache Weise nicht nur Auskunft darüber, welches Artefakt wo im Entwicklungs- und Betrieb steht, sondern auch, welche Station im Prozess mit wie vielen gleichzeitig zu bearbeitenden Aufträgen belastet ist.
Um zur einleitenden Fragestellung zurückzukehren: Sind agile Software-Entwicklung und IT-Betrieb nun natürliche Feinde oder nicht? Die Antwort ist: Es kommt darauf an, wie der IT-Betrieb sich versteht. Ist die Prämisse, höchstmögliche Betriebsqualität als absolut höchste Priorität jederzeit sicherzustellen, werden Mitarbeitende des IT-Betriebes negativ auf Veränderungen reagieren, die durch die agile Entwicklung in hoher Frequenz in die IT-Produktion eingebracht werden. Vermögen IT-Betriebsabteilungen jedoch, ihre Prozesse weitgehend zu flexibilisieren und bei einem einfachen, nicht überengineerten Betriebsprozess-Modell zu bleiben, dann gibt es keinen Grund, warum Entwicklung und Betrieb nicht bestens zusammenarbeiten könnten.
a postmodernist's view 