„Der enge Kontakt mit den Nutzern ist das beste Mittel gegen den Elfenbeinturm“

Victor Volle und Marc Bialowons geben Einblicke aus dem Review eines Platform-Engineering-Projekts in einem großen Unternehmen, das sich in diesem Bereich klar als Vorreiter herausstellte. Marco Paga hat mit ihnen gesprochen.

Marco Paga: Victor, Marc, ihr wart bei einem großen deutschen Unternehmen. Könnt ihr kurz euren Auftrag beschreiben?

Marc Bialowons: Der Kunde hat uns damit beauftragt, einen Blick auf sein Platform Engineering zu werfen, das er gerade für knapp 2000 Mitarbeiter in der IT zur Verfügung stellt. Dabei war es wichtig, unvoreingenommen an das Thema heranzugehen und den Blick des Marktes darauf zu werfen. Wir haben das Thema schnell heruntergebrochen in einzelne Teilkomponenten bzw. unterschiedliche Arbeitspakete: Einerseits haben wir uns mit den Nutzern der Plattform auseinandergesetzt, in Form von User Interviews. Andererseits haben wir uns mit der Technik selbst befasst, damit herumgespielt und in einem Beispielprojekt die Plattform benutzt.

Victor Volle: „Herumgespielt“ damit hat eigentlich Marco Paga. 

MP: Genau, ich hatte die Möglichkeit, mir die Plattform aus Entwicklersicht anzuschauen, zu schauen, wie man damit arbeiten kann, welche Services es gibt. Es war ein sehr spannender Einblick, weil ich mit einem Buddy zusammenarbeiten konnte, der mir die ersten Fragen beantwortet und mich herumgeführt hat. Von daher: Danke, Victor, dass du mir den Ball zugespielt hast. Wir drei waren zufällig in diesem Consulting-Auftrag unterwegs.

Möchtet ihr noch etwas über den Kunden sagen?

VV: Die haben sehr früh mit Platform Engineering angefangen. Die ersten Schritte waren vor fünf Jahren. An der Stelle muss ich skizzieren, was wir mit „Platform Engineering“ meinen. Sie haben ganz banal angefangen, Kubernetes bei sich zu benutzen und internen Teams anzubieten. Das ist für mich der minimale erste Schritt: ein Angebot, das Teams, die Software entwickeln, ganz klischeehaft „Value-Stream-Teams“ genannt, nutzen können, ohne Kubernetes selbst einrichten zu müssen – gerade vor fünf Jahren war das noch ein bisschen schwieriger –, sondern das eine Team, das zum Nukleus des Platform-Engineerings wurde, hat Kubernetes zusammen mit einem externen Dienstleister hochgezogen. Die haben es betreut und betrieben und dann intern angeboten. 

Dann gab es ein Projekt, das Kafka verwendet hat, und andere Projekte wollten ebenfalls Kafka verwenden. Nicht jeder muss alle Details wissen, wie man das betreibt, einrichtet, hochzieht. Das wurde dann auch intern angeboten. Das waren die ersten Schritte, die fünf Jahre her sind. Das ist ganz schön lang. Solche Dinge gab es schon vorher, aber das dann sehr gezielt als Angebot für die eigenen Softwareentwicklungsteams bereitzustellen fand ich schon ziemlich beeindruckend. In Deutschland zählen sie für mich zu den Vorreitern. 

MP: Das heißt, sie haben Probleme gelöst, die sie damals schon hatten. Als der Begriff noch nicht wirklich gängig war. Sie haben verstanden, dass es einen Wert hat und das Ganze ein Produkt ist. 

VV: Ein Produkt ist es dort sicherlich noch nicht. Aber was ich gut finde: Sie sind nicht einfach auf den [Platform-Engineering-]Hype aufgesprungen. Ich finde den Begriff sehr gut, aber er ist momentan auch in aller Munde. Sie haben damals mit einem Problem losgelegt und gemacht, was sie brauchten. Irgendwann haben sie es dann „Platform Engineering“ genannt. 

MP: Sollen wir den Aspekt einmal genauer beleuchten?

