Alta Velocità controllata Sviluppo ad alta velocità del software nelle aziende con normative complesse

Transcript

1 White paper Alta Velocità controllata Sviluppo ad alta velocità del software nelle aziende con normative complesse Greg Hughes, CEO di 1

2 White paper: Alta velocità controllatapiù velocità senza inutili rischi Sommario L esigenza di maggiore velocità... 3 Perché più velocità può significare più danni: conflitti tra procedure da una parte e policy e sistemi dall altra... 4 Rischi per la sicurezza... 5 Rischi per la conformità... 7 Rischi per la prestazioni... 8 Più velocità senza inutili rischi: best practice per le aziende... 8 Perché Serena? Conclusioni e riepilogo Riferimenti Informazioni sull autore Greg Hughes è CEO di e fa parte del consiglio di amministrazione. Da 35 anni Serena è impegnata nell aiutare le grandi aziende caratterizzate da normative complesse a migliorare il ciclo di vita dello sviluppo del software, accelerando la distribuzione del software stesso con meno rischi. Greg ha iniziato come ingegnere e sviluppatore di software, scrivendo applicazioni in più linguaggi e persino esercitando l arte perduta della programmazione Assembly. Prima di entrare in Serena, ha lavorato per Silver Lake Partners, Symantec, VERITAS Software e McKinsey & Company. Si è laureato presso il Dipartimento di Ingegneria elettrica e di Scienze informatiche del Massachusetts Institute of Technology e presso la Graduate School of Business di Stanford. 4

3 White paper: Alta velocità controllatapiù velocità senza inutili rischi Oggi le aziende subiscono pressioni incredibili affinché venga accelerata l innovazione del software a causa della concorrenza e venga colta l opportunità di sfruttare tecnologie rivoluzionarie come quella del mobile. Tali pressioni stanno spingendo le aziende che si occupano dello sviluppo di applicazioni ad adottare una serie di procedure moderne, elaborate presso società Web di dimensioni più ridotte, per il ciclo di vita dello sviluppo del software (SDLC, software development lifecycle). Nel tentativo di accelerare la distribuzione del software, le piccole imprese possono permettersi di aderire al motto sfoggiato da Facebook agli albori: Move Fast and Break Things (Muoviti, cambia le cose e non avere paura di romperle). Tuttavia, se vogliono aumentare la propria velocità e implementare procedure di sviluppo moderne, le aziende più grandi devono evitare i crescenti rischi in termini di sicurezza, conformità e prestazioni che caratterizzano il ciclo di vita dello sviluppo del software. La gestione del rischio associato all SDLC è particolarmente vitale in settori sensibili ad alta regolamentazione quali servizi finanziari, pubblica amministrazione, sanità, industria automobilistica e difesa. In molte imprese caratterizzate da normative complesse, alla base di processi aziendali differenziati, di prodotti esclusivi e di servizi ad alto valore si trova software proprietario. I rischi propri del ciclo di vita dello sviluppo del software possono pregiudicare preziose risorse aziendali, tra cui: Proprietà intellettuale Reputazione dei clienti Posizione giuridica e normativa Capitale finanziario Come devono agire i vertici aziendali in settori a forte regolamentazione per fare in modo che i team per lo sviluppo delle applicazioni adottino procedure di sviluppo moderne, gestendo nel contempo i rischi in termini di sicurezza, conformità e prestazioni? In altre parole, in che modo le aziende possono muoversi velocemente senza inutili rischi? L esigenza di maggiore velocità Viviamo in un era di trasformazioni straordinarie e incessanti basate sull innovazione del software. Lo sviluppo del software non è mai stato così strategico e cruciale, comportando enormi pressioni affinché vengano compressi i tempi dei cicli di sviluppo. Di conseguenza, i team che si occupano dello sviluppo di applicazioni in tutti i settori stanno adottando procedure moderne, tra cui: Sviluppo agile: pone l accento sulla necessità di distribuire software funzionante con una frequenza elevata al fine di soddisfare i clienti e accoglie requisiti in trasformazione anche nelle fasi più avanzate dello sviluppo (Kent Beck 2001). Sviluppo parallelo: consente a più sviluppatori di lavorare alle funzioni in parallelo, facendo confluire le modifiche in un unica linea principale (Appleton 2003). 3

4 White paper: Alta velocità controllatapiù velocità senza inutili rischi Continuous integration promuove frequenti build automatizzate e test di integrazione di linee di sviluppo parallele per individuare eventuali difetti fin dalle prime fasi e ridurre così le operazioni di rielaborazione (Fowler 2006). Continuous Delivery si basa sull utilizzo dell automazione, di rigide procedure per il controllo delle versioni e della collaborazione per accelerare le modifiche del software lungo il ciclo di sviluppo che porta alla produzione (Farley 2011). Lean: adatta i principi del sistema di produzione Toyota, tra cui Kanban board, allo sviluppo del software, eliminando gli sprechi (cioè le attività che non contribuiscono al valore per i clienti) e le batch di piccole dimensioni (Jez Humble 2014) (Vodde 2009). DevOps: mira a migliorare la collaborazione e gli obiettivi condivisi tra sviluppo e operations al fine di risolvere i conflitti tra questi due team (Gene Kim 2015). Uno sviluppo innovativo del software è decisivo per sbloccare il potenziale di tecnologie che possono risultare rivoluzionarie. Secondo uno studio condotto da McKinsey & Co., le tecnologie innovative sono potenzialmente in grado di avere un impatto economico compreso tra 14 e 33 trilioni di dollari all anno nel 2025 (James Manyika 2013). Di seguito vengono indicate alcune di queste tecnologie: Dispositivi mobili: l iphone 4 (costo: 400 dollari) ha prestazioni analoghe al supercomputer più veloce esistente nel 1975, che costava 5 milioni di dollari. Intelligenza artificiale: dai tempi di Deep Blue di IBM (campione di scacchi nel 1997) a Watson (vincitore di Jeopardy nel 2011), si è registrato un incremento di 100 volte delle prestazioni in termini di potenza di elaborazione. Internet of Things: negli ultimi cinque anni, il numero di dispositivi M2M (machine-tomachine) connessi è aumentato del 300%. Tecnologia cloud: il rapporto prezzo/prestazioni di un server nel cloud pubblico raddoppia ogni 18 mesi. È necessario adottare procedure di sviluppo moderne. È diventata una questione di sopravvivenza. Perché più velocità può significare più danni: conflitti tra procedure da una parte e policy e sistemi dall altra Gli sviluppatori di software devono essere liberi di adottare procedure moderne per rendere più efficiente la propria attività. Tuttavia, sebbene tali procedure comportino vantaggi, spesso i sistemi e le policy che si basano su di esse sono deboli e introducono nel ciclo di vita dello sviluppo del software vulnerabilità che possono risultare particolarmente problematiche per le grandi aziende in settori con normative complesse. Di seguito vengono riportate alcune di queste vulnerabilità: Consentire il proliferare di numerosi repository di codice open source (ad es. GIT ed SVN). Consentire agli sviluppatori di configurare e gestire i propri repository di codice sorgente senza tutele adeguate e senza un quadro strategico generale. 4

