Der gebräuchliche deutsche Ausdruck für Multi Tenancy ist Mandantenfähigkeit. Bei einer mandantenfähigen Softwarelösung verwenden mehrere unterschiedliche Kunden beziehungsweise deren Anwender dieselbe Software-Instanz. Sie sind zu jedem Zeitpunkt vollständig voneinander getrennt und nehmen keinen anderen Mandanten am gemeinsam genutzten System wahr.
Das bedeutet, dass die Mandanten niemals die Möglichkeiten haben, auf die Daten der anderen Mandanten zuzugreifen. Die Trennung, Isolierung und Sicherheit der Daten muss aus diesem Grund bereits beim Entwurf des Datenmodells konzipiert werden, um eine Softwarelösung mandantenfähig zu machen.
Für einen Konzern hat eine mandantenfähige Buchhaltungssoftware insbesondere den Vorteil, die Daten jeder Tochtergesellschaft in getrennten Datenbanken zu speichern. Auch beim Einsatz von ERP und CMS Systemen ist Multi Tenancy seit vielen Jahren der Standard.
Wird jedem Kunden eine eigene System-Instanz zur Verfügung gestellt, dann spricht man von einer Single Tenancy Architektur. Diese werden in der Regel auf virtuellen Umgebungen eingesetzt.
Bei Multi Tenancy Architekturen ist eine virtualisierte Umgebung nicht zweckmäßig, da die Software die Trennung der Mandanten bereits enthält. Man erspart sich dadurch den Ressourcen-Overhead, den virtualisierte Umgebungen zwangsläufig mitbringen.
Ein weiterer Vorteil von Multi Tenancy ist die Möglichkeit, alle Daten und Objekte mandantenabhängig oder mandantenübergreifenden zu definieren. Beispielweise sind allgemeingültige Daten wie Postleitzahlen, Städte- und Ländernamen mandantenübergreifend für alle Benutzer zugänglich und müssen nur an einer Stelle gewartet werden. Die Datenbank kann auf drei verschiedene Arten in die Anwendung eingebunden werden. Entweder verwenden alle Mandanten eine gemeinsame Datenbank mit einem gemeinsamen Datenbank-Schema, oder es werden separate Schemata oder sogar separate Datenbanken verwendet.
Eine dezidierte Datenbank pro Mandanten bietet einerseits die maximale Flexibilität und stärkste Isolation der Daten, erfordert aber auch den höchsten Aufwand bei der Wartung, Skalierung und beim Management des Systems.
Eine gemeinsam genutzte Datenbank mit separaten Schemata ist sinnvoll, wenn einige wenige Datenfelder angepasst oder ergänzt werden müssen, die Anwendung aber zum Großteil auf die vorab definierten Datenfelder zugreifen kann. Im Idealfall nutzen alle Mandanten dieselbe Datenbank und Schema, wodurch der geringste Aufwand für die Wartung und den laufenden Betrieb entsteht. Neben der effizienten Nutzung der Hardwareressourcen, ist diese Variante auch am einfachsten zu skalieren.
Bei allen Vorteilen muss man aber auch erwähnen, dass durch die gleichzeitige Nutzung der Anwendung durch viele Nutzer und Mandanten keine Leistungs-Garantie möglich ist.
Es gibt zwar ein paar Möglichkeiten die Auslastung etwas auszubalancieren, diese sind aber nicht vergleichbar mit der Leistungszuweisung in einer virtuellen Umgebung. Auch das Backup und Recovery der Daten ist bei einer Multi Tenancy Lösung sehr komplex, da die Daten nicht so stark voneinander isoliert sind wie in bei einer Multi-Instances-Architektur und beim Recovery einen zusätzlichen Aufwand erfordert. Zusätzlich betreffen fehlerhafte oder fehlgeschlagene Updates gleichzeitig alle Mandanten im System.
Die gebräuchlichere Variante für aktuelle SaaS Lösungen ist auf jeden Fall Multi Tenancy, da die effiziente Ressourcennutzung und geringen Wartungskosten einen entscheidenden Preisvorteil gegenüber Single Tenancy bietet. Nur wenn absolute Flexibilität und Kontrolle notwendig sind, ist eine Single Tenant Infrastruktur in der Regel die bessere Wahl.