Ingenieurwissenschaften

DevOps steht symbolisch für den Schulterschluss aus Development und Operations, also den Entwicklungsabteilungen, die die Software programmieren, und dem Betrieb, der die Software dann operativ betreibt. DevOps umkreist das zentrale Problem, dass die Entwicklung in der Regel schneller Produktänderungen herbeiführen kann, als der Betrieb den reibungslosen Übergang sicherstellen. Die DevOps Bewegung will Lösungen für das Blame Game herbeiführen, das regelmäßig stattfindet, wenn Fehler im Betrieb auftauchen, und sich dafür gegenseitig die Schuld zugewiesen wird – während sich die Kunden aufgrund der Fehler eines zu schnell eingeführten Features oder aufgrund von fehlenden Features, die der Betrieb aus Angst vor Katastrophen nicht schnell genug ausrollt, abwenden.

»Hui«, sagen da Insider der HiTech-Industrie, »Wir kennen diesen Konflikt nur zu gut, aber Respekt, dass ihr gar nicht schaut, wie unsere Lösungsstrategien aussehen und lieber eure eigenen Versuche unternehmt.«

In der Automobilindustrie ist das Problem zwar nicht grundlegend gelöst, aber ein paar DevOps-Ansätze entpuppten sich bereits als Sackgasse. Ich will an dieser Stelle die Idee des DevOps an vier wesentlichen Aspekten festmachen und dann mal kräftig dran ziehen.

1. Bessere Zusammenarbeit und Abstimmung
Was soll man dazu sagen. Ja, das wäre natürlich toll, kostet aber auch Zeit, die niemand hat und die für die eigentliche Arbeit drauf geht. Man sollte nie vergessen, dass erst die bewusste Arbeitsteilung und Nischenspezialisierung die Entwicklung und Produktion von HiTech-Produkten ermöglicht.

2. Automatisierung des Informationsflusses per Tools
Nun ja, wenn es stets auf die persönliche Bekanntschaft ankommt, wie gut ein Entwickler sein Produkt an die Fertigung übergibt, ist der reibungslose Übergang genau so dynamisch, wie es menschliche Beziehungen nun mal sind, insbesondere, wenn beide Seiten nicht verstehen, was die andere macht, was dessen Sorgen sind und was dessen Ziele im Unternehmen sind.

Da hilft es natürlich, den Informationsfluss transparent zu gestalten und zu standardisieren.

Das macht den Informationsfluss allerdings wiederum bürokratisch und träge. Die Information richtet sich nicht nach dem individuellen Bedarf, sondern nach den Features des eingeführten Tools. Taugt das Tool nicht, oder gibt es keine ausreichende Einarbeitung (diese kostet ja schließlich Zeit, die keiner hat), wird es  sehr kreativ umgangen. Hinzu kommt, dass die Schuld durch ein Tool einfacher bewiesen werden kann, weshalb per Tool im Zweifel nur das allernötigste auf den letzten Drücker kommuniziert wird. Gerade so, dass man keinen Ärger bekommt. Also Vorsicht DevOps-ler: Lieber kleine persönliche Tools entwickeln lassen, die von den Beteiligten selbst gepflegt werden, als einen ehrenwerten, aber überbordenden, Ansatz zu wählen, der letztlich nun den Entwicklern diese Ansatzes gefällt.

3. Standardisierung von Prototypenentwicklung und Serienfertigung.

