Standardisierung wird manchmal als Angriff auf die Innovation angesehen. Dass man gezwungen ist, auf ein vielsprachiges Buffet zu verzichten und sich für eine eingeschränktere Speisekarte zu entscheiden, klingt auf jeden Fall erdrückend. Das liegt möglicherweise daran, dass Standardisierung häufig mit Normen zur Einhaltung gesetzlicher Vorschriften in Verbindung gebracht wird, die offiziell klingende Namen wie ISO 8076.905E haben und Checklisten, Prüfer und Aufsichtsausschüsse mit sich bringen.
Tatsächlich gibt es nur sehr wenige Standards (mir fallen tatsächlich keine ein), die die Auswahl von Sprachen, Protokollen und Frameworks durch Unternehmen regeln. Der Grund für die Standardisierung im Unternehmen sind eher praktische Überlegungen, beispielsweise die Verfügbarkeit von Talenten, Nachhaltigkeit und Gesamtbetriebskosten über die (oft beträchtliche) Lebensdauer von Software und Systemen.
Studien haben gezeigt, dass die durchschnittliche Lebensdauer einer Software in den letzten zwanzig Jahren etwa sechs bis acht Jahre beträgt. Interessanterweise nimmt die Lebensdauer bei größeren Programmen, gemessen in Codezeilen, tendenziell zu. Systeme und Software mit über einer Million LOC scheinen eine Lebensdauer von über einem Jahrzehnt zu haben, also 12 bis 14 Jahre. Auch wenn Sie dies vielleicht als irrelevant abtun, ist es wichtig, sich darüber im Klaren zu sein, dass es sich bei Netzwerkautomatisierungssystemen letzten Endes um Software und Systeme handelt. Sie benötigen die gleiche Pflege, Versorgung und Wartung wie die Software aus Ihrer Entwicklungsorganisation. Wenn Sie Ihre Produktionspipeline als Code behandeln, müssen Sie akzeptieren, dass ein erheblicher Prozentsatz dieser automatisierten Pipeline aus Code bestehen wird.
Im Laufe der Lebensdauer dieser Software oder dieses Systems werden mit Sicherheit mehrere Gruppen von Betreibern und Entwicklern für die Aktualisierung, Wartung, den Betrieb und die Bereitstellung von Änderungen an dieser Software oder diesem System verantwortlich sein.
Und genau das ist der Kern der Standardisierungsbestrebungen – insbesondere für NetOps, die sich in die Entwicklung und Wartung von Systemen zur Automatisierung und Orchestrierung der Bereitstellung und des Betriebs der Netzwerk- und Application stürzen.
Wenn Sie (oder Ihr Team) Python wählen, während ein anderer PowerShell wählt, bauen Sie effektiv ein Betriebssilo auf, das den Austausch von Fähigkeiten verhindert. Angesichts der Tatsache, dass die größte Herausforderung für NetOps laut dem „State of Network Automation 2018“ im Mangel an Fähigkeiten besteht (49 % der Befragten gaben an), wäre es töricht, durch die Einführung mehrerer Sprachen und/oder Tool-Sets zusätzliche Reibungspunkte zu schaffen. Ebenso ist es keine gute Idee, Sprachen und Toolsets auszuwählen, für die Sie vor Ort keine geeigneten Talente haben. Wenn andere Organisationen und Universitäten in der Nähe Python unterrichten und Sie sich für PowerShell entscheiden, wird es schwierig für Sie, Leute zu finden, die über die erforderlichen Kenntnisse für die Arbeit mit diesem System verfügen.
Es kommt selten vor, dass eine Organisation eine einzige Sprache standardisiert. Es kommt jedoch häufig vor, dass sie nur wenige standardisiert. NetOps sollten sich an Entwicklungs- und DevOps-Standards orientieren, da sich dadurch der Talentpool noch weiter erweitern lässt.
Viele NetOps-Organisationen sind bereits im Rückstand, wenn es darum geht, die DevOps- und Geschäftsanforderungen zu erfüllen und Kontinuität zu gewährleisten. Die bedauerliche Realität von NetOps und Netzwerkautomatisierung besteht darin, dass es sich um ein heterogenes Ökosystem handelt, für das nur sehr wenige vorgefertigte Integrationen verfügbar sind. Wir haben in der Umfrage zum Stand der Netzwerkautomatisierung festgestellt, dass dieser „Mangel an Integration“ die am zweithäufigsten genannte Herausforderung bei der Automatisierung ist; 47 % der NetOps stimmen dem zu.
Durch die Standardisierung von Tool-Sets und Infrastruktur (z. B. Application ) kann der Integrationsaufwand im gesamten Unternehmen verringert werden. Die Entwicklungen eines Teams können von anderen Teams genutzt werden, um die Wertschöpfungszeit anderer Automatisierungsprojekte zu verkürzen. Die Wiederverwendung ist ein wesentlicher Faktor zur Verkürzung der Wertschöpfungszeit. Wir erkennen die Wiederverwendung an der Vorliebe der Entwickler für Open Source und an der Tatsache, dass 80–90 % der heutigen Applications aus Drittanbieter- bzw. Open-Source-Komponenten bestehen. Dies beschleunigt die Entwicklung und verkürzt die Zeit bis zur Wertschöpfung. Dasselbe Prinzip lässt sich durch Nutzung vorhandener Integrationen auf die Netzwerkautomatisierung anwenden.
Etablieren Sie eine Kultur des Teilens und der Wiederverwendung über alle Betriebsbereiche hinweg, um die Vorteile der Standardisierung zu nutzen.
Anstatt Innovationen zu behindern, wie manche zunächst glauben, kann Standardisierung ein Katalysator für Innovationen sein. Durch die Standardisierung und gemeinsame Nutzung von Software und Systemen über verschiedene Betriebsbereiche hinweg verfügen Sie über eine robustere Mentalität und mehr Erfahrung, die die Zusammenarbeit bei neuen Anforderungen und Systemen ermöglichen. Sie bauen in Ihrem Unternehmen einen Talentpool auf, der Input, Ideen und die Implementierung neuer Features und Funktionen liefern kann, ohne dass der manchmal langwierige Onboarding-Zyklus erforderlich ist.
Darüber hinaus beschleunigt die Standardisierung aufgrund der Vertrautheit die Implementierung. Je mehr Sie mit derselben Sprache, denselben Bibliotheken und Toolsets arbeiten, desto leistungsfähiger werden Sie. Das bedeutet eine höhere Produktivität, sodass weniger Zeit mit dem Bau von Rädern verbracht wird und mehr Zeit darauf verwendet werden kann, darüber nachzudenken, wie man sich mit neuen Funktionen von der Konkurrenz abheben und Mehrwert schaffen kann.
Die Standardisierung kann sich anfangs erdrückend anfühlen, insbesondere wenn Ihre Lieblingssprache oder Ihr Lieblingstoolset aus dem Team gestrichen wird. Doch wenn man die Standardisierung als Chance zum Aufbau einer soliden Grundlage für Automatisierungssysteme und -software betrachtet, kommt das dem Unternehmen zugute und bietet NetOps neue Möglichkeiten, über die gesamte Toolchain zur kontinuierlichen Bereitstellung einen Mehrwert zu schaffen.
Aber standardisieren Sie nicht nur um der Standardisierung willen. Berücksichtigen Sie vorhandene Fähigkeiten und die Verfügbarkeit von Talenten in Ihrer Nähe. Befragen Sie Universitäten und andere Unternehmen, um den aktuellen Stand der Automatisierung sowie die erforderlichen Fähigkeiten und Talente im Betrieb zu verstehen. So können Sie sicherstellen, dass Sie nicht die einzige Organisation sind, die eine bestimmte Sprache oder ein bestimmtes Toolset einführt.
Die besten langfristigen Ergebnisse erzielen Sie, wenn Sie die Standardisierung nicht wie Sicherheit behandeln und erst erledigen, wenn Sie eine Implementierung bereits abgeschlossen haben. Setzen Sie bei Ihren Automatisierungsbemühungen frühzeitig auf Standardisierung. So vermeiden Sie, dass Sie mit betrieblichen und architektonischen Schulden belastet werden, die eine spätere Standardisierung erschweren.
Auch bei der Standardisierung gilt – genau wie bei der Sicherheit –: Besser früher als später.