Wie die interne Plattform gelingt

17. Februar 2025 IT Management

Die meisten internen Entwicklerplattformen, die ich bisher sah, waren gescheitert. An Wirtschaftlichkeit und Kosten, am eigenen Anspruch, an der Akzeptanz der Nutzer, am Anspruch des Managements. Die Einführung von Tools ist nicht gleichbedeutend mit der Nutzung dieser Tools. Vertrauen aufzubauen braucht Zeit - und es ist schnell zerstört. Aber: Die Plattform kann auch gelingen, wenn du die richtigen Punkte berücksichtigst.

Was ist eine Entwickler-Plattform?

Moderne Softwareentwicklung benötigt viele Komponenten. Da braucht es Werkzeuge, um Code zu verwalten und zu prüfen. Wir benötigen Pipelines, um Projekte zu bauen und Infrastruktur, um sie zu betreiben. Wir brauchen Datenbanken, Speicher und Hosting, dazu Komponenten für Logging und Monitoring, um unsere APIs zu sichern oder Nutzeraccounts zu verwalten. Anbieter wie Microsoft, Google oder AWS haben das erkannt und bieten riesige Sammlungen von Werkzeugen an, die diese Bedürfnisse adressieren.

Je größer die Anzahl interner Teams ist, desto wahrscheinlicher kommt die Idee auf, deren Bedürfnisse “zentral” und aus eigener Hand zu bedienen. Aus Gründen der Vereinheitlichung und Kontrolle, zur Kostenoptimierung, als Mittel zur Leistungssteigerung. Das sind alles Management-Gründe, die aus der Sicht der teilnehmenden Teams wenig Relevanz haben. Um Teams auf Plattformen zu bringen, die lediglich aus Management-Sicht Vorteile bieten, muss man die Teams zwingen. Teams machen hingegen freiwillig mit, wenn die Nutzung der Plattform Vorteile bietet. Wenn das vom Team erstellte Produkt mit Plattform besser zu entwickeln und zu betreiben ist als ohne, dann ist es ein Vorteil.

Während das Management eine Plattform betriebswirtschaftlich begründet oder aus Compliance-Sicht, erwartetet der Nutzer dadurch schnellere Bereitstellung, bessere Qualität (als wenn man es selber macht) und im Kern weniger Arbeit.

Selbstbedienung ist der Schlüssel

Viele der funktionierenden Gründe für eine Entwicklungsplattform haben mit der Idee von schnellerer und leichterer Bereitstellung zu tun.

• Ich muss mich um weniger Details kümmern.
• Ich kann bereitstehende Dienste nutzen.
• Ich kann Zeit sparen und die Qualität verbessern, indem ich Vorgänge automatisiere.

All das kann nur passieren, wenn es ohne direkte Inanspruchnahme des Plattform-Teams passiert, denn ansonsten ist dieses stets der Flaschenhals. Wenn ich jede Änderung an der Plattformnutzung bei dessen Team in Auftrag geben muss, wird mich das ausbremsen, es wird die Abhängigkeit erhöhen und das Plattformteam zugleich davon abhalten, die Plattform weiterzuentwickeln. Der Wettstreit zwischen DevOps und “Ticket Ops” ist der wichtigste Erfolgsfaktor. Eine schlechte “developer experience” bedeutet den Tod deiner Plattform.

Wie gut ist die Developer Experience?

Die Fähigkeit deiner Organisation, gute Software zu liefern, wird unmittelbar beeinflusst durch die Fähigkeit deiner Entwickler, diese gute Software zu erstellen. Von stabilen Updates über skalierenden Teams bis hin zu geringer time-to market wird alles davon bestimmt, wie schnell Teams ihre Aufgabe aufnehmen und wie nachhaltig sie diese erfüllen können. Die Antwort auf “developer experience” bezieht sich nicht auf Obstkörbe und Weihnachtsfeiern, sondern auf gut ineinander greifende Werkzeuge und Prozesse.

Alles, was im Vergleich zu Alternativen “höhere Reibung” bedeutet, reduziert die Attraktivität der internen Entwicklungsplattform, und damit ihren Erfolg:

• verwirrenden Schnittstellen
• langsame Leistung
• unzureichende oder veraltete Dokumentation
• fehlende Beispiele und Vorlagen

Das Plattformteam muss in der Lage sein, Dienste anzubieten, die diese Defizite vermeiden. Ist das nicht der Fall, solltest du das Angebot lieber reduzieren, denn:

Du musst liefern, um ernst genommen zu werden

Eine interne Entwicklerplattform kann alles mögliche sein:

• Eine gut gepflegte Dokumentation mit hilfreichen Tipps und Tricks
• Ein frei verfügbares git-Repo mit ein paar nützlichen, dokumentierten Shellskripten
• Eine kleine Sammlung von aktiv gewarteten Basisimages für Vagrant, Docker & Co

