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, sichern die Daten und entwickeln das Produkt weiter.

Der Kunde kauft einen fertigen Service.

Dieses Versprechen gilt weiter. Aber in den Gesprächen mit Großkonzernen sehe ich immer mehr Anfragen, 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 Benutzer und Rechte aus unserem IAM heraus verwalten?"

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

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

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

Diese Anfragen wirken sehr unterschiedlich.

In Wirklichkeit erzählen sie oft dasselbe.

Groß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

Nehmen wir eine sehr einfache Anfrage:

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

Technisch ist das nicht unbedingt ein spektakuläres Feature.

Hinter diesem Satz können aber ein ISO-Audit stehen, eine Sicherheitsrichtlinie, ein Cybersecurity-Team, ein zentrales SIEM, ein Ermittlungsverfahren oder schlicht eine Unternehmenskultur, in der jeder Zugriff nachvollziehbar sein muss.

Genauso bei der Benutzerverwaltung.

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

Man könnte auf manche dieser Anfragen schauen und feststellen: Sie schaffen keinen fachlichen Wert.

Und das wäre richtig.

Aber damit würde man das Thema verfehlen.

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 rund um diesen Wert nötig ist, damit ein bestimmter Kunde das Produkt tatsächlich kaufen, ausrollen und betreiben kann.

SSO ist wahrscheinlich nicht unsere Differenzierung.

Das SIEM auch nicht.

Der Speicherort der Daten auch nicht.

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

Aber fehlt eines dieser Elemente, kann das allein einen Verkauf verhindern.

Sie schaffen den Wert nicht zwangsläufig.

Sie lassen diesen Wert ins Unternehmen hinein.

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

Der interessanteste Fall ist wahrscheinlich die Datenbank.

Stell dir eine Gehaltsabrechnungssoftware vor.

Jeder versteht sofort, um welche Art von Daten es geht: Gehälter, Verträge, persönliche Angaben, Aufbau des Unternehmens.

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

Stell dir nun einen Großkonzern vor, der uns sagt:

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

Das ist keine abwegige Anfrage.

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 Hersteller.

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

Warum fragt ein Kunde danach, obwohl wir eine Datenbank bestens hosten können?

Weil seine Frage nicht zwingend lautet:

„Könnt ihr meine Daten gut hosten?"

Sie kann lauten:

„Bleiben meine Daten unter der Kontrolle meiner Organisation?"

Der Kunde will manchmal, dass die Ressource in seinem eigenen Azure-Abonnement liegt.

Er will seine Netzwerkregeln anwenden.

Seine Sicherheitsrichtlinien.

Seine Schlüssel.

Seine Inventarmechanismen.

Seine Prüfungen.

Seine internen Standards.

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

„Diese Daten bleiben bei uns."

Das ist nicht immer eine regulatorische Auflage.

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

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

Mehr Kontrolle für den Kunden zieht allerdings eine Grenze ein, die man halten muss.

Die fachliche Engine bleibt beim Hersteller.

Ihr geistiges Eigentum bleibt beim Hersteller.

Und vor allem: Die Fähigkeit, das Produkt weiterzuentwickeln, muss beim Hersteller bleiben.

Nehmen wir die Datenbankmigrationen.

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

Wenn jedes Deployment bedeutet, dem Team des Kunden eine Anleitung zu schicken, auf eine Freigabe zu warten, ein Wartungsfenster zu reservieren und danach von Hand zu prüfen, ob die Migration angewendet wurde, dann trägt das Modell nicht.

Schon heute passt es kaum zu einem SaaS, das mehrmals pro Woche ausliefert.

Und morgen passt es noch weniger.

KI-gestützte Softwareentwicklung erhöht schon jetzt unsere Fähigkeit, Software zu bauen, zu testen und zu ändern. Es ist plausibel, 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 entgegengesetzte Richtung.

Schnell ist es dann so: Ein Kunde wendet die Migration am Dienstag an.

Ein anderer wartet bis Freitag.

Ein dritter schiebt sie auf den Folgemonat.

