Hauptgedanke

Gesteht man einem Großkunden zu, dass die Datenbank seiner Gehaltsabrechnungssoftware in seiner Azure-Umgebung liegt, öffnet sich eine Frage, die niemand gestellt hat: Kontrolliert dieser Kunde dann auch die Schemaänderungen und damit den Rhythmus der Deployments?

Das eine hängt nicht am anderen, und wer beides verwechselt, zahlt teuer. Ein Kunde, der seine Daten bei sich behalten will, verlangt nicht, die Migrationen des Herstellers zu steuern. Er will die Hoheit über den Speicherort, nicht über die Weiterentwicklung.

Daraus ergibt sich eine Grenze, die sich in einem Satz sagen lässt: Der Kunde kontrolliert, wo seine Daten liegen, der Hersteller kontrolliert, wie sich das Produkt weiterentwickelt.

Warum das wichtig ist

Erst diese Grenze macht die Vereinbarung tragfähig. Ohne sie hieße, das Hosting zuzugestehen, den Auslieferungskalender aus der Hand zu geben, und der Hersteller verlöre, was einen Onlinedienst überhaupt ausmacht.

Sie liefert auch ein klares Akzeptanzkriterium: Hosting beim Kunden ist mit diesem Modell nur vereinbar, wenn die Migrationen automatisiert und vom Hersteller gesteuert bleiben — in einem Sicherheitsrahmen, den der Kunde akzeptiert.

Nuancen und Grenzen

Die Grenze ist leicht ausgesprochen und in der Praxis umstritten: Ein Kunde, dessen Richtlinie jede nicht freigegebene Änderung verbietet, kann sie so nicht akzeptieren.

Und sie regelt nicht alles: Der Speicherort der Daten hat Folgen für die Überwachung und die Verantwortlichkeiten, die getrennt zu klären bleiben.

Offene Fragen

• Was tun mit einem Kunden, dessen Governance ausgerechnet automatisierte Migrationen verbietet?