NeuerscheinungEnglish
DevOps Mindset in Software Development
      From Apprentice to Journeyman

Ein Reisebericht für Entwicklung und Projektverantwortliche von Dr. Bernhard Scheffold

DevOps ist keine Rolle. Es ist eine Haltung.

Wie gelingt es, Software nicht nur effizient zu entwickeln, sondern auch echten Mehrwert für den Kunden zu schaffen?

DevOps Mindset zeigt einen praxisnahen Weg vom methodenverliebten Werkzeugdenker hin zur reflektierten Fachkraft. Statt auf gehypte Tools zu setzen, beleuchtet der Autor Denkfehler, Kulturprobleme und Erfolgsfaktoren aus über 30 Jahren Softwareentwicklung – inspiriert von Klassikern wie *The Phoenix Project*.

    Was ist, wenn wir die Last der Endbenutzer nicht bewältigen können, die eine neue Funktion nutzen wollen, die mehr CPU-Zyklen verbraucht, als wir dachten? Wenn wir eine Möglichkeit haben, die teure Funktion abzuschalten oder die Verfügbarkeit auf ausgewählte Endnutzer zu beschränken, kann uns das Zeit verschaffen. Auch die Erhöhung der Rechenleistung kann uns Zeit verschaffen, ist aber möglicherweise keine langfristige Lösung, da sie unseren Betrieb zu teuer macht.

    Die Verarbeitung einer einzigen Anfrage kann zum Absturz führen, weil der Speicher pro Anfrage nicht ausreicht. Eine Erhöhung des Arbeitsspeichers pro Anfrage könnte uns Zeit verschaffen, wenn nicht zu viele Endbenutzer unsere Software verwenden, so dass wir den Arbeitsspeicher gegen eine geringere Anzahl gleichzeitig ausgeführter Anfragen eintauschen können. Für andere Ressourcen, die wir verwenden, gibt es ähnliche Strategien zur Risikominderung. Auf einigen Systemen benötigen wir eine Datenbankverbindung pro Anfrage, und wenn die Ausführung von Anfragen langsamer wird, steigt die Anzahl der verwendeten Datenbankverbindungen.

    Natürlich können wir unser Datenbankmanagementsystem so konfigurieren, dass es mehr Verbindungen bereitstellt. Wie bei den anderen Abhilfestrategien sollte dies jedoch nur eine vorübergehende Lösung sein, bis wir eine bessere Lösung zur Begrenzung unseres Ressourcenverbrauchs gefunden haben. Die Lektion hier ist, dass wir nicht alle möglichen Probleme im Voraus planen können, und dass wir manchmal darauf reagieren müssen. Eine gute Zusammenarbeit mit dem Betrieb zahlt sich in solchen Situationen aus.

    Ich möchte eine Geschichte erzählen, die sich wiederholt in der besten Absicht ereignet hat, den Schreibdurchsatz eines MySQL-Datenbank-Setups zu verbessern. Aber in Wirklichkeit war es einfach ein Fall von Aktivismus, der eher Schaden anrichtete als die Situation zu verbessern. Dies sollte Sie darauf hinweisen, dass Sie wirklich verstehen sollten, was passiert, bevor Sie sich auf der Grundlage wilder Vermutungen an die Arbeit machen. Fangen wir also an ...

    (Aus dem Abschnitt „Entschärfung“)

    Eine SQL-Datenbank kann Ihnen alle Fakten nennen, die sich mit einer mehr oder weniger komplexen Abfrage aus ihren Daten ableiten lassen. Sie verwendet einen Optimizer, um einen sogenannten Queryplan zu finden, der am besten geeignet ist, das gewünschte Ergebnis mit dem geringsten Verbrauch von Ressourcen wie CPU und RAM zu erhalten. Der Optimizer kann dies nur erreichen, wenn das Datenbankschema so gestaltet ist, dass es effiziente Abfragen unterstützt und die Arbeit des Optizers ermöglicht. Wenn Sie nicht über eine Datenbank mit einem solchen gut gestalteten Schema mit korrekt definierten Datentypen und Indizes verfügen, müssen Sie alle benötigten Daten in den Anwendungsspeicher holen und die erforderliche Logik selbst ausführen. Sehr oft werden Sie nicht in der Lage sein, das gleiche Maß an Effizienz und Leistung zu erreichen wie ein ausgefeilter Datenbank-Optimizer, der seit Jahrzehnten entwickelt und optimiert wurde, um seine Aufgabe zu erfüllen.

    Als ich ein großes internationales Unternehmen beriet, das eine Reihe von intern entwickelten Anwendungen zur Unterstützung seiner Geschäfte hatte, hörte ich einige alarmierende Signale, die auf ein Datenbank-Setup hindeuteten, das weit davon entfernt war, optimal zu sein. ...

    (Aus dem Abschnitt „Queryplan-Analyse)

