Per chi non avesse voglia/tempo di leggersi l'articolo, del quale indico il link alla fine di questo post, vado ad esporre di seguito una breve sintesi a riguardo.
Sintesi
Il metodo in questione aiuta a prendere decisioni architetturali in maniera rapida e può essere utilizzato a prescindere da : tecnologie , metodi usati per creare il disegno della architettura, standard utilizzati per la documentazione e processi.
Agli IT Architects viene richiesto di essere sempre più veloci nel produrre soluzione inerenti le nuove richieste che arrivano dal business.
Uno strumento di norma utilizzato per limitare i rischi nella produzione di soluzione è quello dell'utilizzo dei cosidetti "patterns", consistente nella scomposizione del problema in strutture meno complesse a cui poter associare elementi già usati in soluzioni già funzionanti e che nel passato che si sono rivelate vincenti.
Questo tipo di approccio però si concentra maggiormente sul processo decisionale piuttosto che sulle informzioni di input e di output.
In pratica con i "patterns" si viene portati a indirizzare la domanda relativa a COME prendere decisioni architetturali per disegnare la soluzione ma non su COSA si decide.
Non conoscendo bene l'oggetto delle nostre decisioni molte volte si rischia di non riuscire a dare risposte a quelle situazioni dove non si riescono ad usare le risposte pre-definite dei patterns.
Quindi si deve provare ad affrontare il problema dal punto di vista del COSA e cominciare a cambiare il punto di vista.
Qui entra in scena l'esperienza dell' IT Architect e la sua capacità di mettere in prospettiva il problema e cominciare a porsi delle domande relative alle qualità della soluzione (NonFunctional Requirements) che si sta cercando di disegnare.
Ecco come funziona il PBA
la prospettiva viene suddivisa in 4 macro-zone
- Requirements
- Business Environment
- IT Environment
- Trends, Forecasting
La cosa interessante è che la risposta di tipo "NON LO SO / NON LO SAPPIAMO" è contemplata e accettata ma non solo: diventa un valido strumento per individuare le aree "grigie" e mettere a fattor comune all'interno del team le criticità maggiori.
Il risultato che esce da questo tipo di approccio è una serie di decisioni molto meglio allineate al business e alle strutture organizzative piuttosto che una mero prodotto che promuova unicamente l'adozione di tecnologie / prodotti "trendy" senza dare indicazioni relative all'utilizzo calato nella realtà.
Riferimenti :
Link all'articolo : http://msdn.microsoft.com/en-us/library/bb245776.aspx
Link alla rivista : http://msdn.microsoft.com/en-us/arcjournal/default.aspx
Link al blog di uno degli autori: http://blogs.technet.com/lcurtis
Salutoni a tutti
Fabio
Nessun commento:
Posta un commento