Bernd Sengpiehl, Head of IT and Software Development bei Haufe, ging es nicht ums Prinzip, sondern um schnellere und bessere Ergebnisse. "Wir haben mit DevOps auf der grünen Wiese angefangen und arbeiten jetzt erfolgreich damit", bilanziert der IT-Chef. Aus den Erfahrungen, die das Haufe-Team gesammelt hat, soll jetzt sogar ein "Manifest" entstehen.
"Bei DevOps fallen die Grenzen zwischen Entwicklung, Produktion und Systembetrieb, weil es keine Übergabeschnittstellen im klassischen Sinne mehr gibt", erlärt Sengpiehl den Ansatz. Dabei ist schon der Titel auf seiner Visitenkarte dem DevOps-Modell geschuldet: Neben IT und Softwareentwicklung leitet er auch den Geschäftsbereich Business Technology Services. CIO-Rolle und -Titel wurden bewusst nicht gewählt, weil sie der Tätigkeit nicht gerecht würden: "Der CIO ist leider immer noch der Infrastruktur-Mensch, und meine Verantwortlichkeiten umfassen auch die Software-entwicklung und die Backoffice-Welt."
Was ist DevOps?
In dem Kunstwort DevOps steckt bereits das Ziel dieses Ansatzes: IT-Entwicklung (Development) und Betrieb (Operations) sollen nicht mehr getrennt agieren, sondern von Beginn an in gemeinsamen Teams zusammenarbeiten.
Diese Teams setzen sich zusammen aus Architekten, Entwicklern, Testern und Betriebsexperten. Aufgrund dieser engen Zusammenarbeit und Abstimmung verkürzt sich im Idealfall die "Time to Deployment" drastisch. Heute wird DevOps stark von Internet-Companies und App-Entwicklungsunternehmen eingesetzt. Allerdings interessieren sich auch immer mehr klassische Unternehmen für das Thema.
Sie sehen darin nicht nur eine Möglichkeit, ihre IT-Entwicklung und -Produktion effektiver zu gestalten, sondern auch die Chance, die Geschwindigkeit in kritischen IT-Bereichen zu erhöhen. Erfahrungen mit agiler Entwicklung helfen Unternehmen, DevOps erfolgreich im eigenen Betrieb umzusetzen.
Auswirkungen auf die Führungsstruktur
Für Sengpiehl steht fest: Das DevOps-Modell muss sich vom Entwickler bis zum Geschäftsführer durchziehen. In einer DevOps-Organisation werden alle Funktionen in einem einzigen Team wahrgenommen. Seine Mitglieder sind verantwortlich für Entwicklung, Test, Auslieferung und Betrieb auf den Plattformen. "Und sie müssen den Erfolg garantierten", ergänzt der Haufe-Manager: "Damit ändert sich die komplette Prozesskette."
Und wozu das Ganze? - Kurz gesagt: Mit Hilfe von DevOps sollen die Anwendungen schneller verfügbar und trotzdem hochwertig sein. "Das haben wir erreicht", beteuert Sengpiehl. Innerhalb weniger Monate sei beispielsweise mit dem "Haufe Zeugnis Manager" eine komplett neue Anwendung aufgesetzt worden. Es handelt sich dabei um eine Software, mit der sich professionell und rechtssicher Arbeitszeugnisse erstellen lassen.
Die Haufe Gruppe ist ein Medien- und Softwareunternehmen mit Hauptsitz in Freiburg. Das Unternehmen ging aus dem 1934 gegründeten Haufe-Verlag hervor. In den vergangenen Jahrzehnten wurden die klassischen Kernbereiche des anfangs reinen Verlagsgeschäfts nach und nach abgelöst und um Angebote im Bereich digitale Arbeitsplatzlösungen und Dienstleistungen erweitert. Das Spektrum des familiengeführten Unternehmens umfasst heute unter anderem Portale, Cloud-Applikationen, E-Procurement-Lösungen und Online-Communities.
Continuous Delivery and Operations
"Wir haben uns von einem klassischen Verlag zu einem Content-Anbieter entwickelt", erläutert Sengpiehl, "das heißt, wir publizieren keine Periodika, die in bestimmten zeitlichen Abständen veröffentlicht werden, sondern wir publizieren permanent." Das gelte nicht nur für den Content, sondern teilweise auch für die Software, die Haufe anbietet: "Und deshalb ist Continuous Delivery für uns die geeignete Produktionsmethode."
Da die Haufe Gruppe auch international tätig ist, heißt das zweite Stichwort: Continuous Operations. Die Basis des Unternehmens sind Web-Applikationen, die permanent aktualisiert und erweitert, also nicht mehr in traditionellen Release-Zyklen veröffentlicht werden. Ein solches Konzept kann aus Sengpiehls Sicht nur im DevOps-Modell effizient umgesetzt werden.
Gegen die ständigen Reibereien
Den Boden für dieses Vorgehen bereitet hat Birte Hackenjos, Chief Operating Officer (COO) der Haufe Lexware Gruppe. Sie hat zusammen mit ihren Kollegen auf der "grünen DevOps-Wiese" begonnen. Und so kommentiert sie den Startpunkt bei Haufe: "Ich habe mich gefragt, woran es liegt, dass es zwischen den Bereichen Softwareentwicklung und Betrieb ständig zu Reibereien kommt - mit der Folge aufwendiger Meetings und dem Verlust von Geschwindigkeit und Qualität."
"Offensichtlich stand hier strukturbedingt nicht mehr der gemeinsame Erfolg im Vordergrund", erinnert sich Hackenjos, "sondern Bereichserfolge, die oft nicht zusammenpassten." Auf der Suche nach Lösungsideen sei sie dann auf die DevOps-Gedanken gestoßen: "Das war eine Idee, die mich sofort begeistert hat und die ich direkt in den Teams mit einer Neuorganisation und einer klaren gemeinsamen Verantwortung bis in die Spitze umgesetzt habe."
Die Technik war kein Problem
Diese Neuorganisation ging erwartungsgemäß nicht ohne anfängliche Diskussionen ab. Und die waren - genauso verständlich - weniger technischer Natur. Über Entwicklungs- und Automatisierungs-Tools finden sich schließlich genügend Informationen.
"Was uns aber niemand beantworten konnte, waren die Auswirkungen eines DevOps-Ansatzes auf die organisatorische Struktur ", beschreibt Sengpiehl das eigentliche Problem. Und so begann das Unternehmen mit der kompletten Neustrukturierung von Teams, deren Mitglieder nach Service-Clustern zusammengestellt wurden.
Mittlerweile arbeitet die Haufe Gruppe seit knapp 17 Monaten zu einem Gutteil im DevOps-Modus. Derzeit entwickelt und betreibt sie 40 Prozent der Web-Applikationen nach diesem Modell. Weitere 30 Prozent befinden sich in der Übergangsphase.
Es gibt aber auch Ausnahmen, wie Sengpiehl klarstellt: "Lexware-Produkte wie Financial Office oder Warenwirtschaft sind Desktop-Anwendungen. Continuous Delivery ist in diesem Legacy-Bereich nicht so einfach möglich, denn hier ist der Installationsprozess bei den verschiedenen Kunden mit ihren verschiedenen Plattformen wesentlich aufwendiger. Außerdem haben wir es da mit Anwendern zu tun, die es noch nicht gewohnt sind oder gar nicht wollen, dass sich ihre Software ständig automatisch updatet."
Vorzeigeprojekt Service-Plattform
Die interne Haufe-Group-Service-Plattform wurde hingegen von einem traditionellen auf das DevOps-Vorgehen umgestellt. Sie erbringt Services wie Lizenzzuteilungen und Identity-Management für die Kunden und ist an SAP-Anwendungen und Shop-Systeme angebunden. "Die Funktionalitäten unterliegen einem ständigen Wandel, weil sie interne Prozessoptimierungen und -erweiterungen unterstützen", beschreibt Sengpiehl die Hintergründe der Applikation.
Alle diese Prozesse sind kundengerichtet sowie Mission und Business Critical. Mehr noch: "Wenn hier irgendetwas nicht funktionieren würde, erhielten wir sofort Rückmeldungen über den Net Promoter Score", führt Sengpiehl aus."
Der Net Promoter Score oder NPS ist eine Kennzahl, mit der sich die Kundenzufriedenheit ermitteln lässt. Entwickelt wurde die Methode von Fred Reichheld, Fellow bei der Unternehmensberatung Bain & Company. Basis ist die Frage: "Wie wahrscheinlich ist es, dass Sie Unternehmen/Marke X einem Freund oder Kollegen weiterempfehlen werden?" Die am Ende resultierende Messgröße wird aus der Summe der Promotoren abzüglich der Kritiker ("Detraktoren") errechnet.
Trial & Error war erfolgreich
Das für die Haufe-Group-Service-Plattform verantwortliche Team ist im rumänischen Temeswar beheimatet. Es besteht aus Architekten, Entwicklern, Testdesignern, Testern und Operations-Mitarbeitern und existiert mittlerweile seit etwas mehr als einem Jahr.
Die Umsetzung der Plattform nach dem DevOps-Ansatz nahm nur wenige Wochen in Anspruch. "Im traditionellen Verfahren hätte das gut einige Monate länger dauern können", ist sich Sengpiehl sicher. "Unser Vorgehen war eigentlich eher hemdsärmelig." Man habe die Skills definiert, einen Teamleiter ernannt, die Prozesse aufgesetzt und dann alle Verantwortlichkeiten in die DevOps-Einheit übertragen.
Eingeflossen sind auch die Erfahrungen, die man in den vergangenen Jahren mit den agilen Entwicklungen bei der Online-Plattform "Lexoffice" gesammelt hatte. "Wer Agile Development noch nicht kann, sollte seine Finger von DevOps lassen", warnt Sengpiehl.
Nicht nur remote und virtuell
"Bei Lexoffice haben wir beispielsweise gelernt, dass die Sprint-Planung an einem virtuellen technischen Board nicht ausreichend gut funktioniert", erinnert sich der IT-Chef: "Die Teammitglieder müssen sich auch in der realen Welt treffen." Und das sei bei DevOps nicht anders: "Man kann nicht alles remote und virtuell machen."
Eine weitere Lektion, die man gelernt habe, lautet: "Mikro-Management ist der Tod jedes DevOps-Ansatzes." Selbsternannte Feuerwehrmänner und Manager in Detailfragen hätten keine Zukunft: "Wer marktfähig bleiben will, muss die Organisation ändern und in Sachen Team-Management komplett umdenken." Der Teamleiter sollte in die Aktivitäten und Sprints "hineinhören", aber sie nicht ständig kontrollieren. Er sollte als Ansprechpartner und Vermittler bei Problemen und Eskalationen dienen, denn die kämen hin und wieder vor, "wenn der Produkt-Manager oder Architekt beispielsweise feststellt, dass eine Funktion anders geplant war".
Dokumentierte Lessons Learned
Alle Lessons Learned hat das Team um Sengpiehl dokumentiert, "um nicht jedes Mal das Rad neu erfinden zu müssen". Diese Erfahrungen will der IT- und Entwicklungschef nun in einem DevOps-Manifest festhalten - mit sämtlichen Dos and Don`ts.
Darin wird auch Sengpiehls Credo zu finden sein, das da lautet: "Wenn man DevOps richtig machen will, kann man es nicht nur über die Prozesse tun, man muss es auch über die Organisation abbilden." Das rät Bernd Sengpiehl allen DevOps-Interessierten:
Konsolidieren Sie die Tool-Landschaft zu wenigen, durchgängigen Werkzeugketten mit hohem Automatisierungsgrad.
Schneiden Sie die interdisziplinären DevOps-Teams entsprechend den bestehenden Geschäftsprozessen und/oder Marktsegmenten zu.
Achten Sie bei der Auswahl der Führungskräfte (Teamleiter) stärker auf Führungserfahrung als auf Fach-Know-how.
Kontinuität bezüglich des Standorts: Wenn Teammitglieder an verschiedenen Lokationen arbeiten, sind sie praktisch ausschließlich auf digitale Kommunikation angewiesen. Das kann zu Problemen führen.
Sie brauchen weiterhin Spezialisten. Auch wenn in DevOps-Teams interdisziplinär gearbeitet wird, heißt das nicht, dass jeder alles gleich gut kann.
Wer am Thema DevOps interessiert ist oder selbst Projekte plant, dem gibt Sengpiehl gerne Auskunft.