MB: Das war für uns eine interessante Erkenntnis. Wir wurden quasi in kaltes Wasser geworfen, um uns einen externen Blick in „die Plattform“ zu erarbeiten. Daher gingen wir davon aus, dass wir uns „die Plattform“ ansehen können. Die erste Erkenntnis war dann aber, dass es gar nicht die eine Plattform gibt, auf der man sich einzelne Services automatisiert zusammenklicken kann. Es war eher ein sehr großes Konstrukt aus verschiedenen Plattform-Teams, die alle ihre spezifischen Services für die Projekte anbieten, aber noch nicht so sehr in einer einzelnen Plattform vereint. 

VV: Um dies zu verdeutlichen: Als du anfingst, unser Beispielprojekt zu bauen, Marco, wie viele Tickets hast du gebraucht, um alles zusammenzubekommen, was du brauchtest? 

„Wir haben alle gefragt: Wohin schaust du als erstes, wenn du etwas suchst? Jeder hat uns eine andere interne URL gesagt.“ 

MP: Das war auf jeden Fall im zweistelligen Bereich. Deswegen hatte ich auch Schwierigkeiten zu verstehen, was mit „Plattform“ gemeint ist. 

VV: Sie sprechen eher von einer „Organisationseinheit Platform Engineering“. Und ja, sie wollen ganz klar – das war auch eine unserer Empfehlungen – zu einer Plattform.

Zu unserem Vorgehen: Wir haben klassischen User Research gemacht – so gut wir es können, wir sind keine Produktmenschen. Dabei haben wir zwei Kerngruppen von Menschen identifiziert, die diese Plattform nutzen. Die eine Gruppe sind Leute, die sehr, sehr erfahren sind. Die sind früher selbst in Plattform-Teams gewesen oder arbeiten schon lange mit ihnen zusammen. Die andere Gruppe sind Leute, die weiter weg sind – das kann auch geographisch sein – oder die einfach noch nicht so lange dabei sind. Wir haben einen riesigen Unterschied in den Bedürfnissen dieser zwei User-Gruppen festgestellt: Die erfahrenen Menschen wollten dieses neue technische Feature und jenes Angebot usw. haben. Nur: Jeder wollte etwas anderes, was ihm oder ihr wichtig war. Die weniger erfahrenen Menschen – „erfahren“ muss hier nicht heißen, dass sie erst seit drei Jahren im Job sind, aber neu bei diesem Kunden oder bei der Plattform – waren teilweise noch sehr am Suchen. Wir haben alle gefragt: Wohin schaust du als erstes, wenn du etwas suchst? Jeder hat uns eine andere interne URL gesagt. Das heißt, es gibt nicht diesen einen Einstiegspunkt. Einer hat uns gezeigt, wie er in deren Weekly gezielt und sehr geschickt sucht, um das Richtige zu finden im „Wald vor lauter Bäumen“. Eine Plattform, die Menschen Self-Service-artig sehr einfach etwas zur Verfügung stellt, machen sie noch nicht. Wo sie richtig gut sind, ist alles andere: Unterstützung, Consulting, Support, Bereitstellen an Informationen bis in die Details. Gerade auch für den Betrieb, Observability und Logging, war alles da – in unterschiedlicher Ausprägung und Tiefe. Das hörten wir auch in den User-Interviews: Die waren zufrieden mit dem, was angeboten wurde, und wollten mehr. 

MB: Das ist ein super spannendes Learning aus dem Projekt: Es braucht nicht unbedingt eine „shiny“ Plattform, um Platform Engineering erfolgreich zu betreiben. Im Kern geht es um gute Leistungen, gute Services, die man als Team der eigenen Firma zur Verfügung stellt. Es war sehr erhellend zu sehen, dass nicht mit einem Tool wie Backstage angefangen wurde, sondern mit den Problemen, die man in der Softwareentwicklung hat. Bei 2000 Menschen in der Entwicklung kommt natürlich irgendwann eine neue Ebene dazu, nämlich die Metaebene: Wie benutze ich die Plattform möglichst effizient?

