Definition „YBIYRI“ Was bedeutet „You build it, you run it“?

Anbieter zum Thema

Vogel IT-Akademie

OutSystems

In einigen DevOps-Strategien sind die Developer für den Betrieb und Support ihrer eigenen Anwendungen verantwortlich. Das zugrunde liegende Motto „You build it, you run it“ ist allerdings nicht unumstritten.

In der Softwareentwicklung gibt es verschiedene Modelle, die das Management eines Projektes beschreiben. Zu den klassischen, sich gegenüberstehenden, Modellen zählen hierbei agiles Management und das Wasserfallsystem.

Der Wasserfall reicht die Aufgaben durch verschiedene Abteilungen hindurch und sorgt so dafür, dass jede neue Task von einem neuen Department gehandhabt wird. Ist die Entwicklung also erst einmal abgeschlossen, hat das Development Team nichts mehr mit der Software (in der veröffentlichten Version) zu tun. Diese wird nun an den Support übertragen.

Development und Support sind im Lebenszyklus einer Software zwei vollkommen unterschiedliche und voneinander abgetrennte Spezialisierungen, die nur über wenig Schnittmenge verfügen. Andere Modelle wie die agile Softwareentwicklung sehen dies allerdings anders.

Im Zuge von DevOps-Strategien werden Schnittmengenteams mit krossfunktionaler Aufgabenteilung gebildet. So soll sichergestellt werden, dass es zu einer besseren Kommunikation und einer schnelleren und präziseren Behandlung von Problemen kommt. Wer eine Software entwickelt, kann sie schließlich auch betreiben – oder wie Werner Vogel es formulierte: You build it, you run it, kurz YBIYRI.

Was sind die Vorteile von YBIYRI?

Wenn es bei einer Software zu Problemen kommt und der Support reagieren muss, so kann dies langwierige und frustrierende Prozesse nach sich ziehen. Treten während You build it, you run it Störungen auf, werden die Entwickler und Entwicklerinnen bereits nach wenigen Schritten kontaktiert. Hierdurch lässt sich sicherstellen, dass Probleme auch tatsächlich von Fachleuten behandelt werden.

Ein weiterer Vorteil offenbart sich in der grundsätzlichen Ideologie während der Entwicklung. Da Developer nun auch (zumindest in Teilen) den Support übernehmen, sollte das Ziel nicht nur die Auslieferung einer funktionalen Software sein, sondern auch die Entwicklung von leicht zu analysierendem und fixenden Code.

Letztlich kann sich die Lage aber nicht nur während der Support-Phase verbessern, sondern auch während der Entwicklung. Haben die Developer schließlich einen tieferen Einblick in den Betrieb einer Software, kann dies auch beim Optimieren von Funktionen helfen und das Design zielgerichteter machen.

Der strukturelle Aufbau von YBIYRI-Systemen

Um einen flüssigen Ablauf zwischen Support und Development zu gewährleisten, erfolgt die Schleife zwischen Feedback und Response bei „You build it, you run it“ in der Regel über eine einzige Stufe, die in zwei verbundene Teams aufgeteilt ist. Auf der einen Seite nimmt der Service Desk Anfragen und Meldungen entgegen und kommuniziert diese mit den Anwenderinnen und Anwendern.

Das Entwicklungsteam befindet sich im gleichen Zeitraum aber on call und muss nicht zwangsläufig vom Serviceteam kontaktiert werden. Über digitale Lösungen wie Prometheus, Slack oder ServiceNow wird das Development Team in Echtzeit informiert und kann ohne weitere Verzögerung reagieren.

YBIYRI im agilen Kontext ist keine Allzweckwaffe

So verführerisch die kurzen Dienstwege zwischen Entwicklung und Support in einigen Fällen auch klingen mögen, so sehr muss die Projektleitung dennoch mit den notwendigen Ressourcen haushalten. Und hier stellt sich auch eine der Schwierigkeiten von You build it, you run it dar, denn der Betrieb eines zweigeteilten Service Teams, dem auch Entwicklerinnen und Entwickler angehören, kostet Zeit und Geld.

Damit stellt sich zwangsläufig die Frage, ob es die wirtschaftlichste und effizienteste Lösung ist, Teile des Development Teams für den Support bereitzustellen und diese über einen potenziell längeren Zeitraum in Bereitschaft zu halten. Dies kann letztlich zu einem Balanceakt werden, in dem auch andere Faktoren (wie die geringeren Kosten bei der Synchronisation zwischen den Teams) eine Rolle spielen.

Inwieweit die bessere Lauffähigkeit und geringere Wartungsintensität einer Software für das Development Team als Incentive genutzt sollten, um weniger Support-Arbeit zu leisten, ist ebenfalls fraglich. Agiles Development sollte stets darauf abzielen, einen leicht handhabbaren Code zu produzieren, der im Continuous Deployment weiter von Iteration von Iteration optimiert werden kann.

You build it, you run it als Managementtool zu nutzen, um Teams mit mehr Support-Dienst in Bereitschaft als Konsequenz zu drohen, wenn diese nicht sauber programmieren, ist letztlich auch eine Frage der Arbeitsmoral und des Managementstils.

(ID:48583104)