Entwurfsspezifikation der Workloadarchitektur
Eine Entwurfsspezifikation für die Workloadarchitektur ist eine detaillierte Spezifikation, die Entwurfsentscheidungen beschreibt und von Diagrammen begleitet wird. Die Designentscheidungen müssen funktionale und nicht funktionale Anforderungen erfüllen und Bestimmungen für Routine-, Ad-hoc- und Notfalleinsätze enthalten.
Informationen zu Diagrammen finden Sie unter Architekturentwurfsdiagramme.
Das Design der Workloadarchitektur beginnt in der Regel umfangreich mit dem Anwendungsdesign und führt zur Auswahl des Clouddiensts weiter. Diese Phasen informieren sich gegenseitig. Das kombinierte Anwendungs- und Infrastrukturdesign muss alle Anforderungen erfüllen.
Das Erreichen einer Lösung, die allen Anforderungen entspricht, ist eine zusammenarbeitsorientierte Arbeit zwischen Denteressengruppen, Entwicklern, Testern, Betriebsteams und Produktbesitzern. Der Entwurfsprozess sollte die Anforderungen mit Klarheit und Aushandlung verfeinern. Der Prozess ist iterativ und erfordert häufig mehrere Rezensionen.
Es wird empfohlen, Ihr Design mit den grundlegenden Richtlinien für Das Azure Well-Architected Framework abzustimmen, die Designprinzipien und Empfehlungshandbücher enthält, und die Kompromisse anerkennen.
Letztendlich wird die Entwurfsspezifikation für die Workloadarchitektur vom Workload-Entwicklungsteam implementiert, sodass sie klar und eindeutig sein muss. Die Spezifikation sollte sofort verfügbar und mit der Dokumentation der Workload gespeichert werden.
Funktionsspezifikation
Die funktionale Spezifikation für eine Workload enthält Details dazu , was und warum das System oder Feature in der Entwicklung, aber nicht die Implementierung. Dieses Dokument muss die aktuellen Probleme erläutern, die vorhanden sind und wie dieses Feature oder System diese Erfahrung verbessern wird. In diesem Dokument werden die meisten Geschäftsanforderungen erfasst.
Ein Architekt kann dabei helfen, dieses Dokument zu gestalten, aber in erster Linie ist es eine Funktion des Produktbesitzes. Ein Architekt sollte dabei helfen, die in dieser Spezifikation erfassten Daten zu entwerfen. Durch diese Beteiligung wird sichergestellt, dass die funktionale Spezifikation ein effektives und effizientes technisches Design fördert.
Nachfolgend finden Sie einige Beispielthemen, die in dieser Spezifikation behandelt werden sollten.
Zusätzlich zur Detailierung, was für diesen Entwurf vorgesehen ist, sind auch die angrenzenden Bedenken explizit, die außerhalb des Umfangs liegen. Durch das Festlegen von klaren Bereichen wird das Kriechen des Bereichs reduziert, indem Grenzen um die Funktionalität definiert werden.
Es ist hilfreich, die Details darüber einzuschließen, wie diese Änderung gemessen werden soll. Welche Messungen gesammelt werden müssen und welche Geschäftsziele diese Messungen unterstützen.
Benutzerflüsse sollten klar beschrieben werden. Auch Fedelity-Modelle können hilfreich sein. Wenn Fehlerbehandlungssituationen für diese Flüsse wichtig sind, stellen Sie das erwartete Verhalten sicher.
Fügen Sie immer alle spezifischen Anforderungen für Barrierefreiheit, Compliance, Leistung, Datenschutz oder Sicherheit ein.
Schließen Sie alle geplanten Rolloutstrategie ein. Beispiel: "Dieses Feature wird für unsere Betabenutzer zwei Monate lang verfügbar sein, bevor sie sich für eine vollständige Version entscheiden."
Vermeiden Sie spezifische Details zur technischen Implementierung in dieser Spezifikation. Diese funktionalen Spezifikationen werden technische Spezifikationen fördern, die vom Architekten erstellt wurden.
Technische Spezifikation
Die technische Spezifikation beschreibt die Art und Weise, wie die in der funktionalen Spezifikation beschriebenen Umfang und Ziele basiert. Diese Spezifikation wurde für das Entwicklungsteam entwickelt, das während der Implementierung als Plan-of-Record verwendet werden kann.
In dieser Spezifikation sind Elemente wie:
- Technologieentscheidungen, einschließlich: Kaufen, Erstellen, Wiederverwenden, Erweitern oder Außerbetriebnahme.
- API- und Datenverträge (Schemas), einschließlich Abwärtskompatibilitätsimplementierungsstrategie
- Details zur Rollout- und Rollbackimplementierung
- Einzigartiger sicherer Entwicklungslebenszyklus (SDL) und Datenschutzimplementierung
- Der Testplan
- Wichtige Überwachungs- und Warnungssignalquellen
- Alternative Designs, die berücksichtigt wurden
Die technische Spezifikation wird technische Anstrengungen fördern. Technische Arbeitsaufgaben werden in erster Linie aus den Inhalten dieser Spezifikation erstellt. Implementierungsteams beziehen sich auf die Arbeitsaufgaben, die technische Spezifikation und die funktionale Spezifikation, um sicherzustellen, dass das Endergebnis sowohl den funktionalen als auch nichtfunktionalen Anforderungen entspricht.
Notfallwiederherstellungspläne
Um die Zuverlässigkeitsanforderungen für die Arbeitsauslastung zu erfüllen, muss ein Architekt ein System entwerfen, das innerhalb des Ziel-Wiederherstellungszeitziels (RTO) und der RPO-Ziele (Recovery Point Objective) wiederhergestellt werden kann. Die Architekturentwurfsspezifikation muss den Wiederherstellungsplan enthalten. Dieser Plan muss die beteiligten Architekturkomponenten, Failovermechanismen und Auswirkungen auf den Benutzer- und Datenfluss sowie operative Empfehlungen abdecken. Es sollte beschrieben werden, welche Wiederherstellungsziele vom Entwurf und wie erfüllt werden.
Obwohl der anfängliche Plan basierend auf Erkenntnissen aus Drills und Überprüfungen nach dem Vorfall weiterentwickelt werden soll, liegt es in der Verantwortung des Architekten, den ursprünglichen Plan für alle neuen Architekturen zu liefern.
Dokumentation zu Sicherheit und Compliance
Ein Architekt ist für das Entwerfen einer Lösung verantwortlich, die den relevanten Sicherheits- und Complianceeinschränkungen entspricht. Es ist wichtig, dass die Designartefakte die in das Design integrierten Angebote hervorheben, um diese Anforderungen zu unterstützen, und alle erforderlichen Ausgleichskontrollen zu identifizieren, wenn die Anforderungen nicht direkt erfüllt werden können.
Konsistenz
Verwenden Sie eine Vorlage, um die verschiedenen Spezifikationen Ihrer Workload zu dokumentieren. Konsistenz hilft Projektbeteiligten, verantwortlichen Parteien und Implementierungsteams, wenn die Spezifikation gelesen wird.
Stellen Sie sicher, dass Spezifikationen über wichtige Metadatenfelder verfügen, z. B.:
- Status: Status " Entwurf", "Überprüfen" und "Genehmigt".
- Verknüpfung "Arbeitsaufgabe": Ein Link zur primären Arbeitsaufgabe im Backlog des Teams.
- Wichtige Verknüpfungen: Links zu verwandten Spezifikationen oder anderen Dokumentationen, die die Spezifikation unterstützen.
- Wichtige Personen: Ein Ort, an dem die Namen der beteiligten Entscheidungsträger aufgelistet werden. Diese Liste kann Rollen wie Business Analyst, Geschäftspartner, technischer Lead und den Produktbesitzer oder Lead enthalten, der sich bei der Spezifikation abgemeldet hat.