5 White paper: Alta velocità controllatapiù velocità senza inutili rischi Controlli degli accessi, protezione delle password e meccanismi di autenticazione di qualità scadente per un team di sviluppo distribuito a livello globale. Controlli e misure di applicazione dei processi scarsamente efficaci, ad esempio: Gestione delle modifiche Test e QA automatizzati Ciclo di vita sicuro dello sviluppo/analisi statica della sicurezza Controllo sull uso del modulo per il codice open source Gestione dell onboarding per dipendenti e consulenti Processi altamente manuali Mancanza di registri degli eventi dettagliati e carenza di tracciabilità, con un conseguente livello insufficiente di supporto per gliaudit Inadeguate separazioni dei compiti e procedure di approvazioni dei carichi di lavoro Mentre le piccole imprese possono adottare il motto di Facebook Move Fast and Break Things, quelle più grandi, in particolare in settori ad alta regolamentazione, devono muoversi velocemente senza inutili rischi. Man mano che gli sviluppatori di software implementano nuove procedure per accelerare la commercializzazione, dirigenti e azionisti devono avere la certezza che i rischi relativi all SDLC vengano gestiti in maniera efficace. Per trovare un equilibrio tra questi principi in conflitto, è opportuno che i dirigenti applichino all SDLC la filosofia dell ERM (Enterprise Risk Management, gestione del rischio aziendale). A tale scopo, è necessario che i team che si occupano di sviluppo delle applicazioni, gestione delle modifiche, sicurezza/rischi IT e verifiche operino in stretta collaborazione con esperti del settore. Il primo passo di questo approccio consiste nell identificazione dei rischi in termini di sicurezza, conformità e prestazioni che caratterizzano lo sviluppo del software. Rischi per la sicurezza Il 12 gennaio 2010 Google ha dichiarato in un post pubblico sul proprio blog di essere stata vittima di un attacco informatico estremamente sofisticato nei confronti della sua proprietà intellettuale più preziosa: il suo codice sorgente (Drummond 2010). L attacco, successivamente denominato Operazione Aurora, proveniva dalla Cina e aveva come obiettivo la sottrazione (o forse la modifica) del codice sorgente di decine di società statunitensi di numerosi settori sensibili, tra cui software, difesa e servizi finanziari. L attacco è stato uno dei primi esempi di minaccia persistente avanzata, un sistema di malware che agisce furtivamente penetrando nelle reti alla ricerca di proprietà intellettuale di valore per poi, non appena le condizioni lo consentono, appropriarsene indebitamente prima di essere rilevato. 5

6 White paper: Alta velocità controllatapiù velocità senza inutili rischi Secondo Dmitri Alperovitch, vicepresidente di McAfee Labs, [i] sistemi SCM (Source Code Management, gestione del codice sorgente) erano assolutamente accessibili. Nessuno aveva mai pensato di proteggerli, nonostante sotto molti aspetti rappresentassero il patrimonio più prezioso di gran parte di queste aziende. Molto più di qualsiasi dato finanziario o che consenta l identificazione personale di qualcuno, risorse nella cui difesa le società investono una quantità enorme di tempo ed energie (Zetter 2010). Le minacce informatiche costituiscono un problema crescente in settori caratterizzati da normative complesse, come testimonia la dichiarazione del CEO di JP Morgan Chase, secondo il quale la banca raddoppierà la propria spesa destinata alla sicurezza informatica da 250 a 500 milioni di dollari all anno dopo una recente violazione salita agli onori della cronaca (Tracy 2014). Queste minacce informatiche hanno due diverse origini, entrambe mosse da forti motivazioni: una all interno e una all esterno all azienda: Origine interna: dopo la vicenda che ha visto protagonista Edward Snowden, le aziende si stanno rendendo conto degli enormi danni che possono essere provocati da persone autorizzate ad accedere alle informazioni, ad esempio dipendenti, consulenti e team all estero. La minaccia interna non è sempre riconducibile a soggetti malintenzionati; più spesso, la causa è da ricercarsi nella scarsa competenza di persone che operano in azienda. Di recente chi scrive ha avuto notizia di un cliente del settore dei servizi finanziari a cui è capitato che uno sviluppatore abbia inviato codice sorgente al proprio indirizzo privato. Origine esterna: le minacce esterne sono quelle che presentano i livelli più elevati di finanziamento, sofisticatezza e organizzazione e in genere vengono suddivise nelle seguenti quattro categorie: 1. sponsorizzate da un governo nazionale, 2. criminalità organizzata, 3. hacktivist e 4. terroristi. Esiste una vasta gamma di minacce per la sicurezza dell SDLC, tra cui: Furto di proprietà intellettuale: è possibile che il codice sorgente rappresenti la proprietà intellettuale più importante generata da un azienda. Nell ambito dell Operazione Aurora, Google, Adobe, Juniper Networks e Rackspace hanno tutte confermato di aver subito attacchi ai propri sistemi. Stando alle notizie riportate dai media, anche decine di altre società di primo piano sono entrate nel mirino dei criminali informatici. Modifiche non autorizzate alla sorgente ( backdoor ): gli autori degli attacchi che riescono ad accedere al codice sorgente possono installare backdoor, dando loro istruzioni command & control su funzioni chiave. Utilizzo del codice sorgente per individuare le vulnerabilità: esaminando il codice sorgente sottratto, gli autori degli attacchi possono ricavare informazioni sufficienti per trovare nuove vulnerabilità nei sistemi colpiti. 6

