Mandantenfähigkeit ohne Fachjargon erklärt: Ein Leitfaden für Gründer

Irgendwann beim Aufbau eines Softwareprodukts wird ein Entwickler das Wort "mandantenfähig" fallen lassen, Ihr Gesicht beobachten und davon ausgehen, dass Sie es verstanden haben. Wahrscheinlich haben Sie genickt. Das tun die meisten Gründer. Doch dies ist eine jener frühen Entscheidungen, die im Stillen die Obergrenze festlegt: wie schnell Sie wachsen, wie günstig Sie betreiben und wie schlimm es schieflaufen kann, wenn ein Kunde jemals Daten sieht, die nicht ihm gehören. Es lohnt sich, jetzt zehn Minuten darauf zu verwenden, denn später nachzubessern ist sehr teuer.

Ich habe vielen nicht-technischen Gründern gegenübergesessen — Menschen mit einer klugen Idee für ein SaaS-Produkt und ohne besonderes Interesse an Datenbanken. Die gute Nachricht: Sie müssen nicht programmieren lernen, um diese Entscheidung gut zu treffen. Sie brauchen ein klares Denkmodell und eine kurze Liste von Fragen. Genau das ist dieser Leitfaden. Keine Schlagworte, keine Architekturdiagramme, die Sie nie wieder ansehen — nur das, was Ihr Entwickler sich wünscht, dass Sie es vor der ersten Codezeile verstehen.

Wenn Sie nur einen Gedanken mitnehmen, dann diesen: Mandantenfähigkeit ist keine Funktion, die man später hinzufügt. Sie ist ein Fundament. Ein Haus können Sie neu streichen, aber das, worauf es steht, lässt sich kaum noch ändern, wenn die Wände erst stehen.

Was "mandantenfähig" wirklich bedeutet

Stellen Sie sich ein Mehrfamilienhaus vor. Jede Partei hat ihre eigene Wohnung — eigenen Schlüssel, eigene Möbel, eigene Wohnungstür. Aber alle teilen dieselbe Struktur: das Fundament, die Leitungen, das Dach, den Aufzug. Der Eigentümer pflegt ein Gebäude, nicht fünfzig einzelne Häuser, und genau das hält die Miete bezahlbar. Mandantenfähige Software funktioniert genau so. Eine Anwendung bedient viele Kunden — "Mandanten" — und jeder erlebt sie als seinen eigenen privaten Bereich, obwohl alle auf demselben gemeinsamen System darunter laufen.

Der entgegengesetzte Ansatz ist Single-Tenant: Jeder Kunde erhält seine eigene, getrennte Kopie der Software, als würde man für jeden ein brandneues Einfamilienhaus bauen. Privater, individueller anpassbar — und dramatisch teurer im Bau, Betrieb und in der Wartung, denn nun pflegen Sie fünfzig Häuser statt eines Gebäudes.

Fast jedes Produkt, das Sie täglich nutzen, ist mandantenfähig. Ihr E-Mail-Dienst, Ihre Buchhaltungssoftware, Ihr Buchungssystem, das CRM, in dem Ihr Vertrieb lebt. Sie und tausend andere Unternehmen teilen sich dieselbe zugrunde liegende Software, und keiner von Ihnen sieht den anderen je. Diese Unsichtbarkeit — diese saubere Trennung — ist die ganze Kunst der Mandantenfähigkeit.

Warum diese Entscheidung Ihr ganzes Unternehmen berührt

Es ist verlockend, dies unter "technisches Detail, um das sich mein Entwickler kümmert" abzulegen. Doch das gewählte Modell wirkt sich direkt auf die Bereiche aus, die Ihnen tatsächlich wichtig sind: Ihre monatliche Hosting-Rechnung, wie schnell Sie eine neue Funktion an alle ausliefern können, was Sie einem nervösen Enterprise-Käufer versprechen können und wie viel Schaden ein einziger Fehler anrichten kann.

Wenn Sie in einem gut gebauten mandantenfähigen Produkt einen Fehler beheben oder eine Funktion veröffentlichen, erhalten alle Kunden sie auf einmal, durch ein einziges Update. In einer Single-Tenant-Welt müssten Sie diese Änderung auf fünfzig getrennte Installationen ausrollen, von denen jede inzwischen leicht anders sein könnte. Das eine ist ein Dienstagnachmittag. Das andere ist ein Projekt. Multiplizieren Sie das über Jahre von Updates, und Sie sehen, warum die SaaS-Branche auf Mandantenfähigkeit setzt.

Die Kehrseite: Geteilte Infrastruktur erhöht den Einsatz bei der Trennung. In einem Mehrfamilienhaus kann ein Rohrbruch mehr als eine Wohnung betreffen. In mandantenfähiger Software bringt ein Fehler in der Trennung der Mandanten nicht nur einen Kunden in Schwierigkeiten — er kann die Daten aller auf einmal offenlegen. Das ist kein Grund, Mandantenfähigkeit zu meiden. Es ist der Grund, sie richtig zu bauen, mit jemandem, der das schon gemacht hat.

Die drei Wege, Mandanten zu trennen