Damit hat man mehrere Versionen der Engine, mehrere Zustände des Schemas und eine Komplexität, die mit jedem Release wächst.

Am Ende verliert man einen der strukturellen Vorteile von SaaS: ein gemeinsames Produkt für alle Kunden laufend weiterzuentwickeln.

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

Er will Kontrolle darüber, wo seine Daten liegen.

Nicht darüber, wie sich unser Produkt weiterentwickelt.

Die Grenze wird damit recht einfach:

Der Kunde kontrolliert, wo seine Daten liegen; der Hersteller kontrolliert, wie sich das Produkt weiterentwickelt.

BYO-Database ist also nur dann wirklich mit SaaS vereinbar, wenn die Migrationen automatisiert und vom Hersteller gesteuert bleiben — in einem Sicherheitsrahmen, den der Kunde akzeptiert.

Kontrolle verschiebt auch die Verantwortlichkeiten

Die Datenbank in die Umgebung des Kunden zu verlegen, hat noch eine 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.

Liegt es an unserer Engine?

Am SQL Server des Kunden?

An Azure?

An einer gerade geänderten Netzwerkregel?

An einem Zertifikat?

An einer IAM-Konfiguration?

An einer Sättigung der Verbindungen?

An einem Kontingent?

An einem 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 deshalb eine Anforderung, die für mich nicht verhandelbar ist: Wir müssen die Datenbank und ihre Anbindung ausreichend überwachen können, um zu verstehen, woher ein Vorfall kommt.

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

Das heißt, über die nötigen Signale zu verfügen: Verfügbarkeit, Latenz, Verbindungsfehler, Sättigung, Health-Status, Ereignisse, die bei der Diagnose helfen.

Diese Observability ist im Betrieb unverzichtbar.

Vertraglich ist sie es ebenso.

Wenn unser SLA Ausfälle ausschließt, die durch eine Ressource unter Kontrolle des Kunden ausgelöst wurden, dann müssen wir objektiv feststellen können, dass ein Vorfall tatsächlich von dieser Ressource kam.

Eine geteilte Verantwortung existiert nur dann wirklich, wenn man Vorfälle zuordnen kann.

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 selbst bezahlen.

Man könnte also denken:

Weil er die Datenbank selbst bezahlt, müsste unser SaaS billiger werden.

Nicht zwangsläufig.

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 Netzwerkvorgaben.

Replikationsmechanismen.

Sicherungen.

Snapshots.

Wiederherstellungen.

Rechte.

Monitoring.

Spezifische Konfigurationen.

Und vor allem mehr Szenarien, die man verstehen muss, wenn etwas nicht mehr läuft.

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

Die Sicherungen zeigen diese Aufteilung gut.

Wenn wir zusagen, 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 kostet also etwas und muss in Rechnung gestellt werden.

Umgekehrt kann der Kunde seine Sicherungen selbst 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 gefasst, erscheint die Datenbank als der schwierigste Fall eines allgemeineren Musters.

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?

Nehmen wir 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 geht weiterhin zum richtigen Zeitpunkt raus, weil unsere Engine entschieden hat, dass sie rausgehen soll.

Genauso bei einer SMS.

Genauso, in bestimmten Fällen, bei einem LLM.

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

Ein Großkonzern kann aber lieber seinen eigenen Azure-OpenAI-Vertrag, seine eigenen Schlüssel oder einen bereits freigegebenen Anbieter nutzen.

Wenn unser Wert im fachlichen Workflow liegt, im Kontext, in den Regeln, den Daten und der Orchestrierung, dann darf ein Wechsel des ausführenden Modells den Kern des Produkts nicht verschieben.

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

Ein Modell kann leistungsfähiger sein als ein anderes.

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

Aber die richtige Frage bleibt:

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

Wenn ein Anbieterwechsel den Wert des Service zerstört, liegt dieser Anbieter wahrscheinlich zu nah am Core Product, um frei austauschbar zu sein.

Wenn sein Austausch den grundlegenden fachlichen Wert nicht verändert, kann er ein Kandidat für Konfiguration, Austausch oder BYO werden.