Und die unendliche Zahl der so genannten „Silver Bullets“, die im Laufe der Jahre angepriesen wurden: neue Sprachen, neue Prozessmodelle, von denen keines allein in der Lage ist, erfolgreiche Softwarelösungen zu garantieren. Hinzu kommt, dass die Softwareentwicklung im Laufe der Jahre von vielen Irrtümern begleitet wurde, wie z. B. der Wiederverwendung absolute Priorität einzuräumen. Oder das Vergessen von Zeit und Budget auf der Suche nach „Flexibilität“.

In diesem Buch geht es um die Implementierung und Nutzung von DevOps, das so ziemlich das Gegenteil einer „Silver Bullet“ ist. Die DevOps-Mentalität reißt organisatorische und mentale Silos nieder, um eine End-to-End-Sicht auf die Softwarebereitstellung zu ermöglichen. Der Autor zeigt, dass DevOps die Softwarebereitstellung deutlich verbessert, und er tut dies auf pragmatische Weise, indem er viele Beispiele aus seiner 40-jährigen Erfahrung in der Softwareentwicklung anführt. Diese Beispiele beinhalten nicht nur technisches und prozessuales Know-how, sondern sie lassen uns auch den sozialen und geschäftlichen Kontext und die Zwänge verstehen, denen wir bei der Bereitstellung von Software ausgesetzt sind. Und nach Ansicht des Autors können wir dies sogar in komplexen Situationen mit mehreren Parteien und Verträgen tun, in denen die sozialen Komponenten von DevOps wirklich ihren Wert zeigen.

(Aus dem Vorwort von Prof. Walter Kriha)

Ein wichtiges Merkmal einer professionelleren Einstellung ist das ständige Nachdenken darüber, wie wir unsere Arbeitsweise so verbessern können, dass wir nicht mehr nur reaktiv sind. Vielmehr streben wir eine Arbeitsweise an, bei der wir besser vorbereitet sind, nicht nur auf schlechte Dinge, von denen wir bereits wissen, dass sie früher oder später passieren werden. Wir möchten auch besser auf die „unbekannten Unbekannten“ vorbereitet sein, d. h. auf Ereignisse, mit denen wir nicht rechnen. Der Wandergeselle ist immer wachsam, um eine unerwartete Situation zu erkennen. Wir sehen uns ein paar Ideen an, wie wir besser auf alles vorbereitet sein können, was auf uns zukommen mag.

(Aus dem Kapitel: „Dritte Stufe: Bereitschaft“)

Rezensionen von frühen Lesern

Ich bin seit rund 20 Jahren in der Softwareentwicklung tätig - zunächst in der Entwicklung selbst und seit ein paar Jahren im Projektmanagement.

In seinem Buch „DevOps Mindset in der Softwareentwicklung, Vom Lehrling zum Gesellen“ beschreibt Bernhard Scheffold auf seine charmante Art alltägliche Situationen in der Softwareentwicklung. Neben vielen hervorragenden Praxisbeispielen gibt es auch viele sehr gute Ansätze wie „Feature Toggles“ oder warum man in jedem Projekt einen „Power User“ braucht.

Das Buch ist aber keineswegs eine Anleitung, wie bestimmte Prozesse abgebildet werden sollen/müssen. Vielmehr ist es ein sehr gelungener Versuch, den Blick der Teilnehmer auf das Thema „DevOps“ zu schärfen, damit wir alle besser miteinander und nicht aneinander vorbei oder gar gegeneinander arbeiten.

Ich habe mich oft dabei ertappt, dass ich zustimmend genickt habe, wenn eine bestimmte Situation beschrieben wurde. Das hatte ich in ähnlicher Form schon selbst erlebt und die Schlussfolgerungen sind sehr hilfreich und nachvollziehbar. Dieses Buch ist daher der perfekte Reisebegleiter auf dem Weg „Vom Lehrling zum Gesellen“.