Wenn Entwickler über Mandantenfähigkeit streiten, streiten sie meist darüber, wie getrennt die Daten jedes Mandanten sein sollen. Es gibt drei gängige Ansätze, und sie liegen auf einer gleitenden Skala von "maximale Teilung, niedrigste Kosten" bis "maximale Trennung, höchste Kosten". Sie müssen nicht selbst einen auswählen — aber Sie sollten den Kompromiss verstehen, den Ihr Entwickler in Ihrem Namen eingeht.

1. Geteilte Datenbank, geteilte Tabellen

Die Daten aller liegen in derselben Datenbank, in denselben Tabellen, mit einer verborgenen Markierung — einer "Mandanten-ID" —, die kennzeichnet, welche Zeilen zu wem gehören. Die Software ist dafür verantwortlich, stets nach dieser Markierung zu filtern, sodass Kunde A immer nur die Zeilen von Kunde A sieht. Das ist das günstigste und am besten skalierbare Modell, das die meisten frühen SaaS-Produkte nutzen. Der Haken: Die Trennung lebt im Code, also reicht ein einziger vergessener Filter, damit Daten abfließen. Es verlangt sorgfältige, disziplinierte Entwicklung.

2. Geteilte Datenbank, getrennte Abteile

Eine Datenbank, aber jeder Mandant erhält darin seinen eigenen abgeschotteten Bereich (Entwickler nennen diese "Schemas"). Stärkere Trennung als beim ersten Modell, immer noch einigermaßen effizient und einfacher, etwa die Daten eines Kunden sauber zu exportieren oder zu löschen. Der Kompromiss: mehr bewegliche Teile, die zu verwalten sind, wenn Sie in die Hunderte und Tausende von Mandanten wachsen.

3. Eine eigene Datenbank pro Mandant

Jeder Kunde erhält seine eigene dedizierte Datenbank — das Nächste an einem privaten Haus, während die Anwendung weiterhin geteilt wird. Das ist die stärkste Isolation und die Geschichte, die sich einem sicherheitsbewussten Enterprise-Käufer am leichtesten erzählen lässt. Es ist auch das teuerste im Betrieb, weshalb es eher hochwertigen Kunden, regulierten Branchen oder Produkten vorbehalten bleibt, bei denen eine Datenverwechslung katastrophal wäre.

Der Punkt, den Sie nicht falsch machen dürfen: Isolation

Wenn es einen Ort gibt, an dem Sie sich Sorgen machen sollten, dann hier. Mandantenisolation ist die Garantie, dass Kunde A unter keinen Umständen jemals die Daten von Kunde B sehen, bearbeiten oder auch nur deren Existenz erahnen kann. Es klingt selbstverständlich. Es ist zugleich die häufigste Ursache schwerwiegender Fehler in mandantenfähigen Produkten, denn das Versagen ist lautlos — alles sieht gut aus, bis zu dem Tag, an dem jemand einen Bericht öffnet und darin die Kunden eines Fremden sieht.

Der Grund dafür ist struktureller Natur. Im günstigsten Modell muss jede einzelne Datenbankanfrage daran denken, nach Mandant zu filtern. Machen Sie es zehntausendmal richtig und einmal falsch, und Sie haben ein Leck. Deshalb verlassen sich erfahrene Teams nicht darauf, dass Entwickler sich erinnern — sie bauen die Isolation ins Fundament, sodass das Vergessen unmöglich wird statt nur unwahrscheinlich. Sie müssen nicht verstehen, wie sie das tun. Sie müssen fragen, ob sie es tun.

Es gibt auch einen leiseren Verwandten dieses Problems: den "lauten Nachbarn". Weil Mandanten sich die Infrastruktur teilen, kann ein Kunde, der etwas Lastintensives tut — ein riesiger Import, ein außer Kontrolle geratener Bericht — das System für alle anderen verlangsamen, so wie eine Wohnung, in der alle Hähne laufen, den Wasserdruck im ganzen Gebäude senken kann. Gutes mandantenfähiges Design plant dies mit Limits und fairer Verteilung ein. Es lohnt sich nachzufragen, besonders wenn Sie einige sehr große Kunden erwarten.

Wann Single-Tenant tatsächlich die richtige Wahl ist

Mandantenfähigkeit ist der Standard für SaaS, aber keine Religion. Es gibt ehrliche Gründe, einem Kunden seine eigene getrennte Kopie zu geben, und ein guter Berater sagt Ihnen, wann Sie auf einen davon gestoßen sind, statt alles ins geteilte Modell zu zwingen.

• Ein Kunde in einer regulierten Branche — Gesundheitswesen, Finanzen, Behörden —, dessen Compliance-Vorgaben faktisch verlangen, dass seine Daten nachweisbar getrennt liegen.
• Ein einzelner Großkunde, der genug zahlt, dass sich ein dediziertes Setup lohnt, und der tiefe Anpassungen wünscht, die nicht in das Erlebnis aller anderen überschwappen sollen.
• Daten, die so sensibel sind, dass die Kosten eines mandantenübergreifenden Lecks das Geschäft beenden würden, was maximale Isolation den Mehraufwand wert macht.
• Eine On-Premise-Anforderung, bei der die Software innerhalb der eigenen Mauern des Kunden laufen muss statt in Ihrer Cloud.

