Lange war das Versprechen von SaaS ziemlich einfach.

Du nutzt die Software. Wir kümmern uns um den Rest.

Wir betreiben die Anwendung, wählen die Infrastruktur, hosten die Datenbank, sorgen für die Backups und entwickeln das Produkt weiter.

Der Kunde kauft einen fertigen Service.

Dieses Versprechen gilt weiterhin. Aber in den Gesprächen mit Konzernen sehe ich immer mehr Forderungen auftauchen, die es verschieben.

„Können die Daten in unserer Azure-Umgebung bleiben?“

„Können wir unseren eigenen SQL Server nutzen?“

„Können wir unsere eigenen Verschlüsselungsschlüssel nutzen?“

„Können wir Nutzer und Rechte aus unserem IAM heraus verwalten?“

„Können wir unseren eigenen LLM-Vertrag und -Anbieter nutzen?“

„Können wir unseren eigenen E-Mail- oder SMS-Anbieter nutzen?“

„Können wir die Sicherheitsereignisse in unser SIEM schicken?“

Diese Forderungen wirken sehr unterschiedlich.

In Wahrheit erzählen sie meist dasselbe.

Konzerne wollen weiterhin SaaS kaufen, aber sie wollen die Kontrolle über einzelne Bausteine zurück.

Und dieser Wandel ist nicht nur technisch oder regulatorisch.

Er ist auch kulturell.

Wenn die Kultur des Kunden zum Bestandteil des Produkts wird

Nimm eine sehr einfache Forderung:

„Ich will wissen, wer sich an der Anwendung anmeldet.“

Technisch ist das nicht unbedingt ein spektakuläres Feature.

Aber hinter diesem Satz können ein ISO-Audit stecken, eine Sicherheitsrichtlinie, ein Cybersecurity-Team, ein zentrales SIEM, ein Untersuchungsverfahren oder schlicht eine Unternehmenskultur, in der jeder Zugriff nachvollziehbar sein muss.

Dasselbe gilt für die Nutzerverwaltung.

Der Kunde will die Rechte womöglich nicht in jedem SaaS pflegen, den er kauft. Er will, dass Identitäten, Gruppen und manchmal auch Rechte aus seinem eigenen IAM gesteuert werden.

Man könnte auf einige dieser Forderungen schauen und feststellen, dass sie keinerlei fachlichen Wert schaffen.

Und das stimmt sogar.

Aber damit ginge man am Thema vorbei.

Das Produkt, das wir bauen, um das fachliche Problem des Kunden zu lösen, ist nur ein Teil dessen, was er tatsächlich kauft.

Genau hier wird die Unterscheidung zwischen Core Product und Whole Product nützlich.

Das Core Product bündelt das, was unseren Wert wirklich ausmacht: unser Fachwissen, unsere Regeln, unsere Workflows, unsere Orchestrierung, unsere Fähigkeit, ein Problem besser zu lösen als eine Alternative.

Das Whole Product ist alles, was es rund um diesen Wert braucht, damit ein bestimmter Kunde das Produkt tatsächlich kaufen, ausrollen und betreiben kann.

SSO ist vermutlich nicht unsere Differenzierung.

Das SIEM auch nicht.

Die Datenresidenz auch nicht.

Die Fähigkeit, das IAM des Kunden zu nutzen, auch nicht.

Aber schon das Fehlen eines dieser Elemente kann einen Verkauf verhindern.

Sie schaffen nicht zwingend den Wert.

Sie lassen diesen Wert ins Unternehmen hinein.

„Ich will euer SaaS nutzen, aber meine Datenbank bei mir behalten“

Der interessanteste Fall ist wahrscheinlich der der Datenbank.

Stell dir eine Lohnabrechnungssoftware vor.

Jeder versteht sofort, um welche Art von Daten es geht: Gehälter, Verträge, personenbezogene Informationen, Unternehmensorganisation.

Im klassischen SaaS-Modell betreibt der Anbieter die Software und die zugehörige Datenbank.

Stell dir jetzt einen Konzern vor, der uns sagt:

Wir wollen eure Anwendung, aber die Daten müssen in einer SQL-Server- oder Azure-SQL-Datenbank in unserer Azure-Umgebung bleiben.

Das ist keine absurde Forderung.

Und in unserem Fall passt sie sogar zu dem Markt, den wir bedienen wollen: Die allermeisten unserer Zielkunden bewegen sich ohnehin im Microsoft-Ökosystem.

Die Engine des SaaS bliebe beim Anbieter.

Aber ihre Datenbank könnte in der Umgebung des Kunden liegen.

Warum fordert ein Kunde das, wo wir doch bestens wissen, wie man eine Datenbank hostet?

Weil seine Frage nicht zwingend lautet:

„Seid ihr in der Lage, meine Daten gut zu hosten?“

Sie kann lauten:

„Bleiben meine Daten unter der Kontrolle meiner Organisation?“

Manchmal will der Kunde, dass die Ressource in seinem Azure-Abonnement liegt.

Er will seine Netzwerkregeln anwenden.

Seine Sicherheitsrichtlinien.

Seine Schlüssel.

Seine Inventarmechanismen.

Seine Kontrollen.

Seine internen Standards.

Und vor allem seinem CISO, seinem Auditor oder seiner Organisation sagen können:

„Diese Daten bleiben bei uns.“

Das ist nicht immer eine regulatorische Pflicht.

Es kann schlicht die Bedingung dafür sein, dass das Unternehmen das Produkt akzeptiert.

Den Ort der Daten zu kontrollieren heißt nicht, das Produkt zu kontrollieren

Dem Kunden mehr Kontrolle zu geben zieht allerdings eine Grenze ein, die man wahren muss.

Die fachliche Engine bleibt beim Anbieter.

Ihr geistiges Eigentum bleibt beim Anbieter.

Und vor allem muss die Fähigkeit, das Produkt weiterzuentwickeln, beim Anbieter bleiben.

Nimm die Datenbankmigrationen.

Angenommen, wir bauen ein Feature, das eine neue Spalte, einen Index oder eine Schemaänderung braucht.

Wenn jedes Deployment bedeutet, dem Team des Kunden ein Verfahren zu schicken, auf eine Freigabe zu warten, ein Wartungsfenster zu reservieren und anschließend manuell zu prüfen, ob die Migration angewendet wurde, trägt das Modell nicht.

Schon heute verträgt es sich kaum mit einem SaaS, das mehrmals pro Woche ausliefert.

Und morgen noch weniger.

KI-gestützte Softwareentwicklung erhöht bereits jetzt unsere Fähigkeit, Software zu produzieren, zu testen und zu verändern. Es ist vernünftig anzunehmen, dass die Auslieferungsfrequenz weiter steigt.

Heute eine Architektur zu bauen, die bei jeder Änderung mehr menschliche Eingriffe bei jedem Kunden verlangt, ginge genau in die Gegenrichtung.

Sehr schnell spielt ein Kunde die Migration am Dienstag ein.

Ein anderer wartet bis Freitag.

Ein dritter verschiebt sie auf den nächsten Monat.

Am Ende hat man mehrere Versionen der Engine, mehrere Schemazustände und eine Komplexität, die mit jedem Release wächst.

Und man verliert einen der strukturellen Vorteile von SaaS: ein gemeinsames Produkt für alle Kunden kontinuierlich weiterzuentwickeln.

Der Kunde, der seine Daten in seiner Umgebung behalten will, verlangt aber nicht zwingend, unsere Migrationen zu steuern.

Er will die Kontrolle darüber, wo seine Daten leben.

Nicht darüber, wie sich unser Produkt weiterentwickelt.

Die Grenze wird damit ziemlich einfach:

Der Kunde kontrolliert, wo seine Daten leben; der Anbieter kontrolliert, wie sich das Produkt weiterentwickelt.

BYO-Database ist also nur dann wirklich mit SaaS verträglich, wenn die Migrationen automatisiert und vom Anbieter gesteuert bleiben können, in einem vom Kunden akzeptierten Sicherheitsrahmen.

Kontrolle verschiebt auch die Verantwortlichkeiten

Die Datenbank in die Umgebung des Kunden zu verlegen hat noch eine weitere Folge.

