Plattform-Anteile vs. applikationsspezifischer Anteil

Der Anteil einer Plattform am Gesamtprodukt ist nicht festgelegt. Er lässt sich in einen plattform- und in einen applikationsspezifischen Anteil unterteilen. Die nachstehende Grafik verdeutlicht die verschiedenen Möglichkeiten. So kann ein Produkt aus Anteilen bestehen, die …

1.

… spezifisch für die Ausprägung des Produktes zu einer Plattform hinzugebaut werden. Sie sind somit nicht Bestandteil der Plattform. Diese applikationsspezifischen Anteile können wiederum default sein (immer für dieses Produkt notwendig), auf die jeweilige Ausprägung des Produktes anpassbar und damit konfigurierbar oder optional. In diesem Fall ist die Produktausprägung entweder vorhanden oder nicht vorhanden.

2.

… aus der Plattform geliefert werden, aber vom Applikationsprojekt auf die spezifische Ausprägung des Produktes angepasst werden müssen.

3.

… aus der Plattform geliefert werden, aber nur optional in dem Applikationsprojekt genutzt werden.

4.

… immer für alle aus der Plattform abgeleiteten Produkte gleich sind. Sie können unverändert eingesetzt werden.

Beschränkt man die Plattform auf die Core-Anteile, bleibt sie selbst zwar schlank, der verbleibende Aufwand in den Applikationsprojekten wird jedoch hoch. Applikationsprojekte sind dafür in der Lage, schneller zu reagieren. Sie müssen keine Wechselwirkungen mit anderen Projekten berücksichtigen, die die Plattform nutzen. Die Menge der wiederverwendbaren Bausteine wird allerdings eher klein bleiben.

Je höher die Reichweite der Plattform, …

Es ist daher ein guter Kompromiss, häufig benutzte Bausteine optional oder konfigurierbar aus der Plattform zu liefern, die «Exoten» aber vom Applikationsprojektteam entwickeln zu lassen.

Die Aufteilung in applikationsspezifische Anteile und Plattform-Anteile kann methodisch unterstützt werden, indem Bausteine, Funktionen oder Komponenten nach Attributen wie

• zeitliche Stabilität der technischen Lösung,
• Entwicklungsaufwand,
• technisches Risiko,
• Anzahl der Wiederverwendungen,
• Testaufwand,
• Nutzen einer Betriebsbewährtheit,
• existierende Zulassungen bewertet werden.

Die Komponenten mit hoher Wiederverwendbarkeit, technologischer Stabilität und hohem Test- oder Entwicklungsaufwand werden dann eher der Plattform zugeordnet. Weniger stabile oder wiederverwendete Komponenten hingegen belässt man eher in dem Applikationsprojekt.

Reichweite der Plattform

Die meisten Entwicklungsteams werden Elemente aus früheren Entwicklungsprojekten wiederverwenden. Es ist daher korrekt, hier von einer Plattform zu sprechen. Der dafür notwendige Dokumentationsaufwand ist gering, weil die Wiederverwendung durch Personen oder zumindest durch Teams erfolgt, die diese Plattform selbst entwickelt haben. Daher sind Projekte unter diesem Plattform-Aspekt zahlenmäßig auf die Kapazität dieser daran arbeitenden Personen beschränkt. Der Benefit einer Plattform-Lösung wird aber umso größer, wenn sie auch von anderen genutzt werden kann, die nicht an der Entwicklung der Plattform beteiligt waren. So ließen sich auch Teams anderer Standorte oder ganz anderer Produktlinien mit einbeziehen.

Diese größere Reichweite macht sich allerdings in höheren Plattform-Kosten bemerkbar. Sie entstehen durch den Mehraufwand an Dokumentation und Anwendungssupport. Es reicht in der Regel nicht aus, nur die Implementierung der Plattform an die Applikationsprojekte zu liefern. Eine Anwenderdokumentation bis hin zu einem Kick-Start-Support durch die Plattform-Spezialisten wird notwendig.

Bei einer Reichweite über das eigene Team hinaus muss besonders auf die Vermeidung des Phänomens «not invented here» geachtet werden. Wenn verschiedene Standorte eine gemeinsame Plattform nutzen, lohnt sich der Aufwand, alle Beteiligten an der Grundsteinlegung zu beteiligen. Es könnten auch Mitglieder der einzelnen Standorte in das Plattform- Team entsandt werden, selbst wenn das die Effizienz des Teams mindert. Doch ohne Akzeptanz an den Standorten ist der Nutzen einer noch so effizient entwickelten Plattform sehr gering.