7 White paper: Alta velocità controllatapiù velocità senza inutili rischi Danneggiamento prima dell arrivo in produzione: nella maggior parte delle aziende, il percorso del codice completo dal team di sviluppo a quello del reparto operation è un processo non controllato altamente manuale, limitato alle ore notturne o ai fine settimana. Le applicazioni multilivello richiedono modifiche coordinate che coinvolgono un gran numero di persone, piattaforme e ambienti (ad es. mainframe, livello Web, cloud, database, ecc.). Se tali modifiche non vengono apportate correttamente, i sistemi possono essere esposti a vulnerabilità durante ogni operazione manuale. Rischi per la conformità Da quando, nel 2002, è stato approvato il Sarbanes-Oxley Act (SOX), la gestione della conformità normativa costituisce un onere crescente nell ambito dell SDLC. Alla luce della natura sempre più variegata delle norme a diversi livelli (statale, federale e internazionale), è difficile stare al passo con le modifiche all SDLC necessarie, in particolare per settori altamente regolamentati quali: Servizi finanziari: Gramm-Leach-Bliley Privacy Act (GLBA), Dodd-Frank, Basel III Assicurazioni: Model Audit Rule Pagamenti: Payment Card Industry Data Security Standard (PCI DSS) Sanità: Health Insurance Portability and Accountability Act (HIPAA), Affordable Care Act Industria automobilistica: ISO26262 Pubblica amministrazione: Federal Information Processing Standards/Federal Information Security Management Act (FIPS/FISMA) Settore aerospaziale/difesa: Export Control Act Attenersi a nuove normative presenta costi non irrilevanti. Ad esempio, si prevede che la Regulation SCI (Systems Compliance and Integrity) della Securities and Exchange Commission statunitense, che riguarda 44 organismi, avrà un costo complessivo iniziale pari a 242 milioni di dollari, più altri 191 all anno. Il rischio di non conformità è un grave problema per i dirigenti di settori caratterizzati da normative complesse. Il tempo, le risorse e i costi causati dalle controversie legali sono onerosi per i team dirigenziali e le penali imposte dalle istituzioni governative possono essere ingenti. Il ciclo di vita dello sviluppo del software per i sistemi chiave rappresenta uno degli ambiti principali cui si rivolgono queste normative (Epps and Norris 2012) (MSDN 2006). La conformità richiede l adozione di procedure di sviluppo sicure e la gestione rigorosa di processi quali autorizzazione, separazione dei compiti, controllo delle modifiche e supporto delle verifiche (ad es. creazione di registri e report). 7

8 White paper: Alta velocità controllatapiù velocità senza inutili rischi Oltre alla conformità normativa, quella legale costituisce un ulteriore problema per l SDLC. Sempre più spesso gli sviluppatori di software usano codice sorgente disponibile gratuitamente online per far fronte a scadenze urgenti. In che modo viene monitorato tutto questo codice sorgente? Come fanno le aziende ad accertarsi che vengano rispettate le restrizioni in materia di licenze? Infine, in che modo le imprese verificano che al software vengano applicate le patch adeguate e che il software stesso venga aggiornato in caso di necessità? Rischi per la prestazioni In questa sede, il concetto di prestazioni ha un accezione vasta, ossia il fatto che il software svolga il compito per il quale è pensato. Nell ambito dell SDLC si presentano rischi in termini di prestazioni quando non vengono portati a termine i test opportuni o quando questi ultimi possono essere elusi prima che il codice vada in produzione. Il processo di rilascio, ossia la promozione del codice dallo sviluppo alla produzione, è una delle fasi più rischiose dell SDLC. Uno dei casi più catastrofici di rischio in termini di prestazioni è la vicenda di Knight Capital (Heusser 2012), una società di high-frequency trading tra i principali operatori nel campo delle azioni statunitensi. Nel giugno 2012 la borsa di New York è stata autorizzata a lanciare il proprio Retail Liquidity Program (RLP) e ha informato le società di trading (tra cui Knight Capital) che tale programma sarebbe diventato operativo il 1 agosto. Nella fretta di approntare il proprio software di trading entro quella data, Knight Capital ha commesso un grave errore che le ha causato perdite vicine ai 440 milioni di dollari nei primi 30 minuti di contrattazioni. La società ha subito danni talmente gravi da dover essere acquisita da una concorrente (Getco LLC). Secondo un articolo pubblicato sul New York Times con il titolo Trying to Be Nimble, Knight Capital Stumbles ( Knight Capital cade dopo aver cercato lo scatto), la concorrenza ha sollevato dubbi sull approccio aggressivo di Knight Capital (Silver-Greenberg 2012). Il tempo intercorso tra l approvazione del software e la sua implementazione è stato incredibilmente breve ha dichiarato un responsabile degli scambi azionari di un altra società. Da un analisi dettagliata è emerso come Knight Capital abbia implementato per errore nella produzione un modulo software di prova che ha eseguito le proprie contrattazioni anziché reagire a quelle di entità esterne (Nanex Research 2012). Questo modulo software di prova non avrebbe mai dovuto essere implementato in produzione. È stato inserito accidentalmente nel pacchetto di rilascio e attivato nel sistema in tempo reale della borsa di New York. Alta velocità controllata: best practice per le aziende Man mano che implementano nuove procedure per accelerare lo sviluppo delle applicazioni, le aziende che operano in settori caratterizzati da normative complesse devono adottare un approccio disciplinato e programmatico alla sicurezza, alla conformità e alle prestazioni dell SDLC. Nei paragrafi che seguono vengono illustrate cinque best practice da prendere in considerazione in tal senso. 8

