I programmi architetturali IT e gli architetti che vi lavorano sono spesso alle prese con il modo di definire se stessi, e soprattutto quale tipo di prodotto dovrebbero realizzare col loro lavoro
by Mike Rosen
Un modo di guardare a questi aspetti è quello di prendere in esame la domanda: «Cos’è l’architettura»?
Una comune definizione informale di architettura è: «La struttura degli elementi fondamentali e le loro relazioni all’interno di un ambiente». Qualcuno ritiene questa definizione troppo soggettiva. Ecco, quindi, un’altra buona fonte per definire l’architettura: “ISO/IEC/IEEE 42010:2007, Ingegneria dei sistemi e del software – Raccomandazioni per la descrizione architetturale dei sistemi a elevato tasso di software”. Si tratta di uno standard per descrivere l’architettura e quello che l’architettura dovrebbe descrivere. I principali concetti della “42010” sono:
- Un sistema è “un gruppo di componenti organizzati per raggiungere una specifica funzione o insieme di funzioni”.
- Un sistema esiste all’interno di un ambiente (o contesto), dove “l’ambiente determina i confini del sistema rispetto ad altri sistemi”.
- Un sistema dispone di uno o più stakeholder.
- Uno stakeholder ha una o più preoccupazioni relativamente al sistema. Preoccupazioni sono “quegli interessi che riguardano lo sviluppo del sistema, il suo funzionamento o qualsiasi altro aspetto critico o comunque importante per uno o più stakeholder”.
- Un sistema ha un’architettura, e questo sistema può essere espresso in una descrizione architetturale.
- La descrizione architetturale può essere suddivisa in “viste” che sono “una rappresentazione di un intero sistema dalla prospettiva di un insieme correlato di preoccupazioni”. Ogni vista affronta una o più preoccupazioni degli stakeholder.
Ma ci sono altri modi di pensare a ciò che è o non è l’architettura. Per esempio, John Zachman distingue tra architettura e ingegneria in termini di elementi primitivi e compositi, mentre un altro approccio è quello di formalizzare l’architettura in termini di un modello architetturale o metamodello. In realtà, questo è fondamentale per raggiungere la coerenza tra i punti di vista che la conformità alla “42010” richiede. Ma non solo: altri mettono in discussione il valore di un approccio e sono più preoccupati per la sua efficacia rispetto al fatto che si tratti o no di “architettura”.
E mentre è importante capire la struttura di una buona architettura, è anche importante capirne lo scopo. Ciò che è altrettanto rilevante è capire che in genere gli approcci di architettura “one-size-fits-all” non sono efficaci. In ogni impresa, la cultura, la struttura, l’organizzazione, il personale e la motivazione per l’architettura sono differenti. Alcune ricorreranno a un’architettura per ridurre la complessità e i costi, mentre altre imprese cercheranno un’architettura in grado di aiutarle nei processi di fusione o acquisizione, e altre ancora lanceranno un nuovo prodotto o servizio, o ci sarà qualche altro motivo. Ma ciascuna di queste ragioni richiederà un approccio diverso, e avrà un diverso insieme di stakeholder.
Il primo passo – Quindi, il primo passo nella progettazione di un programma di architettura è di articolare chiaramente gli obiettivi del fare architettura presso la propria azienda. Facendo qualche passo ulteriore, si può utilizzare il Business Motivation Model (BMM) per definire gli obiettivi, le strategie per il raggiungimento di tali obiettivi, i criteri di implementazione delle strategie e gli obiettivi per misurare l’efficacia delle tattiche.
In genere, utilizzo il BMM nello stesso momento in cui eseguo l’analisi degli stakeholder per assicurarmi di aver identificato gli stakeholder importanti e che i loro obiettivi e traguardi siano rappresentati. Con una migliore comprensione del perché stiamo adottando un’architettura, potremmo rivolgere la nostra attenzione al come.
Definire lo scopo – Alla base, lo scopo dell’architettura è quello di creare un contesto che influenza le decisioni. Si può trattare di decisioni di selezione delle tecnologie o di progettazione delle soluzioni, oppure ancora di scelta di progetto e gestione del portfolio, o di esecuzione di business transformation, solo per citarne alcune. Chiaramente, ciascuna di queste decisioni richiede un contesto diverso e informazioni differenti per influenzare le varie persone che prendono tali decisioni, mentre gli stakeholder e le decisioni dovrebbero essere già stati identificati nell’analisi precedente. È facile mettere in relazione tutto questo alla descrizione di cui alla ISO 42010: stakeholder diversi hanno problemi differenti, che sono descritti in vari punti di vista. Ma non basta aver individuato gli stakeholder e le loro preoccupazioni, perché bisogna portare la definizione della nostra architettura e del programma al passo successivo. Bisogna anche capire il modo migliore per influenzare le decisioni degli stakeholder per quanto riguarda queste preoccupazioni.
La formula del successo – La mia formula per il successo architetturale è questa: «Se la tua architettura rende più facile per qualcuno svolgere il suo lavoro, lo faranno. Se lo rende più difficile, la combatteranno».
La formula in sé è davvero molto semplice. Sembra così ovvio, ma si sa bene che raggiungere il successo è sempre un’altra questione. Quindi, potrebbe essere doveroso chiederci come potremmo rendere più facile il lavoro di qualcuno? Ovviamente, la risposta a tutto questo dipende dalle persone, dalle loro competenze, dal loro lavoro, da come la pensano, e da quali risultati o decisioni stiamo cercando di influenzare. Io uso una serie di domande per determinare la struttura delle architetture:
1 . Quali decisioni stiamo cercando di influenzare con l’architettura? (preoccupazioni)
2 . Chi prende queste decisioni? (stakeholder)
3 . Quali processi usano per prendere tali decisioni?
4 . Dove sono le opportunità all’interno di questi processi per influenzare le loro decisioni?
5. Quale struttura sarebbe utile: (punti di vista)
• a questo punto nel processo
• per quella persona
• dal loro punto di vista, dai loro tool e insieme di skill
• e che sia coerente con i principi architetturali e con le best practice!
Quindi, il problema successivo per un architetto è capire come rispondere a queste domande. Uno dei metodi migliori è quello di chiedere ai decisori stessi: chi meglio conosce i propri processi e le proprie esigenze? E poi, se sono coinvolti nella progettazione delle architetture, forse se ne sentono anche un po’ proprietari e saranno più propensi all’utilizzo.
Per fare un esempio, un cliente voleva sviluppare un’architettura di riferimento per l’implementazione di servizi SOA. L’organizzazione stava già creando servizi, ma c’erano distinzioni non necessarie e incongruenze tra tali servizi. Così, abbiamo chiesto ad alcuni degli sviluppatori più senior: “Come si fa a creare un servizio?”. Questo ha portato a numerose domande successive come “Hai pensato così e così?”, “Perché ci sono queste differenze?”, “Cosa potrebbe essere riutilizzato in tutti i servizi per risparmiare tempo e fatica a tutti?”, “Che tipo di relazioni e di interazioni vi sono tra i servizi?”, “Quali sono alcuni dei problemi?”, “Come potevamo affrontarli in anticipo in sede di progettazione?”.
Queste sono tutte le preoccupazioni architetturali alle quali gli sviluppatori di solito non pensano. Gli architetti avrebbero potuto aver appena ponderato una soluzione a questi problemi e cercato di imporla, ma avrebbe avuto successo? Invece, coinvolgendo chi adotta le scelte progettuali, siamo arrivati a far comprendere la più ampia serie di requisiti e a far sentire proprietari della soluzione. Il risultato finale della discussione è stato uno schizzo alla lavagna di un “modello di progettazione” per l’implementazione dei servizi. Successivamente, il team architetturale ha preso lo schizzo e lo ha formalizzato in un modello di progettazione vero e proprio, che viene largamente utilizzato da tutto il team per una serie di motivi:
- ha il buy-in degli “utenti”, visto che sono stati coinvolti nella sua creazione
- è la struttura giusta per influenzare le decisioni di progettazione (un modello è perfetto per questo)
- utilizzare il modello facilita il lavoro degli sviluppatori!
Così, quando si esamina ciò che è architettura e quanto ha successo un programma di architettura, forse dovremmo guardare verso l’interno e chiedere: “La nostra architettura è correttamente concentrata sugli obiettivi più importanti e sugli stakeholder?”, “La nostra architettura rende più facile o più difficile il lavoro delle persone?”, “Riesce a influenzare le decisioni che portano alla realizzazione della visione architetturale?”. Le architetture di successo sono in grado di rispondere sì a tutte queste domande. E voi?
Mike Rosen
Mike Rosen è director per l’Enterprise Architecture presso il Cutter Consortium e direttore editoriale del SOA Institute. Ha esperienza pluriennale nell’architettura e nella progettazione di applicazioni e oltre 20 anni di esperienza nello sviluppo di prodotti per tecnologie distribuite come DCE, CORBA, DCOM, J2EE, Web Services, Transaction Processing e Messaging. È speaker di fama internazionale e autore di numerose pubblicazioni, tra cui “Applied SOA: Architecture and Design Strategies”. È stato chief enterprise architect presso IONA Technologies, dove era responsabile dello sviluppo dell’intera architettura di prodotto della piattaforma di Web Services di nuova generazione di IONA e della creazione dell’architettura di riferimento per la realizzazione di applicazioni su questa piattaforma.
Mike Rosen presenterà a Roma per Technology Transfer i seminari “Le scelte architetturali che funzionano” il 24-25 novembre 2014 e “Come diventare un grande Architetto” il 26-27 novembre 2014.
