Systeme, die endlich
miteinander reden
APIs, Datenflüsse, Cloud und Legacy-Migration. Wir verbinden, was über Jahre nebeneinander gewachsen ist — in Etappen statt an einem Stichtag, und ohne dass der Betrieb dafür stillsteht.
Systemarchitektur &
API-Integration
- API-Entwicklung
- Schnittstellen & Datenflüsse
- Legacy-Migration
- Cloud & Kubernetes
- Event-Streaming
- Domain-Driven Design
Wir verbinden Systeme, die über Jahre nebeneinander gewachsen sind: ERP, CRM, PIM, Lagerverwaltung und die Altdatenbank, die niemand mehr anfassen will. API-Entwicklung und Systemintegration sind dabei selten das eigentliche Problem — die Arbeit steckt in der Frage, welches System bei welchem Datum recht hat.
Wir schneiden Domänen nach Domain-Driven Design, legen für jedes Feld ein führendes System fest und bauen die Strecke dazwischen: API-Gateway, Warteschlange, Transformation, Protokoll und Wiederanlauf. Betrieben wird auf Docker und Kubernetes, mit Terraform beschrieben und mit Event-Streaming dort, wo Systeme nicht aufeinander warten dürfen.
Die Legacy-Migration läuft in Etappen statt an einem Stichtag. Alt und neu laufen parallel, wir schalten Bereich für Bereich um, und der Rückweg bleibt bis zuletzt offen. Ein Wochenende, an dem alles gleichzeitig kippen kann, kommt in unseren Plänen nicht vor.
Woran es meistens hakt
-
Jedes System hat seine eigene Wahrheit
Die Kundennummer steht im ERP, im CRM und im Shop — dreimal unterschiedlich. Niemand weiß, welche gilt.
-
Nachts läuft ein Skript, das niemand kennt
Der Datenabgleich hängt an einer Datei auf einem Server, den seit Jahren keiner angefasst hat.
-
Die Migration wurde dreimal verschoben
Weil sie als Stichtag geplant ist. Und ein Stichtag, an dem alles gleichzeitig umzieht, verschiebt sich immer.
-
Ein Ausfall, und keiner weiß wo
Die Bestellung ist weg. Ob im Shop, in der Warteschlange oder im ERP, sagt euch niemand.
Was wir dagegen tun
-
Eine Quelle pro Datum
Für jedes Feld wird festgelegt, welches System führt. Der Rest liest, schreibt aber nicht. Das ist die halbe Arbeit.
-
Sichtbare Strecken statt Skripte
Jeder Übergang läuft über eine dokumentierte Schnittstelle mit Protokoll, Wiederholung und Alarm.
-
In Etappen umziehen
Alt und neu laufen parallel, wir schalten Bereich für Bereich um. Zurück geht jederzeit.
-
Jede Nachricht hat eine Spur
Eine Bestellung lässt sich vom Warenkorb bis zur Buchung im ERP nachverfolgen — mit einer ID, nicht mit Vermutungen.
Wo eure Daten herkommen — und wo sie hinsollen.
-
Quellen
- ERP
- CRM
- Lagerverwaltung
- Altdatenbank
- Lieferanten-Feeds
Was schon da ist. Meistens vier bis zehn Systeme, von denen zwei nicht dokumentiert sind.
-
Strecke
- API-Gateway
- Warteschlange
- Transformation
- Protokoll
- Wiederanlauf
Die Schicht, die es vorher nicht gab: ein Ort, an dem Formate übersetzt, Fehler wiederholt und Vorgänge protokolliert werden.
-
Ziele
- Shop
- Kundenportal
- Außendienst-App
- Auswertung
- Partner
Was neu dazukommt, ohne dass die Quellen davon wissen müssen. Ein weiteres Ziel kostet danach Tage, nicht Monate.
Der Aufwand liegt selten in der Schnittstelle selbst, sondern in der Frage, welches System recht hat. Die klären wir zuerst — schriftlich.
Wie so etwas in echt aussieht.
Quellen — was schon da ist
- ERP
- CRM
- PIM
- Lagerverwaltung
- Altdatenbank
- Lieferanten-Feed
Die Schicht, die vorher fehlte
- API-Gateway
- Warteschlange
- Transformation
- Rechte
- Protokoll
- Wiederanlauf
Ziele — was dazukommen darf
- Shop
- Kundenportal
- Außendienst-App
- Partner-API
- Auswertung
- Rechnungslauf
Anonymisiert, aber nicht erfunden: so sieht die Landschaft in den meisten Häusern aus, mit denen wir arbeiten. Die Namen wechseln, die Struktur selten. Der Unterschied liegt in der mittleren Reihe — sie ist der Grund, warum ein weiteres Ziel danach Tage kostet und nicht Monate.
Was am Ende in eurer Hand liegt.
-
Integrationslandkarte
Jedes System, jede Strecke, jede Richtung auf einem Blatt. Auch für Leute lesbar, die nicht entwickeln.
-
Schnittstellen-Verträge
Was rein- und rausgeht, verbindlich beschrieben und versioniert. Änderungen brechen niemandem den Betrieb.
-
Migrationsplan in Etappen
Welcher Bereich wann umzieht, woran der Erfolg gemessen wird und wie der Rückweg aussieht.
-
Überwachte Strecken
Alarme auf Warteschlangenlänge, Fehlerquote und Verzögerung — nicht nur auf „Server läuft".
-
Wiederanlauf-Konzept
Was passiert, wenn ein Zielsystem zwei Stunden weg ist. Getestet, nicht angenommen.
-
Betriebshandbuch
Die Runbooks, mit denen auch jemand anderes nachts die richtige Entscheidung trifft.
Vier Phasen, immer in dieser Reihenfolge.
-
01
Aufnehmen
zuerst, immer
Systeme, Datenflüsse und die undokumentierten Skripte finden. Ergebnis: die Landkarte und eine Liste der Stellen, an denen es weh tun wird.
-
02
Verbinden
sobald die Landkarte steht
Die Strecke bauen, mit einer echten Schnittstelle anfangen — der riskantesten. Parallelbetrieb von Anfang an.
-
03
Umziehen
in Etappen
Bereich für Bereich umschalten, jeweils mit Messung davor und danach. Kein Wochenende, an dem alles auf einmal kippt.
-
04
Abschalten
am Ende
Das Alte geht vom Netz — erst dann, wenn 30 Tage lang nichts mehr dagegen gelaufen ist.
Drei Modelle, ehrlich beschrieben.
-
Festpreis
Für klar geschnittene Vorhaben
Wenn nach dem Klären alles steht, geht auch ein Festpreis. Bandbreite statt Wunschzahl, Nachträge nur bei echten Änderungen.
- Klar abgegrenzter Umfang
- Fester Termin
- Änderungen über Change Requests
-
Meistens die richtige Wahl
Zeit & Material
Der Regelfall
Ein festes Team für eine feste Kapazität. Ihr priorisiert alle zwei Wochen neu, wir liefern kontinuierlich.
- Feste Teamgröße
- Alle 14 Tage neu priorisieren
- Monatlich kündbar nach der Einarbeitung
-
Retainer
Für Betrieb und Weiterentwicklung
Feste Kapazität pro Monat für Wartung, Sicherheit und kleinere Ausbauten. Mit Reaktionszeiten, die im Vertrag stehen.
- Garantierte Reaktionszeit
- Rufbereitschaft optional
- Unverbrauchte Stunden verfallen nicht sofort
-
Fast nie. In den meisten Fällen bleibt das ERP genau da, wo es ist — es bekommt nur endlich eine saubere Schnittstelle. Ablösen ist teuer und selten die Ursache des Problems.
-
Alt und neu laufen eine Zeit lang parallel. Wir schalten pro Bereich um, messen, und schalten zurück, wenn etwas nicht stimmt. Ein Stichtag, an dem alles kippen kann, kommt in unseren Plänen nicht vor.
-
Dann bauen wir eine davor. Datenbank-Sicht, Dateiimport, im Zweifel ein Adapter, der die Oberfläche bedient — unschön, aber sichtbar und überwacht statt versteckt im Cronjob.
-
Was zu euren Anforderungen passt. Wir bauen so, dass der Betriebsort eine Entscheidung bleibt und keine Einbahnstraße — auch weil die Antwort in fünf Jahren eine andere sein kann.
-
Ja. Ein Review mit Landkarte, Risikoliste und Empfehlung. Oft der Abschnitt mit dem besten Verhältnis von Aufwand zu Erkenntnis.
Was in solchen Vorhaben meistens danebensteht.
-
Digitale Produkte
Ein Portal ist schnell gebaut und lange in Benutzung. Wer es entwirft, sollte wissen, wer es danach bedient.
-
E-Commerce
Ein Shop ist der sichtbare Teil. Der unsichtbare ist die Frage, welches System beim Preis recht hat.
-
Webhosting & Betrieb
Was gebaut wird, läuft danach jahrelang. Wer den Pager trägt, gehört deshalb früh an den Tisch.
Zeig uns eure Systemlandschaft
15 Minuten, ohne Verkaufsdeck. Danach weißt du, ob sich der Aufwand lohnt — und womit man anfangen sollte.