9 White paper: Alta velocità controllatapiù velocità senza inutili rischi 1. Adottare strumenti intuitivi per gli sviluppatori: non è un caso se questa regola viene indicata per prima. Se gli sviluppatori non si trovano bene con gli strumenti che hanno a disposizione, cercheranno di evitarli. Senza eccezioni. La tecnologia di gestione del rischio deve fungere da protezione invisibile per gli sviluppatori. Il team di sviluppo delle applicazioni boicotterà i sistemi forniti dall IT se questi ultimi non supportano le procedure avanzate auspicate dal team stesso o se risultano eccessivamente difficili da usare. Gli strumenti devono adottare procedure di sviluppo moderne e supportare interfacce utente all avanguardia. 2. Potenziare il livello di controllo dei processi lungo l intero SDLC: in molte aziende l SDLC consta di numerosi prodotti distinti privi di una solida base in termini di gestione dei flussi di lavoro tra i diversi prodotti. Soluzioni efficaci per la gestione dei processi semplificano il coordinamento delle attività e delle informazioni tra i vari strumenti, garantendo le funzioni di monitoraggio degli eventi e di controllo degli accessi necessarie per la gestione del rischio. Di seguito vengono evidenziate alcune delle principali aree relative ai processi che riguardano i diversi prodotti su cui concentrarsi: Imposizione dell utilizzo di procedure sicure per il ciclo di vita dello sviluppo, ad esempio sicurezza e analisi open source. Solida gestione delle modifiche, ad esempio richiesta di modifica per l integrità del codice sorgente dalla sua creazione al caricamento. Gestione dei rilasci, ad esempio verificando che vengano seguite tutte le procedure appropriate, tra cui l approvazione da parte del Change Advisory Board (CAB). Onboarding e offboarding di consulenti/dipendenti 3. Implementare l automazione ogniqualvolta è possibile: la sostituzione di procedure manuali con l automazione garantisce ripetibilità, limita i costi e riduce il rischio di errori (intenzionali o meno che siano). In alcuni casi l automazione comporta vantaggi accessori, aumentando la velocità dei processi operativi, contenendo i costi e assicurando al tempo stesso controllo e tracciabilità. Ad esempio, nella maggior parte delle aziende, la distribuzione delle applicazioni è un processo a elevato coinvolgimento di risorse che vede la partecipazione di molte persone nelle ore notturne e nei fine settimana. I prodotti per l automazione di questa operazione possono eliminare centinaia di attività manuali, sostituendole con un processo standardizzato, verificabile e automatizzato. 4. Tenere a freno la proliferazione dei repository e creare un solido sistema centralizzato per la gestione del codice sorgente: questo è il corollario alla prima regola. Troppe aziende si lasciano sfuggire di mano il numero di repository di codice sorgente perché gli sviluppatori possono facilmente elaborare i propri sistemi basati su open source, ad esempio GIT e Subversion. La gestione delle modifiche e della configurazione del software (Software Change and Configuration Management, SCCM) va centralizzata e consolidata, ad esempio configurata in sicurezza, gestita correttamente e installata su un altro server protetto (McAfee Labs 2010). La scelta dei fornitori è fondamentale: non tutti i prodotti SCCM, infatti, supportano un livello sufficiente di sicurezza e controllo, ad es. controlli granulari e integrati degli accessi, funzioni dettagliate di verifica e di creazione di registri (per individuare comportamenti anomali, garantire 9

10 White paper: Alta velocità controllatapiù velocità senza inutili rischi la verificabilità e favorire l analisi forense dopo il verificarsi di un evento), analisi integrata da parte dei colleghi, configurazioni base. Le aziende con le prestazioni migliori si concentrano su solide procedure di controllo delle versioni (Puppet Labs 2014). Ad esempio, Google ha un unico repository di codice che supporta ingegneri e tra commit di codice e test automatici al giorno. Se i dirigenti di Google riescono a contenere la proliferazione dei repository, chiunque può farlo! 5. Continuare a usare il mainframe per i sistemi transazionali principali: molte aziende continuano ad ampliare la capacità del proprio mainframe, tra le altre cose per la sicurezza senza eguali garantita da questi sistemi. Le vulnerabilità del mainframe (secondo NIST e US-CERT) si contano sulle dita di una mano rispetto alle centinaia che caratterizzano Windows, Linux e UNIX. Perché Serena? Da 35 anni Serena è impegnata ad aiutare le grandi aziende caratterizzate da normative complesse a migliorare il ciclo di vita dello sviluppo del software, accelerando la distribuzione del software stesso con meno rischi. Serena conosce i problemi specifici delle grandi imprese ad elevata regolamentazione, fornendo i propri servizi a più della metà delle società della classifica Fortune 100 quali assicurazioni, banche commerciali, gestori dei pagamenti, gestori dei patrimoni, enti della pubblica amministrazione, ospedali e fondi previdenziali, enti per la sicurezza nazionale/difesa e telco. Ad esempio, negli Stati Uniti, tra i clienti di Serena figurano: Otto delle10 banche principali Le cinque società più importanti del settore aerospaziale e della difesa Sei delle 10 compagnie leader di assicurazione sulla vita. Le tre società più importanti nel campo delle assicurazioni sanitarie e fondi previdenziali Per soddisfare le notevoli esigenze di queste aziende di primo piano, Serena offre un pluripremiato servizio clienti di livello eccezionale, con un personale che vanta un esperienza straordinaria, avendo prestato servizio in media per più di 11 anni. Il fatto che l attenzione venga posta sul cliente dà impulso alla fidelizzazione (in media, i 100 clienti principali di Serena collaborano con quest azienda da 18 anni). I quattro prodotti più importanti della gamma di Serena accelerano l adozione di best practice per l SDLC: Serena Business Manager: una piattaforma per i flussi di lavoro che consente di potenziare il livello di controllo dei processi lungo l intero SDLC. Serena Deployment Automation: per l automazione della fase di distribuzione delle applicazioni. Dimensions CM: un sistema SCM (Software Change Management, gestione delle modifiche del software) intuitivo per gli sviluppatori, scalabile, tracciabile e sicuro per tenere sotto controllo il proliferare dei repository. 10