Und wie immer gilt: „Eine Aussage ‚es geht nicht‘ zählt nicht!“

Dieses Sachbuch hat die 5 Sterne voll und ganz verdient, und es wird mir eine Freude sein, meine Meinung dazu zu erläutern.

Dr. Scheffold hat nicht einfach einen Braindump erstellt, sondern eine klare und leicht nachvollziehbare Struktur geliefert. Dennoch spürt man in jedem Satz die rohe, reine Erfahrung. Dieses Buch ist keine Fiktion; dieses Buch wirft einen unverblümten Blick auf den Entwicklungsprozess, seziert ihn Stück für Stück und zeichnet dann ein anschauliches Bild, das auch auf Lehrlingsniveau verständlich sein sollte.

Nachdem die Natur der Bestie erklärt wurde, werden die vielen Möglichkeiten, wie die DevOps-Methoden eingesetzt werden können, um sie zu zähmen, sehr gut erläutert.

Es ist anzumerken, dass der klare Schwerpunkt des Buches auf der persönlichen Entwicklung liegt, und das führt meine Rezension zu einem der Teile, die ich an DevOps am meisten liebe: Man kann es einfach selbst machen!

Ja, natürlich sind die Ergebnisse eines unternehmensweiten Kulturwandels und die Vorteile, die sich aus der Kombination von Agile und DevOps ergeben, unbestreitbar.

Aber während man mit Agile nicht wirklich alleine arbeiten kann, gibt es mit DevOps Tools, die man auch isoliert leicht implementieren kann.

Es versteht sich von selbst, dass alle erwähnten Bücher, Tools und Methoden referenziert sind und nachgeschlagen werden können, um das Wissen in jedem der genannten Themen zu vertiefen.

Auch wenn Nicht-Entwickler vielleicht nicht die Hauptzielgruppe sind, sollte dieses Buch jedem, der sich für DevOps interessiert, wertvolle Erkenntnisse liefern können.

Nach so viel wohlverdientem Lob möchte ich diese Rezension mit einem aus dem Buch gestohlenen Schlachtruf beenden: "Resist Muda!"

Als leitender Softwareentwickler erkenne ich zunehmend, wie wichtig es ist, alle Phasen in ihrem Zusammenspiel zu verstehen - von der Entwicklung über die Bereitstellung bis zum Betrieb. Ich hatte bereits erste Erfahrungen mit DevOps, wollte aber mein Wissen vertiefen.

Das Buch beschreibt anschaulich den Weg von einer Haltung des „Softwarebetrieb ist nicht mein Problem“ zu einer Einstellung des „Ich bin auf alles vorbereitet.“ Auf technischer, persönlicher und organisatorischer Ebene bietet das Buch eine beeindruckende Sammlung von Ansatzpunkten - praxisnah, kompakt und mit vielen gut platzierten Querverweisen. Die Kapitel sind meist schnell zu lesen, da sie nicht zu tiefgründig sind, ohne oberflächlich zu wirken. Wer tiefer einsteigen will, findet in den Literaturhinweisen zahlreiche ausgezeichnete Quellen für weiterführende Lektüre.

Besonders gut gefallen haben mir der starke Praxisbezug und die zahlreichen Beispiele - sie bieten Einsichten und Ratschläge, die sich in der Regel erst nach vielen Jahren praktischer Erfahrung ergeben.

Das Buch ist aus der Perspektive eines Entwicklers im E-Commerce-Projektgeschäft mit externen Kunden geschrieben. Das macht es sicherlich besonders lehrreich für diese Zielgruppe - aber ich habe auch aus anderen Perspektiven viel gelernt.

Fazit: Ein gut durchdachtes Fachbuch, das praxisnah und strukturiert zeigt, wie die DevOps-Evolution auf technischer, organisatorischer, kultureller und persönlicher Ebene ablaufen kann. Mit vielen kleinen Impulsen lädt es zum Nachdenken über die eigene Arbeitsweise ein. Eine klare Empfehlung für alle - nicht nur Entwickler - die verstehen wollen, warum Softwareentwicklung erfolgreicher ist, wenn sie ganzheitlich gedacht und mit mehr Verantwortung umgesetzt wird.

