Specifica di progettazione dell'architettura del carico di lavoro
Una specifica di progettazione dell'architettura del carico di lavoro è una specifica dettagliata che descrive le scelte di progettazione ed è accompagnata da diagrammi. Le scelte di progettazione devono soddisfare i requisiti funzionali e non funzionali e includono disposizioni per operazioni di routine, ad hoc e di emergenza.
Per informazioni sui diagrammi, vedere Diagrammi di progettazione dell'architettura.
La progettazione dell'architettura del carico di lavoro, in genere estesa, inizia con la progettazione dell'applicazione e procede alla selezione del servizio cloud. Queste fasi si comunicano reciprocamente. La progettazione combinata dell'applicazione e dell'infrastruttura deve soddisfare tutti i requisiti.
Il raggiungimento di una soluzione che soddisfi tutti i requisiti è uno sforzo collaborativo tra stakeholder, sviluppatori, tester, team operativi e proprietari di prodotti. Il processo di progettazione deve comportare l'affinamento dei requisiti con chiarezza e negoziazione. Il processo è iterativo e spesso richiede più revisioni.
È consigliabile allineare la progettazione alle linee guida fondamentali di Azure Well-Architected Framework, che include principi di progettazione e guide alle raccomandazioni e riconoscere i compromessi.
In definitiva, la specifica di progettazione dell'architettura del carico di lavoro viene implementata dal team di sviluppo del carico di lavoro, quindi deve essere chiara e non ambigua. La specifica deve essere prontamente disponibile e archiviata con la documentazione del carico di lavoro.
Specifica funzionale
La specifica funzionale per un carico di lavoro descrive in dettaglio il motivo e il motivo del sistema o della funzionalità in fase di sviluppo, ma non l'implementazione. Questo documento deve spiegare i problemi correnti esistenti e come questa funzionalità o sistema migliorerà tale esperienza. Questo documento acquisisce la maggior parte dei requisiti aziendali.
Un architetto può aiutare a modellare questo documento, ma principalmente è una funzione di proprietà del prodotto. Un architetto deve aiutare a progettare i dati acquisiti in questa specifica. Questo coinvolgimento garantisce che la specifica funzionale favorisce un design tecnico efficace ed efficiente.
Ecco alcuni argomenti di esempio da trattare in questa specifica.
Oltre a illustrare in dettaglio ciò che rientra nell'ambito di questa progettazione, è anche esplicito sui problemi adiacenti che non rientrano nell'ambito. L'impostazione di ambiti chiari riduce lo scorrimento dell'ambito definendo i limiti relativi alle funzionalità.
È utile includere i dettagli su come verrà misurata questa modifica. Quali misurazioni devono essere raccolte e quali obiettivi aziendali supportano tali misurazioni.
I flussi utente devono essere chiaramente descritti. Anche i mockup a bassa fedeltà possono essere utili. Se le situazioni di gestione degli errori sono importanti per questi flussi, verificare il comportamento previsto descritto.
Includere sempre eventuali requisiti specifici per l'accessibilità, la conformità, le prestazioni, la privacy o la sicurezza.
Includere qualsiasi strategia di implementazione pianificata. Ad esempio, "Questa funzionalità sarà disponibile per gli utenti beta per due mesi prima di decidere una versione completa".
Evitare dettagli di implementazione tecnica specifici in questa specifica. Queste specifiche funzionali determinano specifiche tecniche create dall'architetto.
Specifica tecnica
La specifica tecnica descrive il modo in cui si basa sull'ambito e sugli obiettivi descritti nella specifica funzionale. Questa specifica è progettata per il team di progettazione da usare come piano di registrazione durante l'implementazione.
In questa specifica sono inclusi elementi come:
- Decisioni tecnologiche, tra cui: acquistare, costruire, riutilizzare, estendere o rimuovere le autorizzazioni.
- API e contratti dati (schemi), inclusa la strategia di implementazione della compatibilità con le versioni precedenti
- Dettagli sull'implementazione e sul rollback
- Implementazione univoca del ciclo di vita dello sviluppo sicuro (SDL) e della privacy
- Piano di test
- Monitoraggio chiave e origini segnale di avviso
- Progetti alternativi considerati
La specifica tecnica guiderà le attività di progettazione. Gli elementi di lavoro di progettazione vengono creati principalmente dal contenuto di questa specifica. I team di implementazione fanno riferimento agli elementi di lavoro, alla specifica tecnica e alla specifica funzionale per garantire che il risultato finale soddisfi i requisiti funzionali e non funzionali.
Piani di ripristino di emergenza
Per soddisfare i requisiti di affidabilità per il carico di lavoro, un architetto deve progettare un sistema in grado di eseguire il ripristino entro gli obiettivi RTO (Target Recovery Time Objective) e obiettivo del punto di ripristino (RPO). La specifica di progettazione dell'architettura deve includere il piano di ripristino. Questo piano deve coprire i componenti dell'architettura coinvolti, i meccanismi di failover e l'impatto sul flusso di dati e sulle raccomandazioni operative. Deve descrivere quali destinazioni di ripristino sono soddisfatte dalla progettazione e da come.
Anche se il piano iniziale dovrebbe evolversi in base a informazioni dettagliate provenienti da esercitazioni e revisioni post-evento imprevisto, è responsabilità dell'architetto fornire il piano iniziale per tutte le nuove architetture.
Documentazione sulla sicurezza e sulla conformità
Un architetto è responsabile della progettazione di una soluzione conforme ai vincoli di sicurezza e conformità pertinenti. È importante per gli artefatti di progettazione evidenziare gli inviti incorporati nella progettazione per supportare questi requisiti e identificare i controlli di compensazione necessari quando i requisiti non possono essere soddisfatti direttamente.
Coerenza
Usare un modello per documentare le varie specifiche del carico di lavoro. La coerenza aiuta gli stakeholder, le parti responsabili e i team di implementazione quando la specifica viene letta.
Assicurarsi che le specifiche abbiano campi di metadati chiave, ad esempio:
- Stato: stato bozza, in revisione e approvato.
- Collegamento dell'elemento di lavoro: collegamento all'elemento di lavoro primario nel backlog del team.
- Collegamenti incrociati chiave: collegamenti a specifiche correlate o ad altra documentazione che supporta la specifica.
- Individui chiave: un luogo in cui elencare i nomi dei responsabili delle decisioni chiave coinvolti. Questo elenco può includere ruoli come: business analyst, business partner, responsabile tecnico e proprietario del prodotto o responsabile che ha firmato la specifica.