DevOps Stories: Technologie-Entscheidungen an der Basis treffen - JAXenter
Kolumne

DevOps Stories: Technologie-Entscheidungen an der Basis treffen

Konstantin Diener

Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen möchten wir gerne in dieser Kolumne berichten.

DevOps Stories

„Agilität“, „Management 3.0“, „New Work“ oder „DevOps“ – all diese Bewegungen verändern die Art und Weise, wie Software-Entwicklung organisiert wird. Und wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen möchten wir gerne in dieser Kolumne berichten. Doch wie lassen sich Erfahrungen zu Veränderungen der Unternehmenskultur transportieren? Wir meinen, so wie die Menschheit seit Jahrtausenden Erfahrungen transportiert: durch Geschichten.

Die Geschichte: Es war einmal…

Donnerstag, 23:14 Uhr: Im Entwicklerbüro stapeln sich Pizzakartons, die Luft ist schlecht und vom Geruch von Club Mate durchsetzt. Der Produktmanager Erik sitzt gemeinsam mit den Entwicklern Lukas und Christian vor dem Rechner (Abb. 1). Vor den beiden ziehen langsam Logausgaben auf einer Konsole vorbei.

Erik: „Lukas, lässt sich hochrechnen, wie lange wir für den Upload aller Musiktitel brauchen, wenn es in dieser Geschwindigkeit weitergeht?“

Lukas: „Im Moment brauchen wir für ein Album ungefähr 25 bis 30 Minuten. Da der Kunde die 20 000 wichtigsten Alben für den ersten Batch haben will, brauchen wir bei der aktuellen Geschwindigkeit ungefähr ein Jahr. Der Prozess wird aber immer langsamer. Es dauert also eher noch länger.“

Abb. 1: Das Produkt, an dem die beiden arbeiten, ist gerade in einer äußerst prekären Lage

Vor etwas über einem Jahr hat ein Kunde Lukas’ Arbeitgeber mit der Entwicklung einer neuen Musikplattform mit innovativem Bedienkonzept beauftragt. Direkt im Anschluss haben Lukas und seine Teamkollegen mit der Entwicklung begonnen. Erik betreut die Entwicklung als Product Manager. Am Montag soll das neue Produkt auf einer Messe der Öffentlichkeit vorgestellt werden. Dazu muss Lukas’ Team noch 20 000 Alben über einen Load-Prozess auf der Plattform bereitstellen. In den letzten Stunden hat sich herausgestellt, dass der Prozess viel langsamer läuft als geplant.

Christian: „Der Ladeprozess für die Metadaten ist jetzt vollkommen steckengeblieben. Die Maschinen sind unter Volllast.“

Erik: „Was bedeutet das?“

Christian: „Das Hochladen eines Albums besteht aus mehreren Aufgaben. Die Audiodateien liegen als WAV-, OGG- oder MP3-Dateien vor. Wir müssen sie in ein einheitliches Format überführen und die Lautstärke und so weiter anpassen. Außerdem haben das Album und die einzelnen Titel Metadaten, die wir ins System laden. Mit diesem Schritt haben wir jetzt gerade die größten Probleme.“

Lukas: „Weglassen können wir die Metadaten nicht. Sonst heißen alle Alben auf der Plattform „Untitled“ und die Titel sind einfach durchnummeriert.“

Erik: „Und das innovative Bedienkonzept des Kunden, das auf der Messe präsentiert werden soll, funktioniert ohne Metadaten natürlich auch nicht, oder?“

Lukas: „Genau!“

Erik: „Aber warum macht ausgerechnet das Laden der Metadaten solche Probleme? Nach meinem Verständnis ist das Vorbereiten der Audiodateien viel aufwändiger, braucht mehr Rechenleistung etc.“

Christian: „Ähm, ja … Sag du es ihm …“

Lukas: „Ich glaube, Erik, wir müssen dir was erklären. Wir haben von unserem CTO die Vorgabe, alle Software auf dem Application-Server-Cluster im Rechenzentrum anhand unserer Referenzarchitektur zu entwickeln.“

Erik: „Die kenne ich. Und?“

Lukas: „Was den Metadatenupload angeht, haben wir uns auch daran gehalten. Wir waren uns aber sicher, dass die Vorbereitung der Audiodateien auf dem Cluster viel zu lang dauern würde. Deswegen haben wir uns über die Vorgabe hinweggesetzt, dieses Modul in einer anderen Programmiersprache entwickelt als vorgeschrieben und bei einem Cloud-Anbieter deployt. Hier können wir die Rechenleistung bequem skalieren, wenn wir Lastspitzen wie beim initialen Load haben. Beim Metadatenupload waren wir nicht von solchen Performanceproblemen ausgegangen.“

Christian: „Wir haben ja sogar Performancetests für die Audiovorbereitung auf unserem Cluster gemacht. Es hat hinten und vorne nicht gereicht …“

Erik: „Bei einem Cloud-Anbieter? Aber was kostet das? Dürfen wir die Daten des Kunden überhaupt in der Cloud speichern und verarbeiten?“

Lukas: „Weil wir die Rechenleistung in der Cloud nur für eine kurze Lastspitze brauchen, fallen nur 80 Euro Kosten an. Wir haben zusammengelegt, um den Ärger mit dem Einkauf zu umgehen. Wegen der Daten des Kunden haben wir mit Carsten gesprochen, der die Verträge gemacht hat. Sie lassen eine Verarbeitung in der Cloud zu!“

Erik: „Können wir den Metadatenimport auch in der Cloud machen, damit unser Kunde am Montag ein präsentables Produkt hat?“

Lukas: „Wir können es probieren. Das wird aber auf jeden Fall auf eine Wochenendschicht hinauslaufen …“