Nicht jeder Austausch kostet gleich viel

Ein wichtiger Unterschied bleibt.

Ein E-Mail-Gateway ist relativ stateless.

Genauso ein SMS-Provider.

Und ein LLM kann es auch sein — vorausgesetzt, das dauerhafte Gedächtnis, der fachliche Kontext und die 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 gesichert sein.

Der Wiederanlauf muss vorbereitet sein.

Die Sicherungen müssen verwaltet werden.

Manchmal die Replikation.

Austauschbarkeit ist also nicht binär.

Sie ist ein Gradient.

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

Für die Datenbank gilt das besonders.

Das Whole Product nicht zum Katalog machen

Von hier aus könnte die Versuchung sein, 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 wahrscheinlich 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 Großkonzerne in unserem Zielmarkt bereits um Microsoft und Azure herum aufgebaut sind, dann ist es sinnvoll, mit Azure und SQL Server anzufangen.

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

Sondern weil diese Konstellation unsere Verkaufschancen in dem Markt, den wir anpeilen, 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 allgemeingültige Checkliste des „perfekten Enterprise-SaaS".

Es ist die konkrete Antwort auf die Frage:

Was muss rund um unser Core Product dazukommen, damit die Kunden, die wir bedienen wollen, es tatsächlich kaufen können?

Den Bedarf hinter der Anfrage verstehen

Das heißt nicht, dass man jede Kundenanfrage wörtlich erfüllen muss.

Wenn ein Großkonzern sagt:

Ich will meine Daten in meinem Azure.

dann ist die richtige Antwort nicht sofort:

Einverstanden, bauen wir BYO-Database.

Man muss verstehen, warum.

Ist es eine regulatorische Auflage?

Eine Anforderung an den Speicherort?

Eine Vorgabe des CISO?

Ein Bedarf, die Schlüssel zu kontrollieren?

Eine Auflage aus einem Audit?

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 genügt eine dedizierte Region.

Manchmal genügt ein Customer Managed Key.

Manchmal genügt eine Single-Tenant-Umgebung.

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

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

An der Ausgangslage ändert das aber nichts.

Wenn wir uns entscheiden, an Großkonzerne zu verkaufen, gehört ihre Governance-Kultur zum Markt dazu.

Man kann nicht ihre Volumen, ihre Budgets und ihre Verträge wollen und zugleich ihre Auflagen zu Audit, Sicherheit oder Kontrolle als lästige Details behandeln.

Das ist keine Infrastrukturstrategie

Das ist wahrscheinlich der wichtigste Punkt.

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

Wo hostet man SQL Server?

Wie bindet man die Engine an?

Wie migriert man das Schema?

Wie überwacht man?

Wie verwaltet man die Backups?

Das sind echte Fragen.

Aber sie kommen nach einer anderen:

Für welche Kunden haben wir uns entschieden?

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 Marktes vereinbar.

Wenn die Großkonzerne, die wir bedienen wollen, eine starke Kultur der Kontrolle über ihre Daten, ihre Identitäten, ihre Schlüssel und ihre Anbieter haben, dann müssen manche dieser Fähigkeiten wahrscheinlich Bestandteil unseres Whole Product werden.

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

Full Managed sollte wahrscheinlich die Standardwahl bleiben.

Es bleibt einfacher im Betrieb, einheitlicher und leichter weiterzuentwickeln.

BYO wird dann 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 Hürden erkennen, die die Kunden, die wir bedienen wollen, wirklich vom Kauf unseres Produkts abhalten.

Und dann entscheiden, welche davon wir aus dem Weg räumen wollen.

BYO ist also nicht zuerst eine Infrastrukturstrategie. Es ist eine Entscheidung über das Whole Product und über die 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 gehen über.

Aber das ist nicht der Ausgangspunkt.

Der Ausgangspunkt bleibt der Markt.

Wir versuchen nicht, allen Kunden jede erdenkliche Wahl zu geben. Wir versuchen, das Whole Product zu bauen, das unserem Core Product den Kauf durch die Kunden ermöglicht, für die wir uns entschieden haben.