Freigeben über

Architekturansätze für Steuerungsebenen in mandantenfähigen Lösungen

  • Artikel

Steuerungsebenen sind ein wichtiger Bestandteil von Software-as-a-Service (SaaS)- und mandantenfähigen Lösungen, insbesondere zur Verwaltung einer Lösung im großen Stil. In der Regel gibt es zwei Hauptkomponenten, aus denen eine Steuerungsebene besteht:

  • Der Mandantenkatalog, in dem wichtige Informationen über Ihre Mandanten gespeichert werden, z. B.:
    • Mandantenkonfiguration.
    • Für Mandantenressourcen bereitgestellte SKUs.
    • Welchen Bereitstellungsstempeln die Mandanten zugeordnet sind.
  • Prozesse zum Verwalten von Änderungen an der Umgebung, die durch Mandantenlebenszyklusereignisse ausgelöst werden. Beispiel: Mandanten-Onboarding, Mandanten-Offboarding und alle erforderlichen regelmäßigen Wartungen.

Eine Steuerungsebene ist selber eine Anwendung. Sie müssen sorgfältig über Ihre Steuerungsebene nachdenken und sie mit der gleichen Strenge und Sorgfalt entwerfen, die Sie auch bei allen anderen Teilen Ihrer Lösung anwenden. Weitere Informationen dazu, was eine Steuerungsebene ist, warum Sie diese verwenden sollten, und Überlegungen zum Entwerfen einer Steuerungsebene finden Sie unter Überlegungen zu mandantenfähigen Steuerungsebenen.

In diesem Artikel werden einige Ansätze beschrieben, die Sie beim Entwerfen und Erstellen einer Steuerungsebene berücksichtigen können. Die Liste der hier beschriebene Ansätze ist nicht vollständig. Obwohl die Ansätze alle gültig sind, gibt es andere gültige Architekturen.

Zu berücksichtigende Ansätze und Muster

In der folgenden Tabelle sind die Unterschiede zwischen einigen der Ansätze zusammengefasst, die Sie für eine Steuerungsebene berücksichtigen können. Manuelle, Low-Code- und benutzerdefinierte Ansätze werden verglichen.

Aspekt Manuell Low-Code-Entwicklung Benutzerdefiniert
Operativer Mehraufwand Hoch Low-medium Niedrig
Häufigkeit von Lebenszyklusereignissen, für die der Ansatz geeignet ist Selten Gelegentlich – oft Oft
Zeit und Komplexität für die Implementierung Niedrig Mittel Hoch
Verantwortlichkeiten für die Wartung der Steuerungsebene Niedrig Mittel Hoch
Prüfbarkeit Niedrig Mittel Hoch
Risiko von Inkonsistenzen Hoch Mittel – niedrig Niedrig

Manuelle Prozesse

Es ist nicht immer wichtig, eine vollständig automatisierte Steuerungsebene zu erstellen, insbesondere wenn Sie neu beginnen und nur über eine kleine Anzahl von Mandanten verfügen.

Möglicherweise behalten Sie Ihren Mandantenkatalog an einem zentralen Ort, z. B. in einer Excel-Arbeitsmappe oder einer JSON-Datei, die an einem Ort gespeichert ist, auf den Ihr Team zugreifen kann. Unabhängig vom Format empfiehlt es sich, die Informationen auf strukturierte Weise zu speichern, damit Sie einfach und programmgesteuert mit den Daten arbeiten können.

Hinweis

Eine manuelle Steuerungsebene ist eine hervorragende Möglichkeit, mit der Verwaltung Ihrer mandantenfähigen Anwendung zu beginnen, eignet sich jedoch nur für eine kleine Anzahl von Mandanten (weniger als 5–10). Der Verwaltungsaufwand und das Risiko von Inkonsistenzen erhöhen sich mit jedem Mandanten, für den Sie manuell ein Onboarding durchführen. Sie sollten diesen Ansatz nur verwenden, wenn Sie nur wenige Mandanten haben und kein automatisiertes oder Self-Service-Onboarding benötigen.

