Freigeben über

Empfehlungen für ein Design mit Fokus auf Einfachheit und Effizienz

Gilt für diese Empfehlungen bezüglich der Power Platform Zuverlässigkeits-Checkliste:

RE:01 Gestalten Sie Ihren Workload so, dass er mit Ihren Geschäftszielen übereinstimmt und vermeiden Sie unnötige Komplexität oder Mehraufwand. Treffen Sie mit einem praktischen und ausgewogenen Ansatz Designentscheidungen, die die gewünschten Ergebnisse bereitstellen. Beschränken Sie Ihr Design auf das Notwendigste, um Ineffizienzen und potenzielle Probleme zu reduzieren.

In dieser Anleitung werden Empfehlungen zur Minimierung unnötiger Komplexität und unnötigen Mehraufwands beschrieben, um Ihre Workloads einfach und effizient zu halten. Wählen Sie die besten Komponenten zur Ausführung der erforderlichen Workload-Aufgaben aus, um die Zuverlässigkeit Ihres Workloads zu optimieren. Um Ihren Entwicklungs- und Verwaltungsaufwand zu verringern, nutzen Sie die Effizienzvorteile, die Ihnen plattformseitig bereitgestellte Dienste bieten. Mit diesem Design können Sie eine Workload-Architektur erstellen, die belastbar, wiederholbar, skalierbar und verwaltbar ist.

Definitionen

Begriff Definition
Arbeitsauslastung Eine diskrete Fähigkeit oder Berechnungsaufgabe, die Sie logisch von anderen Aufgaben trennen können.

Wichtige Designstrategien

Ein zentraler Grundsatz bei der Konstruktion auf Zuverlässigkeit besteht darin, die Dinge einfach und effizient zu halten. Konzentrieren Sie sich bei der Gestaltung Ihrer Workload auf die Erfüllung der Geschäftsanforderungen, um das Risiko unnötiger Komplexität oder übermäßigen Mehraufwands zu verringern. Beachten Sie die Empfehlungen in diesem Artikel, um Entscheidungen zu Ihrem Design zu treffen und eine schlanke, effiziente und zuverlässige Workload zu schaffen. Unterschiedliche Workloads haben möglicherweise unterschiedliche Anforderungen an Verfügbarkeit, Skalierbarkeit, Datenkonsistenz und Notfallwiederherstellung.

Sie müssen jede Designentscheidung mit einer Geschäftsanforderung begründen. Dieses Designprinzip erscheint vielleicht offensichtlich, es ist jedoch für die Workload-Gestaltung von entscheidender Bedeutung. Unterstützt Ihre Workload Millionen oder einige tausend Benutzende? Gibt es große Verkehrsspitzen oder eine gleichbleibende Workload? In welchem Umfang sind Ausfälle akzeptabel? Diese Designüberlegungen basieren auf Geschäftsanforderungen.

Nachteil: Eine komplexe Lösung kann mehr Funktionen und Flexibilität bieten, aber sie könnte die Verlässlichkeit der Workload beeinflusen, weil sie mehr Koordination, Kommunikation und Verwaltung von Komponenten erfordert. Andererseits kann es sein, dass eine einfachere Lösung die Erwartungen der Benutzer nicht ganz erfüllt oder sich bei zunehmender Workload negativ auf die Erweiterbarkeit auswirkt.

Kollaborative Designübungen

