Agilität im Unternehmen Wann ist ein DevOps-Ansatz wirklich sinnvoll?

IT ist ohne gute Software nicht denkbar. Aber Software alleine genügt nicht, denn sie muss sich auch im praktischen IT-Betrieb bewähren. Der DevOps-Ansatz hilft, dass beide Bereiche an einem Strang ziehen und so aus Software auch betrieblicher Erfolg wird.

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

FIS Informationssysteme und Consulting GmbH

Insider Research

Adacor Hosting GmbH

DevOps und die Probleme zwischen Entwicklung und Betrieb in der IT sind eigentlich ein alter Hut. Die damit verbundenen Herausforderungen lassen sich aber nicht automatisch durch agile Ansätze bewältigen. Unternehmen müssen das Thema ganzheitlich betrachten, nur so entwickelt das Konzept seine ganze Stärke.

Beispielsweise müssen selbst eingespielte Teams aus Entwicklern und Betriebsmitarbeitern mit einem neuen „Mindset“ ausgestattet werden, wenn sie plötzlich zusammen in einem Raum sitzen sollen. Dieser Punkt stellt sich in der Praxis häufig als schwieriger dar als die technischen Implikationen.

Außerdem müssen IT-Abteilungen endlich das „Blame Game“ zwischen den Herstellern oder Entwicklern einer Software und den Mitarbeitern oder Kunden, die sie betreiben, beenden. Allen Beteiligten ist mittlerweile klar, dass es nicht die Lösung sein kann, bei Problemen alles wegzuwerfen und neu anzufangen. DevOps zeigt neue Wege und Perspektiven auf.

DevOps beginnt vor dem Code

Wer eine Software entwickeln und betreiben möchte und dabei oft damit in Verbindung gebrachte Aspekte wie „Continuous Integration“ oder „Infrastructure as Code” umsetzen will, für den ist das Zusammenfinden der beiden Bereiche „Entwicklung und Betrieb“ vor der ersten Zeile Code obligatorisch.

Das macht man allerdings nicht mal eben nebenbei. Die Eingliederung dieser Themen ist die hohe Schule des gesamten DevOps-Prozesses. Es ist viel initiale Projektarbeit nötig, um die erforderlichen Konzepte, Abläufe und Technologien aufeinander abzustimmen.

In den einzelnen Bereichen (Dev oder Ops) wird es weiterhin Spezialisten für den Betrieb und Spezialisten für die Entwicklung geben. Der eigentliche Betrieb wird aber von – im Bereich DevOps und einer darauf abgestimmten Technologie ausgebildeten – Experten durchgeführt werden.

Kein Framework, eine Kultur

Das Ziel, das mit DevOps verfolgt wird, kann von Projekt zu Projekt und Firma zu Firma stets ein anderes sein. Bei sämtlichen Überlegungen sollte man jedoch beachten, dass DevOps und die damit verbundene Herangehensweise kein Framework sind, sondern eine Kultur. Deshalb ist es wichtig, vor jedem Projekt die genaue Zielsetzung zu definieren:

• Was soll in welchem Maß gemeinsam von beiden Bereichen gesteuert und verwaltet werden?

• Wie viel darf die Implementierung kosten, um den Softwarebetrieb sicherzustellen?

• Sind die Anwendungen vollständig automatisiert, muss die Verwaltung der virtuellen Ressourcen und Container in die Applikation verlagert werden – oder ist (zum Beispiel aus Kostengründen) gar nicht möglich, so weit zu gehen? Hier kann es viele Abstufungen geben.

Normalerweise geht man davon aus, dass auch vor agilen Projekten eine grundsätzliche Kosten-/Nutzenprüfung steht. In der Praxis tritt das Thema bei vielen Unternehmen aber eher in den Hintergrund. DevOps und Agilität liegen im Trend, deshalb steigen viele Unternehmen in das Thema ein, ohne die Notwendigkeit zu hinterfragen.

Aber nur, weil „alle“ auf den DevOps-Zug aufspringen, ist das Thema noch lange nicht für alle Unternehmen vorteilhaft oder notwendig. Wer beispielsweise proprietäre Software kauft und auf seinen eigenen Systemen betreibt, hat kaum Möglichkeiten, die Entwicklung zu beeinflussen. Bei einem solchen Szenario wird definitiv kein DevOps-Team benötigt. An dieser Stelle ist vielmehr eine Überprüfung der Abläufe und Prozesse der eigenen, traditionellen IT-Landschaft zu empfehlen.

Mehr Agilität für besseren Service

