Automotive / Connected Services
LISAweb
Test-Datenplattform für Connected Car bei Volkswagen
In fünf Monaten haben wir LISAweb vom Schmerzpunkt zur produktiven OEM-Plattform gebracht. Über drei Jahre haben wir die Plattform betrieben, weiterentwickelt und alle Konzernmarken bedient. Im Februar 2022 erfolgte die kontrollierte Übergabe an einen Folge-Dienstleister, der LISAweb seither weiterführt.
Zeitraum
2018 - 2022
Rolle
Konzept, Entwicklung, Betrieb
Stack
8 Komponenten
Ausgangslage
Vom Schmerzpunkt zur Plattform
LISAweb hat eine Vorgeschichte. Die Plattform entstand nicht aus dem Nichts, sondern aus mehreren Jahren wachsender Reibung in einem real existierenden Prozess.
Phase 1 (ab 2013). Test-VINs wurden manuell durch eine andere Fachabteilung im Host-System für Fahrzeugdaten angelegt. Die Kommunikation zwischen Tester und Datenpfleger lief über Excel-Tabellen, jede Anfrage ein eigener Bearbeitungsvorgang.
Phase 2 (ab 2016, rund zwei Jahre vor LISAweb). Ein gekauftes System für API-Tests wurde zweckentfremdet, um Testdaten zentral abzulegen. Betrieb und Datenpflege übernahm tarienna. Die Kommunikation lief weiter über Excel-Tabellen, ergänzt um Skripte, die diese in JSON-Dokumente und API-Responses umwandelten.
Phase 3 (Herbst 2018). Der Testaufwand stieg. Testfahrzeuge wurden in großen Mengen gebraucht, Tester wollten sich selbst befähigen, und Drittsysteme sollten programmatisch angebunden werden. Die Excel-und-Skript-Lösung war an ihre Grenze gekommen. Das war der Zeitpunkt, eine eigene Plattform zu konzipieren.
Abgrenzung
Bisheriger Prozess vs. LISAweb
LISAweb trennt klar zwischen zwei Datenpflege-Kanälen: Personen pflegen ausschließlich über die Web-Oberfläche, Drittsysteme ausschließlich über die Public REST-API. Damit decken wir sowohl die manuelle Pflege durch Tester als auch die programmatische Datenkonsistenz über mehrere Testsysteme hinweg sauber ab.
| Bisheriger Prozess | LISAweb |
|---|---|
| Test-VINs manuell durch eine andere Abteilung | Tester pflegen über Web-UI, Drittsysteme über Public REST-API |
| Excel-Tabellen als Kommunikationsmittel | Excel-Import in der Web-UI, asynchrone Operationen über die API |
| Tagesweise Bereitstellung pro Anfrage | Massendaten in Sekunden, asynchrone Operationen |
| Einzeldienst-Anbindung | 16 Mandanten parallel mit Projekt-Isolation |
| Kein Anschluss an den konzernweiten Service Bus | SOAP-Integration in den konzernweiten Service Bus |
| Keine Schutzmechanismen gegen reale Kunden-VINs | X-GDPR-Header und Prozesskontrollen |
Anwendungsfall
SIM-Karte und Fahrzeug systemübergreifend konsistent
Testdaten existieren selten nur in einem System. Für End-to-End-Tests müssen sie über mehrere Testsysteme hinweg konsistent sein. Ein Testdatenmanagement pflegt diese Konsistenz aktiv und schreibt die jeweiligen Anteile in die entsprechenden Zielsysteme. LISAweb ist eines davon.
- 1.Das Testdatenmanagement definiert eine Test-SIM-Karte im Testsystem des Mobilfunkanbieters und aktiviert sie dort.
- 2.Anschließend hinterlegt es per LISAweb Public-API die zugehörige IMEI am Fahrzeug, das diese SIM-Karte nutzen soll.
- 3.SIM-Karte und Fahrzeug sind jetzt systemübergreifend konsistent verknüpft und für End-to-End-Tests einsatzbereit.
Vorgehen
Vier Phasen über vier Jahre
Greenfield & Architektur
Konzeptphase Herbst 2018. Entscheidung für einen JHipster-Starter, Spring Boot Backend und Angular Frontend. MySQL für Transaktionsdaten, Elasticsearch für VIN- und Volltext-Suche. Liquibase für reproduzierbare Schema-Migrationen.
MVP & Go-Live
Produktivstart am 12. Februar 2019, fünf Monate nach Projektstart. Erstrelease mit Excel-Import, VIN-Verwaltung, PR-Nummern, SIM-Karten-Daten und SOAP-Schnittstelle für den Service Bus. Multi-Tenant-Modell mit Rollen USER und PROJECT_ADMIN.
Public API & Multi-Brand
Releases 1.3 bis 1.5. Öffentliche REST-API mit x-api-key-Header, asynchrone Operationen mit Webhook-Rückmeldung, RVS-Notification an den Integration Layer, markenspezifische VIN-Vorgaben für alle Konzernbrands. Java-Upgrade von 8 auf 11.
Skalierung, Sicherheit & Übergabe
Release 1.6.x. Marktspezifischer RVS-Versand (MOD3 Canada, IFA, SA02, SA08), Baugruppen-Verwaltung, mehrsprachige Beschreibungen. Schnelle Log4Shell-Reaktion mit Elasticsearch-Patch. Februar 2022: geordnete Übergabe an den Folge-Dienstleister.
Architektur
Web-UI, REST und SOAP auf einem Backbone
Eine Anwendung, drei Eingangskanäle. Die Web-Oberfläche für Tester, eine öffentliche REST-API für Drittsysteme und eine SOAP-Schnittstelle für den konzernweiten Service Bus teilen sich denselben Business-Layer.
Tech-Stack
Schlüsselentscheidungen
JHipster als Starter für ein realistisches 5-Monats-MVP
Auth, Audit, Liquibase-Migrationen, REST-Layer, Webpack-Build und Test-Setup kamen aus einer Hand. Statt Wochen für Boilerplate flossen die ersten Sprints direkt in fachliche Funktionen.
Java + Angular statt JavaScript-Mono-Stack
Typsicherheit über die volle Vertikale. Eine Großanwendung mit zwölf Marken, zahlreichen Validierungsregeln und Audit-Anforderungen profitiert von Compile-Time-Garantien stärker als von kurzen Bootzeiten.
REST und SOAP parallel betrieben
Die Drittsysteme bekamen REST mit x-api-key und Swagger-Doku. Der konzernweite Service Bus erwartet SOAP mit WSDL2Java-generierten Stubs. Beide Welten existieren parallel im gleichen Backend, ohne dass eine die andere verbiegt.
Public-API-Modell vom internen Domain-Modell getrennt
ViewModels für die Public API, MapStruct-Mapping zur Domain. Damit lassen sich öffentliche Verträge stabil halten, ohne die innere Datenstruktur einzufrieren. Versionskonflikte mit Drittsystemen werden vorhersehbar.
MySQL für Daten, Elasticsearch für Suche
Transaktionale Konsistenz für VIN-Anlage und PR-Nummern, Volltext-Suche für Tester, die nach Teil-VINs oder Modellcodes suchen. Beide Stores synchron gehalten, das richtige Werkzeug an der richtigen Stelle.
AWS-Build, On-Prem-Deployment
Build und Test auf AWS CodeBuild mit klarem Container-Output, das Deployment landet anschließend in der Volkswagen-Infrastruktur. Cloud-Vorteile beim CI/CD ohne Kompromisse beim Zielsystem.
API-Keys pro Mandant statt globaler Schlüssel
Sechzehn Mandanten als parallel datenpflegende Systeme. Jeder bekommt seinen eigenen API-Key, Aktionen werden eindeutig zugeordnet, Rotation pro Mandant möglich.
DSGVO-Schutz als Pflicht-Header
Ein X-GDPR-Header garantiert auf Schnittstellenebene, dass keine realen Kundenfahrzeuge angelegt werden. Schutz an der Eintrittstür, nicht erst in der Auswertung.
Liquibase für Schema-Migrationen
Reproduzierbare Datenmodell-Änderungen über mehrere Jahre und über alle Stages hinweg. Schema-Updates werden Teil des Codes und Teil der Code-Reviews.
Funktionen
Was LISAweb für VW gemacht hat
Im Kern war LISAweb Test-Datenverwaltung. In der Breite war es ein Werkzeug, das die gesamte Pipeline von der VIN-Anlage bis zum RVS-Versand an den Service Bus abgedeckt hat.
VIN-Verwaltung
Anlegen, kopieren, bearbeiten, löschen von Test-Fahrzeugen. Massenoperationen, Excel-Import und SOAP-Response-Import aus dem Host-System. Hoher sechsstelliger VIN-Bestand wurde durchgehend verwaltet.
PR-Nummern & Familien
Verwaltung der Primär-Eigenschaften (PR-Nummern wie NAV, ONL, TPL) und ihrer Familien. Sichtbar pro Fahrzeug und projektübergreifend pflegbar.
Baugruppen & SIM-Karten
Pflege von IMEI, ICCID und eUICCID für Gateway, Emergency-Modul und OCU. Daten werden über die Service-Bus-Schnittstelle an Konsumenten ausgeliefert.
RVS-Versand
Markt- und mode-spezifischer RVS-Versand: MOD3 Canada, IFA, SA02, SA08. Asynchrone Operationen mit Webhook-Rückmeldung an den Aufrufer.
Multi-Brand-Vorgaben
Konfigurierbar pro Konzernmarke. Alle Brands abgedeckt: VW, Audi, Skoda, Seat, Bentley, Porsche, weitere Konzernmarken inklusive.
Public REST API
API-Key-Auth, Swagger-Dokumentation, asynchrone Operationen, VIN-Status und Metadaten setzen, mehrere Versionen parallel. Zwei Konsumenten produktiv angebunden.
Sicherheit & Compliance
DSGVO und Konzern-Compliance von Anfang an
Daten & Zugriff
- X-GDPR-Header als Pflichtfeld verhindert die Anlage realer Kunden-VINs
- API-Key-Management pro Mandant, eindeutige Zuordnung jeder Aktion
- Rollenmodell USER (Lesen), PROJECT_ADMIN (Schreiben), ADMIN (System)
- Projekt-ACL trennt die sechzehn Mandanten sauber voneinander
- Vollständiges Audit-Log über alle schreibenden Operationen
Definition of Done
- Jede User-Story enthält einen expliziten Punkt 'geprüft nach DSGVO'
- Jede User-Story enthält einen expliziten Punkt 'geprüft nach Volkswagen Compliance'
- Dokumentation auf aktuellem Stand ist Teil der Done-Definition, nicht der Folgesprint-Inhalt
Application Security Testing
- Static Application Security Testing (SAST) mit SonarQube und HotSpots
- Software Composition Analysis (SCA) mit OWASP Dependency Track, regelmäßige Ausführung
- Dynamic Application Security Testing (DAST) durch Volkswagen-PenTests
- Architektur-Regeln per ArchUnit als ausführbare Tests im Build
Log4Shell-Reaktion (CVE-2021-44228)
Die Schwachstelle wurde im Dezember 2021 öffentlich. Unsere Reaktion: Elasticsearch wurde unmittelbar auf eine gepatchte Version aktualisiert, der Build neu gezogen und die Produktivumgebung kurzfristig nachgezogen. Software Composition Analysis liefert den Mehrwert genau in solchen Momenten, in denen schnell sichtbar sein muss, ob und wo eine kritische Abhängigkeit im Stack vorhanden ist.
Betrieb & Skalierung
Drei Jahre produktiver Betrieb
- ✓Auslieferung im 14-Tage-Sprint-Rhythmus statt klassischer Versions-Releases (Scrum)
- ✓Hoher sechsstelliger Test-VIN-Bestand kontinuierlich verwaltet
- ✓16 Mandanten parallel als datenpflegende Systeme
- ✓2 API-Konsumenten produktiv über die Public REST API angebunden
- ✓Alle Konzernmarken abgedeckt: VW, Audi, Skoda, Seat, Bentley, Porsche und weitere
- ✓24/7-Betrieb, Support 9-17 Uhr Mo-Fr
- ✓Antwortzeit unter 5 Sekunden bei bis zu 100 Spitzen-Anfragen pro Sekunde
- ✓1058 Commits über drei Jahre Entwicklungs- und Betriebsphase
Übergabe
Saubere Übergabe statt offenes Ende
Im Februar 2022 haben wir LISAweb kontrolliert an einen Folge-Dienstleister übergeben. Eine saubere Code-Basis nach drei Jahren Sprintarbeit, Patterns konsistent durchgezogen, vollständige Dokumentation im Wiki, klar dokumentierte Schnittstellen und ein nachvollziehbares Release-Protokoll.
LISAweb läuft seither bei Volkswagen weiter und wird vom Folge-Dienstleister weiterentwickelt. Genau so soll eine Übergabe aussehen: Der nächste Anbieter setzt auf vorhandene Strukturen auf, der Kunde merkt keinen Bruch im Betrieb, das Produkt entwickelt sich weiter.
Lessons Learned
Drei ehrliche Erkenntnisse
Erkenntnis 1
Vom Schmerzpunkt zur Plattform ist kein Big Bang.
Die Lösung entstand über zwei Vorgänger-Iterationen, manueller Excel-Prozess und gekauftes API-Test-System, nicht aus dem Nichts. Erst die wachsende Reibung machte den Geschäftsfall für eine eigene Plattform sichtbar. Eine neue Plattform braucht eine ehrliche Vorgeschichte, sonst sucht sie ihre Berechtigung im Nachhinein.
Erkenntnis 2
JHipster und konservativer Stack: in fünf Monaten produktiv.
Greenfield-Großanwendungen profitieren von etablierten Generatoren mehr als von experimentellen Architekturen. JHipster lieferte Auth, Audit, Liquibase-Migrationen, REST-Layer und Tests in einer konsistenten Vertikale. Die gewonnene Zeit floss in fachliche Funktionen statt in Boilerplate.
Erkenntnis 3
Saubere Übergabe ist Teil des Auftrags, nicht das Ende.
Ein OEM-Projekt mit Folge-Dienstleister braucht Patterns, die jemand anders weiterentwickeln kann. Diese Haltung muss von Anfang an in Code-Qualität, Dokumentation und Definition of Done verankert sein. Die Plattform endet nicht mit dem letzten Commit, sondern wird übergeben.
Auch dein Prozess braucht eine Plattform?
Wir bauen mit dir die Plattform, die deine wachsende Reibung auflöst, und liefern sie übergabereif.