Zusammenarbeit mit Stakeholdern bei folgenden Aufgaben:

  • Definieren Sie für Ihre Workload und deren Komponenten eine Kritikalitätsstufe und weisen Sie diese zu. Mithilfe dieser Übung können Sie die erforderlichen Komponenten und den besten Ansatz zum Erreichen des erforderlichen Resilienzniveaus bestimmen. Weitere Informationen finden Sie unter Definieren von Anwendungsebenen.

  • Definieren Sie funktionale und nicht funktionale Anforderungen. Funktionale Anforderungen definieren die Funktionen und das Verhalten des Systems. Sie werden vom Benutzer angegeben und in Anwendungsfällen erfasst. Nichtfunktionale Anforderungen definieren die Leistungs- und Qualitätsmerkmale des Systems. Stellen Sie sicher, dass Sie nichtfunktionale Anforderungen wie Verfügbarkeit, Compliance, Datenaufbewahrung/-speicherort, Leistung, Datenschutz, Wiederherstellungszeit, Sicherheit und Skalierbarkeit verstehen. Diese Anforderungen beeinflussen Designentscheidungen und die Auswahl der Technologie.

    Hier sind einige Beispiele für funktionale und nicht funktionale Anforderungen im Zusammenhang mit einer Workload zur Bearbeitung von Spesenabrechnungen:

    Funktionale Anforderungen Nicht funktionale Anforderungen
    Die Workload sollte es Benutzern ermöglichen, sich mit ihren Anmeldeinformationen anzumelden und nur auf ihre persönlichen Daten zuzugreifen. Die Workload sollte mindestens 99,9 % der Zeit verfügbar sein.
    Der Workload sollte ein Dashboard enthalten, das einen Überblick über offene, genehmigte und abgelehnte Spesenabrechnungen bietet. Die Workload sollte den relevanten Bestimmungen und Standards für Datenschutz und Privatsphäre entsprechen.
    Die Workload sollte Sicherungs- und Wiederherstellungsvorgänge für die Workloaddaten unterstützen. Die Workload sollte für die meisten Benutzeranforderungen eine Antwortzeit von weniger als 5 Sekunden aufweisen.
    Die Workload sollte Benachrichtigungen an Benutzer und Administratoren senden, wenn bestimmte Ereignisse oder Schwellenwerte ausgelöst werden. Die Workload sollte über ein hohes Maß an Sicherheit und Verschlüsselung für die übertragenen und gespeicherten Daten verfügen.

    Weitere Informationen finden Sie im Schulungsmodul mit dem Titel Arbeiten mit Anforderungen für Microsoft Power Platform und Dynamics 365.

  • Teilen Sie die Workload in Komponenten auf. Während des Ermittlungs- und Anforderungserfassungsprozesses sollten einige Lösungsideen klar werden. Identifizieren Sie Lösungskomponenten, aus denen die vorgeschlagene Lösung bestehen könnte, um Ihre Geschäftsanforderungen zu erfüllen. Priorisieren Sie bei Ihrem Design Einfachheit, Effizienz und Zuverlässigkeit. Bestimmen Sie die Komponenten, die Sie zur Unterstützung Ihrer Workload benötigen. Heben Sie hervor, wo sofort einsatzbereite Funktionen genutzt werden können und wo möglicherweise eine kundenspezifische Entwicklung erforderlich ist.

  • Verwenden Sie die Fehlermöglichkeitsanalyse, um einzelne Fehlerpunkte und potenzielle Risiken zu identifizieren. Verschaffen Sie sich ein klares Bild von der Risikotoleranz Ihres Unternehmens. Weitere Informationen finden Sie unter Empfehlungen zur Durchführung einer Fehlermöglichkeitsanalyse.

  • Definieren Sie Verfügbarkeits- und Wiederherstellungsziele für Ihre Workload, um die Architekturentscheidungen zu treffen. Zu den Geschäftsmetriken gehören Service-Level-Ziele (SLOs), Vereinbarungen zum Servicelevel (SLAs), mittlere Wiederherstellungszeit (MTTR), mittlere ausfallfreie Betriebszeit (MTBF), Wiederherstellungszeitziele (RTOs) und Wiederherstellungspunktziele (RPOs). Definieren Sie Zielwerte für diese Metriken. Diese Übung erfordert möglicherweise Kompromisse und gegenseitiges Verständnis zwischen den Technologie- und Geschäftsteams, um sicherzustellen, dass die Ziele jedes Teams den Geschäftszielen entsprechen und realistisch sind. Weitere Informationen finden Sie unter Empfehlungen zum Definieren von Zuverlässigkeitszielen. Power Platform-SLAs enthalten die Verpflichtungen von Microsoft hinsichtlich Verfügbarkeit und Konnektivität. Verschiedene Dienste haben unterschiedliche SLAs und manchmal haben SKUs innerhalb eines Dienstes unterschiedliche SLAs. Weitere Informationen finden Sie unter Vereinbarungen zum Servicelevel für Onlinedienste.

Zusätzliche Designempfehlungen

