← Zurück zu Client Studies
Case Study

Eine Plattform. Jedes Ladeprodukt.

Wie Stackbox eine Dual-Layer-eMSP-Plattform gebaut hat, die OCPI-Protokolllogik und Produktschnittstellen sauber voneinander trennt – damit neue Charging Services in Tagen live gehen, nicht in Monaten. Wir haben die Architektur entworfen, die andere für unmöglich hielten.

Kunde MSP
Bereich Ladeprodukte
Produkt Custom Integration Service

Jedes Produkt baute OCPI von Grund auf neu.

MSPs, die neue Ladeprodukte – Abonnements, Rabatte, Kundenbindung – auf den Markt brachten, trugen jedes Mal dieselben versteckten Kosten: den kompletten Aufbau der OCPI-Integrationsschicht von null. Das ist kein Schicksal. Das ist ein Architekturproblem – und wir haben die Lösung.

Enge Kopplung

Da die OCPI-Logik im Produktcode lebte, erforderten selbst kleine Protokoll-Updates gleichzeitige Änderungen in jeder Schnittstelle. Eine einzige OCPI-Spec-Revision konnte drei Teams blockieren.

Langsame Time-to-Market

Neue Produktschnittstellen brauchten Monate, weil Entwickler zuerst den kompletten Protocol-Stack aufbauen und validieren mussten, bevor sie zur eigentlichen Produktlogik kamen. Das 80/20-Verhältnis zerstörte die Entwicklungsgeschwindigkeit.

Die eigentliche Ursache

MSP-Produktentwicklung vermischte zwei grundlegend verschiedene Probleme: die Implementierung eines Protokollstandards (OCPI) und den Aufbau von Produktschnittstellen. Ohne eine klare Architekturgrenze zwischen diesen Schichten zahlte jedes Produkt die vollen Infrastrukturkosten – und trug die volle Wartungslast. Das haben wir geändert.

Ein gemeinsamer OCPI-Kern. Unbegrenzte Produktschnittstellen.

Stackbox hat eine Dual-Layer-Plattformarchitektur entworfen, die eine harte Grenze zwischen dem OCPI-Protokollkern und allen produktorientierten Schnittstellen zieht – und jede Schicht unabhängig voneinander weiterentwickeln lässt. Einmal richtig gebaut, skaliert es ohne Mehraufwand.

1

OCPI-Kernschicht

Eine einzige, gehärtete OCPI-2.2.1-Implementierung übernimmt alle protokollseitigen Aufgaben: CDR-Ingestion und -Validierung, Token-Autorisierung, Session-Synchronisierung, Tarifverwaltung und Location-Feed-Verteilung. Kein Produktcode berührt das Protokoll direkt.

2

Interner Event-Bus

Der OCPI-Kern emittiert strukturierte Events für jede relevante Protokollaktion – Session-Start, CDR-Eingang, Token-Validierung. Produktschnittstellen abonnieren relevante Events, ohne zu pollen oder an Protokollinterna gekoppelt zu sein.

3

Produktschnittstellenschicht

Eigene Produkte und Partner-APIs werden als unabhängige Schnittstellen gebaut, die die interne API und den Event-Stream konsumieren. Jede Schnittstelle besitzt nur ihre Produktlogik – nichts sonst.

4

Extension-Pattern

Neue Produktschnittstellen folgen einem dokumentierten Extension-Pattern: Events abonnieren, interne API aufrufen, produktspezifische Oberfläche exponieren. Eine neue Schnittstelle geht von Konzept bis Produktion in Tagen live, nicht in Monaten.

Dual-Layer-Schnittstellenarchitektur

OCPI-Kernschicht
CDR-Verarbeitung Token-Auth Session-Sync Tarifverwaltung Location Feed
Produktschicht
Abonnements Performance Marketing PSP Integration

Integration

OCPI 2.2.1 REST API Webhooks OAuth2 Docker

Was sich für MSPs ändert.

Die Dual-Layer-Architektur eliminiert duplizierte Infrastrukturarbeit, beschleunigt deine Produktentwicklung und macht die Plattform resistent gegenüber OCPI-Spec-Änderungen. Weil wir wissen, wie man das richtig baut.

OCPI-Implementierung für alle Produkte geteilt – einmal gebaut und gewartet

Tage

bis eine neue Produktschnittstelle live ist – statt Monaten

Zero

Produktschnittstellen durch OCPI-Spec-Updates gebrochen – der Kern absorbiert alle Änderungen

N+

Produkte aus einem einzigen Plattform-Deployment bedient

Echtzeit

Session-Events an alle subscribierten Schnittstellen innerhalb von Sekunden geliefert

100%

Fokus auf individuelle Ladeprodukte – damit du dich im Markt abhebst

Vor Stackbox bedeutete jedes neue Produkt den Versuch, denselben OCPI-Stack für andere Zwecke zu nutzen. Jetzt existiert die Protokollschicht einfach – und unsere Teams konzentrieren sich vollständig auf das Produkt. Wir haben unsere Abonnements in drei Wochen gebaut. Vorher hätte das sechs Monate gedauert.

CTO, eMobility Service Provider · DACH-Region

Baust du ein MSP-Produkt?

Wir führen dich durch die Dual-Layer-Architektur und zeigen dir, wie dein Produkt passt – mit deinem OCPI-Setup, deinen Produktschnittstellen und deinen Zielmärkten.

Gespräch vereinbaren