Für Prozesse wie Mandanten-Onboarding und Wartungsaktivitäten:

  • Erstellen Sie nach Möglichkeit Skripte oder automatisierte Pipelines, auch wenn Sie diese manuell ausführen. Mithilfe von Skripten oder Pipelines stellen Sie sicher, dass die Schritte für jeden Mandanten konsistent ausgeführt werden.
  • Für Aufgaben, für die Sie anfangs keine Skripte erstellen können, dokumentieren Sie den Prozess gründlich und detailliert. Dokumentieren Sie das Wie und das Warum. Wenn jemand die Aufgabe in der Zukunft automatisiert, sollten sie ein gutes Verständnis für beide Punkte haben.

Das folgende Diagramm veranschaulicht eine Möglichkeit, manuelle Prozesse für eine anfängliche Steuerungsebene zu verwenden:

Diagramm, in dem eine Möglichkeit zur Nutzung von Skripts und weitere manuelle Verfahren für eine Steuerungsebene zu sehen sind

Laden Sie eine Visio-Datei dieser Architektur herunter.

Vorteile eines manuellen Ansatzes

  • Einfach: Dokumentation, Skripte und Pipelines sind einfach zu entwickeln und zu ändern. Sie eignen sich daher besonders gut für die Entwicklung Ihrer Prozesse, da sie schnell iteriert und weiterentwickelt werden können.
  • Niedrige Kosten: Die Wartung und Ausführung eines manuellen Ansatzes ist kostengünstig.
  • Überprüft Ihren Prozess: Selbst wenn Sie später einen stärker automatisierten Ansatz verwenden wollen, ist es eine gute Möglichkeit, mit einem manuellen Ansatz zu beginnen, um Ihre Wartungsstrategie zu überprüfen, bevor Sie Zeit in die Entwicklung einer robusteren Automatisierung investieren.

Nachteile eines manuellen Ansatzes

  • Mangel an Kontrolle: Dieser Ansatz beruht darauf, dass alle Beteiligten das Richtige tun. Jemand könnte von den vorgeschriebenen Prozessen abweichen, entweder versehentlich oder absichtlich. Jede Variation des Prozesses erhöht das Risiko von Inkonsistenzen in Ihrer Umgebung, was die laufende Verwaltung wesentlich schwieriger macht.
  • Herausforderungen bei der Zugriffssteuerung: Wenn Sie diesen Ansatz verwenden, müssen Sie in der Regel breit angelegten, hoch berechtigten Zugriff für alle Benutzer gewähren, die Ihre Lösung betreiben, was es schwierig macht, die bewährten Methoden für die Zugriffssegmentierung zu befolgen.
  • Skalierbarkeit: Die zum Ausführen manueller Prozesse erforderliche Arbeit skaliert mit der Anzahl der Mandanten, die Sie verwalten müssen.
  • Testbarkeit: Manuelle Prozesse sind schwierig zu überprüfen und zu testen.

Gründe für eine Abkehr von einem manuellen Ansatz

  • Wenn Ihr Team nicht mit der Menge an Arbeit Schritt halten kann, die es für die Wartung der Anwendung leisten muss. Wenn Ihre Anzahl von Mandanten beispielsweise über einen kritischen Punkt hinaus skaliert, der für die meisten Teams zwischen 5 und 10 Mandanten liegt.
  • Wenn Sie ein Mandantenwachstum über eine kritische Anzahl von Mandanten hinaus erwarten und sich auf die Arbeit vorbereiten müssen, die für die Verwaltung dieser Anzahl von Mandanten erforderlich ist.
  • Wenn Sie das Risiko von Inkonsistenzen mindern müssen. Sie könnten zum Beispiel feststellen, dass einige Fehler auftreten, weil jemand die Prozesse nicht richtig befolgt oder weil die Prozesse zu unklar sind. Das Risiko der Inkonsistenz nimmt üblicherweise mit der manuellen Einbindung weiterer Mandanten und mit zunehmender Größe Ihres Teams zu.

