Comprendere il valore delle architetture di riferimento
Non c’è niente di più che gli architetti amano fare che discutere sulle definizioni. Se mai ti trovi con il tempo di inattività in una stanza di architetti, prova a chiedere una definizione di “Servizio” o “architettura” e vedi che tipo di mischia creativa puoi iniziare. Detto questo, le definizioni sono davvero molto importanti in modo che possiamo avere un linguaggio comune per comunicare l’intento e il beneficio delle cose stesse che stiamo cercando di convincere le imprese a investire in. Da questo punto di vista, una serie di concetti sono emersi negli ultimi dieci anni o giù di lì che sono diventati il top della mente per i sedicenti architetti d’impresa: quadri di architettura e architetture di riferimento. In ZapFlashes precedenti, abbiamo discusso framework di architettura, che lascia il tema delle architetture di riferimento lasciato intatto da ZapThink. Dal momento che non possiamo lasciare un buon argomento alle spalle, useremo questo ZapFlash per esplorare quali sono le architetture di riferimento e quale valore devono aggiungere alla storia dell’architettura orientata ai servizi (SOA).
Che cos’è un’architettura di riferimento?
Una definizione comunemente accettata per l’architettura di riferimento è che fornisce una metodologia e/o un insieme di pratiche e modelli basati sulla generalizzazione di un insieme di soluzioni di successo per una particolare categoria di soluzioni. Le architetture di riferimento forniscono indicazioni su come applicare modelli e/o pratiche specifici per risolvere particolari classi di problemi. In questo modo, serve come “riferimento” per le architetture specifiche che le aziende implementeranno per risolvere i propri problemi. Non è mai previsto che un’architettura di riferimento venga implementata così com’è, ma piuttosto utilizzata come punto di confronto o come punto di partenza per gli sforzi architettonici delle singole aziende.
Altri perfezionano la definizione di architettura di riferimento come descrizione di come costruire una classe di artefatti. Questi artefatti possono essere incorporati in molte forme, tra cui modelli di progettazione, metodologie, standard, metadati e documenti di ogni tipo. Per farla breve, se hai bisogno di indicazioni su come sviluppare un’architettura specifica basata su best practice o gruppi autorevoli di potenziali artefatti, dovresti cercare un’architettura di riferimento che copra l’ambito dell’architettura che stai cercando di costruire.
Uno degli esempi più popolari di architetture di riferimento è l’architettura Java Platform Enterprise Edition (Java EE), che fornisce un’architettura di riferimento a più livelli e modelli che affrontano una serie di problemi tecnologici e aziendali che hanno guidato molti sistemi aziendali basati su Java.
Architetture di riferimento vs. Architecture Frameworks
Mentre le definizioni di cui sopra possono sembrare abbastanza tagliate e secche, c’è molto in comune tra i concetti di architetture di riferimento e framework di architettura. Per alcuni, questo è dove le cose diventano rischiose e le definizioni diventano sfocate. I framework di architettura, come il framework Zachman, l’Open Group Architecture Framework (TOGAF) e il Department of Defense Architecture Framework (DoDAF) forniscono approcci per descrivere e identificare gli input necessari per una particolare architettura, nonché i mezzi per descrivere quell’architettura. Se una particolare architettura è un libro di cucina che fornisce indicazioni su come risolvere un particolare insieme di problemi con un particolare approccio, un framework di architettura è un libro su come scrivere libri di cucina. Pertanto, i framework di architettura forniscono agli architetti aziendali gli strumenti necessari per descrivere e raccogliere adeguatamente i requisiti, senza imporre alcun tipo di architettura specifico. Più specificamente, i framework di architettura descrivono una tassonomia di esempio dei tipi di “viste” architettoniche che un architetto potrebbe considerare di sviluppare, e perché, e fornisce linee guida per fare la scelta per lo sviluppo di viste particolari.
Questo differisce dal concetto di architettura di riferimento di cui sopra in quanto un’architettura di riferimento fa un ulteriore passo avanti accelerando il processo per un particolare tipo di architettura, aiutando a identificare quali approcci architettonici soddisferanno requisiti particolari e capire quale insieme minimo accettabile di artefatti architettonici sono necessari per soddisfare i requisiti delle “migliori pratiche” per una particolare architettura. Per continuare la nostra analogia con i libri di cucina, se un framework di architettura è un libro su come scrivere libri di cucina, allora un’architettura di riferimento è un libro che fornisce indicazioni e migliori pratiche su come scrivere libri di cucina focalizzati sulla perdita di peso, per esempio. Ciò significherebbe quindi che la particolare architettura che sviluppi per la tua organizzazione sarebbe un libro di cucina specifico che fornisce ricette di perdita di peso mirate alla tua organizzazione. In effetti, se ti senti perplesso con le definizioni, sostituire il termine “architettura” con “libro di cucina” è utile: quadri ricettario, libri di cucina di riferimento, e il vostro particolare libro di cucina.
Inoltre, la maggior parte delle architetture di riferimento enfatizza la parte “template” della definizione di un’architettura di riferimento. Sia i framework che i RAS forniscono le migliori pratiche, e mentre si potrebbe sostenere che i RAS forniscono più di una metodologia rispetto a un framework, i RAS non sono ancora realmente caratterizzati dalla loro componente metodologica. La maggior parte può essere caratterizzata dal loro componente modello, tuttavia. Da questo punto di vista, i modelli sono istanze di modelli in questo contesto. In effetti, più architetture di riferimento per lo stesso dominio sono consentite e abbastanza utili. Le architetture di riferimento possono essere complementari fornendo indicazioni per una singola architettura, come SOA, da più punti di vista.
Il valore di un’architettura di riferimento SOA
In molti modi, i progetti SOA hanno un disperato bisogno di architetture di riferimento ben congegnate. ZapThink vede un alto grado di variabilità nei progetti SOA. Alcuni prosperano e riescono mentre altri passeggiano e falliscono. Molte volte la ragione del fallimento può essere ricondotta a cattive pratiche architettoniche, all’acquisto prematuro di infrastrutture e a una governance e gestione inadeguate. Altre volte il fallimento è principalmente organizzativo. Tuttavia, ciò che è comune nella maggior parte dei successi è pratiche architettoniche ben documentate e/o comunicate e un metodo sistematico per imparare dai propri errori e avere un basso costo di fallimento.
Inoltre, troviamo che molti architetti trascorrono una quantità significativa del loro tempo a ricercare, indagare, (ri-)definire, contemplare e discutere le decisioni architettoniche. In molti casi, questi architetti stanno reinventando la ruota come i loro coetanei in altre aziende, o anche la stessa azienda, hanno già speso quel tempo e lo sforzo di definire le proprie pratiche architettoniche. Questo sforzo supplementare non solo è inefficiente, ma impedisce anche all’azienda di imparare dalle proprie esperienze e di applicare tale conoscenza per una maggiore efficacia.
Da questa prospettiva, le architetture di riferimento SOA possono fornire un aiuto a coloro che lottano con i loro sforzi SOA o pensano di lanciarne uno nuovo. Le architetture di riferimento SOA consentono alle organizzazioni di imparare dai successi e dai fallimenti di altri architetti ed ereditare le migliori pratiche comprovate. Le architetture di riferimento possono fornire informazioni architettoniche mancanti che possono essere fornite in anticipo ai membri del team di progetto per consentire migliori pratiche architettoniche coerenti. In questo modo, l’architettura di riferimento SOA fornisce una base di risorse che gli sforzi SOA possono trarre da tutto il ciclo di vita del progetto.
Infatti, al fine di ottenere i benefici SOA promessi di riutilizzo, riduzione della ridondanza, riduzione dei costi di integrazione e maggiore visibilità e governance, le aziende devono applicare i loro sforzi SOA in modo coerente. Ciò significa più che acquistare e stabilire l’infrastruttura di alcuni fornitori come standard aziendale o aderire all’ultimo stack di standard WS -*. Le architetture di riferimento SOA possono servire come base per gli sforzi SOA disparati in tutta l’organizzazione, anche se utilizzano strumenti e tecnologie diverse. Le buone architetture di riferimento SOA forniscono le best practice e gli approcci SOA in modo indipendente da fornitori, tecnologie e standard. Pertanto, non andare a caccia di uno dal vostro fornitore preferito di scelta. In effetti, se hai ottenuto la tua architettura di riferimento SOA da quel fornitore, potresti prendere in considerazione l’idea di abbandonarla al posto di qualcosa di più neutrale rispetto al fornitore.
In particolare, OASIS offre un’architettura di riferimento SOA (RA) che “modella gli elementi architettonici astratti per una SOA indipendentemente dalle tecnologie, dai protocolli e dai prodotti utilizzati per implementare una SOA. Alcune sezioni del RA useranno elementi astratti comuni derivati da diversi standard.”Il loro approccio utilizza il concetto di” modelli ” per identificare diversi metodi e approcci per implementare diverse parti del quadro architettonico. Mentre l’architettura di riferimento SOA OASIS non è certamente l’unica valida sul blocco, è certamente un buon punto di partenza per coloro che cercano un’architettura di riferimento SOA vendor-neutral su cui basare i propri sforzi architettonici.
Lo ZapThink Take
Enterprise architects ha bisogno di tutto l’aiuto che possono ottenere per assicurarsi di fornire architetture affidabili, agili, resilienti e neutrali per i fornitori alla propria organizzazione che soddisfano i requisiti in continua evoluzione del business. Mentre certamente l’arte e la pratica dell’architettura aziendale continua a maturare, le aziende dovrebbero cercare di prendere in prestito il maggior numero di best practice che possono e imparare da altri che hanno già intrapreso il percorso EA e SOA. Se avete intenzione di imparare SOA, o qualsiasi forma di EA per quella materia, come si va avanti, o peggio ancora, da un fornitore, allora si rischia l’intero successo dei vostri sforzi SOA. Piuttosto, sfrutta (gratuitamente) le architetture di riferimento SOA in modo da poter avanzare a un ritmo più veloce e ridurre il rischio. Bernardo di Chartres lo mise meglio nel ben noto detto: “siamo come nani sulle spalle dei giganti, così che possiamo vedere più di loro, e le cose a una distanza maggiore, non in virtù di qualsiasi acutezza della vista da parte nostra, o di qualsiasi distinzione fisica, ma perché siamo portati in alto e sollevati dalla loro dimensione gigante.”Mettiti sulle spalle di altri giganti dell’architettura aziendale e lascia che aumentino la tua visione e il tuo successo.