,

Das Spiel im Sandkasten

Um auf die Veränderungen am Markt reagieren zu können, müssen Produkte schnell, kostengünstig und perfekt auf die Kundenbedürfnisse zugeschnitten entwickelt werden. Ingo Küpper, Geschäftsführer von crossbuilders, erläutert die Funktionsweise einer Sandbox als Mittel für Innovationen.


Ingo Küpper, Geschäftsführer der crossbuilders GmbH
Ingo Küpper, Geschäftsführer der crossbuilders GmbH

BANKINGNEWS: Warum setzen immer mehr Unternehmen auf agile Methoden, die in der IT-Entwicklung schon lange etabliert sind?

Ingo Küpper: Wenn ich als Bank davon ausgehe, dass die durch den Kunden getriebene Veränderung alltäglich wird und die Welt sich schneller verändert als jemals zuvor, dann macht eine agile Organisation viel Sinn. Heute möchte ich nach zwei Jahren Entwicklungszeit nicht mehr nur hoffen, dass die Lösung beim Kunden ankommt, sondern asap mit einem MVP in eine Testphase mit dem Kunden gehen. Mit agilen Methoden und einer Sandbox als Infrastruktur-Ansatz kann ich die Komplexität der Entwicklungsarbeit reduzieren und Lösungen Stück für Stück mit deutlich verringerter Belastung der IT-Ressourcen entwickeln.

„Niemand kann vorhersehen, was der Kunde von morgen möchte“

Welche Idee steckt hinter einer Sandbox?

Das Arbeiten mit einer Sandbox kann man mit dem Spielen im Sandkasten vergleichen. Die Akteure können in einem abgeschlossenen Habitat z.B. Banking-Services erschaffen, ohne ihre produktive IT-Welt zu beeinflussen. Dabei nutzt man in der Sandbox ein Technologie-Stack und ein Set an wiederverwendbaren Grundfunktionen, die mit Blick auf die Entwicklungsarbeit möglichst einfach, schnell und dennoch hinreichend stabil und flexibel sind. Im Sandkasten verwendet man „Sand und Wasser“, d.h. das Technologie-Stack, und „Schaufel und Förmchen“, d.h. die Grundfunktionen und Werkzeuge. Als Sandkasten-Profi baut man damit ein Modell, das der Lösung in der echten Welt verblüffend ähnlich sieht. Und der Betrachter, also der Kunde, kann wertvolles Feedback geben, ob ihm der neue Service gefällt.

Warum ist eine Sandbox für Banken sinnvoll?

Informationstechnologie ist inzwischen Kern einer jeden Bankleistung. Kunden erwarten ständig neue und bessere Services. Dabei kann aber niemand genau vorhersagen, was der Kunde morgen tatsächlich möchte. Daher sollte eine Bank ihre neuen Ideen testen. Eine dazu passende IT-Entwicklung kann nur agil und flexibel erfolgen. Die Herausforderung dabei: Die heutigen IT-Strukturen einer Bank sind nicht darauf ausgelegt, einfach „mal etwas auszuprobieren“, ohne gleich einen zu hohen Aufwand und entsprechende Kosten zu produzieren. Gleichzeitig sind die erforderlichen Ressourcen dreifach ausgebucht oder durch Outsourcing gar nicht mehr vorhanden. Den Anforderungen eines sich immer schneller entwickelnden Marktes können sie damit nicht mehr gerecht werden.

„Eine Sandbox ist keine klassische Testumgebung“

Da es nicht die Lösung sein kann, vor neuen Ideen zurückzuschrecken und immer nur verspätet nachzubauen, was Wettbewerber erfolgreich eingeführt haben, empfehlen wir den Einsatz der Sandbox. Genauer bieten wir unseren Partnern sogar „externe Sandboxen“, die wir für sie betreiben und mit unseren Entwicklern schnell, flexibel und kostengünstig „bespielen“.

Was muss eine Bank bei der Einrichtung einer Sandbox beachten? 

Sinn macht eine Sandbox dann, wenn man eine schnelle, flexible und kostengünstige Entwicklung benötigt. Mit Hilfe der Sandbox sollen außerdem neue Services mit realen Kunden getestet werden. Die entsprechenden regulatorischen Rahmenbedingungen (z.B. Datenschutz und Datensicherheit) sind also einzuhalten. Vor diesem Hintergrund macht eine Sandbox als „One-off-Aktivität“ wenig Sinn. Gleichzeitig nutzt man die Sandbox oft nur über bestimmte Zeitperioden im Service-Testing. Ideal wären also eine ständige Verfügbarkeit, aber dennoch maßgeblich nur nutzungsabhängige Kosten. Cloud-Lösungen sind hierfür nach unseren Erfahrungen recht vielversprechend.

Für welche Zwecke bietet sich eine Sandbox an und für welche eher nicht?

Man sollte eine Sandbox nicht mit einer klassischen Testumgebung verwechseln, wie sie z.B. für die produktiven Banksysteme vorgehalten werden. Sie ist bewusst reduziert und bildet nicht die gesamte Komplexität der IT-Landschaft ab. Sie fokussiert sich auf ein Set von Funktionen, die für einen bestimmten Service benötigt werden. Und genau das stelle ich dem Kunden isoliert zum Test zur Verfügung. Verläuft der Kunden-Test erfolgreich und will ich dem Kunden den Service nun standardmäßig anbieten, dann ist dieser mal mit mehr, mal mit weniger Aufwand für die produktive Systemlandschaft zu realisieren. Auch wenn es mehr kosten sollte, weiß ich nun aber: Der Kunde wird’s lieben, es lohnt sich!