Ein Teil der Infrastruktur, von der unser Service abhängt, steht nicht mehr vollständig unter unserer Kontrolle.

Und an dem Tag, an dem die Anwendung ausfällt, wird dieser Unterschied sehr konkret.

Ist es unsere Engine?

Der SQL Server des Kunden?

Azure?

Eine gerade geänderte Netzwerkregel?

Ein Zertifikat?

Eine IAM-Konfiguration?

Eine Überlastung der Verbindungen?

Ein Quota?

Ein Latenzproblem?

Zu sagen:

„Die Datenbank liegt beim Kunden, das ist nicht unser Problem“

funktioniert nicht.

Für den Nutzer ist es unser SaaS, das nicht mehr läuft.

BYO erzwingt damit eine Anforderung, die mir nicht verhandelbar scheint: Wir müssen die Datenbank und ihre Konnektivität ausreichend monitoren können, um zu verstehen, woher ein Incident kommt.

Das heißt nicht, die gesamte Infrastruktur anstelle des Kunden zu administrieren.

Es heißt, über die nötigen Signale zu verfügen: Verfügbarkeit, Latenz, Verbindungsfehler, Sättigung, Gesundheitszustand, für die Diagnose nützliche Ereignisse.

Diese Observability ist operativ unverzichtbar.

Aber sie ist es auch vertraglich.

Wenn unser SLA Ausfälle ausschließt, die von einer Ressource unter Kontrolle des Kunden verursacht wurden, müssen wir objektiv feststellen können, dass ein Incident tatsächlich von dieser Ressource kam.

Geteilte Verantwortung existiert nur dann wirklich, wenn sich Incidents zuordnen lassen.

Der Kunde zahlt seine Datenbank. Trotzdem kann sein SaaS teurer werden.

Hier taucht ein interessantes Paradox auf.

Der Kunde kann sein Azure SQL oder seinen SQL Server direkt bezahlen.

Man könnte also denken:

Da er die Datenbank selbst bezahlt, müsste unser SaaS günstiger werden.

Nicht unbedingt.

Unsere Servicekosten beschränken sich nicht auf den Preis der Infrastruktur.

Datenbanken in Kundenumgebungen zu unterstützen kann uns zwingen, mehr Varianten zu beherrschen.

Unterschiedliche Versionen.

Unterschiedliche Netzwerkbeschränkungen.

Replikationsmechanismen.

Backups.

Snapshots.

Wiederherstellungen.

Rechte.

Monitoring.

Spezifische Konfigurationen.

Und vor allem mehr Szenarien, die man verstehen muss, wenn etwas nicht mehr funktioniert.

Eine Ressource auszulagern kann also unsere direkten Infrastrukturkosten senken und zugleich unsere Servicekosten erhöhen.

Die Backups illustrieren diese Aufteilung gut.

Wenn wir uns verpflichten, die Backups zu verwalten und die Wiederherstellung einer Datenbank in der Umgebung des Kunden zu garantieren, übernehmen wir eine zusätzliche Verantwortung.

Sie verlangt Technologie.

Tests.

Monitoring.

Wiederanlaufverfahren.

Diese Verantwortung hat also einen Preis und muss abgerechnet werden.

Umgekehrt kann der Kunde entscheiden, seine Backups selbst zu verwalten.

Dann müssen die Verantwortlichkeiten ausdrücklich benannt sein: Aufbewahrung, Qualität der Backups, Wiederherstellung und die Folgen eines unbrauchbaren Backups müssen bei ihm liegen.

BYO lässt die Verantwortlichkeiten nicht verschwinden.

Es zwingt nur dazu, sehr viel genauer zu sagen, wer welche trägt.

Nicht jeder Baustein muss bei uns bleiben

Ist dieser Gedanke einmal gesetzt, erscheint die Datenbank als der schwierigste Fall eines allgemeineren Phänomens.

Eine einfache Frage hilft beim Nachdenken über die anderen Bausteine:

Wenn ich diesen Anbieter durch einen anderen ersetze, ändert sich dann der Wert meines Service?

Nimm den E-Mail-Versand.

