Designspecifikation för arbetsbelastningsarkitektur
En designspecifikation för arbetsbelastningsarkitektur är en detaljerad specifikation som beskriver designval och åtföljs av diagram. Designvalen måste uppfylla funktionella och icke-funktionella krav och innehålla bestämmelser för rutin-, ad hoc- och nödåtgärder.
Information om diagram finns i Designdiagram för arkitektur.
Designen av arbetsbelastningsarkitekturen, vanligtvis expansiv, börjar med programdesign och går vidare till valet av molntjänst. Dessa faser informerar varandra ömsesidigt. Den kombinerade program- och infrastrukturdesignen måste uppfylla alla krav.
Att uppnå en lösning som uppfyller alla krav är ett samarbete mellan intressenter, utvecklare, testare, driftteam och produktägare. Designprocessen bör omfatta förfiningskrav med tydlighet och förhandling. Processen är iterativ och kräver ofta flera granskningar.
Vi rekommenderar att du anpassar din design med grundläggande vägledning för Azure Well-Architected Framework, som innehåller designprinciper och rekommendationsguider, och bekräftar kompromisserna.
I slutändan implementeras designspecifikationen för arbetsbelastningsarkitekturen av arbetsbelastningsutvecklingsteamet, så den måste vara tydlig och entydig. Specifikationen bör vara lättillgänglig och lagras med arbetsbelastningens dokumentation.
Funktionell specifikation
Funktionsspecifikationen för en arbetsbelastning beskriver vad och varför systemet eller funktionen är under utveckling, men inte implementeringen. Det här dokumentet måste förklara de aktuella problem som finns och hur den här funktionen eller systemet kommer att förbättra den upplevelsen. Det här dokumentet innehåller de flesta affärskraven.
En arkitekt kan hjälpa till att forma det här dokumentet, men i första hand är det en funktion av produktägarskap. En arkitekt bör hjälpa till att utforma de data som samlas in i den här specifikationen. Detta engagemang säkerställer att den funktionella specifikationen driver effektiv och effektiv teknisk design.
Här följer några exempelavsnitt som bör tas upp i den här specifikationen.
Förutom att beskriva vad som finns i omfånget för den här designen ska du också vara tydlig med närliggande problem som ligger utanför omfånget. Om du ställer in tydliga omfång minskar omfångskrypning genom att definiera gränser runt funktionerna.
Det är bra att ta med information om hur den här ändringen kommer att mätas. Vilka mätningar måste samlas in och vilka affärsmål som dessa mätningar stöder.
Användarflöden bör beskrivas tydligt. Modeller med låg fedelity kan också vara till hjälp. Om felhanteringssituationer är viktiga för dessa flöden ska du se till att det förväntade beteendet beskrivs.
Inkludera alltid specifika krav för tillgänglighet, efterlevnad, prestanda, sekretess eller säkerhet.
Inkludera en planerad distributionsstrategi. Till exempel "Den här funktionen kommer att vara tillgänglig för våra betaanvändare i två månader innan du bestämmer dig för en fullständig version."
Undvik specifik teknisk implementeringsinformation i den här specifikationen. Dessa funktionella specifikationer kommer att driva tekniska specifikationer som skapats av arkitekten.
Teknisk specifikation
Den tekniska specifikationen beskriver hur den baseras på omfånget och målen som beskrivs i funktionsspecifikationen. Den här specifikationen är utformad för att teknikteamet ska kunna använda som en postplan under implementeringen.
I den här specifikationen finns bland annat följande:
- Teknikbeslut, inklusive som: köpa, bygga, återanvända, utöka eller inaktivera.
- API- och datakontrakt (scheman), inklusive strategi för bakåtkompatibilitetsimplementering
- Distributions- och återställningsimplementeringsinformation
- Unik säker utvecklingslivscykel (SDL) och sekretessimplementering
- Testplanen
- Viktiga övervaknings- och aviseringssignalkällor
- Alternativa konstruktioner som ansågs vara
Den tekniska specifikationen kommer att driva tekniska insatser. Tekniska arbetsobjekt skapas främst utifrån innehållet i den här specifikationen. Implementeringsteamen refererar till arbetsobjekten, den tekniska specifikationen och funktionsspecifikationen för att säkerställa att slutresultatet uppfyller både funktionella och icke-funktionella krav.
Planer för haveriberedskap
För att uppfylla tillförlitlighetskraven för arbetsbelastningen måste en arkitekt utforma ett system som kan återställas inom målmålet för återställningstid (RTO) och målmål för återställningspunkt (RPO). Arkitekturdesignspecifikationen måste innehålla återställningsplanen. Den här planen måste omfatta berörda arkitekturkomponenter, redundansmekanismer och påverkan på användar- och dataflöde samt driftrekommendationer. Den bör beskriva vilka återställningsmål som uppfylls av designen och hur.
Även om den ursprungliga planen förväntas utvecklas baserat på insikter från övningar och granskningar efter incident, är det arkitektens ansvar att leverera den ursprungliga planen för all ny arkitektur.
Dokumentation om säkerhet och efterlevnad
En arkitekt ansvarar för att utforma en lösning som följer relevanta säkerhets- och efterlevnadsbegränsningar. Det är viktigt att designartefakterna belyser de råd som ingår i designen för att stödja dessa krav och att identifiera eventuella nödvändiga kompenserande kontroller när kraven inte kan uppfyllas direkt.
Konsekvens
Använd en mall för att dokumentera arbetsbelastningens olika specifikationer. Konsekvens hjälper intressenter, ansvariga parter och implementeringsteam när specifikationen läse.
Se till att specifikationerna har viktiga metadatafält, till exempel:
- Tillstånd: Status som Utkast, I granskning och Godkänd.
- Länk till arbetsobjekt: En länk till det primära arbetsobjektet i teamets kvarvarande uppgifter.
- Viktiga korslänkar: Länkar till relaterade specifikationer eller annan dokumentation som stöder specifikationen.
- Nyckelpersoner: En plats där du kan lista namnen på viktiga beslutsfattare. Den här listan kan innehålla roller som: affärsanalytiker, affärspartner, teknisk lead och produktägare eller lead som har godkänt specifikationen.