«Der wirtschaftliche Nutzen ist da»

Um neue IT-Projekte schneller in den operativen Betrieb zu überführen, hat SIX vor rund zwei Jahren begonnen, Dev­Ops in die Projektarbeit zu integrieren. Robert Scherrer, Head Application Engineering bei SIX, und Peter Graef, Managing Partner bei ipt, der das Projekt als externer Dienstleister begleitete, berichten über ihre Erfahrungen in der Praxis. Computerworld: Was war der Auslöser für den Umbau? Robert Scherrer: Eine interne Zufriedenheitsumfrage attestierte der IT zwar gute Stabilität, aber zu wenig Tempo und Flexibilität. Das war für mich der Anstoss, eine DevOps-Initiative vorzuschlagen. Innerhalb der IT-Leitung stiess dies sofort auf positives Echo, das erste Pilotprojekt war innert Wochenfrist vorgeschlagen. So konnten wir im vierten Quartal 2015 starten. CW: Was ist Ihr Part dabei, Herr Graef? Peter Graef: Ich beschäftige mich seit ein paar Jahren mit Dev­Ops und wurde von Robert Scherrer als Coach und «subject matter expert» für das Kernteam engagiert. Meine primäre Aufgabe war es, eine Aussensicht ins Projekt zu tragen und Impulse zu setzen, um die DevOps-Bewegung innerhalb der SIX zu unterstützen. CW: Was hat Sie vom DevOps-Konzept überzeugt? Scherrer: DevOps adressiert das Bedürfnis, immer schneller und flexibler neue Dienstleistungen zu lancieren, indem die involvierten Mitarbeiter vom Fachbereich über die IT-Entwicklung bis zum Betrieb funktionsübergreifend eng zusammenarbeiten. Repetitive Aufgaben werden über das heute bekannte Mass hinaus automatisiert und Engpässe nach «Lean»-Prinzipien angegangen. Damit schöpfen wir unser Potenzial optimal aus, was aus meiner Sicht bei Weitem die bessere Antwort auf die Digitalisierung ist als die Forderung nach immer mehr billigen IT-Spezialisten. CW: DevOps soll für schnellere Markteinführungen sorgen. Sollte das nicht schon die agile Software-Entwicklung? Wozu braucht es da noch DevOps? Graef: Agile, Lean, DevOps, Kanban, Kaizen… you name it. Es gibt grosse Überlappungen bei den Konzepten und Ideen, das macht aber den Leuten, die an den Resultaten interessiert sind, nichts aus. Schwieriger wird es, wenn sogenannte «Evangelisten» bestimmte Methodiken, Vorgehensmodelle oder Frameworks möglichst unternehmensweit einsetzen möchten. Da geht es manchmal mehr um das Framework als um das Resultat. CW: Haben Sie denn schon ein IT-Projekt mit einem DevOps-Team umgesetzt? Scherrer: Wir setzen bereits seit bald einem Jahr jede Ent­gegennahme eines neuen oder geänderten Finanzinformations-Feeds in diesem Modus um und haben laufend mehr Projekte, die wir von Beginn weg so starten. Ein speziell zu erwähnendes Projekt ist vielleicht «Sales Revolution», bei dem wir Business-Prozesse bis zum angehenden Kunden hinaus digitalisieren. Hier wurde nicht nur funktionsübergreifend zusammengearbeitet, sondern auch von Anfang an ein «minimum viable product» lanciert, also ein minimaler Funktionsumfang, der bereits Wert generiert und anschliessend iterativ Funktion um Funktion ergänzt wird. CW: Haben Sie damit einen messbaren Nutzen erzielt? Scherrer: Produkt- und Software-Engineering sind von der Natur des Prozesses her dem Design und nicht der Produk­tion zuzuordnen. Damit sind sie per se nicht einfach zähl- und vergleichbar. Jedes neue Produkt wird nur genau einmal erschaffen und kann mit anderen neuen Produkten nicht eins zu eins verglichen werden. Trotzdem messen wir z. B. die Durchlaufzeit und haben in Teams, die bereits umgestellt sind, bei vergleichbaren Aufträgen eine Verkürzung von einem Faktor drei gemessen. Gleichzeitig konnten wir Prozessschritte eliminieren und damit die Prozesskosten senken. Der wirtschaftliche Nutzen ist da und wird ergänzt durch die erhöhte Flexibilität im sich immer schneller wandelnden Geschäftsumfeld. CW: Wie weit ist SIX auf dem Weg zum Dev­Ops-Unternehmen? Scherrer: SIX hat bewusst keinen Ansatz gewählt, der zuerst «Big Bang» die Organigramme ändert. Wir haben stattdessen mit der kulturellen Veränderung und in einem ersten Geschäftsfeld mit den Prozessen und Technologien in Pilotprojekten bzw. -produkten begonnen. Inzwischen arbeitet gut ein Viertel der Mitarbeiter von der Anforderungsdefinition über Entwicklung und Test bis zum Betrieb in DevOps-Clustern. Wo die DevOps-Prinzipien greifen, d. h. die Fach- und IT-Spezialisten direkt miteinander zusammenarbeiten und die Automatisierung weit genug ist, sind wir heute in der Lage, neue Dienstleistungen innert kurzer Zeit zu lancieren und wenn gewünscht unter dem Tag anzupassen. Gerade in der Zusammenarbeit mit anderen Finanzdienstleistern wird dieser Vorsprung eklatant sichtbar. Wir sind auf keinen Fall bereits am Ende dieser Reise angelangt und haben, u. a. mit skalierbarer Software-definierter Infrastruktur, vor allem jedoch mit der Flexibilisierung der Priorisierung auf Portfolio-Ebene noch einen Effizienzsprung vor uns. CW: Was bleibt noch zu tun? Scherrer: 2017 steht im Zeichen der Ausbreitung: Ziel ist es, die 50-Prozent-Grenze zu überschreiten und gleichzeitig «Platform as a Service» hochzufahren. Dies heisst aber nicht, dass in den anderen Bereichen nichts geschieht. Wir verfolgen einen Ansatz mit modularen DevOps-Prinzipien, die im Unternehmen auch ausserhalb des Projektfokus angewandt werden. Damit gibt es kaum mehr einen Fleck in der SIX, an dem nicht beispielsweise das Deployment automatisiert oder der Support zusammengelegt wird. CW: Wie sieht die ideale Teamzusammensetzung in einem Dev­Ops-Projekt aus? Graef: Ein ideales Team zeichnet sich dadurch aus, dass sich alle für das Resultat, also das Produkt bzw. den Service, verantwortlich fühlen. Es geht um Zusammenarbeit über Funktionsgrenzen hinweg, d. h. ein Software-Entwickler wird nie sagen, dass er nicht testet, weil es dafür ja die Tester gibt. Stattdessen werden die Testingenieure schon beim Design der Software involviert und stellen sicher, dass die Software gut automatisiert zu testen ist. Dabei ist aber nicht jeder für alles verantwortlich. Stellen Sie sich einen «T-shaped Engineer» vor: Jedes Teammitglied versteht etwas vom gesamten Spektrum der Teamverantwortung – hat also ein breites T. Aber gleichzeitig ist jeder Spezialist in einer Disziplin – er hat also ein inhaltliches Fokusgebiet als senkrechte Linie im T. Wie viele Rollen ein DevOps-Team haben soll, ist irrelevant. Wichtiger ist, dass ein Team möglichst autonom seine Auf­gaben erledigen kann. CW: Die Entwicklung mag mit DevOps schneller gehen, aber leidet darunter nicht die Sicherheit und die Qualität, weil nicht genug Zeit zum Testing bleibt? Graef: Ich weiss nicht, ob Sie hier auf die heisse Diskussion über bimodal oder DevOps anspielen. Das allein wäre ein ganzes Interview wert. Aber bei DevOps geht es nicht um Speed auf Kosten von Sicherheit und Qualität. Ganz im Gegenteil! Es ist klar erwiesen, dass schnelleres und häufigeres Liefern von Software gleichzeitig zu höherer Qualität und mehr Sicherheit führt. Fehler oder Sicherheitslücken lassen sich besser adressieren, wenn man mehrmals täglich ein Release deployen kann und so den Fix in die Produktion bringt. CW: Gibt es auch Projekte, die sich nicht für DevOps eignen? Graef: Häufig wird diese Frage mit Ja beantwortet und als Beispiele werden Projekte genannt, die wenig Bedarf an Veränderung haben – also etwa irgendetwas mit Buchhaltung oder Mainframe. Ich finde, dass DevOps jedes Projekt und jedes Team angeht. Eigentlich sollte es «BizDevOps» heissen, denn es geht um bessere Zusammenarbeit über Funktionsgrenzen hinweg, egal, wie oft deployed werden muss.