Ontwerpspecificatie voor workloadarchitectuur
Een ontwerpspecificatie voor workloadarchitectuur is een gedetailleerde specificatie waarin ontwerpkeuzen worden beschreven en die vergezeld gaat van diagrammen. De ontwerpkeuzen moeten voldoen aan functionele en niet-functionele vereisten en moeten voorzieningen omvatten voor routine-, ad-hoc- en noodoperaties.
Zie Architectuurontwerpdiagrammen voor meer informatie over diagrammen.
Ontwerp van workloadarchitectuur, meestal uitgebreid, begint met het ontwerpen van toepassingen en gaat verder met de selectie van cloudservices. Deze fasen informeren elkaar wederzijds. Het gecombineerde ontwerp van toepassingen en infrastructuur moet voldoen aan alle vereisten.
Het bereiken van een oplossing die aan alle vereisten voldoet, is een samenwerking tussen belanghebbenden, ontwikkelaars, testers, operationele teams en producteigenaren. Het ontwerpproces moet betrekking hebben op het verfijnen van vereisten met duidelijkheid en onderhandeling. Het proces is iteratief en vereist vaak meerdere beoordelingen.
We raden u aan uw ontwerp af te stemmen op de basisrichtlijnen van Azure Well-Architected Framework, waaronder ontwerpprincipes en aanbevelingsgidsen, en de compromissen te erkennen.
Uiteindelijk wordt de ontwerpspecificatie van de workloadarchitectuur geïmplementeerd door het ontwikkelteam van de workload, dus het moet duidelijk en ondubbelzinnig zijn. De specificatie moet direct beschikbaar zijn en worden opgeslagen met de documentatie van de werkbelasting.
Functionele specificatie
De functionele specificatie voor een workload bevat informatie over wat en waarom het systeem of de functie in ontwikkeling is, maar niet de implementatie. In dit document moeten de huidige problemen worden uitgelegd en hoe deze functie of dit systeem die ervaring gaat verbeteren. In dit document worden de meeste zakelijke vereisten vastgelegd.
Een architect kan dit document vormgeven, maar in de eerste plaats is het een functie van producteigendom. Een architect moet helpen bij het ontwerpen van de gegevens die in deze specificatie zijn vastgelegd. Deze betrokkenheid zorgt ervoor dat de functionele specificatie effectief en efficiënt technisch ontwerp aanstuurt.
Hier volgen enkele voorbeeldonderwerpen die in deze specificatie moeten worden behandeld.
Naast het beschrijven van wat binnen het bereik van dit ontwerp valt, moet u ook expliciet zijn over aangrenzende zorgen die buiten het bereik vallen. Als u duidelijke bereiken instelt, vermindert u het bereik door grenzen rond de functionaliteit te definiëren.
Het is handig om de details op te nemen over hoe deze wijziging wordt gemeten. Welke metingen moeten worden verzameld en welke bedrijfsdoelen deze metingen ondersteunen.
Gebruikersstromen moeten duidelijk worden beschreven. Mockups met weinig fedeliteit kunnen ook nuttig zijn. Als foutafhandelingssituaties belangrijk zijn voor deze stromen, moet u ervoor zorgen dat het verwachte gedrag wordt beschreven.
Neem altijd specifieke vereisten op voor toegankelijkheid, naleving, prestaties, privacy of beveiliging.
Neem een geplande implementatiestrategie op. Bijvoorbeeld: "Deze functie is twee maanden beschikbaar voor onze bètagebruikers voordat ze een volledige release kiezen."
Vermijd specifieke technische implementatiedetails in deze specificatie. Deze functionele specificaties zullen technische specificaties stimuleren die door de architect zijn gemaakt.
Technische specificatie
In de technische specificatie wordt beschreven hoe dit werkt op basis van het bereik en de doelstellingen die in de functionele specificatie worden beschreven. Deze specificatie is ontworpen voor het technische team dat tijdens de implementatie als plan-of-record kan worden gebruikt.
In deze specificatie zijn onder andere items als:
- Beslissingen over technologie, waaronder: kopen, bouwen, hergebruiken, uitbreiden of buiten gebruik stellen.
- API- en gegevenscontracten (schema's), inclusief strategie voor achterwaartse compatibiliteit
- Implementatiedetails voor implementatie en terugdraaien
- Unieke SDL (Secure Development Lifecycle) en privacyimplementatie
- Het testplan
- Belangrijke bewakings- en waarschuwingssignaalbronnen
- Alternatieve ontwerpen die werden overwogen
De technische specificatie zal de technische inspanningen stimuleren. Technische werkitems worden voornamelijk gemaakt op basis van de inhoud van deze specificatie. Implementatieteams verwijzen naar de werkitems, de technische specificatie en de functionele specificatie om ervoor te zorgen dat het uiteindelijke resultaat voldoet aan zowel de functionele als niet-functionele vereisten.
Plannen voor herstel na noodgevallen
Om te voldoen aan de betrouwbaarheidsvereisten voor de workload, moet een architect een systeem ontwerpen dat kan worden hersteld binnen de beoogde beoogde beoogde hersteltijd (RTO) en RPO-doelen (Recovery Point Objective). De ontwerpspecificatie van de architectuur moet het herstelplan bevatten. Dit plan moet betrekking hebben op de betrokken architectuuronderdelen, failovermechanismen en impact op de gebruikers- en gegevensstroom en operationele aanbevelingen. Hierin moet worden beschreven aan welke hersteldoelen wordt voldaan door het ontwerp en hoe.
Hoewel van het eerste plan wordt verwacht dat het zich ontwikkelt op basis van inzichten uit drills en incidentbeoordelingen, is het de verantwoordelijkheid van de architect om het eerste plan voor alle nieuwe architectuur te leveren.
Documentatie voor beveiliging en naleving
Een architect is verantwoordelijk voor het ontwerpen van een oplossing die voldoet aan relevante beveiligings- en nalevingsbeperkingen. Het is belangrijk voor de ontwerpartefacten om de betaalbaarheden te markeren die zijn opgenomen in het ontwerp om deze vereisten te ondersteunen en om eventuele noodzakelijke compenserende controles te identificeren wanneer niet rechtstreeks aan vereisten kan worden voldaan.
Consistentie
Gebruik een sjabloon om de verschillende specificaties van uw workload te documenteren. Consistentie helpt belanghebbenden, verantwoordelijke partijen en implementatieteams wanneer de specificatie wordt gelezen.
Zorg ervoor dat specificaties belangrijke metagegevensvelden hebben, zoals:
- Status: Een status als Concept, In beoordeling en Goedgekeurd.
- Koppeling werkitem: een koppeling naar het primaire werkitem in de achterstand van het team.
- Belangrijke kruiskoppelingen: koppelingen naar verwante specificaties of andere documentatie die ondersteuning biedt voor de specificatie.
- Belangrijke personen: een plaats om de namen van de betrokken besluitvormers weer te geven. Deze lijst kan rollen bevatten als: bedrijfsanalist, zakenpartner, technische lead en de producteigenaar of potentiële klant die zich heeft afgemeld bij de specificatie.