Überlegungen zum Mandantenlebenszyklus in einer mehrinstanzenfähigen Lösung

  • Artikel

Wenn Sie eine mehrinstanzenfähige Architektur in Betracht ziehen, ist es wichtig, alle verschiedenen Phasen im Lebenszyklus eines Mandanten zu berücksichtigen. Auf dieser Seite erhalten technische Entscheidungsträger Informationen zu den Phasen des Lebenszyklus und zu den wichtigen Überlegungen für jede Phase.

Testmandanten

Berücksichtigen Sie bei der Erstellung von SaaS-Lösungen, dass viele Kunden Testversionen wünschen oder benötigen, bevor sie sich zum Kauf einer Lösung entscheiden.

Testversionen bringen die folgenden besonderen Überlegungen mit sich:

  • Anforderungen an den Dienst: Sollen bei Testversionen die gleichen Anforderungen an Datensicherheit, Leistung und Servicelevel gelten wie bei den Daten der Kunden der Vollversion?
  • Infrastruktur: Soll für Testmandanten die gleiche Infrastruktur verwendet werden wie für Kunden der Vollversion, oder soll für Testmandanten eine dedizierte Infrastruktur vorhanden sein?
  • Migration: Wie können Kunden, die Ihren Dienst nach einer Testphase erwerben, die Daten von ihren Testmandanten zu ihren kostenpflichtigen Mandanten migrieren?
  • Anforderungsprozess: Gibt es Einschränkungen in Bezug auf die Personen, die eine Testversion anfordern können? Wie können Sie den Missbrauch Ihrer Lösung verhindern? Können Testmandanten automatisch erstellt werden, oder muss Ihr Team bei jeder Anforderung einbezogen werden?
  • Einschränkungen: Welche Einschränkungen möchten oder müssen Sie Testkunden auferlegen (beispielsweise zeitliche Einschränkungen, Featureeinschränkungen oder Leistungseinschränkungen)?

In bestimmten Situationen kann ein Freemium-Preismodell eine Alternative zur Bereitstellung von Testversionen sein.

Durchführen des Onboardings neuer Mandanten

Berücksichtigen Sie beim Onboarding eines neuen Mandanten Folgendes:

  • Prozess: Ist das Onboarding ein Self-Service-Prozess, ein automatisierter Prozess oder ein manueller Prozess?
  • Datenresidenz: Hat der Mandant bestimmte Anforderungen an die Datenresidenz? Sind z. B. Bestimmungen zur Datenhoheit wirksam?
  • Compliance: Muss der Mandant Compliancestandards wie PCI-DSS oder HIPAA erfüllen?
  • Notfallwiederherstellung: Hat der Mandant bestimmte Anforderungen an die Notfallwiederherstellung – beispielsweise eine Recovery Time Objective (RTO) oder eine Recovery Point Objective (RPO)? Unterscheiden sich diese von den Garantien, die Sie anderen Mandanten bieten?
  • Informationen: Welche Informationen benötigen Sie, um ein vollständiges Onboarding des Mandanten durchführen zu können? Müssen Sie beispielsweise den offiziellen Namen der Organisation kennen? Benötigen Sie das Firmenlogo, um die Anwendung mit Branding versehen zu können? Falls ja: Welche Dateigröße und welches Format benötigen Sie?
  • Abrechnung: Bietet die Plattform verschiedene Preisoptionen und Abrechnungsmodelle?
  • Umgebungen: Benötigt der Mandant Präproduktionsumgebungen? Und gibt es feste Erwartungen an die Verfügbarkeit für diese Umgebung? Ist sie vorübergehend (bei Bedarf) oder immer verfügbar?

Nach dem Onboarding geht es für die Mandanten wie gewohnt weiter. Aber auch dann können noch mehrere wichtige Lebenszyklusereignisse auftreten.

Aktualisieren der Infrastruktur von Mandanten

Sie müssen sich überlegen, wie Sie Updates auf die Infrastruktur Ihrer Mandanten anwenden. Updates können zu unterschiedlichen Zeiten auf verschiedene Mandanten angewendet werden.

Weitere Überlegungen zum Aktualisieren der Bereitstellungen von Mandanten finden Sie unter Updates.

Skalieren der Infrastruktur von Mandanten

Überlegen Sie, ob Ihre Mandanten saisonale Geschäftsmuster aufweisen oder anderweitig den Verbrauch für Ihre Lösung ändern.

Wenn Sie beispielsweise eine Lösung für Einzelhändler anbieten, ist davon auszugehen, dass in einigen geografischen Regionen zu bestimmten Zeiten des Jahres besonders viel Betrieb herrscht, während es zu anderen Zeiten ruhig ist. Überlegen Sie, ob diese Saisonalität Auswirkungen auf den Entwurf und die Skalierung Ihrer Lösung hat. Berücksichtigen Sie mögliche Auswirkungen der Saisonalität auf Noisy Neighbor-Probleme – etwa, wenn es bei einem Teil der Mandanten zu einem plötzlichen und unerwarteten Lastanstieg kommt, der die Leistung für andere Mandanten beeinträchtigt. Ergreifen Sie ggf. Abhilfemaßnahmen. Beispiele wären die Skalierung der Infrastruktur einzelner Mandanten, die Verschiebung von Mandanten zwischen Bereitstellungen sowie die Bereitstellung von ausreichender Kapazität zur Bewältigung von Datenverkehrsspitzen und -tälern.

