Es ist keine Veröffentlichung, es ist ein Lebenszyklus

Es ist ein altes Mantra in der Technik: Entweder man verfügt über die richtige Technologie, sonst kommt man nicht weiter. Doch ist die Prämisse, dass die beste Technologie gleichbedeutend mit Erfolg ist, wirklich gültig?

Heute wissen wir, dass da noch mehr dahinter steckt. Sie könnten die beste Technologie der Welt entwickeln, aber wenn Sie den Menschen nicht dabei helfen, zu verstehen, wie sie die neuen Konzepte und Möglichkeiten auf ihre Probleme anwenden können, haben Sie lediglich ein Widget, das niemand verwenden kann – und keine Möglichkeit herauszufinden, ob es überhaupt funktioniert.

Die eigentliche Aufgabe, ein erfolgreiches Produkt zu bauen, besteht darin, gleichermaßen in die Entwicklung des Produkts und in die Menschen zu investieren, die es in ihrem Umfeld nutzen werden. Angesichts der technologischen Entwicklung ist es wichtig, dass die Anbieter aktiv in die Ausbildung, Betreuung und Befähigung der Menschen investieren – noch vor der Produktentwicklung – und ihnen die grundlegenden Fähigkeiten vermitteln, die für die Nutzung neuer Technologien erforderlich sind.

Auf diese Weise tragen wir zum Aufbau einer besseren, besser informierten Benutzerbasis bei, die ihre Erfahrungen und ihr Wissen anwenden kann. Und im Gegenzug geht diese neu informierte Benutzerbasis eine symbiotische Beziehung mit uns als Anbieter ein und unterstützt uns bei der Entwicklung von Produkten und Lösungen aus einer Position reifer, informierter Autorität heraus.

In diesem Umfeld liegt der Maßstab für den Erfolg nicht mehr in der Veröffentlichung eines neuen Produkts. Dabei geht es darum, alle Produktbestandteile – Kunden, Partner, F5-Techniker, Supportmitarbeiter – kontinuierlich einzubinden und ihnen zuzuhören, in einem konstanten Lebenszyklus aus Innovation und Verbesserung.

Einsatz von DevOps-Methoden für die Schulung

Wie das funktioniert, können Sie sehen, wenn Sie sich den Verlauf des Super-NetOps-Programms ansehen. Im Rahmen der Umwandlung von F5 in ein Unternehmen für Multi-Cloud-Anwendungsdienste mussten wir Hunderte von Ingenieuren auf der ganzen Welt in neuen grundlegenden Fähigkeiten in den Bereichen Cloud, Automatisierung, Orchestrierung und DevOps-Methoden schulen.

Dabei haben wir hart daran gearbeitet, eine symbiotische Beziehung zu unseren eigenen Ingenieuren aufzubauen. Der Zyklus sah folgendermaßen aus: Entwickeln Sie Schulungsinhalte. Testen Sie den Inhalt mit einigen Benutzern. Bestimmen Sie, wo das Benutzererlebnis verbessert werden muss. Bauen Sie das in unser Produkt ein. Wiederholen.

Wenn Sie ein Produkt auf den Markt bringen und Kunden damit beliefern, können Sie die gleiche DevOps- und Agile-Methodik wie folgt kombinieren: Sie bauen etwas und haben nun einen Prototyp. Sie müssen Feedback erhalten, aber Sie werden kein Feedback bekommen, bis Sie Leute finden, die bereit sind, Zeit und Mühe zu investieren. Und dafür brauchen sie eine Ausbildung. Sie benötigen eine Dokumentation. Sie brauchen Hilfe, um da durchzukommen.

Deshalb arbeiten wir parallel zu unseren Entwicklungsbemühungen an der Ausarbeitung der Mechanismen für unser Training. Und ein Teil davon ist die Integration einer Feedbackschleife – sowohl in Bezug auf die Schulungen als auch auf die Produkte selbst. Wie können wir dafür sorgen, dass die Benutzer dieser Prototypen im Sinne von Open Source etwas zurückgeben können? Was können wir daraus lernen, wenn ein Kunde bei einer Implementierung nicht weiterkommt? Und wie nutzen wir diese Erkenntnisse, um unsere Produkte und unseren Support noch besser zu machen?

In den vergangenen Jahren haben wir unsere Kunden und die Community eingebunden und diese Bemühungen haben zum heutigen Super-NetOps geführt, das auf der Einführung des Programms bei Agility vor zwei Jahren aufbaut.

Dies war eine grundlegende Änderung für unsere NetOps-orientierten Ingenieure. Wir entwickeln nicht nur Automatisierungs- und Orchestrierungslösungen, sondern orientieren uns auch an der Methodik rund um DevOps und den Softwareprozess. Wir entwerfen es, als wäre es ein riesiges verteiltes Softwareprojekt, das zufällig auf der F5-Plattform läuft und in diese integriert ist, und nicht als Netzwerkkram, der in etwas hineingequetscht wird, das wie ein Softwaresystem aussieht.

Partnerschaften aufbauen

Dabei geht es zu gleichen Teilen um die Akzeptanz und Nutzung von DevOps, aber auch um die Schaffung von Partnerschaften. Jetzt haben wir alle Voraussetzungen für eine neue Konversation mit unseren Kunden geschaffen. Wir hören aufmerksam zu und führen eine aktive, konstruktive Debatte, die ganz darauf ausgerichtet ist, wie wir für den Kunden das bestmögliche Ergebnis erzielen können. Manchmal geschieht das, indem wir sagen: „Ja, wir entwickeln eine Funktion.“ Manchmal drücken wir dies dadurch aus, dass wir Ihnen empfehlen, diesen Weg nicht einzuschlagen.

Darüber hinaus bietet es uns die Tools, die es uns ermöglichen, NetOps zu einem echten Partner von DevOps zu machen. Sie müssen nicht die Person sein, die nur Projekte bekommt, die über die Mauer geworfen wurden. Sie können ein Partner sein – derjenige, der DevOps- und Entwicklerteams zum Erfolg verhelfen und ihre Anwendung, ihr Ding, ihre Kreation zum Erfolg führen kann. Sollte es diese Person in Ihrem Unternehmen noch nicht geben, können wir sie innerhalb von zwei Wochen dorthin bringen.

Das Durchlaufen dieses Prozesses und die Umsetzung dieser Veränderungen haben die Sichtweise von F5 auf die eigene Zukunft grundlegend verändert. Wir wissen jetzt, wie wir uns mit der neuesten Technologie auseinandersetzen müssen, wie Container-Ökosysteme aufgebaut werden, wie Mikrodienste erstellt werden und wie in der modernen Zeit Software entwickelt wird.

Und wie Sie an unserer Veröffentlichung der Automation Toolchain -APIs in diesem Monat sehen werden, handelt es sich dabei um eine Philosophie, die auch bei unseren Produkten wirklich einen Unterschied macht – Lebenszyklus für Lebenszyklus.