Entwicklung eines Features als Whitelabel-Komponente für verschiedene Kunden

Bei Softwareprojekten, die im Rahmen eines einzelnen Kunden oder einer Marke entwickelt werden, werden Features meist eindeutig für beispielsweise eine App oder Webseite umgesetzt. Die Entwicklung kann dabei entlang der durch den Kunden und das Projekt aufgestellten Rahmenbedingungen erfolgen.

Was ist jedoch, wenn ein Projekt mehrere Kunden umfasst und die Entwicklung eines Features vorsieht, das in mehrere Apps integriert werden soll? Dies können sowohl bestehende als auch neue Apps sein. Jeder Kunde hat eigene Vorstellungen, wie das Feature integriert werden soll oder wie es auszusehen hat. Auch können technische Anforderungen bestehen, da bestimmte kundeneigene Systeme angebunden werden müssen.

Im Folgenden wollen wir die Herausforderungen und einen erarbeiteten Lösungsansatz für die Umsetzung eines derartigen und kürzlich bei Cap3 durchgeführten Projektes näher betrachten.

Projektbeschreibung

Ziel des Projektes war es, ein Feature im Bereich des Gesundheitswesens in eine bestehende App eines Kunden zu integrieren sowie als eigenständige App für verschiedene andere Kunden zu entwickeln. Die Apps nutzen dabei das gleiche technologische Grundgerüst. Neben den rein technischen Anforderungen der Funktionalität wurden im Laufe des Projekts auch die unterschiedlichsten Anforderungen im Bereich UX/UI formuliert. Für die Entwicklung musste also beispielsweise nicht nur die Anbindung verschiedener individueller Schnittstellen ermöglicht werden, sondern auch die unterschiedlichsten Kundenwünsche an die visuelle Aufbereitung des Features eingearbeitet werden. Insgesamt ergaben sich somit eine Reihe von projektspezifischen Anforderungen für die Umsetzung der Funktionalität, die auf die Beteiligung der verschiedenen Kunden zurückzuführen ist:

• CI (Farben, Schriften, Icons, Animationen, usw.) für jeden Kunden konfigurierbar.
• Texte für jeden Kunden individuell anpassbar.
• Anbindung von kundenspezifischen Schnittstellen.
• Optionale zusätzliche Teil-Features je Kunden müssen möglich sein.
• Unterschiedliche Einstiegspunkte in das Feature (Tab bei bestehender App bzw. eigenständige App).

Die Liste ist nicht vollständig, liefert aber bereits einen Einblick über die diversen Anforderungen des Projekts.

Vorangegangener Ansatz

In der Vergangenheit wurde bereits ein Projekt mit ähnlichem Umfang und Anforderungen bei Cap3 durchgeführt. Entwickelt wurde auch hier ein Feature für eine bestehende App und für einige Kunden als separate App. Die Umsetzung erfolgte zunächst als Whitelabel-App in einem eigenen Repository. Im weiteren Projektverlauf wurde dieses Repository dann für die einzelnen Kunden-Apps geklont und um die jeweiligen kundenspezifischen Anpassungen ergänzt. Für einen weiteren Kunden wurden wesentliche Bestandteile, die das zu entwickelnde Feature beschreiben, in die bereits bestehende App kopiert und übernommen.

Ab diesem Moment ergab sich jedoch eine Schwierigkeit, da die Entwicklung in der Whitelabel-App noch nicht abgeschlossen war. Die Kunden-Apps mussten also regelmäßig mit der WL-App synchronisiert werden, was fehleranfällig und mit Aufwand verbunden war. Weiterhin mussten auch die einzelnen Änderungen in den Repositories der Kunden-Apps zwischen diesen synchronisiert werden, damit alle Apps den gleichen Stand aufweisen.

Die folgende Grafik stellt den gewählten Ansatz dar und lässt den Mehraufwand durch die Synchronisation zwischen den einzelnen Apps erkennen.

Ein großer Vorteil dieses Ansatzes ist, dass Wünsche und Anforderungen einzelner Kunden leichter in den Apps realisiert werden können, ohne dass diese zwingend mit den anderen Kunden abgestimmt werden müssen. Ein weiterer positiver Aspekt ist die strukturelle Trennung der einzelnen Repositories. Dies verhindert, dass sich eventuelle Fehlkonfigurationen automatisch auf andere Kunden auswirken.

Gleichzeitig wird allerdings die Komplexität erhöht, die in einem kleinen Team schnell zu einem Problem wird und somit die Vorteile überwiegt. Aus den gesammelten Erfahrungen und weiteren Überlegungen im Team wurde schließlich ein neuer Ansatz erarbeitet, der es uns ermöglichte, Komplexität zu reduzieren sowie Synchronisationsprobleme zu vermeiden.

Modulbasierter Ansatz

Zentraler Bestandteil des neuen Ansatzes ist ein Modul, welches das zu entwickelnde Feature bereitstellt. Es bietet zudem alle Konfigurationsoptionen, wie beispielsweise für Farben, Schriften und Texte, die für die Integration für die einzelnen Kunden relevant sind. Das Modul stellt das Feature zum einen als komplette App bereit, zum anderen ist aber auch eine Teilintegration in eine bestehende App möglich. Innerhalb des Moduls findet die gesamte Entwicklung statt. Das Modul ist versioniert und kann über einen Paketmanager leicht in eine App integriert werden.

Für die Integration des Features in die bestehende App des einen Kunden kann das Modul an einem bestimmten Punkt in der bestehenden Navigation eingehängt werden. Für die anderen Kunden wird das Modul als vollständige Navigation in eine Whitelabel-App eingebunden. Diese Whitelabel-App beinhaltet alle Konfigurationen der entsprechenden Kunden sowie eine Variante der App zu Demonstrationszwecken. Die Bereitstellung der App für einen Kunden kann mit einem Klick erfolgen.

Die Vorteile dieses Ansatzes liegen auf der Hand. Änderungen und Anpassungen sind an einer zentralen Stelle möglich. Weiterhin ist sichergestellt, dass alle Apps aus der gleichen Codebasis gebaut werden und Änderungen somit für alle Kunden automatisch bereitstehen. Die Entwicklung ist zudem deutlich weniger komplex und wartungsärmer.

Da die Entwicklung jedoch an einer zentralen Stelle stattfindet, müssen Änderungen gut kommuniziert und abgesprochen werden. Eine wichtige Voraussetzung für diesen Ansatz ist daher, dass der grundsätzliche Aufbau des Features möglichst einheitlich ist. Jede Ergänzung oder Abweichung für einzelnen Kunden sollte genauestens begründet und abgewägt werden, um eine Verkomplizierung des Moduls zu minimieren und eventuelle Auswirkungen auf bestehende Funktionen und Anpassungen für einzelne Kunden zu unterbinden.