Specifikace návrhu architektury úloh
Specifikace návrhu architektury úloh je podrobná specifikace, která popisuje volby návrhu a je doprovázena diagramy. Možnosti návrhu musí splňovat funkční a nefunkční požadavky a zahrnovat ustanovení pro rutinní, ad hoc a nouzové operace.
Návrh architektury úloh, obvykle expansivní, začíná návrhem aplikací a pokračuje ve výběru cloudové služby. Tyto fáze se vzájemně informují. Kombinovaný návrh aplikací a infrastruktury musí splňovat všechny požadavky.
Dosažení řešení, které splňuje všechny požadavky, je spolupráce mezi zúčastněnými stranami, vývojáři, testery, provozními týmy a vlastníky produktů. Proces návrhu by měl zahrnovat upřesnění požadavků s přehledností a vyjednáváním. Proces je iterativní a často vyžaduje více kontrol.
Doporučujeme, abyste svůj návrh vyrovnal se základními pokyny architektury Azure Well-Architected Framework, která zahrnuje principy návrhu a průvodce doporučeními a uznává kompromisy.
Specifikace návrhu architektury úloh je nakonec implementována týmem pro vývoj úloh, takže musí být jasná a jednoznačná. Specifikace by měla být snadno dostupná a uložená v dokumentaci k úloze.
Funkční specifikace
Funkční specifikace úlohy podrobně popisuje , co a proč systém nebo funkce ve vývoji, ale ne implementace. Tento dokument musí vysvětlit aktuální problémy, které existují, a způsob, jakým tato funkce nebo systém tuto funkci zlepší. Tento dokument zachycuje většinu obchodních požadavků.
Architekt může pomoct tento dokument tvarovat, ale primárně je to funkce vlastnictví produktu. Architekt by měl pomoct navrhnout data zachycená v této specifikaci. Tato účast zajišťuje funkční specifikaci efektivní a efektivní technický návrh.
Tady je několik ukázkových témat, která by se měla v této specifikaci probít.
Kromě podrobností o tom, co je v rozsahu tohoto návrhu, také explicitně o sousedních obavách, které jsou mimo rozsah. Když nastavíte jasné obory, sníží se tím, že definujete hranice kolem funkčnosti.
Je užitečné zahrnout podrobnosti o tom, jak se bude tato změna měřit. Jaká měření je potřeba shromáždit a jaké obchodní cíle tato měření podporují.
Toky uživatelů by měly být jasně popsány. Mockupy s nízkou fedelitou můžou být užitečné i. Pokud jsou pro tyto toky důležité situace zpracování chyb, ujistěte se, že je popsáno očekávané chování.
Vždy uveďte všechny konkrétní požadavky na přístupnost, dodržování předpisů, výkon, ochranu osobních údajů nebo zabezpečení.
Zahrňte jakoukoli plánovanou strategii zavedení. Například "Tato funkce bude dostupná pro naše beta uživatele po dobu dvou měsíců před rozhodnutím o úplné verzi.".
V této specifikaci se vyhněte konkrétním podrobnostem o technické implementaci. Tyto funkční specifikace budou řídit technické specifikace vytvořené architektem.
Technická specifikace
Technická specifikace popisuje, jak na základě rozsahu a cílů popsaných ve funkční specifikaci. Tato specifikace je určená pro technický tým, který bude během implementace používat jako záznam plánu.
V této specifikaci patří například:
- Rozhodnutí o technologiích, včetně nákupu, sestavování, opětovného použití, rozšíření nebo vyřazení z provozu
- Rozhraní API a kontrakty dat (schémata), včetně strategie implementace zpětné kompatibility
- Podrobnosti implementace zavedení a vrácení zpět
- Implementace jedinečného životního cyklu zabezpečeného vývoje (SDL) a ochrany osobních údajů
- Testovací plán
- Klíčové zdroje signálu monitorování a výstrah
- Alternativní návrhy, které byly považovány za
Technická specifikace bude řídit technické úsilí. Technické pracovní položky se primárně vytvářejí z obsahu této specifikace. Implementační týmy odkazují na pracovní položky, technickou specifikaci a funkční specifikaci, aby se zajistilo, že konečný výsledek splňuje funkční i nefunkční požadavky.
Plány zotavení po havárii
Aby bylo možné splnit požadavky na spolehlivost pro danou úlohu, musí architekt navrhnout systém, který se může zotavit v rámci cíle doby obnovení (RTO) a cílů bodu obnovení (RPO). Specifikace návrhu architektury musí zahrnovat plán obnovení. Tento plán musí zahrnovat zahrnuté součásti architektury, mechanismy převzetí služeb při selhání a dopad na tok uživatelů a dat a provozní doporučení. Měl by popisovat cíle obnovení, které jsou splněny návrhem a způsobem.
I když se očekává, že se počáteční plán bude vyvíjet na základě přehledů z podrobných postupů a závěrečného vyhodnocení incidentů, je zodpovědností architekta zajistit počáteční plán pro všechny nové architektury.
Dokumentace k zabezpečení a dodržování předpisů
Architekt zodpovídá za návrh řešení, které dodržuje příslušná omezení zabezpečení a dodržování předpisů. Je důležité, aby artefakty návrhu zvýraznily cenové ceny, které jsou součástí návrhu, aby tyto požadavky podporovaly, a aby identifikovaly všechny nezbytné kompenzační kontroly, pokud požadavky nelze splnit přímo.
Konzistence
Pomocí šablony zdokumentujte různé specifikace vaší úlohy. Konzistence pomáhá zúčastněným stranám, zodpovědným stranám a implementačním týmům při čtení specifikace.
Ujistěte se, že specifikace obsahují klíčová pole metadat, například:
- Stav: Stav jako Koncept, Kontrola a Schválení.
- Odkaz na pracovní položku: Odkaz na primární pracovní položku v backlogu týmu.
- Klíčové křížové odkazy: Odkazy na související specifikace nebo jinou dokumentaci, která specifikaci podporuje.
- Klíčové osoby: Místo pro výpis jmen klíčových osob s rozhodovací pravomocí. Tento seznam může zahrnovat role, jako jsou obchodní analytik, obchodní partner, technický zájemce a vlastník produktu nebo zájemce, kteří se ke specifikaci přihlásili.