Die IT-Landschaften in den Unternehmen sind in der Regel zu groß und heterogen, um die gesamte Unternehmens-IT über einen Kamm scheren zu können. Im Vorteil sind diejenigen, die agil starten und zuerst nur kleine, überschaubare Bereiche verändern; die zunächst Erfahrungen in agilen Methoden sammeln und die „traditionell“ gemanagte IT nicht generell und ohne Grund in Frage stellen. Nicht jede traditionelle IT-Landschaft ist zu teuer oder zu statisch, nur weil keine agilen Methoden eingesetzt werden oder weil die Projekte nicht der DevOps-Kultur folgen.

Es kann Unternehmen durchaus passieren, dass ein neues Projekt, das viele „neue“ agile Herangehensweisen beinhaltet, kulturell DevOps lebt und nahezu vollständig automatisiert ist, VMs hoch- und herunterfährt, stündliche Deployments macht – und sehr viel teurer als erwartet ist. Die gängigen Erfahrungen zur Kostenabschätzung im IT-Betrieb treffen nicht mehr zu. Zu hoffen ist in einem solchen Fall, dass das Ziel die Erreichung einer hohen Servicequalität war und nicht die Reduktion von Kosten.

Die Entscheider in einem Unternehmen sollten sich davon verabschieden, die IT lediglich als einen einzigen Kostenblock zu sehen, mit dem man jährlich Einsparungsrunden drehen kann. Die einzelnen, durch die IT gesteuerten Prozesse sind maßgeblicher Teil der Wertschöpfungskette und werden im Rahmen der Digitalisierung in Zukunft mehr vom Kuchen benötigen.

Fazit

Ein einzelner Artikel oder auch ein ganzes Buch über agile Methoden werden die Probleme der Unternehmen beim Thema „DevOps“ nicht ausreichend beleuchten. Meist ist jede Information auch nur ein Baustein zum Gesamtbild. Das zu zeichnen, bleibt die große Aufgabe in den Unternehmen.

Die Anforderungen an die IT wachsen weiter, vor allem in Bezug auf die Geschwindigkeit. Dabei stellt selten die IT die Vorgaben, diese stammen eher aus Fachabteilungen oder werden durch das jeweilige Geschäftsmodell verursacht. Hier helfen schnelle Reaktionen auf die Veränderungen, eine offene Sichtweise und ein vorausschauendes Tun und Handeln. Jedem, der in der IT arbeitet, muss klar werden: Ein System ist niemals fertig. Es muss sich entwickeln beziehungsweise weiterentwickeln.

Der IT-Betrieb glich bisher immer einer Fahrschulprüfung. Solange man sich regelkonform verhielt und der Prüfer hinten auf der Rückbank stillsaß, machte der Schüler alles richtig. Das ändert sich gerade, und der Prüfer ruft mittlerweile recht häufig nach vorne: „Ach ja, beim Stopp-Schild können Sie nun einfach weiterfahren.“ Genauso ist es bei der Einführung von agilen Methoden oder DevOps. Das Vorgehen ändert sich, es wird schneller und beweglicher.

Angst vor Neuem ist fehl am Platz. Innovationstreiber sind im IT-Betrieb gefragt. Bei Adacor haben wir das Glück, dass unsere Entwicklungsabteilung schon früh agile organisatorische Herangehensweisen getestet und anschließend in der ganzen Firma implementiert hat. Aus dem Betrieb hat sich ein Team entwickelt, das mit den Kollegen aus der Entwicklung zusammenarbeitet und DevOps vorbildlich lebt und vermittelt. Diese Innovationstreiber sind für unsere Entwicklung maßgeblich.

Alexander Lapp

Generell gilt: Die Bereiche Dev und Ops gehören zusammen, jetzt müssen sie noch zusammenwachsen. Dabei sollten die Softwareentwickler ihre Tätigkeit transparenter gestalten, und die Kollegen aus dem IT-Betrieb sollten sich gern in die Karten schauen lassen. Das wäre ein guter Start einer langen Reise.

* Alexander Lapp ist Geschäftsführer und Chief Customer Officer (CCO) der ADACOR Hosting GmbH. Unter seiner Federführung wird jeder Service, den ein Kunde bucht, konzipiert und implementiert. Besonders anspruchsvoll ist dabei die technische Konzeption, welche Alexander Lapp und sein Team regelmäßig für die Kunden umsetzen. Denn zu dem Zeitpunkt dieser Aufgabe müssen bereits alle Rahmenbedingungen und technischen Spezifikationen festgelegt sein, um später einen reibungslosen Ablauf der Hosting- und Cloud-Projekte gewährleisten zu können.

(ID:44862584)