11 White paper: Alta velocità controllatapiù velocità senza inutili rischi ChangeMan ZMF: lo strumento SCM mainframe leader per le applicazioni transazionali mission critical. Serena si attiene con dedizione alla prima regola definita dalle best practice, facendo in modo che tutti i prodotti siano intuitivi per gli sviluppatori. Gli sviluppatori di software di Serena utilizzano i prodotti dell azienda per l SDLC, sfruttando forum di consulenza per i clienti, gruppi virtuali di utenti ed eventi per ottenere feedback dai clienti. Le soluzioni Serena riflettono la complessità dell SDLC aziendale, integrandosi con prodotti di terze parti (open source, proprietarie, mainframe) e adattandosi facilmente a processi personalizzati. Serena Business Manager In una grande azienda, il ciclo di vita dello sviluppo del software consta di flussi di lavoro trasversali a team specializzati che si occupano di diverse aree funzionali, ognuno utilizzando strumenti differenti per il proprio lavoro. In fase di rilascio del software, ad esempio, entrano in scena sviluppo, QA e operation, mentre gli strumenti impiegati includono gestione del codice sorgente, database dei difetti e gestione dei test. Altri flussi di lavoro comprendono gestione delle modifiche, monitoraggio di problemi e difetti, gestione dei consulenti e onboarding del personale. In molte aziende questi flussi di lavoro non sono gestiti e i dipendenti usano una serie di tecnologie ad hoc (ad es. , fogli di calcolo, ecc.) per promuovere il coordinamento necessario per svolgere la propria attività. Tuttavia, se apparentemente permette di risparmiare qualcosa, questo approccio non gestito presenta svariati costi e problemi nascosti. È opportuno che le aziende di dimensioni maggiori passino da flussi di lavoro non gestiti a quelli gestiti nel loro SDLC, utilizzando un applicazione per processi per ottenere i seguenti vantaggi: Promuovere un processo standard uniforme Tenere traccia delle operazioni necessarie per ottemperare a policy e normative e per supportare le verifiche Garantire trasparenza e responsabilità, evidenziando chi fa cosa e chi no Concentrarsi sui colli di bottiglia a livello di processi e risolverli a supporto di un continuo miglioramento dei processi stessi Automatizzare e orchestrare le procedure per ridurre il tempo dedicato ad attività che non forniscono valore aggiunto Storicamente, le applicazioni basate su processi nell SDLC sono state sviluppate mediante due possibili approcci: (1) se disponibile, acquistando un applicazione pacchettizzata o un servizio SaaS, oppure (2) sviluppando internamente soluzioni. Questi ultimi vengono elaborati in una miriade di modi: applicazioni appositamente sviluppate in linguaggi di programmazione moderni, inserendo scriptnon standard in sovrascrittura ai singoli prodotti o persino utilizzando Lotus Notes e SharePoint. 11

12 White paper: Più velocità senza inutili rischi Spesso le applicazioni pacchettizzate sono caratterizzate da scarsa flessibilità, risultando difficili da personalizzare o da adattare a cambiamenti futuri. Di frequente i sistemi sviluppati internamente sono complessi da gestire e possono non disporre di funzioni base condivisibili aziendalmente quali il controllo della sicurezza e degli accessi. Serena offre una terza via per sviluppare applicazioni basate su processi per la gestione dei flussi di lavoro nell SDLC: usando la piattaforma Serena Business Manager (SBM) per l automazione dei processi. SBM è una piattaforma BPM (Business Process Management, gestione dei processi aziendali) per l IT progettata da zero per automatizzare i processi chiave che caratterizzano le diverse esigenze in termini di gestione dello sviluppo delle applicazioni e dei rilasci, di processi operativi IT e, più in generale, di manutenzione dell IT. Di solito i clienti Serena applicano la piattaforma SBM in tre fasi diluite nel tempo: 1. ottenimento di risultati rapidi nell SDLC, 2. implementazione di SBM per gestire processi IT di più ampia portata, 3. estensione di SBM a processi aziendali che si intersecano con l IT (Tabella 1). Tabella 1. Fase Esempi 1. Ottenimento di risultati rapidi nell SDLC. In genere, potenziare il livello di controllo dei processi nell SDLC rappresenta un opportunità ricca di obiettivi per SBM. 2. Implementazione di SBM per gestire processi IT di più ampia portata. SBM è una piattaforma eccellente per la gestione dei processi IT. 3. Estensione di SBM a processi aziendali che si intersecano con l IT. Gli utenti più aggressivi di SBM ne ampliano il raggio di azione per gestire una vasta gamma di processi aziendali. Serena offre modelli di processi per una serie di flussi di lavoro dell SDLC, tra cui: Gestione di problemi e difetti Gestione delle richieste di modifica Gestione del lavoro e dei progetti Gestione dei casi di test Gestione del codice open source Gestione dei rilasci: Serena offre un applicazione basata sulla piattaforma SBM per la gestione dei rilasci. Serena Release Control favorisce la maturazione del processo di gestione dei rilasci, migliorando trasparenza, tracciabilità e controllo. Gestione dei servizi IT, ad es. Serena Service Manager, un applicazione supportata dalla piattaforma SBM che promuove il passaggio alla gestione dei processi basata su ITIL per incidenti, modifiche e problemi Gestione della sicurezza, ad esempio gestione degli incidenti di sicurezza e dei certificati Gestione e monitoraggio delle risorse Provisioning dei server Analisi delle cause profonde Risorse umane: onboarding/offboarding dei dipendenti, gestione dei consulenti, provisioning di nuove assunzioni Vendite: processo di definizione dei preventivi, approvazione degli sconti, riferimenti dei clienti Finanza: rimborso delle spese, approvazione delle richieste di viaggio, richieste di acquisto, richieste di spese in conto capitale Reparto legale: approvazione dei testi, conservazione ai fini di contenziosi Aspetti specifici del settore: elaborazione delle richieste di risarcimento, gestione delle sperimentazioni cliniche 12