Low-Code-Steuerungsebene

Eine Low-Code- oder No-Code-Steuerungsebene setzt auf einer Plattform auf, die geschäftliche Prozesse automatisiert und Daten nachverfolgt. Es sind zahlreiche Plattform erhältlich, die Ihnen diese Aufgaben ermöglichen, ohne dass individuelle Programmierung benötigt werden.

Microsoft Power Platform ist ein Beispiel für eine dieser Plattformen. Wenn Sie Power Platform verwenden, behalten Sie möglicherweise Ihren Mandantenkatalog in Dynamics 365, Dataverse oder Microsoft 365 bei. Denkbar ist auch, den Katalog an Mandanten, den Sie für manuelle Verfahren nutzen, weiterhin einzusetzen, falls Sie nicht gleich alles auf einmal automatisieren möchten.

Um Mandanten einzubinden und zu warten, können Sie mit Power Automate Workflows ausführen, die Mandanten verwalten und konfigurieren, Pipelines oder API-Aufrufe auslösen und weitere Aufgaben erfüllen. Außerdem können Sie mit Power Automate Ihren Katalog der Mandanten auf Änderungen überprüfen, sofern diese Daten für Power Automate zugänglich sind. Wenn Sie einen manuellen Mandantenkatalog verwenden, können Power Automate-Workflows auch manuell ausgelöst werden. Sie können sich entscheiden, manuelle Genehmigungsschritte in Ihre Workflows aufzunehmen, wenn Sie jemand aus Ihrem Team benötigen, um etwas zu überprüfen oder zusätzliche Schritte auszuführen, die nicht vollständig automatisiert werden können.

Darüber hinaus können Sie mit dieser Herangehensweise Ihren Kunden eine Option für die Self-Service-Anmeldung bieten. Lassen Sie dafür zu, dass Ihre Webanwendung direkt Datensätze in Ihren Mandantenkatalog einpflegen kann, ohne dass ein manueller Eingriff nötig ist.

Das folgende Diagramm veranschaulicht, wie Sie mithilfe der Microsoft Power Platform eine Steuerungsebene mit Self-Service-Registrierung erstellen könnten:

Diagramm, in dem eine Möglichkeit zu sehen ist, wie Sie Power Automate und Dataverse als Low-Code-Steuerungsebene nutzen können.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Vorteile eines Low-Code-Ansatzes

  • Einfach: Die Erstellung von Low-Code-Workflows und ihre Einbindung in die Systeme der Umgebung sind schnell und kosteneffizient umsetzbar.
  • Verwendet Plattformtools: Sie können native Plattformfeatures verwenden, um Daten zu speichern, Verwaltungsportale für die Verwendung durch Ihr Team zu erstellen und die Workflows während der Ausführung zu überwachen. Indem Sie native Funktionen der Plattform nutzen, müssen Sie viele Komponenten nicht selbst entwickeln.
  • Anpassbar: Wenn Sie mehr Anpassungen benötigen, können Sie Ihre Workflows in der Regel mit benutzerdefiniertem Code und Prozessen erweitern. Sie könnten beispielsweise Power Automate verwenden, um einen Bereitstellungsworkflow in GitHub Actions auszulösen, oder Sie können Azure Functions aufrufen, um Ihren eigenen Code auszuführen. Auf diese Weise wird auch eine stufenweise Implementierung unterstützt.
  • Geringer Mehraufwand: Low-Code-Dienste sind in der Regel vollständig verwaltet, sodass Sie keine Infrastruktur verwalten müssen.

