Nel gennaio del 2008 la Commissione Europea ha varato la prima fase di attuazione del progetto SEPA con il lancio dello strumento paneuropeo di pagamento SEPA Credit Transfer (SCT), imponendo alle aziende una precisa scadenza da rispettare per la migrazione ai sistemi SEPA di incasso e pagamento. A partire dal 1 febbraio 2014, infatti, le imprese non possono più incassare crediti dai clienti attraverso i sistemi nazionali di addebito diretto invalsi fino a quel momento.
Non tutte le aziende hanno provveduto ad adeguarsi ai requisiti SEPA entro la scadenza del 1 febbraio, come ha di fatto riconosciuto la delibera del 9 gennaio di quest’anno che ha sancito una deroga di sei mesi dall’obbligo di adozione del formato SEPA per i pagamenti – pur rimanendo ferma la data ultima della migrazione fissata per il 1 febbraio. Resta comunque la speranza che la maggior parte delle aziende sia pronta e non incorra in inconvenienti seri quali mancati incassi, penali, danni di immagine e perdita di quote di mercato.
In prospettiva, quanto hanno faticato le aziende a conformarsi ai nuovi regolamenti? La scadenza di febbraio ha pesato sull’operatività degli ambienti di sviluppo e test? Come potranno essere rispettati anche in futuro gli obblighi imposti dalla SEPA o da altre direttive senza subire ricadute negative a scapito di altre iniziative aziendali altrettanto importanti, quale la messa a punto di nuove architetture applicative, le creazione di nuove applicazioni mobile o il lancio di nuovi prodotti o servizi?
Una indagine indipendente (lo studio“The Business Benefits of Service Virtualization”, commissionato da CA Technologies e condotto dalla Coleman Parkes Research mediante interviste a 100 responsabili delle funzioni QA, Development, Environments e Chief Architect in Italia) svolta nel nostro Paese fra i responsabili delle funzioni di Test, QA, Sviluppo e Architettura ha evidenziato che il 64% degli intervistati ha un’idea piuttosto imprecisa della reale scalabilità di complesse applicazioni composite (con un elevato numero di integrazioni con sistemi terzi). Queste risposte destano serie preoccupazioni perché “sperare non basta: serve una strategia”. La stessa inchiesta ha mostrato che secondo il 59% degli intervistati le funzionalità delle applicazioni sarebbero aumentate rispetto all’anno precedente, mentre il 64% ha accusato dei ritardi dovuti all’indisponibilità “occasionale”, “frequente” o “molto frequente” di sistemi o ambienti operativi.
La risposta a questi rischi inaccettabili per qualsiasi progetto va cercata nel concetto di “Service Virtualization”, ovvero la simulazione dei servizi applicativi, che serve in pratica ad affrancare chi fa sviluppo o test dall’indisponibilità degli ambienti applicativi terzi o da un numero troppo limitato e spesso troppo costoso di ambienti mainframe, SAP, sistemi di terze parti, ecc. Un apposito agente rileva il traffico fra i sistemi di test, elabora i dati e li converte in un modello “simil-reale”, configurabile, che si comporti come il sistema realtà ma che renda anche possibile dei test negativi attraverso dei casi di test “What if…?”.
La Service Virtualization nel mondo SEPA
La virtualizzazione dei servizi può rivelarsi utile per mettersi in regola con il regolamento SEPA, con altri regimi normativi o, più banalmente, con il normale ciclo di rilasci applicativi. Nel caso della SEPA, alcune banche hanno deciso di servirsi di soluzioni SaaS per convertire i tradizionali formati dei conti in codici conformi ai nuovi sistemi SEPA. L’idea è ottima, ma come si potrà assicurare un’integrazione indolore fra una piattaforma esterna e i sistemi consolidati dell’impresa? Come se ne potranno saggiare le prestazioni al variare delle richieste dei clienti? Le terze parti intestatarie della piattaforma esterna potrebbero decidere di far pagare anche l’accesso alle interfacce dei test, senza contare che la disponibilità e la performance di tali interfacce potrebbero non combaciare al 100% con le versioni impiegate in produzione. La Service Virtualization azzera tali sovraccosti, poiché opera con un modello “simil-reale”.
Pagamenti SEPA su mobile devices
Molti analisti prevedono che prima della fine del 2017 le vendite dei tablet avranno superato quelle dei PC e verranno sviluppate sempre più applicazioni con funzionalità imperniate su tablet o smartphone. Le condizioni dinamiche della rete influiscono sui canali di comunicazione fra le applicazioni, i servizi (con relative dipendenze) e gli utenti finali che spesso devono affrontare le limitazioni tipiche dell’ultimo miglio. Questo insieme di fattori complica il lavoro dello sviluppo e della certificazione perché i test eseguiti senza emulare le condizioni della rete possono dare risultati poco precisi.
Fra i principali problemi potenziali va citato un calo della performance registrato allorché i sistemi downstream e i mockup non corrispondono ai comportamenti o ai tempi di risposta richiesti. È raro che le connessioni di rete presenti nei laboratori di prova rispecchino le condizioni della rete utilizzata in produzione, andando così a inficiare le previsioni sulla performance degli utenti finali.
La virtualizzazione dei servizi di rete supera questo scoglio simulandone i tempi di risposta a seconda dei diversi scenari di produzione anziché in base a un banco di prova perfetto in cui “ha funzionato tutto bene”. La Service Virtualization rileva ed emula all’interno del laboratorio di prova le condizioni delle reti in produzione, il che significa che le connessioni usate nei test rispecchiano i limiti della vita reale. In altre parole, è possibile testare, validare e ottimizzare la performance delle applicazioni prima del deployment, pronosticando in modo affidabile i livelli di servizio dopo il deployment.
Nel corso di questa attività vengono anche generate automaticamente alcune raccomandazioni riguardanti il potenziale di ottimizzazione che in alcuni casi realizzano un miglioramento quantificabile della performance pari al 40% e più. Chi deciderà di eseguire delle transazioni SEPA su un tablet o su uno smartphone potrà usufruire dello stesso livello di performance di un portatile a casa o in ufficio.
Quanto sono realmente “robuste” le applicazioni presenti in impresa?
Un dibattito che spesso accompagna il varo di importanti pacchetti legislativi (come il regolamento SEPA) riguarda la previsione dei comportamenti futuri:che performance offrirà una data applicazione quando sarà utilizzata contemporaneamente da un certo numero di clienti, partner o dipendenti in determinati orari e con determinati volumi? Altrettanto importante sarà testarne la resilienza: cosa succederà se non saranno disponibili, attivate o pronte a rispondere una o più delle componenti da cui dipende quell’applicazione?
I progetti di distribuzione del software hanno la tendenza a sforare sui tempi, perciò spesso viene imposto di ridurre i tempi dedicati alle attività tipiche delle fasi finali del ciclo di vita di sviluppo delle applicazioni quali il performance testing. Quanto appare vicina la scadenza SEPA e quali scorciatoie si finirà col prendere? Il test di carico può essere eseguito solo verso la fine del ciclo di vita, necessita di ingenti risorse infrastrutturali, solo di rado riproduce in modo fedele i livelli di performance esistenti in produzione e non prevede quasi nessuna delle condizioni di testing negativo. In genere, i laboratori non riescono a eseguire questi test finché non sono disponibili tutti i componenti da cui dipendono le prestazioni.
La metodologia di simulazione è in grado di “catturare” migliaia di transazioni che intercorrono fra i componenti applicativi in funzione, ma a una frazione minima del costo di gestione dei dati. Questi ambienti virtuali mettono a disposizione dei valutatori un set molto più vasto di dati di prova con cui ricreare la variabilità dell’applicazione, consentendo di anticipare la verifica delle prestazioni dell’applicazione ben prima che si completi l’integrazione.
I dati dei test: raramente citati, spesso problematici
Gestire i dati relativi ai test tende a essere l’attività più dispendiosa(sia come tempo che come costi) nell’esecuzione di un test sulle prestazioni. A complicare ulteriormente la questione, parecchi dei test eseguiti sono distruttivi perciò è necessario resettare, o condizionare, i dati per il set di test successivi, allungando i tempi e accrescendo la complessità del programma di testing; ad esempio, può essere necessario simulare una serie di variabili quali date o importi cumulativi nell’ambito di una transazione in modo da validare queste tipologie di workflow complessi al livello di dettaglio necessario.
Le applicazioni composite prevedono generalmente una pluralità di data store da rifornire di dati per i test e da sincronizzare. Nel caso di carichi di lavoro più elevati cresce anche la mole di dati necessari a condurre test realistici. A ciò va aggiunto il fatto che, in seguito all’introduzione delle norme sulla tutela dei dati personali, molte organizzazioni non sono più autorizzate a usare i dati di produzione per eseguire test sulla performance. Quali dati potranno allora utilizzare per testare le interazioni dei clienti con gli strumenti di pagamento SEPA? Fino a che punto produrranno degli esiti realistici? L’impiego di modelli virtuali consente all’IT di poter sempre accedere in modalità on demand ai dataset relativi ai sistemi da testare, con la certezza che i dati comprenderanno scenari pressoché infiniti in grado di soddisfare il fabbisogno di performance test e regression test da eseguire su ingenti volumi di dati.
Visibilità completa sull’applicazione e sulla relativa performance
Pur essendo possibile programmare e prevedere il comportamento di un’applicazione prima del relativo deployment, spunteranno sempre delle sorprese, grandi o piccole, nel momento in cui verrà calata nella realtà – come, ad esempio, il possibile impatto degli accessi sui tempi di risposta negli orari di punta. La Service Virtualization può essere integrata con una tecnologia APM (Application Performance Management) per confrontare i tempi di risposta pre-produzione con quelli in produzione. In questo modo si potrà ottenere un riscontro diretto fra le metriche di produzione e i test case, simulandone i futuri comportamenti nell’ambiente reale. Per chi si occupa di performance testing e sviluppo, ad esempio, si dimostra molto utile la funzione fornita da una soluzione APM che consente di estrarre dati di produzione fra un livello e l’altro e anche all’interno di uno stesso livello applicativo. Così facendo si potrà smettere di sperare in bene puntando invece su informazioni concrete che permettano di dormire sonni più tranquilli.
La scadenza del 1 febbraio e oltre la SEPA
E’ giunto il momento di controllare il proprio stato di preparazione dopo l’entrata in vigore del sistema SEPA. Quanto tempo servirà per rilasciare aggiornamenti o correzioni di poco conto e misurare l’eventuale impatto delle prestazioni di alcune applicazioni sugli ambienti di produzione? Come cambierà l’esperienza degli utenti e quanto tempo sarà necessario per risolvere eventuali problemi? Molte delle organizzazioni di servizi finanziari più importanti si sono affidate alla Service Virtualization per ridurre sensibilmente i rischi associati ai loro programmi nevralgici – e non solo quelli insiti nella compliance normativa. È forse giunta l’ora di prendere in considerazione un’impostazione nuova per i processi di sviluppo, test e rilascio delle applicazioni?
