Inhalt
Man entwickelt schnell den Eindruck, dass DevOps das große Ding in der modernen IT-Welt ist. Das „must have“, um erfolgreich zu sein. Dass es eine handfeste Art und Weise gibt wie DevOps „gemacht“ wird. Doch wenn man einmal nachbohrt, fallen die Definitionen davon was jetzt eigentlich DevOps ist und wie es umgesetzt wird, meistens eher schwammig.
Um das warum zu verstehen, muss man sich erst einmal vor Augen führen, dass DevOps kein Vorgehen mit festen Handlungsanweisungen, Normen und Plänen ist. DevOps ist eine Kultur bzw. eine Sammlung von Best-Practices. Also kann man DevOps nicht einfach „machen“.
Es handelt sich um eine Unternehmenskultur, die auf viele, bereits bekannte und teilweise gelebte Bausteine aufsetzt und diese vereint, um die Effizienz des Softwareentwicklungsprozesses und des gesamten Unternehmens zu verbessern. Folglich reicht es auch nicht aus, wenn neue Tools eingeführt werden, einzelne Positionen im Unternehmen mit „DevOps Menschen“ besetzt werden oder Führungskräfte ihr Team als „bereit für DevOps“ deklarieren. Vielmehr ist die Einführung von DevOps ein laufender Prozess, der die bisher gelebte Kultur einer Firma oder Abteilung hinterfragt und dabei versucht, bestehende Abläufe aufzubrechen und zu optimieren. DevOps ist also ein Prozessverbesserungsansatz!
Warum also “DevOps”?
Änderungen in Unternehmenskulturen stoßen eigentlich immer auf Widerstand.
„Die Dinge sind schon immer so gewesen und haben doch funktioniert. Warum sie jetzt ändern? Und überhaupt, wir sind doch schon agil.“
So oder so ähnlich könnten erste Argumentationen ausfallen, wenn man damit anfangen möchte, DevOps in der eigenen Firma oder beim Kunden einzuführen.
Den meisten von uns dürfte während der Ausbildung eingetrichtert worden sein, dass die IT aus drei Fachdisziplinen (Silos) besteht: Software-Entwicklung, Test und Betrieb. Und dass jeder dieser Bereiche seine ganz eigene Rolle spielt und eigene Ziele verfolgt:
-
Die Softwareentwicklung kümmert sich um die vom Kunden gewünschte Umsetzung oder Änderung an Software im Sinne des geschäftlichen Auftrages.
-
Die Qualitätssicherung hängt zwischen den Stühlen und ist für ihre Arbeit sowohl auf die Ergebnisse aus der Softwareentwicklung als auch auf die vom Betrieb zur Verfügung gestellten Testsysteme angewiesen.
-
Der Betrieb rollt die Software aus und kümmert sich für um Stabilität und Kontinuität. Er kennt die Systeme, auf denen die Software laufen soll bzw. baut sie auf.
Auch wenn jeder Bereich für sich einen guten Job macht, so ist das Ergebnis am Ende häufig doch nicht optimal. Oft lassen sich die Gründe hierfür auf eine mangelnde Kommunikation zwischen den einzelnen Fachbereichen zurückzuführen. Erschwerend kommt noch hinzu, dass der 4. Bereich, das Management, häufig immer nur mit einem der drei IT-Bereiche direkt kommuniziert.
Durch mangelhafte Kommunikation entstehen unweigerlich Konflikte, die den meisten Softwareprojekten inhärent sind. Das Hauptziel von DevOps ist es daher diese Konflikte abzubauen. In der Sprache von DevOps die „Wall of Confusion“ entfernen.
„Devs are from Venus, Ops are from Mars.(1) … Tester are probably from one of the moons of Jupiter and Management is something else entirely.“
Lassen wir einmal die Kollegen aus dem Test und dem Management außen vor und betrachten zunächst die „Wall of Confusion“ zwischen den Namensgebern für DevOps - der Softwareentwicklung (Dev) und dem Betrieb (Ops).
Solange jede Gruppe in ihren eigenen Silos arbeitet und nur die eigenen Ziele vor Augen hat, ist der Konflikt vorprogrammiert. Die Kollegen des Betriebs sind unglücklich, weil gegebenenfalls Software eingeführt werden soll, die Änderungen an den bestehenden Systemen erfordert und im schlimmsten Fall durch Inkompatibilitäten und Rückfragen Ausfallzeiten entstehen. Die Kollegen der Softwareentwicklung sind unglücklich, weil die entwickelten, neuen Features nicht zeitnah ausgerollt werden können oder sich erst beim Ausrollen herausstellt, dass die Betriebs-Infrastruktur nicht kompatibel zu den Neuentwicklungen ist. Inkompatible Frameworks, Tools und Verfahren tun ihr übriges. Die Kommunikation erfolgt meistens nicht direkt, sondern über Tickets, E-Mails oder Dritte, was den Aufwand und den Stress noch erhöht. Beide Seiten sehen durch die Handlung der jeweils „anderen“ die Erreichung ihrer Ziele bedroht, an denen sie vom Management gemessen werden. Auftretende Fehler werden PingPong-artig zwischen Dev, Ops und dem Kunden hin und her gespielt - Jeder besteht darauf „seinen“ Job gemacht zu haben und sieht die Verantwortung bei den anderen.
Dabei wäre die Lösung „relativ" einfach. Eine bessere Kommunikation untereinander und eine Abstimmung und Standardisierung der eingesetzten Prozesse und Tools über die gesamte Prozesskette hinweg. DevOps soll hier helfen die Kommunikation zu verbessern und vor allem das Verständnis zwischen den beteiligten Parteien zu fördern. Leider gehört die Änderung einer Kommunikationskultur zu den schwierigeren Herausforderungen bei der Einführung einer neuen Unternehmenskultur.
Auch wenn die Silos Management und Test nicht Bestandteil der Namensgebung von „DevOps“ sind. Natürlich gilt für sie das gleiche. Jeder möchte „seinen“ Job machen, ohne das Gefühl zu haben, dass er von den anderen Parteien eingeschränkt wird.
„Lack of trust in an organization is really expensive. You can’t villianize others if you know their kids.“ (2)
Hier kommt eine der Grundideen hinter DevOps zum Tragen. Durch die bessere Kommunikation der Silos untereinander steigt das Verständnis der Bedürfnisse der jeweils anderen Bereiche und Konflikte werden minimiert, bzw. können frühzeitig erkannt und umschifft werden. Statt also das “Kind” Softwareprojekt von einem „Elternteil“ zum anderen weiter zu reichen, wird ein gemeinsames Sorgerecht von der Entwicklung über das Testen, bis zum Deployment und dem Betrieb ausgeübt.
Daraus ergeben sich für die Beteiligten auch neue Herausforderungen. Statt wie bisher in seinem eigenen Silo mit seinem eigenen Wissen als Spezialist und Spezialistin zu arbeiten, ist nun ein weiteres Verständnis der Prozesse und Verfahren, sowie eingesetzten Tools in den anderen Silos nötig, um effektiv zusammenarbeiten zu können. Statt nur ein Thema als Spezialist beziehungsweise Spezialistin in der Tiefe zu durchdringen (I-Shape Spezialist) sind nun vermehrt Menschen gefragt, die neben Spezialwissen auch über ein breit gefächertes Wissen im gesamten IT-Prozess verfügen. Diese T-Shape Professionals sind zwar Experten und Expertinnen auf ihrem Gebiet, können aber dank ihres breit gefächerten Wissens einfacher mit anderem kommunizieren oder zur Not auch andere Aufgaben übernehmen.
Bringt man jetzt mehre solcher Personen zusammen, so können Sie auf Basis Ihrer überlappenden Wissensgebiete besser miteinander interagieren und wir erhalten „DevOps-People“, die in Ihrem Wissen nicht mehr in Silos getrennt, sondern Kammförmig aufgestellt sind.
Das Schöne daran? Wissen färbt ab. Eine Firma muss nicht neue Mitarbeiter einstellen oder explizit schulen (obwohl dies sicher hilft). Durch das Aufbrechen der Silo-Struktur der einzelnen Teams und das „Mischen“ der Spezialisten in entsprechenden Teams kommt es fast zwangsweise zu einer Wissenserweiterung, solange die Voraussetzungen für eine offene und direkte Kommunikation gegeben sind.
Der Weg dahin führt also über einen Zwischenschritt. Die „DevOps-Teams“, in denen Kollegen und Kolleginnen interdisziplinär für ein Projekt zusammengefasst werden und die Kommunikation einfach und direkt erfolgen kann. Mögliche Barrieren in der Kommunikation, die nichts mit dem Wissen zu tun haben, sollten hier von vornherein eliminiert werden. Hierzu zählen zum Beispiel räumliche Trennung, unterschiedliche Vorgesetzte oder festgelegte Kommunikationswege über Personen außerhalb des Teams. Daher bietet es sich zum Beispiel an, diese Teams möglichst räumlich zusammenzufassen und eigenorganisiert arbeiten zu lassen.
Auch die Kommunikation unter den Teams sollte gefördert werden, damit entstehende neue Prozesse, Tools sowie Vorgehensweisen und Erkenntnisse untereinander abgestimmt werden können. Aus diesen Abstimmungen kann sich dann nach und nach eine DevOps Vorgehensweise entwickeln, die speziell auf die jeweilige Firma zugeschnitten ist.
Das Grundziel in Bezug auf den Softwareentwicklungsprozess ist es also aus einem „Wir gegen die anderen“- ein „Wir gemeinsam“-Gefühl zu entwickeln. Wichtig für die Zufriedenheit der Kollegen ist hier außerdem, dass DevOps nicht als Order von Oben kommuniziert wird, sondern als Chance auf Veränderung und Verbesserung der bestehenden Prozesse.
„If you automate a mess, you get an automated mess.” (5)
Aber, Stopp, bei DevOps geht es doch um Tools und Automation und CI/CD und festgelegte Prozesse …
Dies ist einer der Irrglauben bei diesem Thema. Nur dadurch, das am „besten“ von oben bestimmten Tools und Prozesse „verordnet“ werden, lässt sich eine Firma nicht auf DevOps ausrichten. Ein solches Vorgehen wird zwangsweise den Widerstand der Mitarbeiter nach sich ziehen. Zum einen wird hierdurch das „Wir-Gefühl“ zunichte gemacht und DevOps wird nicht mehr als Chance, sondern als Pflicht wahrgenommen, zum anderen laufen diese Anweisungen eventuell an den Bedürfnissen des Projektes oder der Mitarbeiter vorbei.
Die besten Tools und Automationen führen zu keinem guten Ergebnis, wenn die zu Grunde liegenden Prozesse nicht darauf ausgerichtet sind, diese zu unterstützen. Wen die Mitarbeitenden allerdings gemeinsam und in Abstimmung untereinander die nötigen Prozesse entwickeln, können sie anschließend auch gemeinsam die Tools bestimmen, die sie nutzen müssen bzw. wollen, um ihr Ziel zu erreichen und dafür auch die geeigneten Automatisierungsschritte ableiten. Nicht zwangsweise sind die Tools die Team A nutzt, um ihr Projekt zum Erfolg zu bringen, die gleichen Tools, die bei Team B zum Erfolg führen.
Trotzdem ist auch hier eine übergeordnete Kommunikation nötig, um eine firmenweite Abstimmung zu erreichen. Gibt es schon Tool-Sets und Vorgehensweisen die anderen Teams erfolgreich genutzt haben? Oder gibt es Vorgaben bezüglich Anschaffung und Kosten? Ist es sinnvoll, eine neue Lösung einzukaufen, zu implementieren und zu betreiben, inklusive des notwendigen Know-how-Aufbaus? Oder gibt es bereits eine bestehende Lösung mit den gleichen Funktionalitäten?
Das sind Fragen die im Zweifel übergreifend geklärt werden sollten. Mit der Zeit und dadurch, dass die Teams für einzelne Projekte immer wieder neu zusammengestellt werden können, entwickelt sich aber auch hier ein firmenspezifischer Satz an Tools. Dieser sollte aber weiterhin immer für Diskussionen oder Verbesserungen offen sein.
Das gleiche gilt für Prozesse, die entwickelt werden. Auch sie sollten möglichst übergreifend eingesetzt werden. Aus solchen sauber modulierten Prozessen können dann auch die entsprechenden Automationen abgeleitet und implementiert werden.
Automationen und Tools führen dazu, das kostbare Zeit für die Mitarbeitenden in den Teams frei wird, die sie dann wiederum auf den Wissensaustausch und das Erreichen ihres Projektziele verwenden können. Es liegt also auch im Interesse der Teams hier Wissen zu teilen und eine Basis zur Erreichung des gemeinsamen Zieles zu finden.
Ohne eine erfolgreiche Kommunikation sind also alle Tools und Ansätze zur Automatisierung nichts wert!
Der Mehrwert von DevOps
Aber was haben die Organisation, das Management und der Mitarbeitende davon, wenn DevOps eingeführt wird? Immerhin bricht die Grundidee von DevOps mit vielen, lang gelebten Traditionen in Unternehmen. Die Trennung zwischen den Abteilungen in der IT wird weitegehend aufgehoben, Teams sind für ihr Produkt verantwortlich und organisieren sich weitgehend selbst und Mitarbeitende sollen ihr Wissen und damit auch ihre Exklusivität teilen. Warum also nicht alles so lassen, wie es ist und auf Nummer sicher gehen?
Die Antwort ist: Innovation und Zufriedenheit!
Für den Kunden
DevOps führt durch die verbesserte Kommunikation und die daraus resultierenden, besseren internen Prozesse zu schnelleren Releases von geforderten Funktionalitäten bei höherer Qualität der Software, da viele Fehlerquellen im Vorfeld bereits ausgeschlossen werden können. Durch die engere Integration der Tester in den Softwareentwicklungs-Prozess und das direkte Feedback an das gesamte Team sind Fehlerbehebungen schneller möglich. Die Release-Zyklen werden gestrafft und der Kunde sieht schneller Resultate. Dies schlägt sich in einer höheren Kundenzufriedenheit nieder.
Für den Mitarbeiter
DevOps unterstützt Innovation und neue Ideen, sowie die Wissensbildung bei den Mitarbeitenden. Außerdem handeln die Mitarbeitenden in den Teams eigenverantwortlich und sehen das Resultat ihrer Arbeit direkt beim Kunden. Durch Automation und Tools werden zeitraubende und als unnötig empfundene Tätigkeiten so weit wie möglich eliminiert und mehr Zeit für die Umsetzung von Ideen geschaffen. Durch den horizontalen Teil des T-Shapes ist die fachliche Kommunikation unter den Kollegen einfacher und es stehen im Zweifel auch mehr Ressourcen zu Verfügung einzelne Kollegen zu entlasten. Das Gefühl ein Projekt nur auf den eigenen Schultern zu tragen, weicht einem Wir-Gefühl. Dies trägt letztendlich auch zu einer Steigerung der Mitarbeiterzufriedenheit bei.
Für das Management
Statt der Vermittler zwischen den Silos bei Problemen zu sein und die Kommunikation leiten zu müssen, kann sich das Management auf einen übergeordneten Blickwinkel konzentrieren. Da die Teams sich in der Umsetzung der Projekte weitestgehend selbst organisieren, bleibt dem Management mehr Raum, um als Innovator für Veränderungen zu agieren und bereits die nächsten Projekte vorzubereiten. Durch die steigende Automatisierung und den Einsatz von entsprechenden Tools wächst die Menge der zur Verfügung stehenden Kennzahlen für das Reporting und die Messbarkeit der Effizienz.
Für das Unternehmen
Durch die verbesserte Reaktionsfähigkeit, sowie durch zur Verfügung stehende Automatisierungen und die flexibleren Teams können neue Produktideen schneller ausprobiert und deren Marktfähigkeit validiert werden. Durch die schnelle Umsetzung von Ideen und die Lieferung von Prototypen entsteht ein klarer Wettbewerbsvorteil. Durch motivierte Mitarbeitende und die Eliminierung unnötiger Prozessbremsen steigt die Produktivität des Unternehmens an. Eine höhere Kundenzufriedenheit verbessert den Ruf des Unternehmens. Die aus den Tools und Automatisierungen gewonnenen KPI können genutzt werden, um die bestehenden Prozesse weiter zu optimieren und zu verschlanken, wodurch der Effekt noch zusätzlich verstärkt wird.
Fazit
DevOps ist definitiv mehr als ein Buzzword. Allerdings auch kein Allheilmittel das Vorgesetzte verordnen können, um sich den Stempel “Agil” zu holen. „Wir sind jetzt agil und wir machen jetzt DevOps!“
Wenn man die Vorteile von DevOps nutzen möchte, muss man sich vor allem zunächst darüber im Klaren sein, dass DevOps eine Idee und kein Dogma ist. Man kann keine, auf die eigene Organisation perfekt zugeschnittene 1:1 Lösung erwarten, sondern muss sich diese individuell unter Einbeziehung aller Beteiligten selbst gemeinsam erarbeiten. DevOps ist also eher eine Richtschnur an Best Practices.
Auch wenn die Umsetzung eine offene Kommunikation, eine gewissen Risikobereitschaft und den Willen auch aus Misserfolgen zu lernen voraussetzt, so sind die Vorteile, die sich in den Firmen zeigen, die eine erfolgreiche Umsetzung durchgeführt haben, nicht von der Hand zu weisen. Firmen wie Amazon oder Netflix oder auch die NASA haben bereits erfolgreich die Transformation vollzogen.
DevOps ist also eine Möglichkeit sich prominent am Markt zu positionieren und den eigenen Mitbewerbern durch höhere Innovationskraft, bessere Kundenbindung und höhere Mitarbeiterzufriedenheit einen Schritt voraus zu sein.
Wir bei der frobese GmbH haben für uns bereits erfolgreich die Ideen des DevOps implementiert. Daher helfen wir gerne und aus Überzeugung unseren Kunden ihre individuelle Strategie für die Umsetzung von DevOps bei sich im Unternehmen zu finden. Genauso unterstützen wir von der frobese GmbH Sie auch tatkräftig mit unseren DevOps geschulten Mitarbeitern bei der praktischen Durchführung ihrer Projekte.
Quellen
Über Stefan Rose