Beachten Sie das Muster: Single-Tenant ist die Ausnahme, zu der Sie bewusst greifen, meist für einen bestimmten hochwertigen Kunden, nicht der Standard, auf dem Sie das ganze Unternehmen aufbauen. Schlägt ein Entwickler Single-Tenant für Ihr Standardprodukt vom ersten Tag an vor, lassen Sie sich erklären, warum — meist bedeutet es deutlich höhere Betriebskosten und langsamere Updates, und das soll eine Entscheidung sein, kein Versehen.

Die Fragen, die Sie stellen sollten, bevor jemand Code schreibt

Sie müssen die Architektur nicht entwerfen. Sie müssen sicherstellen, dass die Person, die es tut, über die richtigen Dinge nachgedacht hat. Hier ist die kurze Liste, die ich einem nicht-technischen Gründer für dieses erste Gespräch mitgeben würde — drucken Sie sie aus, stellen Sie die Fragen, beobachten Sie, wie souverän sie beantwortet werden.

1. 1
   Wie halten Sie die Daten der Mandanten getrennt?

   Sie horchen auf eine strukturelle Antwort — das System setzt es durch — nicht auf "wir sind vorsichtig". Das ist die nicht verhandelbare Frage.
2. 2
   Welches Modell nutzen wir, und warum?

   Geteilte Tabellen, getrennte Abteile oder Datenbank pro Mandant. Es gibt keine falsche Antwort, aber es sollte einen Grund geben, der zu Ihren Kunden und Ihrem Budget passt.
3. 3
   Können wir einem Großkunden später dedizierte Isolation bieten?

   Selbst wenn Sie vollständig geteilt starten, sollte der Entwurf Raum lassen, einem großen oder regulierten Kunden ohne Neuaufbau eine stärkere Trennung zu geben.
4. 4
   Was passiert, wenn ein Kunde riesig wird?

   Wie verhindert das System, dass ein lastintensiver Mandant alle anderen ausbremst? Sie wollen hören, dass Szenarien mit lauten Nachbarn bedacht wurden.
5. 5
   Wie exportieren oder löschen wir die Daten eines Kunden sauber?

   Kunden gehen, und das Datenschutzrecht verlangt, dass Sie ihre Daten auf Wunsch entfernen. Das sollte ein einfacher, gut verstandener Vorgang sein, kein Notfall.

Sie benoten nicht das technische Detail der Antworten. Sie prüfen, ob keine dieser Fragen als Überraschung ankommt. Ein Team, das schon mandantenfähige Software gebaut hat, wird auf alle fünf knappe, fast gelangweilte Antworten haben. Zögern bei der ersten oder dritten ist das Signal, das Tempo zu drosseln und tiefer nachzuhaken.

Ein kurzes, realitätsnahes Beispiel

Ein Gründer kam mit einem funktionierenden Prototypen für ein Terminplanungstool für kleine Praxen zu uns. Es hatte bereits drei zahlende Kunden — und ein stilles Problem. Um schnell auf den Markt zu kommen, hatte der erste Entwickler jeder Praxis ihre eigene getrennte Kopie der App gegeben. Drei Kunden, drei Installationen, drei leicht unterschiedliche Versionen, weil jede unterwegs eine kleine Anpassung gewünscht hatte.

Bei drei funktionierte es wunderbar. Der Albtraum des Gründers war der Gedanke an dreißig. Jede Fehlerbehebung bedeutete, sich an drei Stellen einzuloggen. Jede neue Funktion bedeutete drei Deployments und drei zu testende Dinge. Eine neue Praxis einzurichten dauerte von Hand fast eine Woche. Das Modell, das sie zum Start gebracht hatte, deckelte nun ihr Wachstum — genau das Fundamentproblem, um das es in diesem ganzen Artikel geht.

Wir haben nicht alles in einem dramatischen Neuschrieb herausgerissen. Wir haben den Kern auf ein geteiltes mandantenfähiges Fundament neu aufgebaut, mit auf Systemebene durchgesetzter Isolation, die praxisspezifischen Anpassungen als konfigurierbare Einstellungen statt getrennter Codebasen beibehalten und die drei bestehenden Praxen einzeln nacheinander, parallel, migriert, sodass niemand einen beängstigenden Umschalttag hatte. Die Einrichtung einer neuen Praxis ging von einer Woche manueller Arbeit zu einer Self-Service-Anmeldung über. Neue Funktionen erreichen nun jeden Kunden aus einer einzigen Veröffentlichung.

Die Zahlen hier sind beispielhaft, kein Versprechen — jedes Produkt ist anders —, aber das Muster ist typisch: Der Neuaufbau kostete echtes Geld und ein paar Monate, und er hatte sich bereits mit der Handvoll neuer Kunden amortisiert, die sie nun ohne den geringsten Aufwand aufnehmen konnten. Die Lehre, die der Gründer mitnahm, war die günstigere: Hätten sie die fünf Fragen zu Beginn gestellt, hätte es nichts neu aufzubauen gegeben.

Häufige Fragen