Erik: „OK, ich schlage euch folgenden Deal vor: Lasst uns jetzt alles daran setzen, den Messetermin zu retten. Im Nachgang spreche ich mit unserem Management, dass ihr mehr Freiheiten für eure Technologieentscheidungen bekommt und kleinere Ausgaben wie für den Cloud-Anbieter auch nicht mehr so umständlich sind.“

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

Entscheidungen an der Basis

Die Computerpionierin Grace Hopper hat den Ausspruch geprägt „Es ist einfacher, um Vergebung, als um Erlaubnis zu bitten“ – und genau das war bei Lukas und seinen Kollegen der Fall, als sie sich für die Implementierung der Medienverarbeitung über die Vorgaben ihres CTOs hinweggesetzt haben. Das Ergebnis scheint ihnen Recht zu geben.

Warum gibt es in Softwareprojekten immer wieder Situationen, in denen das absolut sinnvoll Erscheinende im Widerspruch zu den Vorgaben des Managements steht? Softwareprojekte sind komplexe Systeme [1]. Um diese Systeme zu steuern oder von außen möglichst sinnvolle Entscheidungen zu treffen, benötigt man ein umfassendes mentales Modell des Systems.

Das bedeutet: Je vollständiger die Informationen über das System sind, desto besser sind die Entscheidungen für die Steuerung. Sind die Informationen unzureichend, passt die Entscheidung nicht zur Realität des Projekts.

Betrachten wir die klassische Aufgabenteilung zwischen Management und Entwicklungsteam (Abb. 2): Der Manager erhält Informationen aus dem Team und versucht, sein Modell durch eine weitere Informationsbeschaffung zu vervollständigen. Wenn er meint, genügend Informationen zu haben, trifft er eine Entscheidung und gibt sie ans Team zur Ausführung. Danach beginnt der Austausch von vorne, weil sich durch die Entscheidung eine neue Informationslage ergibt.

Abb. 2: Arbeitsteilung zwischen Manager und Team

Damit diese Zusammenarbeit funktioniert, muss der Manager genau die richtigen Informationen erhalten. Da beide Parteien aber nicht vorab wissen, welche das sind, erhält er in der Regel zu viele oder zu wenige Informationen.

Lukas und seine Kollegen haben die Erfahrung gemacht, dass durch unzureichende Informationen beim CTO Entscheidungen zustande kommen, die nicht zur Realität in ihrem Projekt passen. Zudem trägt die beschriebene Aufgabenteilung nicht zur Robustheit und Resilienz des Teams bei. Fällt der Manager beispielsweise durch Krankheit aus oder ist nicht erreichbar, ist das Team vollständig gelähmt.

Dabei können sich der CTO und das Entwicklungsteam den Aufwand für den Informationen-Entscheidungen-Kreislauf sparen. Offensichtlich liegen im Team alle Informationen vor, um eine adäquate Technologieentscheidung zu treffen. Die Informationen, die dem Team noch fehlten („Erlauben unsere Verträge es, Cloud-Technologien zu verwenden?“) haben sie sich besorgt. Um zu schnellen und guten Entscheidungen zu kommen, ist es sinnvoll, sie so nah wie möglich an der Basis an den Informationsquellen zu treffen. Ähnlich wie ein Fluglotse dem Piloten die Steuerung der Maschine überlässt und nicht laufend mit allen Detailinformationen der Maschine versorgt wird, um aus der Ferne eine Entscheidung zu treffen.

Erik stellt durch das Gespräch mit Lukas und Christian fest, dass das Delegieren von Technologieentscheidungen an das Entwicklungsteam gerade sein Produkt rettet. Als er einige Tage später mit dem CTO spricht, kann er ihn tatsächlich davon überzeugen, dass das Team diese Art von Entscheidungen in Zukunft eigenständig treffen kann. Die Entwickler dürfen außerdem Ausgaben von bis zu 100 Euro im Monat selbst anweisen, müssen aber die Kollegen in der Buchhaltung darüber informieren. Für höhere Ausgaben bleibt es vorerst beim aktuellen Verfahren. Die Art der Delegation ist also abhängig vom Thema.

Jurgen Apello unterscheidet in „Management 3.0“ sieben mögliche Stufen der Entscheidungsfindung:

  • Stufe 1 – Tell: Der Manager trifft die Entscheidung und informiert das Team.
  • Stufe 2 – Sell: Der Manager trifft die Entscheidung und versucht das Team davon zu überzeugen.
  • Stufe 3 – Consult: Der Manager holt die Meinungen des Teams ein, entscheidet aber alleine.
  • Stufe 4 – Agree: Manager und Team entscheiden im Konsens. Alle Stimmen haben das gleiche Gewicht.
  • Stufe 5 – Advise: Das Team holt die Meinung des Managers ein und entscheidet dann eigenständig.
  • Stufe 6 – Inquire: Das Team entscheidet und versucht den Manager davon zu überzeugen.
  • Stufe 7 – Delegate: Das Team entscheidet vollkommen eigenständig.

Abb. 3: Das Team vor seinem Delegation Board

In ihrem Büro haben Lukas und seine Kollegen ein sogenanntes Delegation Board aufgestellt (Abb. 3). Darauf ist für jedes Thema gut sichtbar die Art der Delegation vermerkt und die Vereinbarung zwischen Team und Management explizit festgehalten und visualisiert. In ein paar Monaten wollen sie sich wieder mit Erik und ihrem Management zusammensetzen. Sie werden sich ansehen, ob die Veränderungen erfolgreich waren und ob die Delegationsstufen möglicherweise angepasst werden müssen.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.