13 White paper: Più velocità senza inutili rischi SBM offre i seguenti vantaggi come piattaforma per la gestione dei flussi di lavoro legati ai processi: Creazione rapida di applicazioni basate su processi: è possibile iniziare con uno dei modelli di processo base per poi utilizzare Composer, uno strumento unificato per la progettazione di applicazioni basate su processi, per perfezionare il risultato. Composer è una soluzione completamente visiva che modella tutti gli aspetti di un applicazione, compresi flussi di lavoro umani, flussi di lavoro dei sistemi, integrazioni, form dinamici e interazione tra gli utenti, regole aziendali, ruoli, privilegi, report e dipendenze. Facilità di personalizzazione e adattamento: gli analisti aziendali possono facilmente modificare flussi di lavoro, form, dati, integrazioni, regole, privilegi e altri elementi tassonomici utilizzando SBM Composer, per poi implementarli senza perdere dati (anche cronologici) o pregiudicare l integrità dei processi. Se necessario, è possibile apportare modifiche anche a elementi dei processi dinamici. Tutte le modifiche apportate ai processi vengono automaticamente sottoposte al controllo della versione sia a design time che a run time e possono essere facilmente annullate. Integrazione con altri sistemi: è possibile utilizzare il motore di orchestrazione integrato per gestire integrazioni sofisticate con altri sistemi attraverso servizi Web e API basate su REST, acquisire informazioni da più fonti e metterle a disposizione degli utenti in tempo reale, nonché automatizzare le procedure che in precedenza richiedevano un intervento manuale. Utilizzo delle ricche funzionalità di creazione di report e di verifica: è possibile concentrarsi sui colli di bottiglia a livello di processi con una libreria integrata di report e dashboard di elencazione, di distribuzione, sulle tendenze e di altro tipo. Gli utenti finali possono creare report avanzati per gestire e valutare il lavoro automatizzato in SBM con procedure guidate per la creazione e la modifica di report di facile utilizzo. SBM presenta inoltre funzioni complete di verifica delle modifiche, con funzionalità automatiche di acquisizione delle modifiche stesse e di creazione di report su di esse, a supporto della governance normativa. Vasto modello di privilegi basato sui ruoli completamente personalizzabile in SBM Composer: chi si occupa di progettazione dei processi può definire sicurezza basata sui ruoli a livello applicativo fino al livello dei dati/del campo e specifiche azioni relative ai flussi di lavoro per soddisfare requisiti di conformità normativa e di sicurezza. Inoltre, il motore SSO (Single Sign-On) di SBM fa in modo che l identità dell utente che partecipa venga diffusa in sicurezza in tutti i flussi di lavoro di sistema attivati per garantire l integrità delle transazioni. Supporto dell intera gamma di dispositivi in dotazione agli utenti (cellulari, tablet e PC): ivi incluse approvazioni preferenziali e notifiche istantanee in ogni luogo o circostanza in cui vi siano utenti al lavoro. Serena Business Manager e le sue applicazioni per processi costituiscono la base di una strategia volta a migliorare il controllo dei processi lungo l intero SDLC, applicando poi lo stesso rigore all IT e al resto dell azienda. 13

14 White paper: Più velocità senza inutili rischi Serena Deployment Automation Come ricordato in precedenza, molte aziende stanno adottando un approccio al rilascio di nuove applicazioni avanzate basato sullo sviluppo ad alta velocità del software, che dà impulso ai profitti in quanto il software non rende dal punto di vista economico finché non arriva agli utenti. Attualmente, tuttavia, la maggior parte delle aziende utilizza un processo di distribuzione delle applicazioni altamente manuale, che prevede script personalizzati dettagliati per ciascun livello dell applicazione (ad es. database, Web, server) e può coinvolgere decine di persone (se non di più) alla volta al telefono per ore. Questo processo di distribuzione a elevato utilizzo di risorse non riesce a gestire i rilasci di software a frequenza più elevata senza aggravare notevolmente il rischio di prestazioni insufficienti o di vulnerabilità per la sicurezza. Inoltre, le aziende caratterizzate da normative complesse devono supportare le funzioni di monitoraggio dettagliato e separazione dei compiti necessarie per ragioni di conformità, uno scenario difficile in presenza di un processo manuale. La soluzione di Serena prevede l automazione della distribuzione delle applicazioni mediante Serena Deployment Automation. Serena Deployment Automation offre i seguenti vantaggi: Semplifica, standardizza e automatizza la distribuzione delle applicazioni multilivello più complesse in tutti gli ambienti Consente di distribuire in modo ottimale le applicazioni in ambienti eterogenei fisici distribuiti, virtuali e cloud Aiuta a ridurre anche del 90% gli errori delle applicazioni nelle operazioni di produzione dei data center Taglia anche dell 80% i tempi e i costi associati alla gestione delle distribuzioni Di seguito vengono riportate alcune funzioni di Serena Deployment Automation: Editor grafico di facile utilizzo per l automazione di processi e distribuzioni Distribuzioni basate su modelli mediante istantanee delle applicazioni Repository di artefatti per archiviazione e tracciabilità sicure Massima visibilità, report di verifica e di conformità pronti per l uso Architettura plug-in con supporto immediato dei principali ambienti applicativi Sicurezza, approvazioni e supporto delle notifiche basati sui ruoli Integrazione ottimale con strumenti di terze parti: SCCM, build e rilascio, QA, help desk e ticket di assistenza Serena Deployment Automation è il componente chiave di una strategia volta ad automatizzare l SDLC ogniqualvolta è possibile. 14

15 White paper: Più velocità senza inutili rischi Dimensions CM Dimensions CM di Serena vanta una storia di tutto rispetto, essendo uno dei sistemi leader per la gestione delle modifiche e della configurazione del software, con una solida presenza nelle aziende altamente regolamentate dove il controllo assoluto sul processo e sugli artefatti di sviluppo del software è un requisito imprescindibile. Tuttavia, negli ultimi 5-10 anni, con l adozione delle procedure moderne elaborate da piccole imprese anche da parte dei team di sviluppo delle grandi aziende, si sono diffuse rapidamente sacche indipendenti di Subversion e GIT, popolari strumenti open source per il controllo delle versioni. La conseguente proliferazione dei repository ha provocato numerosi problemi per le aziende caratterizzate da normative complesse: Repository multipli di codice sorgente e altri artefatti stanno creando potenziali problemi di sicurezza, di accesso e di perdita di dati. Il controllo sulle policy che regolano l accesso al codice sorgente è per sua stessa natura debole. L ottemperanza a un processo di sviluppo documentato (ad esempio controlli di sicurezza statici) viene compromessa. La gestione della configurazione e delle modifiche viene eseguita manualmente mediante labeling e/o la gestione delle differenze in fase di check-in/merging negli strumenti open source. Gli strumenti open source tengono traccia delle modifiche per mezzo di file di registro, non database completi come un vero strumento SCCM, limitando le funzionalità di verificabilità e di monitoraggio. Molti anni fa Serena ha riconosciuto questa situazione e ha effettuato ingenti investimenti di carattere tecnico nello sviluppo di un vero strumento SCCM facile da usare e potente per gli sviluppatori, assicurandosi che non si scendesse a compromessi nell ambito del controllo dei processi e degli artefatti, aspetto assolutamente cruciale per le aziende ad alta regolamentazione. Il risultato, il prodotto Serena più importante commercializzato negli ultimi sette anni, è Dimensions CM 14. Un cliente Serena Una delle banche di credito cooperativopiù grandi e in più rapida crescita degli Stati Uniti ha collaborato con Serena a supporto delle proprie applicazioni per dispositivi mobili, sempre più diffuse. Il team di sviluppo usa procedure moderne per accelerare l'innovazione e i tempi di risposta dei clienti. I team addetti alle verifiche e alla conformità, però, necessitano di tracciabilità e sicurezza. La banca di credito cooperativ usa ChangeMan ZMF per supportare le applicazioni nel sistema transazionale back-end, Dimensions CM per tutti gli altri ambienti ed SBM a supporto del controllo dei processi. Dimensions CM 14 dispone di numerose funzioni apprezzate dagli sviluppatori: Potente funzionalità di branching e merging a livello visivo. Processo di analisi da parte dei colleghi ottimizzato e integrato. Accesso ad alta velocità via WAN attraverso una cache di libreria locale. Integrazione con i principali IDE (Integrated Development Environment, ambiente di sviluppo integrato) come Eclipse e Visual Studio e con la moderna catena di strumenti di distribuzione continua (Jenkins, Hudson, Chef, Puppet, ecc.). Supporto dello sviluppo mobile. 15

