Verkürzung der Wertschöpfungszeit: Prozess und Parallelisierung

Zur Weihnachtszeit gibt es eine allgemeine Klage. Es wird von den Dächern und unter den stacheligen Zweigen der Kiefern gerufen.

„Wenn ein Licht ausgeht, gehen alle aus!“

Dies ist der Aufschrei von jemandem, der mit in einem Reihenschaltkreis angeschlossenen Lichtern festsitzt. Ich möchte hier nicht weiter darüber abschweifen, warum das so ist. Es genügt zu sagen, dass eine einzelne durchgebrannte Glühbirne ein blockierender Faktor ist.

Dies gilt nicht für diejenigen, die mit in einem Parallelschaltkreis angeordneten Lichtern gesegnet sind. Eine Glühbirne kann ausfallen, während die anderen hell weiterleuchten.

Was hat das mit der Wertschöpfungszeit und den Applications zu tun? Alles. Denn wie es scheint, arbeitet die traditionelle IT in einem seriellen Kreislauf auf die Produktion hin, während die Entwicklung moderner Apps rund um die Uhr in einem parallelen Kreislauf auf Hochtouren läuft.

Verfahren

In einem aktuellen Blog entwirft James Urquhart, CTO von Pivotal Global Field, ein wichtiges Bild der kontinuierlichen IT, das sich zu Recht auf den Prozess statt auf das Produkt konzentriert. Er nennt es den Weg zur Produktion.

Bei der Idee eines Pfads zur Produktion geht es eigentlich um Prozesse und, in der traditionellen IT, um Parallelisierung. Dieses Konzept ist der Kern der modernen Application und -architektur. Allein die Zerlegung von Apps in einzelne, fokussierte Komponenten (manchmal auch Microservices genannt) führt zwangsläufig zu einer parallelen Entwicklung. Dies liegt daran, dass kleinere Teams gleichzeitig an verschiedenen Komponenten arbeiten. Dies ist letztendlich der Grund, warum Agile als Mechanismus zum Erreichen einer höheren Geschwindigkeit und zur Verkürzung der Wertschöpfungszeit für Applications funktioniert. Es sind nicht kleinere Teams. Es sind keine kleineren Apps. Es handelt sich um die Parallelisierung , die durch die Nutzung dieser Konzepte bei der Entwicklung und Bereitstellung von Applications erreicht wird.

Der gleiche Ansatz gilt für den Pfad zur Produktion. Das bedeutet, dass die Produktionskomponenten (Dienste), die zur Skalierung und Gewährleistung der Applications erforderlich sind, Teil eines viel größeren Prozesses sind und zum Teil parallel entwickelt und bereitgestellt werden können.

Was dem im Weg steht, ist die traditionelle IT. Serielle IT. Wasserfall-Entwicklungsmethoden, die auf den Produktionspool übergriffen. Wir bauen Netzwerke als serielle Kanäle auf, weil Daten seriell durch das Netzwerk fließen. Vom Router über die Firewall und das Load Balancing bis hin zum App-Server und der Datenbank. Daten fließen auf einem vorhersehbaren Pfad von einem Ende des Netzwerks zum anderen. Deshalb implementieren und liefern wir diese Application auf die gleiche Weise: in einem vorhersehbaren, serialisierten Prozess, der dem Datenpfad auf natürliche Weise folgt.

So wird es nicht mehr gehen.

Erstens, weil es mittlerweile mehrere Datenpfade gibt . Nicht nur die Datenpfade, die NS und EW durchlaufen, sondern auch die, die in andere Hauptrichtungen abweichen. NE zu einer Cloud, um ein Skript abzurufen. SW zum Abrufen von Sprites und Webfonts. WSE, um eine Karte zu erfassen und sie in unsere App einzubetten.

Aber nicht nur die Verteilung der Datenwege macht heute eine Parallelisierung des Weges zur Produktion notwendig. Es ist die Suche nach Effizienz und Geschwindigkeit, auch bekannt als Optimierung.

Parallelisierung

Um die für die Umsetzung der heutigen Time-to-Value-Erwartungen erforderliche Geschwindigkeit zu erreichen, ist eine parallele Entwicklung erforderlich. Nicht nur in der App-Entwicklung, sondern auch in der Kern-IT. Wenn wir uns die Bandbreite der Application ansehen, die heute in Unternehmen im Einsatz sind , erkennen wir mehrere Bereiche, in denen Parallelisierung zu einer schnelleren Bereitstellung beitragen kann.

