DevOps bei der Haufe Gruppe: Mikromanagement ist der Tod von DevOps

Quelle: Flickr/Matt Moor

DevOps – für die Haufe Gruppe ist das kein Buch mit sieben Siegeln mehr. Gleich vorne weg: „Auf hehre Prinzipien bei dieser Art der Softwareentwicklung konnten wir nicht zurückgreifen. Denn die gibt es nicht. Wir haben auf der grünen Wiese angefangen und arbeiten jetzt damit erfolgreich“, so der Head of IT and Software Development bei Haufe. Aus den Erfahrungen 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“, erklärt Bernd Sengpiehl. Schon sein Titel ist dem DevOps-Modell geschuldet: Er ist „Head of IT and Software Development“ und damit Geschäftsbereichsleiter Business Technology Services.

Die CIO-Rolle und der -Titel wurden bewusst nicht gewählt, weil sie der Tätigkeit nicht gerecht würde. „Der CIO ist leider immer noch der Infrastruktur-Mensch, und meine Verantwortlichkeiten umfassen auch die Software-Entwicklung und die Backoffice-Welt.“ Für Sengpiehl steht fest: Das DevOps-Modell muss sich vom Entwickler bis zum Geschäftsführer durchziehen.

Bernd Sengpiehl, Head of IT & Software Development Haufe-Lexware GmbH & Co. KG

Alle Funktionalitäten werden in einer DevOps-Organisation in einem einzigen Team realisiert. Seine Mitglieder sind verantwortlich für Entwicklung, Test, Auslieferung und Betrieb auf den Plattformen. „Und sie müssen den Erfolg garantierten. Damit ändert sich die komplette Prozesskette.“

Das Ziel: Anwendungen sollen schneller und trotzdem qualitativ hochwertig verfügbar sein. „Das haben wir erreicht. Innerhalb weniger Monate wurde beispielsweise mit dem Haufe Zeugnis Manager eine komplett neue Anwendung aufgesetzt.“ Mit dem „HZM“ lassen sich professionelle und rechtssichere Arbeitszeugnisse erstellen.

Warum DevOps?

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 anfänglich reinen Verlagsgeschäfts mehr und mehr abgelöst und auch um Angebote im Bereich digitale Arbeitsplatzlösungen und Dienstleistungen erweitert. Das Spektrum des familiengeführten Konzerns umfasst heute unter anderem auch Portale, Cloud Applikationen, eProcurement-Lösungen und, Online-Communitys.

Der Firmensitz in Freiburg. Quelle: Haufe Gruppe

„Wir haben uns aus einem klassischen Verlag zu einem Content-Anbieter entwickelt. Das heißt, wir publizieren keine Periodika, die in bestimmten zeitlichen Abständen veröffentlicht werden, sondern wir publizieren permanent. Das gilt nicht nur für den Content, sondern auch teilweise für die Software, die wir anbieten. Deshalb ist Continuous Delivery für uns die geeignete Produktionsmethode“, erklärt Sengpiehl.

Und da die Haufe Gruppe auch weltweit tätig ist, heißt das zweite Stichwort: Continous operations. Wenn Web-Applikationen die Basis eines Unternehmens darstellen, die permanent aktualisiert und erweitert werden – und die nicht mehr in traditionellen Release-Zyklen veröffentlicht werden können, dann kann das für Sengpiehl nur über DevOps – die Integration von Development und Betrieb – effizient umgesetzt werden.

Am Anfang stand die Frage nach den Reibereien

Den Boden für dieses Vorgehen bereitet hat Birte Hackenjos, COO der Haufe Lexware Gruppe. Sie zählt zu den Top-Female COOs der deutschen IT-Branche und hat zusammen mit ihren Kollegen auf der „grünen DevOps-Wiese“ begonnen.

Sie kommentiert den Anfang von DevOps bei Haufe: „Ich habe mich gefragt, woran es liegt, dass es zwischen den Bereichen Softwareentwicklung und Betrieb ständig zu

Birte Hackenjos, COO der Haufe Gruppe. Quelle: obs/Haufe Gruppe

Reibereien kommt – mit der Folge aufwendiger Meetings und Verlust von Geschwindigkeit und Qualität. Offensichtlich stand hier strukturbedingt nicht mehr der gemeinsame Erfolg im Vordergrund, sondern Bereichserfolge, die oft nicht zusammenpassten. Auf der Suche nach Lösungsideen bin ich auf die DevOps-Gedanken gestoßen, 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 anfänglichen Diskussionen waren dabei weniger technologischer Natur, denn über Technologien wie Docker, Automatisierung & Co. finden sich genügend Informationen. „Was uns aber niemand beantworten konnte, waren die Auswirkungen auf die organisatorische Struktur “, so Sengpiehl. Und so begann man mit der kompletten Neustrukturierung von Teams, deren Mitglieder physisch nach Service-Clustern zusammengefasst wurden.