Prototypen mit Werkzeugen zu fertigen, die nicht in der Serien zum Einsatz kommen, ist einfacher und flexibler. Es ist menschlich, die Komplexität von Technologie in naiver Weise zu unterschätzen und erst durch eine Fehlerlösung festzustellen, dass man die vermeintlich einfache Technologie doch nicht so gut beherrscht und versteht, wie gedacht.
In der industriellen Massenfertigung für HiTech Produkte gibt es so etwas namens Vorserienfertigung. Das Produkt wird so flexibel es geht entwickelt, muss dann allerdings in größerer Stückzahl durch Anlagen laufen, die vergleichbar mit der eigentlichen Serie sind, auch wenn sie nicht entsprechend vernetzt (alle Einzelanlagen zur einer großen zusammengeschaltet) sind und nicht ansatzweise die Kapazitäten aufweisen. Bei riskanten Änderungen können jederzeit in der Vorserie Tests durchgeführt werden oder Kriterien für einen Stresstest abgeleitet werden, der dann in Leerlaufphasen in der Serienfertigung durchgeführt wird. Es gibt logistische Qualitätssysteme, die Änderungen per Schlüssel definieren und zu Blocks zusammen fassen etc. Um nur ein paar Beispiele zu nennen.
Vorsicht DevOps-ler: Eine Standardisierung bringt nur Trägheit und Innovationshemmung in die Entwicklung. Es ist vielleicht ein guter Kompromiss, eine  Vorserie zu betreiben, auf der die Entwickler einerseits ihr Produkt zum Laufen bringen müssen und von der andererseits der eigentliche Betrieb das Produkt übernimmt. Die Vorserie wird dann von pragmatischen Personen betrieben, die kein Problem haben, zwischen den Stühlen zu stehen, zu vermitteln und gewünschte Technologie von beiden Seiten den jeweils anderen zur Verfügung zu stellen. Beide Seiten (Entwicklung und Betrieb) müssen sich dann mit der jeweils anderen nur indirekt beschäftigen, aber eben nicht in Gänze. Das ist natürlich sehr teuer und lohnt sich nur für sehr große Betriebe. Also DevOps-ler. So ein Vorserienjob müsste doch eigentlich euer Traumjob sein!

4. Optimieren der Prozesse

Zum Schluss eine philosophische Sichtweise auf das Problem

Wenn ein unerwünschter Zustand festgestellt wird, schauen erst einmal alle doof. Dann wird sich gefragt, wie das passieren konnte (Stichwort Blame Game). Dann kommen die Besonnenen und stellen fest, dass ein wie auch immer gearteter Ablauf fast zwangsläufig in zu diesem Zustand führen musste und natürlich kein menschlicher Vorsatz vorliegt. Sei es durch mangelndes Knowhow, sei es durch mangelnde Qualitätssicherung, sei es durch mangelnde Kompetenz oder sei es durch ein unglückliches Missverständnis. Letztlich liegt im Prozess zwischen Anfangs und Endzustand das Problem und nicht in den Zuständen selbst.

Man kommt dann relativ schnell darauf, dass es Sinn macht, diesen Prozess zu beeinflussen, statt immer wieder neue Runde des Blame Games einzuleiten, bei dem man Änderungen an den Zuständen fordert.

Die besonders Besonnenen kommen dann irgendwann auf die Idee, den Prozess zu optimieren. Und dann kommen die noch Besonneneren und erkennen, dass es noch besser ist, nicht die Art des Prozesse (also wiederum einen Zustand) zu verändern, sondern den Prozess durch einen Prozess zu verändern. Hurra, nennen wir es Changemanagement und verdienen uns als Berater damit eine goldene Nase. Warum aber Philosophie?

Wer in Zuständen denkt, benutzt das Sein-Wort. Wer in Prozessen denkt, benutzt aktive Verben und argumentiert mit zeitlicher Perspektive. Vergleichen Sie einmal die folgenden Aussagen.

»Eine Information ist falsch. Die daraus abgeleitete Anforderung ist aber richtig. In der Umsetzung der Anforderung liegt also nicht das Problem.«

»Eine Voraussetzung führte zu einer irrtümlichen Information. Daraus entwickelte sich eine problematische Anforderung. Die Umsetzung der Anforderung verursachte aber keine weiteren Probleme. Es sollte untersucht werden, warum die Anforderung erst im Nachhinein als problematisch erkannt wurde.«

Also DevOps-ler: Der Ton macht die Musik. Verbessert euer Sprachniveau, benutzt mehr aktive Verben anstelle von Sein-Wörter und ihr verbessert automatisch das Prozessdenken und damit Handlungs- und Einsatzbereitschaft. Auch wenn es ständig um Zustände in euren Produkten geht, diese Zustände entstehen durch Prozesses, letztendlich also durch eure Arbeit.

Philosophische Sichtweise Over and Out.

DevOps
Bewerte den Beitrag

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.