Prof. Jan Bosch
Kürzlich nahm ich an einer Diskussion teil, die im Bereich der Automobilindustrie angesiedelt war. Irgendwann drehte sich das Gespräch um Plattformen. Nach einer Weile wurde mir klar, dass mehrere Definitionen von Plattformen durcheinandergeraten waren. Da ich seit den 1990er Jahren mit Plattformen arbeite, war es für mich sehr interessant zu sehen, wie sich der Begriff der Plattformen selbst entwickelt hat. Im Folgenden werde ich drei Arten diskutieren: Plattformen für die Wiederverwendung, für DevOps und für Ökosysteme.
Ursprünglich bestand die Hauptaufgabe von Plattformen darin, Standardfunktionen zwischen verschiedenen Produkten einer Produktlinie oder eines Portfolios gemeinsam zu nutzen, d.h. eine Plattform für die Wiederverwendung. Der Gedanke war, dass, wenn wir vermeiden könnten, dass jedes Produktteam immer wieder dieselbe Funktionalität entwickelt, dies eine höhere F&E-Effizienz ermöglichen würde, da die Produktteams an den produktspezifischen, differenzierenden Funktionen arbeiten könnten, während das Plattformteam alle Produktteams bedienen würde.
Nachdem ich fast 25 Jahre lang an Software-Produktlinien gearbeitet habe, ist mir klar, dass diese einfache Argumentation funktionieren kann, dass es aber viele Möglichkeiten gibt, die Vorteile von Plattformen zu vereiteln. Insbesondere die Koordinationskosten zwischen Plattform- und Produktteams und die unterschiedlichen Prioritäten zwischen ihnen können so viele Ineffizienzen verursachen, dass die Vorteile der Wiederverwendung von Funktionen leicht zunichte gemacht werden können.
Meine wichtigste Lektion über Plattformen für die Wiederverwendung ist, dass der Schwerpunkt nicht auf der (vermeintlichen) Effizienz, sondern auf der Geschwindigkeit liegen sollte. Produktteams sollten sich darauf konzentrieren, die Geschwindigkeit zu maximieren. Wenn eine Plattform dabei helfen kann, schneller zu arbeiten, dann sollten Sie unbedingt eine Plattform verwenden. Wenn die Nutzung der Plattform für die Produktteams optional ist, werden auch für das Plattformteam die richtigen Prioritäten gesetzt.
In den letzten Jahren haben sich die Bedeutung und die Verwendung von Plattformen durch die zunehmende Einführung der kontinuierlichen Bereitstellung von Software für Produkte in der Praxis verändert. Als die Produktsoftware vielleicht ein- oder zweimal im Jahr veröffentlicht wurde, war es durchaus möglich, einen erheblichen manuellen Aufwand für die Anpassung der neuesten Version der Plattformsoftware an ein bestimmtes Produkt und deren Integration in die neueste Version der produktspezifischen Software zu betreiben. Wenn jedoch die Häufigkeit der Veröffentlichungen zunimmt, wird der manuelle Aufwand nicht mehr machbar. Dies führt zu Plattformen für DevOps. Hier ist die Plattform die Obermenge der Funktionalität in allen Produkten und die Software für jedes Produkt wird automatisch durch die Konfiguration der Plattformsoftware abgeleitet.
Wenn es um Plattformen für DevOps geht, ist die größte Herausforderung, mit der Unternehmen meiner Erfahrung nach zu kämpfen haben, der Übergang von der Anpassung zur Konfiguration von Software. Vor allem in der Automobilindustrie neigen die OEMs dazu, alle möglichen Anpassungen zu verlangen, die, ehrlich gesagt, oft nur einen geringen geschäftlichen Nutzen bringen. Wenn es wirklich nicht möglich ist, Anpassungen in allen Kontexten zu vermeiden, sollte das Ziel sein, eine Schnittstelle zwischen der Plattform und der Anpassungssoftware zu definieren, die diese strikt voneinander trennt. Dies ermöglicht die unabhängige Weiterentwicklung der Plattformsoftware in Produkten, die in der Praxis eingesetzt werden.
'Many aspire to have an ecosystem platform but few have realized one'
Der dritte Typ, den viele anstreben, aber nur wenige realisiert haben, ist eine Ökosystem-Plattform, die Kunden, Partner und Dritte über eine Reihe von APIs erweitern können. Für ihre eigenen Zwecke, um Branchen zu bedienen, die vom Plattformanbieter nicht bedient werden, oder um Lösungen für ein breites Publikum anzubieten, die nicht von der Plattform abgedeckt werden. Jedes Unternehmen, mit dem ich zu tun habe, strebt danach, das iPhone seiner Branche anzubieten, aber die Umsetzung dieses Ziels ist in den meisten Fällen ein harter, schwieriger Kampf.
Das typische Spannungsverhältnis in Unternehmen, die eine Ökosystem-Plattform anbieten möchten, besteht zwischen dieser im Entstehen begriffenen Plattform und dem bestehenden Produktgeschäft. Ein Software-Ökosystem muss skalierbar sein, d.h. dieselben „Anwendungen“ müssen in einer möglichst breiten installierten Basis eingesetzt werden können. Dies erfordert, dass jedes Produkt im Portfolio die Standard-APIs des Ökosystems bereitstellt, was die Autonomie der Produktteams einschränkt. Außerdem konzentriert sich die vorherrschende Produktphilosophie darauf, so viele nützliche Funktionen wie möglich in das Produkt einzubauen, während eine Plattformphilosophie von uns verlangt, bestimmte Funktionsbereiche an das Ökosystem abzugeben, um sicherzustellen, dass Partner und Drittanbieter einen ausreichend attraktiven Business Case haben.
Plattformen sind großartig, aber Diskussionen werden leicht verwirrend, wenn verschiedene Plattformdefinitionen verwendet werden, ohne dass die Teilnehmer sich dessen bewusst sind. Ich habe versucht, hier etwas Struktur zu schaffen. Für die meisten Unternehmen, die DevOps einführen, ist die produktzentrierte Arbeitsweise nicht mehr machbar und stattdessen ist ein plattformzentrierter Ansatz erforderlich. Das hat große Vorteile, erfordert aber eine sorgfältige Strategie und Arbeitsweise, da es auf dem Weg dorthin einige Fallstricke gibt.
auf dem Laufenden halten
Erhalten Sie unsere monatlichen Updates