Wenn wir unseren E-Mail-Anbieter durch den des Kunden ersetzen, ändert sich dann der fachliche Wert unseres Produkts?

Wahrscheinlich nicht.

Die Nachricht wird weiterhin zum richtigen Zeitpunkt verschickt, weil unsere Engine entschieden hat, dass sie verschickt werden soll.

Dasselbe gilt für eine SMS.

Dasselbe gilt in manchen Fällen für ein LLM.

Unser Produkt kann standardmäßig ein KI-Modell mitliefern.

Aber ein Konzern zieht womöglich seinen eigenen Azure-OpenAI-Vertrag vor, seine eigenen Schlüssel oder einen bereits freigegebenen Anbieter.

Wenn unser Wert im fachlichen Workflow, im Kontext, in den Regeln, den Daten und der Orchestrierung steckt, darf ein Wechsel des Ausführungsmodells den Kern des Produkts nicht verschieben.

Das heißt nicht, dass alle Anbieter perfekt austauschbar sind.

Ein Modell kann leistungsfähiger sein als ein anderes.

Ein E-Mail-Anbieter kann eine bessere Zustellbarkeit haben.

Aber die richtige Frage bleibt:

Ist es dieser Baustein, der den Wert trägt, für den der Kunde unser Produkt kauft?

Wenn der Austausch eines Anbieters den Wert des Service zerstört, liegt er wahrscheinlich zu nah am Core Product, um frei ersetzbar zu sein.

Wenn sein Austausch den grundlegenden fachlichen Wert nicht ändert, kann er zum Kandidaten für Konfiguration, Substitution oder BYO werden.

Nicht jede Substitution kostet gleich viel

Ein wichtiger Unterschied bleibt.

Ein E-Mail-Gateway ist relativ stateless.

Dasselbe gilt für einen SMS-Provider.

Und ein LLM kann es ebenfalls sein — vorausgesetzt, dauerhafter Speicher, fachlicher Kontext und Entscheidungen bleiben in unserem Produkt.

Eine Datenbank ist etwas anderes.

Sie enthält den dauerhaften Zustand des Systems.

Man wechselt nicht von einem SQL Server zum nächsten, indem man einfach einen API-Schlüssel austauscht.

Die Daten müssen migriert werden.

Ihre Konsistenz muss garantiert sein.

Der Wiederanlauf muss vorgesehen sein.

Die Backups müssen verwaltet werden.

Manchmal auch die Replikation.

Substituierbarkeit ist also nicht binär.

Sie ist ein Gradient.

Ein Baustein kann für unser Produkt nicht differenzierend und operativ trotzdem extrem wichtig sein.

Für die Datenbank gilt das besonders.

Das Whole Product nicht in einen Katalog verwandeln

Von hier aus wäre die Versuchung groß, alle Möglichkeiten zu bauen.

Azure.

AWS.

GCP.

SQL Server.

PostgreSQL.

Oracle.

Fünf KI-Anbieter.

Drei E-Mail-Anbieter.

Vier SMS-Gateways.

Das wäre vermutlich ein Fehler.

Die richtige Frage lautet nicht:

„Was können wir technisch unterstützen?“

Sondern:

„Was müssen wir für die Kunden unterstützen, die wir bedienen wollen?“

Wenn 90 % der Konzerne, die wir adressieren, ohnehin um Microsoft und Azure herum aufgebaut sind, ergibt es Sinn, mit Azure und SQL Server anzufangen.

Nicht weil SQL Server an sich besser wäre als eine andere Datenbank.

Sondern weil diese Konstellation unsere Verkaufsfähigkeit im anvisierten Markt wahrscheinlich am stärksten erhöht.

Umgekehrt bringt es nicht zwingend Wert, eine Datenbank oder eine Cloud zu unterstützen, die in unserem Segment niemand verlangt.

Die Breite der technologischen Unterstützung ist kein Ziel an sich.

Sie muss der kommerziellen Positionierung folgen.

Das Whole Product ist keine universelle Checkliste des „perfekten Enterprise-SaaS“.

Es ist die konkrete Übersetzung der Frage:

Was müssen wir rund um unser Core Product ergänzen, damit die Kunden, die wir bedienen wollen, es tatsächlich kaufen können?

Den Bedarf hinter der Forderung verstehen

Das heißt nicht, dass man jede Kundenforderung wörtlich erfüllen müsste.

Wenn ein Konzern sagt:

Ich will meine Daten in meinem Azure.

ist die richtige Antwort nicht sofort:

Alles klar, bauen wir BYO-Database.

Man muss verstehen, warum.

Ist es eine regulatorische Pflicht?

Eine Residenzanforderung?

Eine Richtlinie des CISO?

Ein Bedarf, die Schlüssel zu kontrollieren?

Ein Audit-Zwang?

Der Wunsch nach Reversibilität?

Oder schlicht eine Kultur, nach der sensible Daten unter direkter Kontrolle des Unternehmens bleiben müssen?

Die Lösung kann von dieser Antwort abhängen.

Manchmal reicht eine dedizierte Region.

Manchmal reicht ein Customer Managed Key.

Manchmal reicht eine Single-Tenant-Umgebung.

In anderen Fällen muss die Datenbank tatsächlich im Tenant des Kunden liegen.

Zu verstehen, warum der Kunde Kontrolle verlangt, erlaubt es, das richtige Maß an Kontrolle anzubieten.

Aber am Ausgangsbefund ändert das nichts.

Wer sich entscheidet, an Konzerne zu verkaufen, für den gehört deren Governance-Kultur zum Markt.

Man kann nicht ihre Volumina, ihre Budgets und ihre Verträge wollen und gleichzeitig ihre Audit-, Sicherheits- oder Kontrollanforderungen als lästige Details behandeln.

Das ist keine Infrastrukturstrategie

Das ist vermutlich der wichtigste Punkt.

Auf den ersten Blick sieht das ganze Thema nach einer Architekturdiskussion aus.

Wo hostet man den SQL Server?

Wie verbindet man die Engine?

Wie migriert man das Schema?

Wie monitort man?

Wie verwaltet man die Backups?

Das sind echte Fragen.

Aber sie kommen nach einer anderen:

Welche Kunden haben wir zu bedienen beschlossen?

Das Core Product schafft den Wert.

Die Positionierung wählt den Markt.

Und das Whole Product macht das Core Product mit der Realität dieses Markts verträglich.

Wenn die Konzerne, die wir bedienen wollen, eine ausgeprägte Kultur der Kontrolle über ihre Daten, ihre Identitäten, ihre Schlüssel und ihre Anbieter haben, dann müssen einige dieser Fähigkeiten wahrscheinlich zum Bestandteil unseres Whole Product werden.

Nicht weil BYO besser wäre als Full-Managed.

Full-Managed sollte wahrscheinlich die Standardwahl bleiben.

Es bleibt einfacher zu betreiben, homogener und leichter weiterzuentwickeln.

BYO wird zur Option, wenn der Markt es rechtfertigt.

Und sein Umfang muss auf dieselbe Weise entschieden werden.

Wir müssen nicht jede Komponente austauschbar machen.

Wir müssen nicht jede Technologie unterstützen.

Wir müssen vor allem die Zwänge identifizieren, die die Kunden, die wir bedienen wollen, tatsächlich am Kauf unseres Produkts hindern.

Und dann entscheiden, welche davon wir aufheben wollen.

BYO ist also nicht zuerst eine Infrastrukturstrategie. Es ist eine Entscheidung über Whole Product und kommerzielle Positionierung.

Die technische Folge kann ein modulareres SaaS sein.

Die Engine bleibt unter unserer Kontrolle.

Bestimmte Daten bleiben beim Kunden.

Bestimmte Anbieter werden austauschbar.

Bestimmte Verantwortlichkeiten wechseln den Besitzer.

Aber das ist nicht der Ausgangspunkt.

Der Ausgangspunkt bleibt der Markt.

Es geht nicht darum, allen Kunden jede erdenkliche Wahl zu geben. Es geht darum, das Whole Product zu bauen, das unserem Core Product erlaubt, von den Kunden gekauft zu werden, die wir zu bedienen beschlossen haben.