Es ist nicht so sehr so, dass die traditionelle IT in Silos isoliert wäre. Denn das Ergebnis einer Microservices-Architektur sind Dutzende oder Hunderte kleiner, isolierter Teams, die sich jeweils auf einen ganz bestimmten Satz von Application konzentrieren. Die traditionelle IT besteht bereits aus Silos innerhalb von Silos. Das Problem besteht darin, dass agile Entwicklungspraktiken die parallele Entwicklung innerhalb ihrer Silos fördern und die traditionelle IT die Produktionsprozesse immer noch methodisch und serialisiert abwickelt.

Problematisch ist die Übergabe zwischen den Teams und die Art und Weise, wie wir den Netzwerkverkehr auf unserem Weg zur Produktion spiegeln. Es handelt sich nicht um einen seriellen Prozess. Wann immer es möglich ist, sollten wir die Entwicklung und Bereitstellung von Diensten parallelisieren.

Das bedeutet funktionsübergreifende Teamstrukturen, die die Zusammenarbeit eher früher als später fördern.

Durch die Parallelisierung von Prozessen mittels der Einführung agilerer Praktiken in allen Belangen können Unternehmen eine höhere Geschwindigkeit und Effizienz auf dem Weg zur Produktion erreichen.

Der Prozess ist das Produkt

Wie James andeutet, ist der Weg zur Produktion eigentlich ein Prozess. Und Prozesse bestehen aus Schritten. Jeder Six-Sigma-Prozess-Ninja mit schwarzem Gürtel wird Ihnen sagen, dass die Beschleunigung dieses Prozesses darin besteht, Ineffizienzen zu finden und zu beseitigen. In der Produktion äußern sich diese Ineffizienzen als Wartezeiten (Übergaben) zwischen starren, serialisierten Schritten im Bereitstellungsprozess.

Werkzeuge können hilfreich sein. Letztendlich erfordert die Verbesserung jedoch eine lange und gründliche Prüfung der Prozesse und die Suche nach Möglichkeiten zur Parallelisierung der Bereitstellung von Application als Teil Ihres Weges zur Produktion.

Kultur – insbesondere eine Kultur der Zusammenarbeit – ist nicht optional. Es hat einen sehr realen Einfluss auf Verhalten und Praktiken. Allein die Teamstruktur verändert die Pipeline-Automatisierung dramatisch, wobei traditionelle Teams mit nur einer Funktion hinter ihren modernen, DevOps-gesteuerten Gegenstücken zurückfallen. Setzen Sie sich für stärker kollaborative Teamstrukturen ein. In diesem Sinne sollte sich ein zusammenarbeitendes Team auch auf die wichtigsten Kennzahlen einigen. Durch gemeinsame Messgrößen können NetOps und Security ohne Einschränkungen auf eine kontinuierliche Bereitstellung hinarbeiten. Derzeit werden fast drei Viertel der NetOps anhand der NETZWERKVERFÜGBARKEIT gemessen. Die Einsatzhäufigkeit ist ihnen kaum bewusst. Sie werden sich darauf konzentrieren, das Netzwerk aufrechtzuerhalten, denn darauf müssen sie sich konzentrieren. Durch gemeinsam genutzte Metriken kann sich NetOps auf die geschäftlichen Anforderungen konzentrieren: schnellere und häufigere Bereitstellungen. 

Schließlich ist Empathie gefragt. Sie sind alle im selben Team und legen – das mag Sie überraschen – Wert auf dieselben Dinge. NetOps legen wahrscheinlich ebenso großen Wert auf die Pipeline-Automatisierung wie DevOps. Bedenken Sie, dass DevOps gegenüber NetOps zehn Jahre Vorsprung hat, wenn es darum geht, Hindernisse in Bezug auf Integration, Tools und Fähigkeiten zu bewältigen. Kollaborative Teams können helfen, indem sie die Standardisierung von Tools fördern, die von der Lieferung bis zur Bereitstellung reichen (wie Jenkins und GitHub/GitLab).

Der Weg zur Produktion ist kein Produkt. Es ist ein Prozess. Dabei handelt es sich um einen kollaborativen Prozess, der möglichst parallel durchgeführt werden muss, um die Wertschöpfungszeit zu verkürzen und eine erfolgreiche Application zu ermöglichen.