„Im Kern geht es um gute Leistungen, gute Services, die man als Team der eigenen Firma zur Verfügung stellt.“

Freedom and Rules 

VV: Was extrem spannend war, denn diese grundsätzliche Diskussion haben wir auch unabhängig von Platform Engineering immer wieder, war die Frage: Wie viel schreibe ich den Teams vor und wie viel Freiheit gebe ich? Das war dort in meinen Augen sehr ungewöhnlich, denn die Teams hatten sehr viel Freiheit. Wir sagen immer „Freedom and Rules“. Es muss eine Balance geben. Meine Lieblingsanekdote: Jemand, der sehr erfahren war und den wir interviewt haben, sagte, es gebe zu wenige Regeln. Aber dann sagte er wenig später, dass er sich selbst an gewisse Regeln nicht halte. Diesen Kampf haben wir immer wieder, sobald ein Team anderen Teams etwas bereitstellt oder vorschreibt – berühmt-berüchtigt: die Enterprise-Architektur im Elfenbeinturm. Das gab es dort in dieser Form nicht, und das tat auch manchmal weh. Aber das Angebot war einfach gut. Ich hatte nicht nur ein fertiges Kubernetes, sondern auch ein Kubernetes, das schon mit allem verknüpft war, was ich brauchte. Nicht ganz out of the box, aber es war der berühmte Golden Path, ein Spotify-Begriff. Das ist ein Riesengewinn. Marc Schnitzius sprach von „Cognitive Load“. Ich sage ganz banal: Aufwand runter. Ich schaue eher mit einer Management-Brille darauf. Ich will den Aufwand, der nicht notwendig ist, der keinen Value generiert, aus dem Value-Stream-Teams rausnehmen. Das klappt [in dem Unternehmen] einfach gut, weil das Angebot größtenteils schlüssig und aus einem Guss ist und funktioniert.

MB: „Freedom and Rules“ hat bei diesem Kunden auch eine große Auswirkung darauf gehabt, wie die Plattform wahrgenommen wurde. Dadurch, dass die Teams am Ende die Entscheidungshoheit darüber hatten, die Plattform zu nutzen oder nicht zu nutzen und sich selbst etwas zusammenzustellen, eignete man sich implizit die Produktdenkweise an. Man fragte sich, welche Probleme der Teams es wirklich zu lösen gilt, damit die Plattform Traktion erfährt. Das führt zu einer sehr produktorientierten Denkweise im Plattform-Team. In anderen Unternehmen wird den Entwicklungsteams eher etwas vorgeschrieben, was sie als Standard-Entwicklungsprozess nutzen müssen.

VV: Eines der wenigen Dinge, die vorgeschrieben waren: Wenn du in die Cloud gehen wolltest, war ein bestimmter Cloud-Provider vorgeschrieben, und du hast über das Plattform-Team einen Account bekommen. Das fand ich sehr gut. Das sind Basics. Das muss einfach gesetzt sein, sonst herrscht völliges Chaos. Aber in diesem Cloud-Account hätte ich tun und lassen können, was ich will. Ich hätte mit Haskell in Lambda mit einer selbstgestrickten MongoDB arbeiten können. Als ehemaliger Entwickler finde ich das toll. Als Mensch, der den Wildwuchs beherrschen muss, habe ich Angst. Es war gut zu sehen, dass das gut funktioniert hat. 

MB: Eines der Architekturprinzipien, die sie beim Kunden angewendet haben, war: „You can use the new fancy stuff if you've tried out the old boring stuff first.“ Das hat sehr bei mir resoniert, weil es herrlich pragmatisch ist und gleichzeitig dem Drang, technisch Neues auszuprobieren, entspricht.

VV: Der enge Kontakt mit den Nutzern ist das beste Mittel gegen den Elfenbeinturm. Wir kennen Kunden, wo sich die Enterprise-Architektur etwas ausdenkt, und alle sechs Wochen gibt es ein Architecture Board, bei dem man etwas vorstellen muss, und dann sagen die „Nein“, schicken dich zurück, und sechs Wochen später darfst du wiederkommen. Das gibt es dort [beim Kunden] nicht. Klar, es hat auch Nachteile, wenig vorzuschreiben. Bei Security ist bei uns immer die Grenze erreicht. 

