Plattformen: Funktionale Synergie (ohne ausufernde Generik)

Software Plattform != Generik !

Sobald das Wort „Plattform“ in Entscheiderkreisen fällt, ist die Angst vor ausufernden Aufwänden in vielen Gesichtern abzulesen. Zu Unrecht, denn diese Angst basiert auf einer falschen Annahme. Und zwar, dass „Plattform“ automatisch Generik bedeutet und diese bekannterweise teuer ist. Herkunft dieser Annahme ist, dass zu Projektstart wenig über die Anforderungen bekannt ist, und somit jeder denkbare Fall versucht wird vorzusehen. Das produziert Aufwand und stellt dennoch nicht sicher, dass ein Produkt auf Basis der Software Plattform auch wirklich den benötigten Handlungsspielraum hat.

Die eigentliche Aufgabe: Die richtige Modularisierung

Der häufige Fauxpas bei Plattformprojekten liegt darin, dass ein Plattform-Projekt nicht mit dem Plattform-Konzept beginnt, sondern direkt mit einzelnen konkreten Anforderungen und Use-Cases.

Es geht im ersten Schritt um Anforderungsarten statt konkrete einzelne Anforderungen

Statt dessen braucht es – trotz aller Agilität – einen breiten Blick auf später abzubildende Produkte und dabei vor allem auf Arten von Anforderungen.

Zentrale Fragen:

• Welche Bausteine sind in den Anwendungen anatomisch ähnlich?
• Welche sind architektonisch ähnlich aufgebaut?
• Welche haben ähnliche Datenstrukturen?
• Welche ähnlichen Aspekte können per vorzusehende Erweiterungsmodule flexibel gestaltet werden?

Typische Beispiele für Software Plattform Features

Beispiel Such-Module: In jeder Anwendungen gibt es irgendwo eine Suche. Eine solche könnte beispielweise so konzipiert werden, dass die Suche immer gegen ein zentrales API Gateway geht. Flexible Such-Module könnten dann nachrüstbar sein, so dass viele Use Cases abbildbar werden, dennoch die eigentliche Query zentralisiert ist.

Beispiel Gesamt-Navigation: Auch wenn Use Cases sehr heterogen sein mögen: Der Weg zu den Use Cases könnte immer ähnlich sein. So kann ein zentrales Dashboard mit einem zentralen Aufgabenmanagement zu einzelnen Anwendungsteilen navigieren.

Beispiel Anreicherung: Datensätze werden häufig um Informationen ergänzt. Zum Beispiel in Form von Kommentaren oder Anhängen. Solchen Funktionalitäten könnte es – technisch gesehen – egal sein, an welchem Datenobjekt sie hängen! Eine Kommentar-Funktion einmal als sauber isoliertes Micro-Frontend implementiert, und schon kann es überall ohne viel Aufwand genutzt werden. Aus Plattform-Perspektive könnte diese Art der Anforderung – nennen wir sie „Anreicherung“ – auch erweiterbar konzipiert werden. Sobald ein Produkt auf Basis der Plattform eine neue Form der Anreicherung benötigt (Wie wäre es mit Labels? Oder mit Favoriten?), könnte sie nach Definition nachgerüstet werden.

Grenzen kennen und akzeptieren

Bei der Konzeption von Plattformen geht also weder um umfassende und teure Flexibilität und Generik, noch um harte Vorgaben die die Qualität der kommenden Produkte schmälert.

Es geht um die genau passende Erweiterbarkeit.

Jenseits dieser Erweiterbarkeit muss dann im Projektverlauf sehr genau hingeschaut werden, ob eine kollidierende Anforderung wirklich wichtige neue Erkenntnisse und Änderungen der Architektur provozieren sollte, oder ob es nicht doch eine Anforderung aus der Richtung „Aber das haben wir doch schon immer so gemacht!“ ist. Oft hilft ein mutiger Blick von außen…!