Quelli di noi incaricati di lavorare su argomenti di livello superiore,come l’architettura e la strategia aziendale, temono quando viene posta la semplice domanda: “cosa fai?”Quando i risultati finali mancano di tangibilità e chiarezza, le risposte a questa domanda lasciano l’interrogante stordito e quasi dispiaciuto per il rispondente. Un termine comune gettato nella risposta, come segnaposto per incertezza e incompletezza, è l’architettura di riferimento.
Questo termine può significare molte cose o qualcosa per persone diverse. Se lasciato indefinito, dà l’impressione di fluffiness e fuzziness che genera frustrazione e spreco. Coloro che hanno il compito di attuazione può mettere in discussione la vostra capacità di concetti di base e il pensiero in realtà e concretezza. Quindi, le definizioni sono utili. Ecco la mia definizione di architettura di riferimento:
L’articolazione di considerazioni, opzioni e standard noti per guidare la progettazione di un prodotto, soluzione o sistema, sulla base di osservazioni da indagini, esperienza e sperimentazione, in un linguaggio e formato visivo familiare al pubblico di destinazione.
La verità è che, una volta chiarito l’intento, il valore e il contesto di utilizzo per un determinato pubblico, avere una definizione formale non ha importanza.
La vera domanda è—
“che cosa vogliamo fare?”
In secondo luogo—
“cosa vogliamo che le persone (chiunque siano) facciano?”
Avere risposte chiare a queste domande è l’inizio per sfocare il significato e la consegna dell’architettura di riferimento. L’intento, il contenuto, il pubblico e il valore devono essere chiari. La parola “riferimento” suggerisce che l’output fornisce indicazioni e standard dall’osservazione, dall’esperienza e dalla sperimentazione, al contrario di una definizione di ciò che deve essere costruito. Una “architettura” suggerisce che sia strutturata, coerente e verificabile.
Ci sono varie definizioni di architettura di riferimento trovate su Internet, ma la regola di chiarezza di cui sopra (intento, contenuto, pubblico, valore) può essere trovata in ciascuna. Considera una definizione alternativa alla mia che appare come il risultato principale in una ricerca su Google:
(1) Chiarire il mezzo e il formato di ciò che verrà consegnato, ad esempio “un documento”. Questo informa gli strumenti necessari, la natura del lavoro da svolgere e le competenze dei contributori da coinvolgere. Modi alternativi di consegna potrebbero essere una presentazione o una base di conoscenza in grado di query.
(2) Concordare la struttura e la scala di ciò che verrà consegnato, ad esempio “un insieme di documenti”. Un deliverable potrebbe essere insufficiente, ma la scala del dominio di sistema in questione potrebbe richiedere che il deliverable venga scomposto in più documenti.
(3) Identificare il pubblico primario e gli stakeholder(s) ad esempio “project manager”. Avere una comprensione del tipo e del formato delle informazioni che consumano regolarmente. Lo status quo potrebbe anche svolgere un ruolo qui. In alcuni casi l’architettura di riferimento viene “tramandata” come politica le linee di reporting, mentre in altri casi viene trattata come un “bello da avere”, con l’aspettativa che descriva il modo migliore e le alternative da considerare.
(4) Identificare altre parti interessate che potrebbero aver bisogno di utilizzare l’architettura di riferimento. È necessario creare viste o livelli diversi? C’è bisogno e spazio per formare gli altri su come interpretare e applicare l’architettura di riferimento?
(5) Chiarire cosa dovrebbe fare il pubblico/ lettore con il documento, ad esempio “fare riferimento per le migliori pratiche.”Gli output dovrebbero fornire ciò che dicono sulla copertina, comprese le prove e i collegamenti alle fonti per la convalida. Un’architettura di riferimento potrebbe anche fornire “apprendimento” dalla sperimentazione in modo coerente e attuabile.
(6) Rendere chiaro il dominio di rilevanza. Un’architettura di riferimento senza un dominio specifico è una filosofia di principi guida di livello superiore piuttosto che un’architettura. Un’architettura, anche un’architettura di riferimento, deve essere vincolata al dominio. Più piccolo è questo dominio, più rilevante e fruibile è l’architettura di riferimento.
(7) Il valore previsto dell’architettura di riferimento dovrebbe essere comunicato, in quanto ciò aiuta il pubblico a giudicare il suo scopo e i suoi limiti, ad esempio “selezionare il miglior metodo di consegna.”I team di implementazione sanno quindi dove andare quando questa decisione deve essere presa.
(8) Avere esempi dal dominio e indicare le tecnologie pertinenti, aiuta a chiarire il contesto dell’architettura di riferimento.
(9) Le alternative e le fonti di componenti e capacità da considerare, in fase di implementazione, dovrebbero essere ben documentate e collegate.
Un’architettura di riferimento non è necessariamente un blocco prima dell’avvio di un progetto tecnologico. Può essere sviluppato in parallelo o dopo la consegna, che serve come la documentazione di un post-mortem e le lezioni apprese. Se viene creato prima dell’inizio di un progetto, richiede indagini, prove ed esperimenti per informare le buone pratiche. Di seguito è riportata una tassonomia suggerita delle possibili classi di architettura di riferimento, a seconda del pubblico, della soluzione e dell’attuale divario di conoscenza all’interno di un’organizzazione o di un team di progetto.
L’acronimo di cinque diversi aspetti di un’architettura di riferimento è la MUSICA, che ha dimostrato di essere memorabile in conversazioni a qualsiasi livello organizzativo o di un dominio di conoscenza:
- embership: l’elenco e la classificazione degli elementi dell’architettura considerati rilevanti per il dominio.
- salvia: storie degli utenti, casi aziendali, processi, flussi di lavoro e mezzi per spiegare le attività nel dominio.
- tructure: come i vari elementi in un dominio sono interconnessi per supportare l’utilizzo.
- nteraction( o Integrazione): le interfacce e i messaggi scambiati tra gli elementi dell’architettura durante l’utilizzo.
- ontrols: i vincoli e le politiche utilizzate per governare le interazioni.
Ora questo non suggerisce che tutte le architetture di riferimento debbano fornire 25 documenti o sottosezioni, coprendo ciascuna delle aree identificate. Ciò illustra che ci sono probabilmente 25 diverse aree in cui considerazioni, opzioni e responsabilità devono essere articolate in un’organizzazione o in un progetto. Questo cambierà a seconda del pubblico. Non c’è confusione o fluffiness nelle architetture di riferimento. Sono il risultato di uno sforzo esplorativo e sono i risultati tangibili della ricerca applicata a breve termine.