MP: Wenn ihr das Thema Platform Engineering jetzt mit dem erweiterten Horizont beschreiben müsstet, würdet ihr es jetzt anders sehen als am Anfang des Projekts?

VV: Was [beim Kunden] noch besser sein könnte, ist der Produktgedanke. Sie haben eng mit ihren Nutzern gearbeitet, aber eher mit denen, die ohnehin laut waren, weil sie sie gut kannten. Richtig wäre es herauszufinden, welche Nutzergruppen es gibt und wie groß sie sind und danach vorzugehen. Gerade in dieser Größe würde ich jedem dazu raten.

Das zweite, was ich anders machen würde, ist das Thema Self-Service. Einfach loslegen zu können würde eine deutliche Beschleunigung ermöglichen. Das betrifft nur den Start eines Projekts, eines Services, das muss man sich auch klar machen. Wenn ich die Hürde niedrig halten möchte, gerade am Anfang einer Plattform, wenn sie noch nicht so ausgereift ist, möchte ich, dass die Leute sie benutzen.

Plattformen auf der Plattform

MP: Habt ihr bei dem Kunden irgendwelche Patterns gesehen, die für euch ein Augenöffner waren?

MB: Sie haben ein Kern-Plattform-Team, das die einzelnen Plattform-Services aufbaut und zur Verfügung stellt. Dadurch, dass sie eine derart große Organisation sind, die in unterschiedlichen Verticals, Produkten und Sparten aufgeteilt ist, haben sich „Platform-on-top-of-platform-Teams“, wie wir sie nannten, gebildet, die die Plattfom-Services genutzt haben, um eigene Mehrwerte neu zu kreieren, beispielsweise, um ein Applikations-Template für ihren spezifischen Bereich neu aufzubereiten, um die Entwickler, die in ihrem Bereich tätig sind, mit einer noch „fertigeren“ Lösung zu unterstützen. Das war ein interessantes Pattern, von dem wir am Anfang noch nicht sicher waren, ob es gut ist oder nicht. Am Schluss kamen wir zu der Erkenntnis, dass es ein sehr positives Zeichen ist, dass es eine lebende Plattform ist, wenn sich diese Teams bilden, wirklich damit arbeiten und eigene Lösungen auf Basis einer Plattform bauen. Denn genau das ist es, was man mit einem Plattform-Gedanken erreichen will. 

VV: Es gibt Schichten: ganz unten das Netzwerk, dann kommt vielleicht der Cloud-Provider, dann das Plattform-Team. Ganz oben sind die Value-Stream-Teams. Und wir dachten wirklich erst, zwischen Plattform-Teams und Value-Streams braucht es nichts mehr. Aber wenn ich z. B. einen großen E-Shop baue und darin 30, 40 oder 100 Services habe, haben diese Services in diesem Produkt ähnliche Anforderungen: Sie müssen in die gleiche CI/CD-Pipeline-artige Struktur hinein usw. In der Größe will ich das nicht für 2000 Entwickler standardisieren. Das wäre Wahnsinn. Ich würde völlig stillstehen. Deswegen sage ich, wie Marc, das ist gut. Wie auch Marc dachte ich zuerst: „Das riecht komisch.“ Jetzt sage ich: „It smells like green apples.“

MB: Eine spannende Frage ist: Wie sieht es in Unternehmen aus, die nicht 2000 Menschen in der IT haben? Ich glaube tatsächlich, dass das, was in diesen „Platform-on-top-of-platform-Teams“ passiert ist, durchaus in einem kleineren Kontext in das Plattform-Team hineingezogen werden kann oder sollte. Sie haben sich Blaupausen bzw. Applikationstemplates überlegt – was Projekte, Produkte oder Applikationen sind, die sie häufig bauen, die man als Standard definieren kann – und eine technische Infrastruktur darunter gelegt, um diese skalierbar und wiederverwendbar zu machen. Das kann für ein Plattform-Team viel Mehrwert generieren. 

