Systeme verbinden, die nie dafür gebaut wurden.
Zwei Systeme, die miteinander reden müssen, und niemand kann sagen, was dabei verlorengeht. Das ist das häufigste und das teuerste Problem in einer gewachsenen Landschaft — und es wird mit jedem Jahr teurer, in dem es niemand anfasst.
So klingt das Problem, bevor jemand es benennt.
-
01
„Wir wollen das Altsystem ablösen, aber niemand hat die vollständige Liste der Nachbarsysteme."
Der alte Code muss gelesen werden, und jede Verzweigung darin hat eine fachliche Konsequenz, die im neuen System wieder auftauchen muss. Diese Arbeit lässt sich nicht überspringen — sie lässt sich nur ordentlich oder unordentlich machen.
-
02
„Der Nachtbatch reicht nicht mehr."
Das Mengengerüst ist über das Verfahren hinausgewachsen. Bestände laufen auseinander, es wird überverkauft, und die Korrektur kostet mehr als die Umstellung.
-
03
„Die Daten dürfen das Land nicht verlassen, die Verarbeitung soll aber in die Cloud."
Beides gleichzeitig scheint sich auszuschließen. Tut es nicht — es verlagert die Frage nur an die Kante, an der gefiltert wird.
-
04
„Vor dem Umstieg steht die Angst."
Der Schnitt ist so groß geworden, dass niemand ihn mehr verantworten will. Und je länger gewartet wird, desto größer wird er. Die Antwort darauf ist kein mutigerer Termin, sondern ein Verfahren, das keinen Stichtag braucht.
-
05
„Die Modernisierung bedroht das Team."
Die Leute, die das Altsystem und die Fachdomäne beherrschen, beherrschen die neue Technik nicht. Sie zu ersetzen hieße, das Domänenwissen zu verlieren — also muss die Technik so gewählt werden, dass ein Quereinstieg in Wochen möglich ist.
-
06
„Ein Broker wurde eingeführt, aber niemand hat ihn zu Ende gedacht."
Schema-Evolution, Idempotenz und die Behandlung nicht zustellbarer Nachrichten fehlen. Jetzt gibt es Doppelbuchungen und stille Datenverluste — und stille Verluste sind die teureren.
Was dabei entsteht.
-
Anbindung von Schnittstelle zu Schnittstelle
REST, GraphQL, gRPC und SOAP-Altlasten. Einschließlich Authentifizierung, gegenseitiger TLS-Authentifizierung, Durchsatzbegrenzung und Vertragstests gegen das Nachbarsystem.
-
Eventgetriebene Architektur
Kafka, Pub/Sub, Solace, NATS und die Dienste der großen Anbieter. Topic-Schnitt, Schema-Evolution, Reihenfolgegarantien, Idempotenz, Wiederanlauf und die Behandlung nicht zustellbarer Nachrichten.
-
CQRS und Event Sourcing
Trennung von Schreib- und Lesemodell, Projektionen, Cursor- und Sequenzverwaltung, Rückspulen und Nachversorgung.
-
Change Data Capture
Datenbankänderungen als Ereignisstrom — ohne das Quellsystem anzufassen. Häufig der einzige Weg an ein System heran, das unter Änderungsstopp steht.
-
Schrittweise Ablösung im Parallelbetrieb
Beide Systeme werden gleichzeitig beschrieben, das Altsystem bleibt führend, umgeschaltet wird je Dienst über einen Schalter. Kein Stichtag, an dem alles auf einmal umfällt.
-
Migration von Punkt-zu-Punkt auf Ereignisströme
Aus n mal n Verbindungen wird ein Strom mit definierten Verträgen. Das ist weniger eine Technikfrage als eine Frage des richtigen Schnitts.
Abbildungsregeln sind der Paradefall für eine belastbare Spezifikation.
Jede Transformationsregel lässt sich als Beispiel aufschreiben: dieser Eingang, jener Ausgang, dieser Sonderfall. Damit ist der Umfang bestimmbar — und was bestimmbar ist, lässt sich vorab zusagen statt hinterher abrechnen.
Genau deshalb steht am Anfang eine Analyse und nicht ein Angebot aus dem Bauch. Was dabei entsteht, gehört Ihnen — auch dann, wenn Sie danach jemand anderen beauftragen.
Ein Anruf reicht, um zu klären, ob es passt.
Kein Formular mit zwölf Pflichtfeldern, keine Rückrufkette über einen Vertrieb. Sie schildern den Fall, wir sagen Ihnen, ob wir der Richtige dafür sind — auch dann, wenn die Antwort nein lautet.