16 White paper: Più velocità senza inutili rischi Dimensions CM 14 presenta anche funzioni gradite ai team operation, QA e addetti alle verifiche: Controllo granulare degli accessi per stabilire chi può fare cosa, a quali oggetti, quando e perché. Analisi retrospettiva completa per le attività di sviluppo a supporto della conformità a standard quali ISO9000, Capability Maturity Model Integration (CMMI), ecc. Gestione integrata delle richieste di modifica con livelli di controllo configurabili. Scalabilità fino a migliaia di utenti contemporaneamente, centinaia di terabyte di archiviazione e milioni di versioni di file. Dimensions supporta il bilanciamento dei carichi per una disponibilità elevata e il failover per il ripristino di emergenza. Dimensions CM funge da hub aziendale sicuro e conforme per la gestione del codice sorgente al di fuori dell ambiente mainframe. Spostando tutto il codice sorgente (compreso quello memorizzato in appositi repository come GIT e Subversion) nel centralizzato e sicuro repository di Dimensions CM, si consolida il livello di sicurezza e conformità delle aziende in termini di riservatezza, integrità e verificabilità: Riservatezza: Dimensions supporta numerosi meccanismi di autenticazione con controllo granulare degli accessi basato sui ruoli. GIT e Subversion garantiscono un supporto minimo per il controllo granulare degli accessi basato sui ruoli, l autenticazione è limitata e difficile e il livello di autorizzazione è rudimentale (ad es. interi repository per GIT). Integrità: Dimensions dispone di solidi controlli antimanomissione per i dati in movimento e quelli stabili, oltre a processi integrati stage-gate, di approvazione e di revisione. In GIT e Subversion questo richiede una livello elevato di consolidamento, personalizzazioni e strumenti di terze parti. Dimensions utilizza un architettura centralizzata ad alta velocità per garantire l integrità dei dati. Auditabilità : Dimensions offre un analisi retrospettiva completa di chi ha fatto cosa, quando e perché, con registrazione di tutte le transazioni in un sistema RDBMS (Relational DataBase Management System). GIT e Subversion forniscono solo un analisi retrospettiva base sotto forma di registro dei commit e, in assenza di strumenti di terze parti, non tengono traccia dei motivi delle modifiche. Dimensions CM è la soluzione ideale per tenere a freno la proliferazione dei repository. ChangeMan ZMF Il mainframe, presente fin dagli anni 60, continua ad avere successo, soprattutto per i clienti di grandi dimensioni che lo usano per complesse applicazioni transazionali. In base a uno studio condotto da BMC, il 90% dei mainframe shop di grandi dimensioni prevede un uso stabile o crescente di MIPS nei prossimi due anni (BMC 2014). I due motivi principali addotti a giustificazione del protrarsi degli investimenti nel mainframe sono stati i vantaggi della piattaforma mainframe in termini di disponibilità e i punti di forza per quanto riguarda la sicurezza. Nell era della connettività Internet attiva 24 ore su 24 sette giorni su sette, le caratteristiche di disponibilità (ad es. virtualizzazione hardware/software, ridondanza, funzionalità hot swap, ecc.) e le tecnologie di sicurezza (ad es. coprocessori crittografici hardware) del mainframe ne fanno il server dati centralizzato di elezione per settori ad alta regolamentazione quali pagamenti, operazioni bancarie, assicurazioni e telecomunicazioni. 16

17 White paper: Più velocità senza inutili rischi Le APPstanno facendo crescere il volume di transazioni nel mainframe. Ad esempio, i clienti delle banche controllano più spesso i propri conti se sono facilmente accessibili. Molti team che si occupano di mainframe si stanno rendendo conto che sviluppare nuove APP e supportare quelle esistenti rientrano tra le priorità. Serena ChangeMan ZMF è la soluzione più completa e totalmente integrata per la gestione delle modifiche, della configurazione e del rilascio a livello di software in ambiente z/os. Da quasi 20 anni, grandi aziende con normative complesse si affidano a ChangeMan ZMF per gestire e automatizzare il processo di migrazione delle modifiche del software dall ambiente di sviluppo a quello di testing e, in ultimo, di produzione. ChangeMan ZMF è pensato per sviluppatori, addetti ai test e alla gestione dei rilasci: Gli sviluppatori possono scegliere tra diverse interfacce utente, tra cui un ambiente ISPF tradizionale o un client Windows. Gli utenti dell IDE di RDZ, basato su Eclipse, possono accedere alle funzionalità di ZMF senza abbandonare il proprio IDE. L analisi su vasta scala dell impatto e lo sviluppo parallelo sicuro migliorano la produttività. Gli addetti ai test apprezzano le ricche funzionalità integrate di approvazione e notifica, nonché quelle che garantiscono la completezza e la stabilità della distribuzione del codice. La promozione attraverso aree di test è sottoposta a rigidi controlli. Gli addetti alla gestione dei rilasci usano le funzionalità integrate di calendario dei rilasci, di pianificazione automatica degli stessi, di distribuzione automatica alle fasi di testing e produzione e di annullamento completo al fine di ridurre il rischio. La verificabilità è garantita imponendo l integrità del codice sorgente da quando viene creato al suo caricamento. Uno dei punti di forza più significativi di Serena per le aziende caratterizzate da normative complesse è la linea di prodotti per più piattaforme che supporta il ciclo di vita dello sviluppo del software dal mainframe alle applicazioni per dispositivi mobili. Vista la crescente importanza del mainframe per nuove applicazioni come quelle mobili, per molte aziende sta diventando sempre più essenziale coordinare il proprio SDLC in aree chiave quali la gestione dei rilasci. Serena è un partner tecnologico ideale per queste imprese. Conclusioni e riepilogo Le aziende di grandi dimensioni adottano moderne procedure per lo sviluppo ad alta velocità del software, tra cui: Sviluppo agile Integrazione/distribuzione continua DevOps Lean 17