Im DevOps-Modus entwickelt die Haufe-Gruppe seit rund 16 Monaten und derzeit 40 Prozent der Web-Applikationen. Weitere 30 Prozent befinden sich in der Übergangsphase. „Die Lexware-Produkte wie Financial Office oder Warenwirtschaft sind Desktop-Anwendungen. Continuous Delivery in diesem Legacy-Bereich ist nicht so einfach möglich. Denn hier ist der Installationsprozess bei den verschiedenen Kunden mit 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 Software ständig automatisch updatet.“

Ein Vorzeigeprojekt: Die Haufe Group Service Platform

Von einem traditionellen auf das DevOps-Vorgehen umgestellt, wurde die interne Haufe Group Service Plattform. Sie erbringt Services wie Lizenzzuteilungen und Identity-Management der Haufe-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.“

Alle diese Prozesse sind: a) kundengerichtet sowie b) Mission und Business Critical. Mehr noch:„Wenn hier irgendwas nicht funktionieren würde, erhielten wir sofort Rückmeldungen über den Net Promoter Score. Insofern sind die Services auch „nps critical“, sagt Sengpiehl.

Das verantwortliche in Temeswar beheimatete Team besteht aus Architekten, Entwicklern, Test-Designern, Testern und Operations-Mitarbeitern. Es existiert seit etwas mehr als einem Jahr. Die Umsetzung der Plattform nach DevOps-Manier dauerte nur wenige Wochen. „Im traditionellen Verfahren hätte das dagegen gut einige Monate länger dauern können“, dessen ist sich Sengpiehl sicher.

Trial & Error war erfolgreich

„Unser Vorgehen war eigentlich hemdsärmelig“, gibt Sengpiehl zu. Man habe die Skills definiert, einen Teamleiter ernannt, die Prozesse aufgesetzt und alle Verantwortlichkeiten in diese DevOps-Einheit übertragen. Eingeflossen sind dabei auch die Erfahrungen, die man in den vergangenen Jahren mit den agilen Entwicklungen bei der Online-Plattform „Lexoffice“ gesammelt hat. Denn „wer Agile Development noch nicht kann, sollte seine Finger von DevOps lassen“ resümiert Sengpiehl.

Die Finanz- und Buchhaltungs-Plattform Lexoffice.

Gerade diese Erfahrungen mit agiler Software-Entwicklung sind wichtig, betont Sengpiehl. „Bei Lexoffice“ haben wir beispielsweise gelernt, dass die Sprint-Planung an einem virtuellen technischen Board nicht ausreichend gut funktioniert. Die Team-Mitglieder müssen sich auch in der realen Welt treffen.“ Das gilt auch für DevOps. Man kann nicht alles remote und virtuell machen. Mitunter müssen die Teams auch physisch zusammenkommen.“

Man habe auch eine weitere Lektion gelernt. „Mikromanagement ist der Tod jedes DevOps-Ansatzes.“ Wer sich als Feuerwehrmann und Mikromanager begreife, habe 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 „hinein hören“ – aber nicht ständig kontrollieren. Er sollte als Ansprechpartner und als Vermittler bei Problemen und Eskalationen dienen. Denn die kommen hin und wieder vor, „wenn der Produktmanager oder Architekt beispielsweise feststellt, dass eine Funktion anders geplant war“.

Das Rad nicht mehr neu erfinden

Alle Lessons Learned hat das Team um Sengpiehl dokumentiert, „um nicht jedes Mal das Rad neu erfinden zu müssen.“ Diese Erfahrungen will er nun in einem DevOps-Manifest festhalten – mit sämtlichen do´s and don´ts. Darin wird auch sein Credo zu finden sein: „Wenn man DevOps richtig machen will, kann man es nicht nur über Prozesse, sondern muss es auch über die Organisation abbilden.“

Rat an Kollegen

✔ Management committment ist der Schlüssel zum Erfolg!

✔ Konsolidierung der Tool-Landschaft zu wenigen, durchgängigen Tool-Ketten mit hohem Automatisierungsgrad.

✔ Zuschnitt der interdisziplinären DevOps-Teams entsprechend der bestehenden Geschäftsprozesse und/oder Marktsegmente.

✔ Bei der Auswahl der Führungskräfte (Teamleiter) sollte stärker auf Führungserfahrung als auf Fach-Know-how geachtet werden.

✔ Ein Team an einem Standort. Wenn Teammitglieder an verschiedenen Standorten arbeiten sind sie praktisch ausschließlich auf digitale Kommunikation angewiesen. Das reicht oft nicht aus.

✔ Auch wenn in DevOps-Teams interdisziplinär gearbeitet wird, heißt das nicht, dass jeder alles gleich gut kann. Die Mitarbeiter bleiben weiterhin Spezialisten ihres Faches, auch wenn sie ihre Grenzen ausdehnen.

DevOps-Interessierte bitte melden!
Wenn Sie ebenfalls DevOps-Projekte verfolgen und/oder an einem Austausch mit anderen IT-Verantwortlichen über das Thema interessiert sind, können Sie Herrn Sengpiehl gerne unter bernd.sengpiehl@haufe-lexware.com kontaktieren. Er plant, gemeinsam mit Christoph Witte von den IT Rebellen (cwitte@wittcomm.de ) und anderen Partnern einen DevOps-Freundeskreis aufzubauen, der als Online- und Event-Plattform dem Erfahrungsaustausch dienen wird.