Dieses Buch wird Ihnen weder beibringen, wie Sie DevOps in Ihrem Unternehmen implementieren können, noch wird es Ihnen eine Schritt-für-Schritt-Anleitung bieten. Stattdessen konzentriert es sich auf etwas Grundlegenderes: das Verständnis dafür, wie Sie mithilfe von Software echten Mehrwert für Ihre Kunden schaffen können.

Als jemand, der am Anfang seiner Reise steht, um ein besserer Softwareentwickler zu werden, habe ich aus diesem Buch sehr viel gelernt. Der Autor teilt viele persönliche Erfahrungen und zeigt, wie eine veränderte Denkweise ein Projekt positiv beeinflussen kann.

Das Buch ist sehr verständlich geschrieben, so dass man es leicht lesen und nachvollziehen kann. Ich glaube, es ist nicht nur für Anfänger wie mich wertvoll, sondern auch für erfahrene Entwickler, die darüber nachdenken wollen, wie sie an die Entwicklung von Software herangehen. Darüber hinaus denke ich, dass auch Projektmanager von den hier vorgestellten Ideen profitieren können, da es eine breitere Perspektive auf das bietet, was erfolgreiche Projekte wirklich antreibt.

Kurzum: eine inspirierende und aufschlussreiche Lektüre, die ich Entwicklern und Projektmanagern gleichermaßen von ganzem Herzen empfehlen kann.

Ich bin seit 25 Jahren in der Softwareentwicklung tätig und habe diese Lektüre wirklich genossen. "DevOps Mindset" ist eines der wenigen Bücher, die es richtig machen und sich, unbeeinflusst von Branchentrends, auf das konzentrieren, was tatsächlich funktioniert.

Das Buch stellt die gesamte Herausforderung der DevOps-Bereitstellung als eine Änderung der Denkweise des Einzelnen und der allgemeinen Kultur dar, nicht nur als eine Änderung des Werkzeugkastens. Es baut auf einer klaren Grundlage auf: Verbesserung der persönlichen Arbeitsabläufe, Verkürzung der Feedbackschleifen und Verpflichtung zur ständigen Verbesserung.

Am besten gefällt mir die Metapher des "Wandergesellen" als praktisches Modell für die berufliche Entwicklung einer Person: von einem Junior-Entwickler, der auf Probleme reagiert, zu einer Führungskraft, die "architektonisch" arbeitet und Wert auf Bereitschaft legt.

Hier gibt es nichts Übertriebenes oder Fluffiges. Es ist ein pragmatischer Leitfaden für jeden ernsthaften Ingenieur, der sein Denken weiterentwickeln möchte. Ich kann es nur empfehlen.

Dieses Buch hat eindeutig fünf Sterne verdient. Beim Lesen merkt man sehr schnell, dass Dr. Scheffold kein Theoretiker ist, sondern ein Mann der Praxis mit viel Erfahrung. Die angeführten Beispiele verlieren sich nicht in technischen Details, sondern zeigen, dass DevOps weit mehr ist als nur die Entwicklung, Bereitstellung und der Betrieb von Software. Die Lektüre fühlt sich an wie ein Gespräch mit einem guten Freund bei einem Kaffee oder einem Glas Wein, der über DevOps philosophiert. Unbedingt lesenswert!

Ich kann es nur empfehlen!

Scheffold schwätzt nicht lange drumrum, und das war mal nötig, dass jemand auch mal auf den Tisch haut. Vieles, was bei unerfahrenen Codern hoch im Kurs steht, ist bei genauerem Hinsehen Schmarrn. Software muss als oberstes Gebot sicher laufen. Wenn sie dann noch ressourcenschonend läuft, ist das ein Sahnehäubchen. Muss sie auch noch sexy sein? Nein! Also zumindest nicht, wenn es auch nur ein Mü an der Sicherheit kostet.

Für diese Erkenntnis alleine musste ich einige Bücherläden durchlesen - daher danke!

DevOps Mindset in Software Development von Dr. Bernhard Scheffold ist eines der seltenen Bücher, das tiefe berufliche Erfahrung mit klaren, nachvollziehbaren Geschichten verbindet. Das Buch erklärt nicht nur die DevOps-Prinzipien – es ist eine Reise vom „Lehrling“ zum „Gesellen“ und illustriert jedes Konzept mit realen Beispielen aus Jahrzehnten der Praxis.

