Hauptgedanke

Eine Funktion braucht eine neue Spalte in der Datenbank. Wenn die Datenbank beim Kunden liegt und jedes Deployment verlangt, seinem Team eine Anleitung zu schicken, auf eine Freigabe zu warten, ein Wartungsfenster zu reservieren und von Hand zu prüfen, ob die Migration durchgelaufen ist, dann hängt die Auslieferung nicht mehr vom Hersteller ab.

Die Folge ist nicht nur eine Verzögerung. Ein Kunde wendet die Migration am Dienstag an, ein anderer wartet bis Freitag, ein dritter schiebt sie auf den Folgemonat. Man hat dann mehrere Versionen der Engine, mehrere Zustände des Schemas und eine Komplexität, die mit jeder Auslieferung wächst.

Verloren geht dabei der strukturelle Vorteil des Modells: ein gemeinsames Produkt für alle Kunden laufend weiterzuentwickeln.

Warum das wichtig ist

Das Auseinanderlaufen sieht man nicht in dem Moment, in dem man die Vereinbarung eingeht — der erste Kunde ist leicht zu bedienen. Es zeigt sich beim zehnten, wenn jede Korrektur gegen mehrere Schemazustände getestet werden muss.

Und der Trend arbeitet dagegen: Je höher die Auslieferungsfrequenz, desto teurer wird eine Architektur, die bei jeder Weiterentwicklung einen menschlichen Eingriff pro Kunde verlangt.

Nuancen und Grenzen

Der Befund gilt für strukturelle Änderungen. Eine Konfiguration, ein Inhalt, ein Parameter können von Kunde zu Kunde variieren, ohne dieses Auseinanderlaufen zu erzeugen.

Und es gibt Modelle, die mehrere Versionen bewusst in Kauf nehmen — eine beim Kunden installierte Software. Das ist ein anderes Geschäft, mit anderen Kosten.

Offene Fragen

• Wie viele Schemavarianten kann ein Team halten, bevor die Testkosten untragbar werden?