Im Februar 2001 fand eine Gruppe von Software-Entwicklern in einem Hotel in den Wasatch-Bergen in Utah zu einem Gedankenaustausch zusammen. 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.
«DevOps» heisst «Development» und «Operations» (Quelle: Jon Collier, CC BY 2.0 )
Feinde oder nicht? Je nachdem (Quelle: Frits Ahlefeldt-Laurvig, CC BY 2.0).)
Agile Softwareentwicklung kam nicht über Nacht
Damit wurde einem Industrietrend 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 Open-Source-Verfahren, die Publikation von Architekturstandards für hoch skalierbare Umgebungen, 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 doch ein Codefehler in die Produktion geschlichen hatte – diesen in kurzer Zeit zu beheben.
Software isst die Welt auf
Und so wird wahr, was Netscape-Gründer Marc Andreessen 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 sollen 2018 bereits 2.8 Milliarden Erdenbürger Verwender eines sozialen Netzwerkes sein. Somit werden IT-basierende Leistungen nicht nur für die «Digital Natives» zur Selbstverständlichkeit, sondern für breite Bevölkerungsschichten.
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 gegenseitig.
Als entsprechend schwerfällig wird die traditionelle IT von den «neuen Wilden» wahrgenommen, ist es doch die Mission eines IT-Betriebes, die ihr anvertrauten Leistungen möglichst ausfallfrei zu erbringen.
Was revidiert werden muss
So ist denn der Betrieb eines etablierten Unternehmens 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. David Norfolk (Bloor Research) 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 unrealistisch 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.
Kultureller Wandel durch DevOps
Die Bemühungen, den IT-Betrieb flexibler zu gestalten und auf agile Entwicklungsteams abzustimmen, werden gerne unter dem Begriff zusammengefasst. Wie jedes Schlagwort wird auch dieses gerne in Anspruch genommen, um neue Technologien und Dienstleistungen an den RZ-Mann resp. die RZ-Frau zu bringen.
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 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 Stabilität, das unter konstanter Attacke der Anwendungsentwicklung steht. 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.
Anleihen bei der Autoindustrie
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» bedienen. Dabei handelt es sich um eine Optimierungsmethode für industrielle Produktionsbetriebe, die zwei Ingenieure – Taiichi Ohno und Eiji Toyoda – in den 40er Jahren für den Autohersteller Toyota entwickelt haben. Die beiden identifizierten sieben Bereiche, in welchem Verschwendung anfallen kann; davon können die Bereiche Wartezeiten, Perfektionismus, umständliche Arbeitsschritte und Qualitätsfehler ohne Widerstand in die Welt der agilen Software-Entwicklung übernommen werden.
Gleichzeitig können diese Bereiche 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 den agilen Entwicklungsprozess liegen auf der Hand.
Auf der kulturellen Seite 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.
Feinde? Oder doch nicht?
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. Unter der 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 es 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.
Stefan Züger ist Mitglied der AG Redaktion swissICT Magazin und Presales Manager Switzerland EMC.
