Als solche bezeichnet man in der IT eine Software-Architektur, welche zwar eine Bereitstellung für viele unterschiedliche Mandanten vorsieht, allerdings auf eine Art und Weise, dass die Systeme komplett voneinander abgeschottet sind.
Es wird also nix miteinander geteilt, weder Netzwerk Ranges, noch Adressräume im flüchtigen Speicher, noch Datenbanken, Message Queues, FTP-Server, Festplaten-Speicher, Logfiles, Zertifikate, Binaries uvm.
Die Bereitstellung eines neuen Software Releases von Gridware erfolgt daher separat pro Mandant. Natürlich geschieht das nicht manuell, sondern Deployment und Ausrollen der kompletten Infrastruktur ist voll-automatisiert.
Analog dazu setzen wir neue Mandanten auf Knopfdruck auf, nachdem ein paar Konfigurations-Dateien angepasst wurden und Bilder, Farben etc. hinterlegt wurden. Diverse Test- und Preprod-Systeme verhalten sich dadurch auch zu 99% gleich und sichern die Qualität.
Womit wir beim letzten Punkt sind: Selbstschutz! Ein Bug in der Software darf niemals dazu führen, dass ein Datenleck entsteht und z.B. ein Mandant die Daten eines anderen sehen kann. Das ist in der Vergangenheit schon in dem einen oder anderen Online-Banking- Tool passiert und – wenn nicht unmittelbar schädlich – dann doch hochnotpeinlich und damit indirekt geschäftsschädigend. Nun kann man von einer Bank natürlich nicht verlangen, eine eigene Software-Instanz pro Kontoinhaber zu erstellen, im B2B Kontext allerdings, wo wir uns bewegen, ist das die pragmatischste Antwort.
Wieder anders ist das in der Beziehung von Mandanten zu Unter-Mandanten. Da hier gemeinsam Nutzer verwaltet und Infrastruktur betrieben wird, hängen die Geschäftsprozesse und damit Daten letztlich so eng zusammen, dass man dies in einem System belässt, weil man die Daten untereinander referenzieren muss. Das gilt dann analog auch für Unter-Untermandanten und so fort.
Schließlich ermöglicht diese SW-Architektur auch die Integration in die IT-Landschaft unserer Kunden mittels E2E-Verschlüsselung.
