Migration

Warnzeichen, dass Sie an ein proprietäres Format gebunden sind

Ein Lock-in entsteht selten durch eine einzelne Entscheidung. Er wächst allmählich, eine bequeme Abkürzung nach der anderen, bis eine Codebasis, die als vernünftige Integration mit einem Anbieter begann, still und leise kaum noch von diesem Anbieter zu trennen ist. Einige konkrete Muster sollten Sie als Warnzeichen erkennen, denn jedes davon wirkt für sich genommen harmlos, wenn es entsteht.

Die genauen Feldnamen eines Anbieters werden in Ihrem gesamten eigenen Datenmodell verwendet. Wenn Ihr Datenbankschema, die Antworten Ihrer internen API und Ihr Frontend-Code alle die Feldbenennung eines bestimmten Anbieters verwenden, also formatted_address oder display_name oder wie auch immer dieser Anbieter es nennt, statt einer selbst gewählten Benennung, die einmal an der Schnittstelle übersetzt wird, dann hat jede Schicht Ihrer Anwendung eine Abhängigkeit von den Konventionen dieses einen Anbieters übernommen.

Anbieterspezifische Eigenheiten wurden in der Geschäftslogik umgangen, statt an der Integrationsgrenze isoliert zu werden. Wenn ein Workaround für eine bestimmte Eigenheit, wie ein Anbieter eine Randfall-Adresse formatiert, in der allgemeinen Geschäftslogik steckt statt in der schmalen Funktion, die mit diesem Anbieter kommuniziert, bedeutet eine Migration, diesen Workaround aus Code herauszusuchen und zu entwirren, der auf den ersten Blick nichts mit Geokodierung zu tun hat.

Niemand kann schnell sagen, an wie vielen Stellen der Codebasis der Anbieter namentlich referenziert wird. Wenn die Antwort auf die Frage „Wo hängen wir von diesem Anbieter ab?“ eine sorgfältige Prüfung erfordert statt einer schnellen und sicheren Antwort, ist diese Unsicherheit selbst ein Zeichen für Lock-in, denn sie bedeutet, dass sich die Abhängigkeit weiter ausgebreitet hat, als irgendjemand aktiv nachverfolgt.

Die spezifischen Objekttypen der Client-Bibliothek werden an anderer Stelle im Code als Funktionssignaturen verwendet. Wenn Funktionen, die nichts mit Geokodierung zu tun haben, den SDK-Antworttyp eines bestimmten Anbieters als Parameter akzeptieren, ist das Typsystem dieses Anbieters faktisch Teil des Typsystems Ihrer eigenen Anwendung geworden, und um es zu entfernen, müssen Sie jede Funktion anfassen, die darauf verweist, nicht nur den Geokodierungscode.

In all den Jahren, in denen die Integration in Betrieb ist, wurde nie eine Migration getestet, auch nicht teilweise. Eine Integration, die theoretisch zu einem anderen Anbieter wechseln könnte, aber nie tatsächlich mit einem getestet wurde, unterscheidet sich in der Praxis nicht wesentlich von einer, die überhaupt nicht wechseln kann, bis jemand es tatsächlich testet.

Keines dieser Muster ist für sich allein katastrophal, und die meisten Integrationen weisen mindestens eines davon auf, ohne dass es lange Zeit echte Folgen hat. Der Wert, sie zu erkennen, liegt darin, Lock-in zu einem bewussten, akzeptablen Kompromiss zu machen statt zu einem versehentlichen, den niemand gewählt hat. Manchmal ist die Bequemlichkeit die Kopplung wert, besonders bei einem kleinen Projekt, bei dem eine vollständige Migration mehr Entwicklungszeit kosten würde, als die Flexibilität wert ist. Problematisch wird es nur, wenn Lock-in unsichtbar entsteht und im schlechtesten Moment entdeckt wird, bei einer erzwungenen Migration unter Termindruck, statt vorher bewusst anerkannt und akzeptiert zu werden.

Wenn es für den Anbieter, von dem Sie derzeit abhängen, bereits einen Kompatibilitäts-Host gibt, ist ein Teil dieses Risikos von vornherein geringer, denn 17 Kompatibilitäts-Hosts bedeuten, dass mindestens ein wahrscheinlicher Migrationsweg überhaupt kein Entwirren von Lock-in auf Feldebene erfordert, sondern nur einen Wechsel von Host und Schlüssel. Das ist eine vernünftige Absicherung, selbst für eine Integration, bei der Sie keinen unmittelbaren Wechsel planen.