Verschieben von Mandanten zwischen Infrastrukturen

Eine Verschiebung von Mandanten zwischen Infrastrukturen kann beispielsweise aus folgenden Gründen erforderlich sein:

  • Ausgleich: Sie verwenden einen vertikal partitionierten Ansatz, um Ihre Mandanten der Infrastruktur zuzuordnen, und müssen einen Mandanten in eine andere Bereitstellung verschieben, um die Last auszugleichen.
  • Upgrades: Ein Mandant führt ein Upgrade seiner SKU oder seines Tarif durch und muss in eine dedizierte Einzelmandantenbereitstellung mit höherer Isolation gegenüber anderen Mandanten verschoben werden.
  • Migrationen: Ein Mandant möchte, dass seine Daten in einen dedizierten Datenspeicher verschoben werden.
  • Regionale Verschiebungen: Ein Mandant möchte, dass seine Daten in eine neue geografische Region verschoben werden. Dies kann bei Unternehmensübernahmen, bei Gesetzesänderungen oder bei einer Veränderung der geopolitischen Lage der Fall sein.

Überlegen Sie, wie Sie die Daten Ihrer Mandanten verschieben und Anforderungen an die neue Infrastruktur umleiten, die ihre Instanz hostet. Bedenken Sie auch, ob das Verschieben eines Mandanten ggf. zu Downtime führt, und stellen Sie sicher, dass sich die Mandanten dieses Risikos vollständig bewusst sind.

Zusammenführen und Aufteilen von Mandanten

Es ist verlockend, Mandanten oder Kunden als statische, unveränderliche Entitäten zu betrachten. In Wirklichkeit ist dies jedoch häufig nicht der Fall. Beispiel:

  • In Geschäftsszenarien können Unternehmen aufgekauft werden oder fusionieren, einschließlich Unternehmen in verschiedenen geografischen Regionen.
  • Ähnlich kann es in Unternehmensszenarien zu Aufspaltungen oder Veräußerungen von Unternehmen kommen.
  • In Consumerszenarien können sich einzelne Benutzer Familien anschließen oder diese verlassen.

Überlegen Sie, ob Sie Funktionen zur Verwaltung der Zusammenführung und Trennung von Daten, Benutzeridentitäten und Ressourcen bereitstellen müssen. Berücksichtigen Sie außerdem, wie sich der Datenbesitz auf die Behandlung von Zusammenführungs- und Aufteilungsvorgängen auswirkt. Nehmen wir zum Beispiel eine Consumerfotoanwendung, die für Familien entwickelt wurde, um Fotos miteinander zu teilen. Befinden sich die Fotos im Besitz der einzelnen Familienmitglieder, die sie beigetragen haben, oder der Familie als Ganzes? Wenn Benutzer die Familie verlassen, sollten ihre Daten entfernt werden oder im Dataset der Familie verbleiben? Wenn sich Benutzer einer anderen Familie anschließen, sollten ihre alten Fotos sie begleiten?

Durchführen des Offboardings von Mandanten

Es ist auch unvermeidlich, dass Mandanten gelegentlich aus Ihrer Lösung entfernt werden müssen. In einer mehrinstanzenfähigen Lösung bringt dies einige wichtige Überlegungen mit sich, einschließlich der folgenden:

  • Aufbewahrungszeitraum: Wie lange sollen die Kundendaten aufbewahrt werden? Gibt es gesetzliche Anforderungen zum dauerhaften Löschen von Daten nach einem bestimmten Zeitraum?
  • Erneutes Onboarding: Soll Kunden ein erneutes Onboarding ermöglicht werden?
  • Ausgleich: Muss die Zuordnung von Mandanten zur Infrastruktur neu ausbalanciert werden (bei Verwendung einer gemeinsam genutzten Infrastruktur)?

Deaktivieren und erneutes Aktivieren von Mandanten

Es gibt Situationen, in denen das Konto eines Kunden möglicherweise deaktiviert oder erneut aktiviert werden muss. Beispiel:

  • Der Kunde hat Deaktivierung angefordert. In einem Consumersystem kann ein Kunde das Abonnement kündigen.
  • Dem Kunden kann keine Rechnung gestellt werden, und Sie müssen das Abonnement deaktivieren.

Deaktivierung unterscheidet sich von Offboarding dadurch, dass sie als vorübergehender Zustand vorgesehen ist. Nach einem bestimmten Zeitraum können Sie für einen deaktivierten Mandanten jedoch ggf. Offboarding durchführen.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

  • John Downs | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Überlegungen zu den Preismodellen, die Sie für Ihre Lösung verwenden.