Das Buch zeichnet sich dadurch aus, dass es DevOps nicht als Berufsbezeichnung oder Toolset behandelt, sondern als Unternehmenskultur und persönliche Denkweise. Scheffold betont, dass es bei der erfolgreichen Bereitstellung von Software ebenso sehr um Kommunikation, Verantwortung und Kundennutzen geht wie um Automatisierungspipelines und Infrastruktur als Code.

Was ich besonders schätzte, war:

  • Die drei Säulen von DevOps (Flow, Feedback, Continuous Improvement) werden anhand von praktischen Schritten und zu vermeidenden Fallstricken erklärt.
  • Die „Wanderschafts“-Struktur – von Unwissenheit über Bewusstsein und Reaktivität bis hin zu Bereitschaft – macht es einfach, die Lektionen aufzunehmen und anzuwenden.
  • Zahlreiche Fallstudien und Anekdoten, die zeigen, wie sich DevOps in realen Organisationen auswirkt, einschließlich der sozialen und geschäftlichen Herausforderungen.
  • Ein ausgewogener Blick auf KI in der Entwicklung – weder übermäßig gehyped noch abweisend, sondern realistisch hinsichtlich ihrer Stärken und Grenzen.
  • Konkrete Techniken zum Testen, Überwachen und Verbessern von Systemen und Teamzusammenarbeit.

Im Gegensatz zu vielen technischen Büchern wendet sich dieses an Entwickler, Manager und Fachleute für den Betrieb gleichermaßen. Der Ton ist pragmatisch, ansprechend und erfrischend frei von Jargon um des Jargons willen. Am Ende fühlt man sich motiviert, nicht nur DevOps-Tools zu übernehmen, sondern die DevOps-Mentalität zu leben – Brücken zwischen den Teams zu bauen, sich auf die Bereitstellung von echtem Wert zu konzentrieren und kontinuierlich zu lernen.

Mir persönlich gefällt das Zitat "don't try to make it cool" – denn normalerweise macht ein Entwickler, der versucht, es cool zu machen, es schlechter und weniger stabil.

Wenn Sie also ernsthaft daran interessiert sind, die Bereitstellung von Software in Ihrem Unternehmen – oder auf Ihre eigene Karriere – zu verbessern, ist dieses Buch ein Muss. Es ist die perfekte Mischung aus praktischer Anleitung, kultureller Einsicht und langfristiger Vision.

Worum geht es in seinem Buch?

Wenn man schwierige und schöne Projekte durchlebt hat, gibt es immer etwas zu erzählen. Eine Reflexion über das, was gut war und was schief gelaufen ist, zusammengefasst in zum Nachdenken anregenden Textzeilen.

Ich dachte zunächst, für wen ist dieses Buch? DevOps-Ingenieure? Für das Management von Softwareunternehmen? Dann wurde mir klar: wahrscheinlich für beide. Normalerweise kennen sich Ingenieure nicht so gut mit der geschäftlichen Seite aus, und das Management eines Unternehmens hat nicht immer ein gutes Verständnis für die Herausforderungen, vor denen die Technik steht. Es war schon immer eine Herausforderung, beide Seiten auf die gleiche Seite zu bringen. Wie man das methodisch angehen kann und welche Fallstricke es auf dem Weg dorthin geben kann, das erfahren Sie in diesem Buch.

Was sich stark mit meiner persönlichen Erfahrung deckt, ist der Fokus auf den Aufbau eines Vertrauensverhältnisses mit dem Kunden, indem man sich unermüdlich auf das konzentriert, was dem Kunden einen Mehrwert bietet. Das ist etwas, das man nicht aus einer Theorie lernen kann, sondern nur durch eigene Erfahrung.

Und indem man das übernimmt, was so schwierig zu übernehmen ist: die Verantwortung.

Ab sofort erhältlich!

Hier kaufen

Interessierten Fachleuten aus Entwicklung oder in Projektverantwortung mit Freude an guten Prozessen und Lust an Diskussion stellen wir gern ein Rezensionsexemplar (Print / PDF / eBook) zu Verfügung [hier kontaktieren]

Über den Autor

Portrait of Bernhard Scheffold Dr. Bernhard Scheffold ist seit über 30 Jahren als Softwareentwickler, Architekt und Projektconsultant tätig. Er lebt in Freiburg, liebt Skateparks, ein gutes Glas Wein und komplexe Systeme einfacher und wertvoller zu machen.

Bernhard auf Linkedin kontaktieren.

Bernhards Blog lesen.

Folge der Linkedin-Seite zum Buch.