Sie können die folgenden Empfehlungen ohne Einbeziehung der Stakeholder umsetzen:

  • Streben Sie bei Ihrem Design nach Einfachheit und Klarheit. Verwenden Sie für Ihre Komponenten und Dienste die entsprechende Abstraktions- und Granularitätsebene. Vermeiden Sie eine Über- oder Unterentwicklung Ihrer Lösung. Zum Beispiel:

    • Wenn Sie eine Anforderung zur Prozessautomatisierung mit Power Automate lösen, kann die Aufteilung eines großen Prozesses in mehrere kleinere Cloud-Flows dazu führen, dass dieser schwieriger zu verstehen, zu testen und zu warten ist. Andererseits kann es sich negativ auf die Leistung und das API-Aufrufvolumen auswirken, wenn alles in einem großen Flow gehalten wird.

    • Wenn Sie eine benutzerorientierte Anforderung mit Power Apps lösen, kann sich eine große monolithische Canvas-App mit vielen Steuerelementen negativ auf die Leistung auswirken. Die Aufteilung in einzelne Apps oder benutzerdefinierte Seiten erschwert zwar möglicherweise die Tests, kann sich jedoch erheblich positiv auf die Leistung auswirken.

  • Rechnen Sie mit Veränderungen im Laufe der Zeit, sei es, um Fehler zu beheben, neue Funktionen oder Technologien zu implementieren oder vorhandene Systeme skalierbarer und widerstandsfähiger zu machen.

  • Lagern Sie übergreifende Aspekte auf einen separaten Dienst aus. Minimieren Sie die Notwendigkeit, Code für verschiedene Funktionen zu duplizieren. Verwenden Sie vorzugsweise Dienste mit klar definierten Schnittstellen wieder, die problemlos von verschiedenen Komponenten genutzt werden können. Wenn beispielsweise eine Reihe von Datenvorgängen von verschiedenen Orten aus ausgeführt werden muss, können Sie diese Funktionalität in ein Low-Code-Plug-In verschieben.

  • Bewerten Sie die Eignung gängiger Muster und Vorgehensweisen für Ihre Anforderungen. Vermeiden Sie es, Trends oder Empfehlungen zu folgen, die für Ihren Kontext oder Ihre Anforderungen möglicherweise nicht optimal sind. Beispielsweise ist die Implementierung benutzerdefinierter Codekomponenten möglicherweise nicht für jede Anwendung die beste Option, da sie zu Komplexität, Mehraufwand und Abhängigkeitsproblemen führen können.

Entwickeln Sie nur so viel Code, das er ausreicht

Die Prinzipien der Einfachheit, Effizienz und Zuverlässigkeit gelten auch für Ihre Entwicklungspraktiken. Beachten Sie diese Empfehlungen:

  • Nutzen Sie die Funktionen der Plattform, wenn diese Ihren Geschäftsanforderungen entsprechen. Zum Beispiel:

    • Verwenden Sie moderne Steuerelemente, anstatt eigene Codekomponenten zu entwickeln, um einen Fluent-2-Designstandard zu erreichen.
    • Verwenden Sie native Connectors, anstatt benutzerdefinierte Connectors zu entwickeln, damit Sie weniger benutzerdefinierten Code brauchen.
    • Verwendung generativer Antworten in Microsoft Copilot Studio, damit Ihr Agent Informationen aus mehreren Quellen, intern oder extern, ohne die manuelle Erstellung von Themen finden und darstellen kann.

  • Führen Sie dedizierte Code-Review-Sitzungen als Entwicklungspraxis ein.

  • Implementieren Sie einen Ansatz zur Identifizierung von redundantem Code. Seien Sie skeptisch gegenüber dem Code, den Ihre automatisierten Tests nicht abdecken.

  • Berücksichtigen Sie die Fähigkeiten Ihres Entwicklungsteams. Es braucht Zeit, eine neue Fähigkeit zu erlernen oder sich eine neue Technologie anzueignen.

Berücksichtigen Sie, wo sich Ihre Daten befinden

Als Teil Ihres Architekturdesigns müssen Sie überlegen, wie Sie Ihre Daten speichern oder wie Sie Ihre Daten für Leseaktivitäten abrufen. Daten können auf unterschiedliche Arten abgerufen und gespeichert werden:

  • Neue Daten: Wenn Ihre App Daten erstellt, die noch nicht vorhanden sind, z. B. wenn beim vorhandenen Geschäftsprozess bisher Papier zum Einsatz kam, empfiehlt es sich, die Daten in Microsoft Dataverse zu speichern.

  • Lesen/Schreiben aus einem vorhandenen System: Wenn Ihre App Daten aus einer vorhandenen Datenbank oder einem vorhandenen System abrufen muss, müssen Sie die beste Möglichkeit zum Herstellen einer Verbindung mit der Datenbank oder dem System ermitteln: mithilfe eines sofort einsatzbereiten Konnektors, eines benutzerdefinierten Konnektors oder virtueller Tabellen.

  • Erstellen Sie eine Kopie der Daten: In Situationen, in denen die Originaldaten niemals geändert oder überschrieben werden sollen, können Sie die Daten in einen anderen Datenspeicher wie z.B. Dataverse kopieren. Bei dieser Strategie bleiben die Daten des ursprünglichen Systems unverändert, Ihre App kann aber damit arbeiten. Dieses Szenario ist bei der Arbeit mit Daten in Buchhaltungs- und einnahmebezogenen Systemen üblich. Sie müssen berücksichtigen, wie Daten kopiert werden, wie oft sie aktualisiert werden und ob eine bidirektionale Synchronisierung stattfinden muss.

Umsetzung in Power Platform

Praktische Designtipps finden Sie in den folgenden Artikeln:

Zuverlässigkeitscheckliste

Lesen Sie die vollständigen Empfehlungen.

Zuverlässigkeitscheckliste