Was das Burger bauen mit der Modernisierung von Anwendungen zu tun hat…
Mit einer Burger Competition endete der erste Enterprise DevOps Day Frankfurt. Die gut 60 Teilnehmer hatten sichtlich Spaß und kamen noch intensiver ins Gespräch. Steckte da mehr dahinter als nur der gelungene Ausklang eines inhaltsreichen Programmtages? Auf den zweiten Blick zeigen sich erstaunliche Parallelen zwischen unserem Business Thema DevOps und der fachgerechten Zubereitung eines individuellen Bulettenbrötchens.
Aus Erfahrung lernen
Am Anfang eines neuen Vorhabens ist es immer gut, sich Tipps von Praktikern zu holen, die bereits Erfahrungen gesammelt haben – das gilt in der Küche, und noch viel mehr in der IT. In Sachen DevOps-Einführung öffnete meine Kollegin Sigal Ishay, Functional Architect in unserem Entwicklungsteam für Octane, ihr ganz persönliches Rezeptbuch. Sie berichtete aus der Praxis, welche Vorgehensweisen sich für ihr Team bewährt haben. Denn auch unsere Entwicklungsmannschaft hat eine beachtliche Transformation durchlaufen: von 18-Monats-Zyklen auf eine monatliche Delivery. Von 30 Features pro Jahr auf 10 pro Monat. Ein Weg nicht ohne Hindernisse – und eine Lernkurve, bei der es ab und an heiß her ging und sich das Team auch mal die Finger verbrannte. „We needed to learn and to fail to learn what is working for us”, gab sie unumwunden zu. Sie berichtete vom Umbau der Teams in eine vertikale Organisation, in der jedes Team für die pünktliche und stabile Bereitstellung der von ihm entwickelten Features verantwortlich ist. Mit diesen formalen Änderungen ging auch ein kulturelles Umdenken einher: Die Mitarbeiter mussten sich erst daran gewöhnen, durch die kürzeren Sprints kontinuierlich am Ball zu bleiben. Ein weiteres Learning aus der Micro Focus Entwicklung: Eine Eins-zu-eins-Zuordnung der Features auf einzelne Mitarbeiter erwies sich nicht als zielführend. Heute werden die Features nach ihrer Bedeutung priorisiert und je wichtiger ein Feature ist, umso mehr Ressourcen werden ihm zugewiesen.
Die Qualität muss stimmen
Eine weitere Parallele zwischen Burger bauen und Entwicklung: Neben dem richtigen Timing muss auch die Qualität des Endergebnisses passen. In punkto Qualität stellte die „Zutat“ Automatisierung eine der größten Herausforderungen dar. Für mich verhält es sich mit der Automatisierung so wie mit dem Salzen: Zu wenig ist wirkungslos, zu viel dagegen kontraproduktiv.
Jedes Unternehmen müsse für sich herausfinden, welche Schritte sich sinnvoll automatisieren ließen und welche nicht, gab Sigal Ishay den Zuhörern mit. Denn es ist nicht damit getan, eine Testumgebung aufzusetzen und dann die Programmcodes einfach „durchzuschieben“. Unstabile Testszenarien führen schnell zu irrtümlichen Fehlermeldungen. Die sich anschließende, aufwändige Ursachensuche kann im schlimmsten Fall dazu führen, dass das Team mit Automatisierung langsamer vorankommt als ohne. Diesen „Noise“ gilt es möglichst auszuschalten. Daher überwachen Sigal Ishay und ihre Kollegen über Quality Dashboards zahlreiche Key Performance Indikatoren, darunter die durchschnittliche Zeit, bis ein Fehler behoben ist (MTTR – Mean Time To Recover): „Are we reducing the time to recover? This is an indicator that we understand the processes and are improving”, verriet sie.
„Wir müssen reden“
Unternehmen, die das Thema DevOps angehen, müssen vor allem in punkto Zusammenarbeit und Kommunikation umdenken: Das bestätigte auch Sigal Ishay. Ihr Team führte daher einen speziellen „Sprint 0“ ein. In diesem Sprint erklären die Functional Architects den Entwicklern die Hintergründe jedes Features. Die Entwickler verstehen so besser die Intention einer Anforderung. Entwicklungen, die am User-Nutzen vorbeigehen, werden so ebenso vermieden wie Qualitätsabstriche am Ende eines zeitlich knappen Sprints. Genau wie bei einem guten Burger: Alle Komponenten müssen in ihren Aromen und ihrer Zubereitung aufeinander abgestimmt sein, damit es am Ende beim Reinbeißen rundherum schmeckt. Damit dies gelingt, müssen sich alle beteiligten Köche abstimmen.
Zu heiß und schnell „gebraten“ ist nicht die Lösung
Dass Schnelligkeit allein noch kein DevOps macht, bestätigte bei unserem Enterprise DevOps Day auch das Praxisbeispiel der Provinzial Rheinland Versicherung. Auslöser für die digitale Transformation im Jahr 2010 war die Tatsache, dass die IT des Versicherers 30 bis 40 Deployments pro Tag auf den Weg brachte – dies jedoch nicht voll kontrolliert. Die hohe Schlagzahl führte mitunter dazu, dass Code sogar ohne Tests ausgerollt wurde. Die Teams für Java- und Mainframe-Entwicklung arbeiteten zudem nicht optimal zusammen. Das liegt natürlich auch in der Natur der Sache. Schließlich treffen hier zwei fundamental unterschiedliche Welten aufeinander: JAVA-basiertes, agiles Arbeiten auf der einen, die COBOL-Welt mit ihrem traditionellen Wasserfall-Ansatz für Projekte auf der anderen Seite. Ein übergreifendes Release Management, Audits oder Tracking der Deployments fand damals nicht statt. Inzwischen hat der Versicherer einen konsistenten Planungsprozess von der Anforderung bis zum Release etabliert. Mit einem Set integrierter Tools ist es heute möglich, dass Java- und Mainframe-Teams enger abgestimmt entwickeln. Zudem kann die Umsetzung einer Anforderung durch die gesamte Deployment Pipeline nachverfolgt werden.
Blueprint ja, Patentrezept nein
Selbst die kreativsten Köche arbeiten irgendwie nach Rezept: Auch wenn Sie kein Rezeptbuch neben sich liegen haben, folgen sie doch einem Raster, wann was wie zu tun ist. Mit unserem Blueprint für Enterprise DevOps wollten wir den Teilnehmern genau so ein Gerüst an die Hand geben – vom Projektportfolio-Management über IDE, Source Code Management und dem Testen bis zum operativen Betrieb. Mit welchen Zutaten, sprich Tools, welche Phase bewerkstelligt werden kann, wurde ebenfalls gezeigt – sowohl theoretisch als auch anhand einer umfassenden Live-Präsentation, bei der wir das Zusammenspiel der einzelnen Phasen demonstrierten. Denn die Micro Focus Lösungsbereiche Application Modernization & Connectivity sowie Application Delivery Management bieten sowohl eine breite Palette verschiedenster Werkzeuge aus dem eigenen Haus als auch umfassende Integrationsmöglichkeiten zu Anwendungen anderer Anbieter.
Dieser erste Enterprise DevOps Day hat recht plastisch vor Augen geführt: Das eine Patentrezept für DevOps gibt es nicht. DevOps bietet lediglich das Gerüst einer Methodik, die von Organisation zu Organisation ganz unterschiedlich mit Leben zu erfüllen ist. Diese Flexibilität erfordert einen entsprechend variablen Werkzeugkasten und die Offenheit, die Tools nach Bedarf zu entsprechenden Prozessen zu kombinieren. Damit lassen sich die unterschiedlichen Rollen im Software Development weiterentwickeln und es entsteht eine neue Kultur der Zusammenarbeit. Noch eine weitere Erkenntnis zeigte sich für mich überdeutlich. Wenn sich in einem Team Stärken bündeln, kann etwas Großartiges entstehen – sowohl in der IT, als auch beim Burger bauen. In diesem Sinne nochmals: Herzlichen Glückwunsch dem Sieger-Team der Burger Challenge!
