Fallstudien

Als der Webshop bereit war, das Back-End aber nicht

Kurzprofil

Umsetzungskontext: Kundennahe Integrationsarbeit, fachlich geführt von Stefan innerhalb der Delivery-Organisation des ERP-Anbieters. Kunde: Skyline Access (deutsche Vermietgruppe für Hubarbeitsbühnen). Flottengröße: über 1.000 Maschinen an bundesweiten Standorten. Kernsystem: InterSystems-Caché-Datenbank für Vermietbestand, Wartungsfenster und Kundenaufträge. Projektdauer: 3 Monate (Architektur, Umsetzung und Go-live).

Die Herausforderung

Ein großer deutscher Vermieter hatte eine externe Webagentur mit dem Aufbau eines Online-Buchungsportals beauftragt. Das Projekt war weit fortgeschritten, Design und Nutzerführung funktionierten, ein Launch-Termin war fix. Was fehlte, war die Verbindung zum produktiven Vermiet-Back-End. Die Webagentur hatte den Shop isoliert entwickelt, ohne Sicht auf bestehende IT-Infrastruktur, Datenbankarchitektur und API-Anforderungen. Als diese Integrationsaufgabe bei Stefan landete, wurde klar: Integration war nicht nur vertagt, sie war nie belastbar spezifiziert worden.

Rahmenbedingungen

Termindruck: Zwischen Vermieter und Webagentur war bereits ein öffentlicher Launch-Termin zugesagt. Die Integration musste ohne Terminbruch gelöst werden.

Organisatorische Silos: Webagentur und interne IT arbeiteten unabhängig voneinander, ohne Vorab-Abstimmung zu Infrastruktur- oder Sicherheitsanforderungen.

Systemkomplexität: Die Caché-Datenbank verwaltete nicht nur Verfügbarkeiten, sondern auch Wartungsfenster, Maschinen-Gruppenersatz, Distanzlogik zum Einsatzort und überlappende Reservierungen. Eine scheinbar einfache Verfügbarkeitsprüfung erforderte Abfragen über mehrere voneinander abhängige Datenebenen.

Sicherheitsreife: Die interne IT hatte bislang weder öffentliche APIs exponiert noch DMZ-Strukturen betrieben. Zuerst musste ein belastbares Sicherheitsfundament geschaffen werden.

Vorgehen

Stefan moderierte einen Drei-Parteien-Workshop (interne IT, Webagentur und ERP-seitiges Delivery-Team), um die fehlende Integrationsschicht vollständig zu modellieren.

Infrastruktur-Assessment: Festgestellt wurde, dass weder öffentliche IP-Zuweisung noch DMZ-Topologie oder Firewall-Regeln für externe API-Exposition vorhanden waren. Stefan entwarf eine sichere Perimeter-Architektur mit dediziertem DMZ-Server für das CSP Gateway.
Firewall- und Netzwerk-Hardening: Gemeinsam mit der internen IT wurden Enterprise-Firewall-Regeln, notwendige TCP-Portfreigaben und Netzsegmentierung zwischen öffentlichem Gateway und internem Caché-System umgesetzt.
CSP-Gateway-Bereitstellung: Das InterSystems CSP Gateway wurde ausgerollt und abgesichert, um als HTTP-Brücke zwischen Webshop und Caché-Datenbank zu dienen.
REST-API-Design: Ein REST-Endpunkt für Maschinenverfügbarkeit wurde implementiert. Die API-Logik berücksichtigte Maschinen-Gruppenersatz, Wartungsfenster, Distanzfilterung zum Einsatzort und gegengeprüfte Reservierungsdaten, um bereits gebuchte Maschinen zuverlässig auszuschließen.
Datenqualitäts-Feedbackloop: Während der Tests zeigte der Webshop inkonsistente Verfügbarkeiten. Die Analyse legte Legacy-Datenfehler offen, etwa als verfügbar markierte Maschinen mit geplanter Wartung. Stefan verfolgte die Ursachen bis zu historischen Erfassungsfehlern zurück und ermöglichte gezielte Bereinigung.
Übergabe und Wissenstransfer: Die interne IT erhielt Training zu Firewall-Betrieb, DMZ-Härtung, API-Monitoring und Sicherheitsauswirkungen öffentlicher Dienste.

Lieferumfang

Sichere API-Infrastruktur: DMZ-gehostetes CSP Gateway mit REST-Endpunkt, gehärtet für öffentliche Erreichbarkeit
Verfügbarkeits-Logik-Engine: Mehrfaktorberechnung über Maschinen-Gruppen, Wartungsfenster, Distanz und Reservierungen
Firewall- und Netzwerksicherheitskonfiguration: Enterprise-Regeln, Portmanagement und Segmentierung
Operative Dokumentation und Training: interne IT für API-Betrieb, Sicherheitslage und Troubleshooting befähigt

Ergebnisse

Der Webshop ging nach drei Monaten Integrationsarbeit termingerecht live. Stefan übergab Infrastruktur und API-Komponenten an die aufnehmenden IT-Teams, die den laufenden Betrieb übernahmen. Auch ohne nachgelagerte Adoptionsmetriken wurde ein strategischer Vertriebskanal freigeschaltet, relevant für ein Unternehmen mit über 40 Standorten im wettbewerbsintensiven deutschen Markt für Hubarbeitsbühnenvermietung.

Warum es funktioniert hat

Frühe Intervention verhinderte teure Nacharbeit Die gemeinsame technische Klärung vor weiterer Implementierung verhinderte ein späteres Nachrüsten in inkompatible Architekturen.

Security-first-Design Der DMZ- und API-Layer wurde von Beginn an produktionsgerecht abgesichert. So wurde das typische Muster vermieden, erst unsicher zu starten und später mühsam nachzuhärten.

Domänenlogik im API-Back-End zentralisiert Die komplexe Verfügbarkeitslogik blieb serverseitig in der API statt im Webshop-Frontend. Dadurch blieb sie konsistent und für weitere Vertriebskanäle wiederverwendbar.

Datenqualität als positiver Nebeneffekt Die Integrationstests legten über Jahre angesammelte operative Datenfehler offen und machten das API-Projekt zugleich zu einer wirksamen Datenhygiene-Initiative.

Kontext der Umsetzung

Stefan arbeitete als technische Brücke zwischen Webagentur, internen Stakeholdern des Vermieters und der ERP-seitigen Delivery-Organisation. Nach Architektur und Umsetzung der Integrationsschicht wurden alle Assets sowie Betriebswissen an die aufnehmenden Teams übergeben, sodass Betrieb und Weiterentwicklung eigenständig möglich waren.