Un decalogo di cose e azioni che chi ha in mano e in mente un’architettura orientata ai servizi deve evitare accuratamente.
In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.
Come per qualsiasi altro nuovo paradigma di sviluppo, le Soa offrono enormi vantaggi potenziali. Separare la realtà concreta dal puro desiderio è possibile, attraverso un’attenta pianificazione e valutazione dei rischi.
Ecco di seguito alcuni dei più comuni errori da evitare.
Non partire in quarta
Non cercare di convertire l’intera azienda alla nuova architettura sin da subito, e non trovarsi nella condizione di pagare immediatamente l’intero progetto. I progetti di maggior successo sono quelli che partono con un numero di servizi inferiore a 10, che integrano un numero limitato di sistemi e vengono completati in meno di 6 mesi. Dopo il successo iniziale, questi progetti tipicamente crescono in maniera incrementale.
Non pensare che la Soa sia solo una tecnologia
La Soa non è una tecnologia che si acquista. Si tratta di una serie di principi che regolano il modo in cui le aziende progettano la loro architettura e utilizzano la tecnologia per facilitare il riutilizzo di sistemi e applicazioni esistenti. Se ci si concentra sul massimo riutilizzo, l’integrazione verrà praticamente da sè.
Non lasciare che i dipartimenti lavorino in maniera isolata
Gli It manager non sono in grado di sezionare i processi di business per aumentare l’efficienza, così come i business manager da soli non possono riarchitettare i sistemi per garantire una migliore bottom line. Analisi e pianificazione devono essere fatte in collaborazione, per evitare che i risultati non soddisfino le aspettative.
Non eliminare e rimpiazzare
Sottovalutare gli asset esistenti può essere costoso. La maggior parte delle aziende è più vicina alla realizzazione di una Soa di quanto creda, e spesso può utilizzare e sfruttare strumenti di cui già dispone per creare una rete di servizi. Piuttosto che rimpiazzare stack vecchi con nuovi, è consigliabile aprire gli stack esistenti alla nuova tecnologia.
Non creare servizi fortemente integrati
I servizi tightly coupled vengono raramente utilizzati oltre che per l’applicazione iniziale. I servizi che richiedono linguaggi, protocolli o piattaforme specifici offrono un’usabilità ridotta, limitando di fatto uno dei principali vantaggi offerti dalle Soa.
Evitare il vendor lock-in
Realizzare un’infrastruttura Soa su piattaforme proprietarie è un errore notevole e costoso. L’apertura è uno dei principi fondamentali delle Soa, e il vendor lock-in, anche all’interno di un piccolo progetto, può compromettere tutti i progetti futuri.
Non dimenticare la sicurezza
Mentre molti progetti Soa iniziano dietro al firewall, aggiungere connettività business-to-business rappresenta un’estensione naturale e spesso un notevole vantaggio. È importante assicurarsi che un ambiente comprenda servizi di qualità enterprise, o che possa essere facilmente esteso in un secondo tempo al fine di comprenderli.
Non dimenticare la gestione
Così come la sicurezza, la gestione è critica per la qualità del servizio. Potrebbe non essere necessaria sin da subito, ma diventerà cruciale a mano a mano che la rete di servizi Soa cresce. E proprio come la sicurezza, il sistema di gestione deve operare su una vasta gamma di piattaforme per supportare una crescita estesa.
Non chiudersi in un unico schema di messaggistica
Applicazioni diverse richiedono schemi di messaggistica differenti (sincroni e asincroni, Xml e binari, solo per citarne alcuni) e dipartimenti diversi potrebbero già disporre di sistemi di messaggistica differenti. Utilizzare un solo schema di messaggistica limita la crescita e il successo.
Non creare un altro hub
Uno dei principali vantaggi offerti dalle Soa è quello di sostituire applicazioni monolitiche con processi di business creati da una serie di servizi loosely coupled. Sfortunatamente, molte implementazioni Soa richiedono pesanti servizi centralizzati che minacciano di erodere il ritorno sugli investimenti di molte iniziative Soa.
(*) Regional Director Southern Europe Iona
