La governance diventa sempre più difficile a mano a mano che l’azienda si sposta verso un’architettura orientata ai servizi. Analizziamo tutte le complessità, partendo dai Web service.
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.
«I nostri processi sono a prova di bomba, nulla va in produzione se non ha superato l’intero processo di approvazione». Ultime parole famose pronunciate da fin troppi enterprise architect. Alcuni pensano realmente che sia vero, altri pensano che sperando sia vero, possa diventarlo.
La realtà, come qualunque sviluppatore può confermare, è molto meno prevedibile. La sfida è che la governance è più complessa quando l’azienda si sposta verso un’architettura orientata ai servizi.
Una delle leggende che guida le decisioni in tema di enterprise architecture governance è che “aggiungendo più regole si riduce il rischio”. Ciò può essere vero nella teoria, ma in pratica non è per niente garantito. E il motivo è semplice: la complessità implica un controllo più attento e di fatto un aumento dei i rischi. Un esempio di questo, vissuto da molti di noi, sono le policy per il controllo delle password. Al fine di migliorare la sicurezza, molte organizzazioni It hanno disabilitato l’utilizzo di parole presenti nel dizionario come password, richiedono la sostituzione frequente delle password, disabilitano il riutilizzo di password precedenti, ecc. Ne risulta che, a causa della maggiore complessità, un numero maggiore di persone scrive la password su un post-it. E le password “scritte” aumentano la possibilità di “buchi” nel sistema di sicurezza incrementando di conseguenza la difficoltà nell’individuazione del pericolo stesso.
Evitare la complessità
Ci sono due modi per affrontare la complessità: avere un numero minore di regole, ma di importanza maggiore; automatizzare l’adeguamento alle policy di sicurezza.
In termini di importanza delle regole, ci sono molti casi in cui gli architetti mettono troppa enfasi sull’aspetto tecnico e troppo poca sul business. Per esempio, vediamo un requisito tecnico: la necessità di promuovere il riutilizzo. Questa operazione spesso porta a molte regole legate all’uso di determinati schemi, meccanismi di sicurezza, progettazione di un’interfaccia di servizio, e altre. Il riutilizzo è sicuramente importante ed è quindi logico avere delle regole per promuoverlo. Ma, paragoniamolo a un’esigenza di business: la conformità alle normative – sia che si tratti di Sarbanes-Oxley (Sox), privacy, Hipaa o programma Cisp (Visa Cardholder Information Security Program) anche queste richiedono un set di regole. Supponiamo di dover scegliere tra le regole che promuovono il riutilizzo o quelle che garantiscono la conformità alle normative. Scegliereste quelle che non hanno un effetto direttamente quantificabile e, al massimo, portano a un aumento dei costi e a una riduzione dell’agilità? O scegliereste le regole che vi evitano di infrangere la legge, rischiare il posto di lavoro, essere multato o vedere chiudere la vostra azienda? Se messe in questi termini è facile comprendere quali regole sono più importanti.
L’altro approccio è quello di tentare di automatizzare al massimo il controllo delle regole. Ci sono soluzioni che consentono di farlo ad ogni stadio del ciclo di vita di un’applicazione. Certo, non tutte le regole possono essere automatizzate, ed è quindi necessario controllare da vicino e prioritizzare le regole che gli sviluppatori devono tenere presenti.
Automatizzare la governance
Per quanto riguarda le regole da automatizzare, uno degli approcci più diffusi è l’implementazione di un punto di controllo. In fase di test i servizi vengono confrontati con un set di regole automatizzate che possono verificare che i servizi siano “Ws-I compliant”, (incrementandone l’interoperabilità) e seguire poi altre regole specifiche dell’azienda come l’utilizzo di schemi predefiniti, l’uso di particolari mezzi di trasporto, ecc. L’aspetto positivo è che questa procedura cattura i servizi non conformi prima che vadano in produzione. Quello negativo è che quando il servizio viene individuato, spesso è troppo tardi e non c’è abbastanza tempo per rivedere il processo dall’inizio: quando bisogna scegliere tra rispettare una scadenza o seguire le linee guida degli architetti, spesso è il business che ha la meglio. I servizi quindi nella maggior parte dei casi vengono comunque messi in produzione rimandando gli “aggiustamenti operativi” a chi gestisce l’esercizio delle piattaforme.
Un ulteriore passo avanti relativo all’automatizzazione della validazione delle regole di governance può essere quello di applicare controlli in fase di sviluppo. Ci sono diversi prodotti in grado di validare gli stessi set di regole con un approccio “deployment checkpoint”, ma lo fanno quale parte integrante del processo di sviluppo stesso. Il vantaggio offerto da questi strumenti è che guidano lo sviluppatore di servizi da subito ed evitano di lavorare a vuoto. Un vantaggio aggiuntivo è che, non solo controllano che i metadati (come Wsdl) siano conformi alle regole, ma verificano che anche il contenuto dei messaggi lo sia.
C’è però un grande limite a questa tipologia di approcci: possono validare solo ciò che gli si dice di validare. Ed è qui che entra in gioco il terzo aspetto dell’automatizzazione della governance: governance in runtime. Ci sono tre tipologie di blind-spot nello sviluppo ed implementazione di prodotti di governance che vengono soddisfatte solo dalle tecnologie di runtime governance.
Blind Spot #1: Comportamento del servizio
Mentre gli approcci di “time development & deployment” possono verificare i metadati come Wsdl e (in alcuni casi) il contenuto dei messaggi, ciò che non possono fare è validare che un servizio si comporti in produzione secondo le regole. Per esempio, il servizio tiene un audit-trail in tutti i casi richiesti? Il servizio permette solo agli individui autorizzati di poterlo utilizzare? Questi aspetti non possono essere controllati in fase di sviluppo o deployment da strumenti di “time governance”. Anche gli strumenti di test non sono in grado di verificare in maniera adeguata che queste tipologie di regole vengano applicate in tutti i casi in cui sono necessarie. In molti casi, quando queste tipologie di regole vengono implementate nel codice, l’unico modo per assicurarsi che siano applicate correttamente è entrare nel codice e valutarlo rispetto a una vasta gamma di scenari potenziali.
In alternativa, è possibile trarre vantaggio da strumenti che fanno governance in runtime cioè sui processi veri. Questi prodotti modificano le regole di governance in base al comportamento tramite semplici configurazioni e non tramite codifica. In questi prodotti si utilizza il “point and click” per dichiarare auditing, sicurezza e altri comportamenti delle policy. Questo passaggio dalla codifica alla configurazione soddisfa due requisiti. Il primo è la ripetitività: configurando i prodotti nello stesso modo, si comportano nello stesso modo (..non si può dire lo stesso di codici custom). In secondo luogo, poiché la configurazione è un insieme di metadati, la conferma che il servizio soddisfa le regole di governance può ora essere automatizzata, eliminando o almeno riducendo in modo significativo la possibilità di errore umano e il tempo e costo della validazione.
Blind Spot #2: Consapevolezza dei processi
Le architetture orientate ai servizi modificano sensibilmente il modo in cui si deve pensare alle applicazioni in produzione. Quando un servizio va in produzione, non è la fine, ma solo l’inizio. Il motivo è che ogni volta che un servizio viene riutilizzato, diventa parte di una nuova applicazione – un nuovo processo di business – e quel processo potrebbe dover sottostare a regole totalmente diverse.
Prendiamo ad esempio un servizio utilizzato per archiviare un audit log di informazione; quando il servizio va in produzione per la prima volta potrebbero essere state definite specifiche regole di governance, verificate sia in fase di sviluppo che di deployment. Se poi un nuovo processo deve utilizzare lo stesso servizio come parte del processo di gestione ordini da parte di fornitori esteri e, tra le informazioni da loggare, ci sono anche quelle relative alla carta di credito, ecco che il servizio è di fatto soggetto a nuove regole (Visa Cisp) anche se il servizio non è stato modificato. L’unica cosa che è cambiata è il modo in cui il servizio viene utilizzato e il set di regole di governance applicabili al nuovo processo.
Il risultato netto è che non si può assumere che i controlli alla governance effettuati in fase di sviluppo e deployment su un servizio siano sufficienti. E anche qui la runtime governance viene in aiuto. I più avanzati prodotti di runtime governance possono applicare le policy non solo a servizi individuali, ma su interi processi di business end-to-end, indipendentemente da quando sono stati implementati. Poiché il processo di business e quindi il nuovo utilizzo del servizio è ciò che viene implementato, è possibile validare le policy in maniera efficace nel momento in cui si effettua l’implementazione dei processi di business. Al contrario, senza poter discriminare come i servizi sono usati nei processi di business, sarebbe obbligatorio rianalizzare ogni servizio già in produzione nel momento in cui un’altra applicazione viene implementata – un compito arduo, complesso e molto lungo.
Blind Spot #3: i servizi “fuori controllo” (rogue service)
Fino ad ora, siamo partiti dal presupposto che il processo di revisione della governance sia a conoscenza di tutti i servizi definiti dagli architetti e che in produzione siano usati solo questi. Ma, è un presupposto realistico? In molti casi no. Se un servizio va in produzione senza essere passato per il processo di approvazione corretto, si ha quello che viene definito un “rogue service” cioè un servizio” fuori controllo”. Questi servizi rappresentano un rischio organizzativo così come un forte elemento di inefficienza.
Raramente i “rogue service” sono il frutto di atti maligni. La maggior parte delle persone non cerca intenzionalmente di bypassare il processi di approvazione, ma può succedere per svariate ragioni. Per esempio, se si implementa un’applicazione di mercato o un’applicazione realizzata da una terza parte si potrebbe non essere al corrente di tutti i servizi contenuti in questa applicazione. Anche se si conoscono, a volte sono comunque troppi per valutare. Sap, per esempio, ha centinaia di servizi pronti da essere utilizzati out-of-the-box. Un secondo caso è quello di un servizio realizzato puramente per uso interno e quindi non soggetto al processo di approvazione, ma qualcuno in un’altra applicazione se ne appropria e inizia a utilizzarlo. Quando si parla di utilizzo di “rogue service”, il numero di casi in cui questo si può verificare è ancora più elevato.
Ad esempio citiamo il caso di un’azienda che, dopo aver sviluppato un servizio per 5 persone autorizzate (ognuna delle quali con una chiave speciale che ne consentiva l’identificazione), si è trovata 34 utenti in produzione. Questo perché uno dei 5 autorizzati aveva inserito l’utilizzo del servizio in un file jar che, per semplicità, integrava la chiave d’accesso di quell’utente. Ventinove altri team hanno utilizzato questo jar file senza sapere che si avvaleva di un servizio esterno, riutilizzando inconsapevolmente il servizio stesso.
L’azienda come è venuta a conoscenza di questi altri utilizzi? Per scovare un problema legato alle prestazioni del servizio hanno implementato un prodotto di runtime governance (la maggior parte misura i livelli di servizio) perché 5 utenti non giustificavano un calo nel rendimento. Il prodotto di runtime governance implementato offriva inoltre la possibilità di identificare automaticamente nuovi servizi e nuovi utenti di servizi. Il prodotto ha individuate automaticamente tutti e 34 gli utenti. Interfacciandosi con il registro dei servizi aziendali approvati, la soluzione ha determinato che 29 erano “rogue consumer” e li ha segnalati per l’approvazione. I prodotti di runtime governance più evoluti sono in grado di mettere in quarantena automaticamente i rogue service e gli utilizzi dei servizi fino al momento in cui vengono approvati, eliminandone il rischio.
Integrare il tutto
Al fine di implementare un approccio completo alla Soa governance, è necessario prendere in considerazione sviluppo, implementazione e governance in runtime. Uno sguardo olistico sugli aspetti di governance automatizza al massimo il controllo, fornendo uno strumento per catturare i rogue service i loro consumer e per gestire in modo accurato i livelli di servizio e le policy aziendali sui vari processi di business. La soluzione perfetta naturalmente non esiste e l’elemento umano gioca comunque ancora un ruolo fondamentale. Al fine di ridurre il rischio, è necessario diminuire la complessità dei processi manuali identificando strategicamente le regole necessarie o indispensabili e dando loro priorità rispetto alle regole non vincolanti per i processi di business aziendale.
* Chief technology officer di Progress Software