„Ab acht Teams muss man schon gute Gründe haben, sich aktiv gegen ein Plattform-Team zu entscheiden.“

VV: Sie haben auch Support für ihre Leute geleistet und sie enablet, weil sie deren Fehlersituationen viel besser kennen als ein Plattform-Team für 2000 Leute. Wir glauben, dass dieses Pattern erst ab dieser einer Größe relevant wird. 

Wir haben neulich darüber diskutiert, ab wann sich ein Plattform-Team lohnt. Es gab sehr unterschiedliche Meinungen, von „ab zwei Teams“ bis „ab acht Teams“. Wir haben keine finale Meinung. Wir haben festgestellt, dass man ab dem zweiten Team Dinge gleich handhaben muss – etwa, weil das zweite Team einfach nur ein Split des vorherigen Teams ist – und dass man ab dem vierten oder fünften Team auf jeden Fall darauf achten muss, um nicht irgendwann überrollt zu werden und dann hinterherlaufen zu müssen. Eine Daumenregel, auf die ihr mich aber bitte nicht festnagelt: Ab acht Teams muss man schon gute Gründe haben, sich aktiv gegen ein Plattform-Team zu entscheiden.

MP: Was sind weitere Punkte, die nicht unter den Tisch fallen sollten?

VV: Eine Anekdote: Wir machen am Ende von Projekten immer eine Retrospektive. Die projektexterne Kollegin, die diese moderiert hat, war vorher schon etwas neidisch, weil das alles spannend klang. Hinterher sagte sie: „Jetzt bin ich noch neidischer.“ So war es auch. Das Projekt hat einfach Spaß gemacht, und das muss ich umso deutlicher sagen, weil ich am Anfang skeptisch war, ob es wirklich interessant ist. 

MB: Da kann ich mich voll anschließen. Mit einem „Outside View“ auf eine gewachsene Plattform zu schauen war unglaublich spannend. Wir haben viel gelernt und konnten auch glaube ich viel zurückgeben – hoffentlich! Das war sehr schön.

VV: Unsere Empfehlungen kamen extrem gut an. Es war natürlich nicht wahnsinnig viel Neues, aus zwei Gründen: Wir haben ihnen vorab schon erzählt, was unsere Pläne sind, um uns früh Feedback zu holen, damit wir nicht aus deren Sicht in eine falsche Richtung laufen. Wir haben versucht, die Schwerpunkte zu betonen. Denn: Die Leute im Platform Engineering kommen aus der Technik. Gerade die, die früh angefangen haben und viel gemacht haben, kennt das: Dies wird gebaut, jenes hinzugefügt. Dadurch verringert sich die Innovationsgeschwindigkeit, gerade in den Bereichen, die wirklich ausgereift sind. Daher waren sie etwas enttäuscht. Wir arbeiten ja gerne mit der Simon-Wardley-Metapher „Pioneers, Settlers, Town Planners“. Die Pioneers am Anfang legen einfach los, machen einfach. Wenn dieselben Leute nach drei, vier Jahren immer noch da sind, wird denen langweilig. Denn es bedeutet viel Maintenance. Da brauche ich die Settler oder die Town Planner. Das war ein Effekt, den wir sehr deutlich dort sehen konnten: Die [Pioneers] wollten – natürlich – am liebsten neue Technologien, neue Features machen, und wir haben uns bemüht, sehr nachdrücklich zu sagen: Ihr seid in vielen Bereichen an einer anderen Stelle. Ihr müsst euch vor allem um die Leute kümmern, die neu reinkommen und nicht nur „Fancy Sh...“ machen. So waren sie natürlich nicht, ich übertreibe jetzt. Die waren richtig schlau, deswegen hat die Zusammenarbeit auch unglaublich Spaß gemacht.

MP: Ich danke euch beiden sehr für eure Zeit! 

VV: Vielen Dank auch an dich!

Dieses Gespräch führten Marc, Pascal, Marco und Max im Rahmen unseres Podcasts SoftwerkerCast. Weitere Folgen unter https://www.codecentric.de/softwerkercast