18 White paper: Più velocità senza inutili rischi Domanda: quali procedure di sviluppo moderne sta adottando la tua azienda per aumentare la velocità dello sviluppo del software? Tuttavia, parallelamente all implementazione di queste procedure moderne, le aziende a elevata regolamentazione devono gestire tre rischi fondamentali nel ciclo di vita dello sviluppo del software: Sicurezza Conformità Prestazioni Domanda: quali sono i rischi principali nel ciclo di vita dello sviluppo del software della tua azienda? In che modo vengono individuati e affrontati? I dirigenti possono prendere in considerazione cinque best practice per accelerare la distribuzione del software e gestire il rischio. È opportuno che nello sviluppo della soluzione vengano coinvolti rappresentanti dei team di sviluppo delle applicazioni, di sicurezza e verifica e di gestione delle modifiche IT. Di seguito vengono indicate le cinque best practice: 1. Adottare strumenti intuitivi per gli sviluppatori 2. Potenziare il livello di controllo dei processi lungo l intero SDLC 3. Implementare l automazione ogniqualvolta è possibile 4. Tenere a freno la proliferazione dei repository con un solido sistema centralizzato per la gestione del codice sorgente 5. Continuare a usare il mainframe per i sistemi transazionali principali Domande: la tua azienda ha predisposto un iniziativa basata su una o più di queste best practice? Sta procedendo velocemente e con urgenza? Chi si occupa della promozione di queste iniziative? Serena è un partner tecnologico ideale per i dirigenti di aziende con normative complesse che desiderano incrementare la velocità dell innovazione del software. Serena è consapevole delle specifiche sfide dell SDLC nelle imprese altamente regolamentate. I quattro prodotti più importanti della gamma di Serena accelerano l adozione di best practice per l SDLC: Serena Business Manager per potenziare il controllo dei processi lungo l intero SDLC Serena Deployment Automation per automatizzare la distribuzione delle applicazioni 18

19 White paper: Più velocità senza inutili rischi Dimensions CM per tenere a freno la proliferazione dei repository ChangeMan ZMF per supportare i principali sistemi transazionali mainframe Serena si integra con sistemi di terze parti e spazia dal mainframe ai dispositivi mobili lungo l intero SDLC. Serena offre un servizio clienti best-in-class mirato all SDLC. Domanda: in che modo Serena può aiutare la tua azienda a muoversi velocemente senza inutili rischi? 19

20 White paper: Più velocità senza inutili rischi Riferimenti Appleton, Stephen Berczuk e Brad Software Configuration Management Patterns: Effective Teamwork, Practical Integration. Addison-Wesley. BMC Annual Mainframe Research Results. Risultati della ricerca, BMC Software, Inc. Drummond, David google.com. 12 gennaio. Epps, Cindy Van e Nick Norris Software Development Compliance - Overview. 28 settembre. Farley, Jez Humble e David Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Pearson Education, Inc. Fowler, Martin Continuous Integration, maggio. Gene Kim, Patrick Debois, John Willis, Jez Humble, Damon Edwards, John Allspaw The DevOps Cookbook. Pubblicazione prevista nel 2015, l autore ha rivisto la prima bozza. Heusser, Matthew Software Testing Lessons Learned from Knight Capital Fiasco. 14 agosto. James Manyika, Michael Chui et al Disruptive technologies: Advances that will transform life, business, and the global economy. McKinsey & Co. Jez Humble, Joanne Molesky e Barry O Reilly Lean Enterprise: How High Performance Organizations Innovate at Scale. O Reilly Media. Kent Beck, et al Manifesto for Agile Software. McAfee Labs Protecting Your Critical Assets: Lessons Learned from Operation Aurora. McAfee. MSDN Regulatory Compliance Demystified: An Introduction to Compliance for Developers. Marzo. Nanex Research The Knightmare Explained. 3 agosto. Puppet Labs State of DevOps Report. Silver-Greenberg, Jessica Trying to Be Nimble, Knight Capital Stumbles. 2 agosto. Tracy, Ryan wsj.com. 10 ottobre. Vodde, Craig Larman e Bas Scaling Lean & Agile Development. Pearson Education. Zetter, Kim Report: Google Hackers Stole Source Code of Global Password System. 20 aprile. 20

21 Informazioni su Serena Sito Web: Telefono: fornisce alle aziende Global 2000 soluzioni per lo sviluppo orchestrato delle applicazioni e la gestione orchestrata dei rilasci. I nostri clienti aziendali attivi, tra cui la maggior parte delle società della classifica Fortune 100, hanno fatto di Serena il più grande fornitore ALM (Application Lifecycle Management, gestione del ciclo di vita delle applicazioni) indipendente e l'unico a orchestrare DevOps, i processi che integrano sviluppo applicativo e operations. Serena, con sede nella Silicon Valley, è una società partecipata di HGGC, una media impresa di private equity leader del settore. Copyright 2015, Inc. Tutti i diritti riservati. Serena è un marchio registrato di, Inc. Tutti gli altri nomi di prodotti o società vengono utilizzati esclusivamente a scopi identificativi e potrebbero essere marchi dei rispettivi titolari. Febbraio ID documento: WP