Nachteile eines Low-Code-Ansatzes

  • Erforderliche Expertise: Um Low-Code-Plattformen zum Erstellen von Prozessen zu verwenden und diese Plattformen effektiv zu nutzen, benötigen Sie in der Regel proprietäres Wissen. Viele Organisationen verwenden diese Tools bereits, sodass Ihr Team möglicherweise bereits über die erforderliche Expertise verfügt, vielleicht aber auch nicht. Sie sollten überlegen, ob Sie Ihr Team schulen müssen, um diese Plattformen effektiv nutzen zu können.
  • Verwaltung: Es kann eine Herausforderung sein, die Verwaltung großer Mengen an Low-Code-Konfigurationen zu bewältigen.
  • Testbarkeit: Überlegen Sie, wie Sie Änderungen an der Steuerungsebene testen und höher stufen können. In einer verwalteten Plattform ist das Erstellen eines typischen DevOps-Prozesses zum testen und höher stufen von Änderungen schwieriger, da Änderungen normalerweise über die Konfiguration und nicht über Code vorgenommen werden.
  • Entwurf: Überlegen Sie sorgfältig, wie Sie nicht-funktionale Anforderungen wie Sicherheit und Zuverlässigkeit erfüllen können. Diese Anforderungen werden häufig auf einer Low-Code-Plattform für Sie verwaltet.

Gründe für eine Abkehr von einem Low-Code-Ansatz

  • Schließlich können Ihre Anforderungen so komplex werden, dass Sie diese nicht mehr sinnvoll in eine Low-Code-Lösung einbauen können. Wenn Sie Tooleinschränkungen umgehen müssen, um Ihre Anforderungen zu erfüllen, ist es wahrscheinlich sinnvoll, sich von einer verwalteten Lösung in Richtung einer benutzerdefinierten Steuerungsebene zu bewegen.

Benutzerdefinierte Steuerungsebene

Sie können auch die Erstellung Ihrer eigenen, vollständig benutzerdefinierten Steuerungsebene in Betracht ziehen. Diese Option bietet die größte Flexibilität und Leistung, erfordert aber auch die meiste Arbeit. Der Mandantenkatalog wird in der Regel in einer Datenbank gespeichert. Sie arbeiten in diesem Fall nicht direkt mit dem Katalog, sondern verwalten ihn stattdessen über eine Verwaltungsschnittstelle, die eine benutzerdefinierte Anwendung oder ein System wie die CRM (Customer Relationship Management)-Anwendung Ihrer Organisation sein könnte.

In der Regel erstellen Sie eine Reihe von Komponenten für die Steuerungsebene, die für alle Verwaltungsfunktionen Ihres Mandanten konzipiert sind. Diese Komponenten können ein Verwaltungsportal oder eine andere Benutzeroberfläche, eine API und Komponenten für die Hintergrundverarbeitung umfassen. Wenn Sie z. B. Code oder Infrastruktur bereitstellen müssen, wenn Mandantenlebenszyklusereignisse auftreten, können Bereitstellungspipelines auch Ihre Steuerungsebene bilden.

Stellen Sie sicher, dass alle zeitintensiven Prozesse geeignete Tools verwenden. Sie können beispielsweise Durable Functions oder Azure Logic Apps für Komponenten verwenden, die das Onboarding von Mandanten oder Bereitstellungen orchestrieren, oder für Komponenten, die mit externen Systemen kommunizieren müssen.

Wie der Low-Code-Ansatz können Sie Ihren Kunden mit diesem Ansatz die Self-Service-Registrierung bieten, indem Ihre Webanwendung das direkte Hinzufügen von Datensätzen zu Ihrem Mandantenkatalog ermöglicht, ohne menschliches Eingreifen.

Das folgende Diagramm zeigt eine Möglichkeit zum Erstellen einer einfachen benutzerdefinierten Steuerungsebene, welche eine Self-Service-Registrierung bietet:

Diagramm, in dem eine Steuerungsebene gezeigt wird, die mit Durable Functions, einer SQL-Datenbank und einem Service Bus erstellt wurde.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Vorteile eines benutzerdefinierten Ansatzes

  • Volle Flexibilität und Anpassbarkeit: Sie haben die vollständige Kontrolle darüber, was Ihre Steuerungsebene tut und können sie ändern, wenn sich Ihre Anforderungen ändern.
  • Testbarkeit: Sie können einen Standard-Softwareentwicklungslebenszyklus (Software Development Lifecycle, SDLC) für Ihre Steuerungsebenenanwendung verwenden und normale Ansätze für Tests und Bereitstellungen implementieren, genau wie bei Ihren Hauptanwendungen.