aber auch

• Ein Self-Service Portal zur Nutzung komplexer Dienste wie Kubernetes
• Libraries, die deine Nutzer in ihre Projekt einbinden (inner-source-Prinzip)
• Betriebsfertige Komponenten wie Datenbanken, API-Management, Monitoring & Logging, die Teil der Softwareprojekte der Nutzer werden.

Es ist nicht schlimm, wenn du kleiner startest. Low hanging fruit ist gut. Schritt für Schritt steigt der Aufwand für das Plattformteam. Um die Nutzer zu überzeugen, muss deine Leistung überzeugen, also geh nur den Schritt, den du erfolgreich und zuverlässig leisten kannst.

Die etablierten Angebote großer Hersteller vermitteln den Eindruck, dass eine Plattform nur in der maximalen Ausbaustufe sinnvoll sein kann. Vergiss nicht: Bei Microsoft & Co stehen seit Jahren hunderte von Entwicklern hinter den Angeboten. Ist dein Plattformteam genauso groß - und erfahren? Mit großer Macht kommt große Verantwortung. Wie viel kannst du schultern?

Sei ein Produkt

Wir wissen jetzt: Du musst automatisieren, und du musst zuverlässig gute Qualität liefern. Deine Nutzer sind deine “Kunden”, also behandle sie so. Gestalte deine Plattform wie ein kommerzielles Produkt, für das Kunden nur dann bezahlen würden, wenn die Leistung stimmt.

• Bediene die Bedürfnisse deiner Kunden. Höre zu und lerne. Wenn du die Features der Entwicklungsplattform planst, ohne Entwickler einzubeziehen, dann machst du etwas wichtiges falsch.
• Sei klar bezüglich deiner Leistung: Was genau bietest du an, und was nicht? Wenn die Plattform dein Produkt ist, und Agilität dein Umfeld, dann brauchst du einen Product Owner. Aber einen wirklichen, bitte.
• Biete angemessenen Support für dein Produkt. Zieh die Grenze zwischen deinem Produkt und den Teams: Mein Autohersteller betreibt die Werkstatt, fährt mich aber nicht zum einkaufen.
• Kommuniziere, was du geändert hast (Changelog) und was du zukünftig vorhast (Roadmap). Gib Nutzern die Chance, dein Produkt strategisch einzuplanen.
• Kontrolliere deine Qualität. Messe Verfügbarkeit und Leistung, sei transparent mit diesen Zahlen.

Ein gutes Produkt bietet einen echten Mehrwert. Es schützt den Nutzer vor interner Komplexität und lässt zu, dass man sich auf die Verwendung konzentriert. Deine Plattform soll genauso sein.

Du brauchst Entwickler

Die interne Entwicklerplattform ist selbst ein IT-Produkt, besteht aus Software und Quelltexten, verwendet IT-Methoden. Die Mitglieder des Plattformteams müssen in der Lage sein, mit den Entwicklern in den Produktteams auf Augenhöhe zu sprechen, ihre Bedürfnisse zu verstehen und angemessene Lösungen zu finden. Zu den Methoden des Plattformteams gehört die Entwicklung von Automatisierung, Middleware und Adaptern, das Formulieren von Beispielimplementierungen und Dokumentation. Die Plattform unterliegt Veränderung und Releases wie jede andere Software auch. Kurz: Das Plattformteam ist ein Entwicklungsteam, seine Mitglieder müssen prinzipiell die gleichen Kenntnisse verfügen wie die Entwickler an anderer Stelle.

No shit, Sherlock: In der Plattformentwicklung arbeiten Entwickler.

Die Entscheidung für eine interne Entwicklerplattform muss also berücksichtigen, dass dort ebenfalls Entwickler arbeiten. Nur wenn dein Plattformteam über diese Kenntnisse verfügt, ist die erfolgreiche Entwicklung und der zuverlässige Betrieb der Plattform möglich.

Keep it simple, stupid! (KISS)

Komplexität ist dein Feind. Nicht der Mangel an CPU oder Tools lässt dich scheitern, sondern zu viel Komplexität und deine mangelnde Kontrolle darüber. Overengineering führt zur Schaffung überkomplexer Lösungen, die schwer zu verstehen und zu nutzen sind, unnötige Funktionen enthalten und zu langsam oder unzuverlässig arbeiten. Einfachere Lösungen reduzieren deinen Wartungsaufwand - und bieten den Nutzern zugleich Flexibilität, nehmen Rücksicht auf teamspezifische Bedürfnisse und versetzen Nutzer in die Lage, legitime Anpassungen vorzunehmen.