Nachteile eines benutzerdefinierten Ansatzes

  • Wartungsverantwortlichkeiten: Dieser Ansatz erfordert mehr Wartungsaufwand, da Sie alles selbst erstellen müssen. Eine Steuerungsebene ist ebenso wichtig wie jeder andere Teil Ihrer Anwendung. Sie müssen Ihre Steuerungsebene sorgfältig und gewissenhaft entwickeln, testen und betreiben, damit ihre Zuverlässigkeit und Sicherheit gewährleistet wird.

Hybridansätze

Sie können auch die Verwendung eines Hybridansatzes in Betracht ziehen. Sie könnten eine Kombination aus manuellen und automatisierten Systemen verwenden, oder eine verwaltete Plattform wie Microsoft Power Platform, und diese mit benutzerdefinierten Anwendungen erweitern. Möglicherweise bietet sich ein hybrider Ansatz an, falls es erforderlich ist, dass die Steuerungsebene individuell anpassbar sein muss, Sie aber nicht zwangsläufig ein komplett maßgeschneidertes System entwickeln und warten möchten. Denken Sie daran, dass Ihre automatisierten Anpassungen an Ihre manuellen Prozesse oder Ihre verwaltete Plattform irgendwann genau so komplex wie ein vollständig benutzerdefiniertes System werden können. In jedem Unternehmen gilt ein anderer Kipppunkt. Wenn sich aber herausstellt, dass die Verwaltung eines hybriden Ansatzes zu aufwendig ist, sollten Sie überlegen, auf ein komplett maßgeschneidertes System umzusteigen.

Schrittweise Implementierung

Auch wenn Sie wissen, dass Sie ihre Steuerungsebene letztendlich automatisieren möchten, müssen Sie nicht unbedingt mit diesem Ansatz beginnen. Ein gängiger Ansatz während den ersten Phasen der Erstellung Ihrer Anwendung besteht darin, mit einer manuellen Steuerungsebene zu beginnen. Wenn sich Ihre Anwendung weiterentwickelt und mehr Mandanten integriert, sollten Sie mit der Identifizierung von Engpässen beginnen und diese bei Bedarf automatisieren und zu einem Hybridansatz wechseln. Während Sie mehr automatisieren, könnten Sie schließlich eine vollständig automatisierte Steuerungsebene haben.

Zu vermeide Antimuster

  • Zu langes Verlassen auf manueller Prozesse. Obwohl es sinnvoll ist, zu Beginn oder wenn Sie eine geringe Anzahl von Mandanten haben und eine relativ einfache Verwaltung erfordern, manuelle Prozesse zu verwenden, müssen Sie planen, wie Sie beim Wachstum auf eine automatisierte Lösung skalieren können. Wenn zur Verwaltung der manuellen Verfahren die Einstellung weiterer Teammitglieder nötig ist, ist es an der Zeit, dass Sie einzelne Teile der Steuerungsebene automatisieren.
  • Verwenden unangemessener Tools für zeitintensive Workflows. Vermeiden Sie beispielsweise die Verwendung von Azure-Standardfunktionen, synchroner API-Aufrufe oder anderer Tools, die ein Zeitlimit für die Ausführung zeitintensiver Vorgänge haben, z. B. Azure Resource Manager-Bereitstellungen oder Mehrschritt-Orchestrierungen. Nutzen Sie dafür Azure Logic Apps, Durable Functions und weitere Tools, die Workflows mit langer Ausführungsdauer oder Abfolgen mehrerer Vorgänge ausführen können. Weitere Informationen finden Sie unter Azure Functions-Leistung und -Zuverlässigkeit und Asynchrones Anforderung/Antwort-Muster.

Beitragende

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

Hauptautoren:

Andere Mitwirkende:

Nächste Schritte