MISTERO SOA. Le applicazioni orientate ai servizi: suggerimenti, spiegazioni e scenari per il loro utilizzo nelle imprese

Transcript

1 MISTERO SOA Le applicazioni orientate ai servizi: suggerimenti, spiegazioni e scenari per il loro utilizzo nelle imprese a cura della redazione di Computerworld Italia ICT e R&S >> Applicazioni, linguaggi e sistemi operativi

2 Sommario L'ABC della SOA... 4 E' questione di maturità?... 8 Quando i web services sposano i sistemi legacy Glossario Pagina 2 di 11

3 Introduzione Spiega un esperto di tecnologia: La Service Oriented Architecture (SOA) non è una nuova tecnologia rivoluzionaria che richiederà di spezzare, rimpiazzare o ristudiare tutto ciò che già si conosce. SOA è piuttosto un passo evolutivo in un percorso di interoperabilità, rappresentando una buona notizia per un qualsiasi dirigente business o dei sistemi informativi che sogni di avere a disposizione un framework tecnologico sufficientemente flessibile da poter andare incontro ai processi di business del mondo reale. Bello, ma di cosa si tratta in realtà nel dettaglio? Quando conviene adottare un'architettura orientata ai servizi? Il dossier di questo mese parte quindi con una serie di Domande e risposte sui suoi concetti di base, per non dare per scontato nulla sull'argomento. Proseguendo, attualmente le argomentazioni che spingono verso l adozione delle Service Oriented Architecture sono molteplici: di volta in volta gli analisti sottolineano l utilità delle SOA come forma di integrazione leggera fra aziende e fra sistemi informativi, come strumento per gestire in modo più flessibile i processi, come abilitatore di strategie multicanale e via dicendo. Se una SOA diventa una vera e propria topologia software dei servizi IT aziendali, nuovi o legacy che siano, diventa però essenziale progettarla e realizzarla in un modo molto più organizzato di quanto non siano oggi le attività di sviluppo e di gestione del parco applicativo d impresa. Vediamo perché. Infine, il tema integrazione per quelle realtà dotate di sistemi consolidati da tempo. Di fatto mainframe e sistemi legacy hanno posto ai responsabili IT molti grattacapi nel decennio passato, per far fronte alle necessità di aggiornamento del software, ma anche per le nuove richieste del business e di servizi per il web. Il reparto IT si è trovato nella condizione di dover affiancare i sistemi host con le componenti open più adatte a supportare le nuove applicazioni. Malgrado la forte spinta al cambiamento, molte aziende non hanno avuto le risorse o talvolta la necessità di rimpiazzare mainframe e altri sistemi informativi su cui avevano investito nel corso degli anni. Una situazione che ha fatto esplodere i problemi d'integrazione. Pagina 3 di 11

4 L'ABC DELLA SOA Questa sigla riempie giornali, dibattiti e convegni. Oltre le promesse e i numeri scarsamente controllabili, cerchiamo di capirci qualcosa Un avvertimento: la breve introduzione che segue non è farina del nostro sacco. E semplicemente quello che si trova scritto o viene detto oggi nella grandissima parte degli articoli che riguardano la SOA. E che più o meno cominciano così. Il concetto di Service Oriented Architecture è ormai nell agenda di tutti i CIO perché promette di fornire un modo più rapido di costruire e adattare le funzionalità di un software e mettere in produzione nuovi e più flessibili processi. Gli articoli e i discorsi proseguono richiamando i numeri impressionanti forniti da questo o quell istituto specializzato; per esempio quelli che indicano che tutte le oltre 300 organizzazioni intervistate in un apposito sondaggio hanno già avviato iniziative sul fronte SOA o dicono di averle programmate entro un massimo di due anni. Puntualmente ricordano che un approccio di tipo SOA permetterà finalmente di abbattere le barriere che ancora separano l IT dal business aziendale e per dar più forza a queste promesse ricorrono un altra volta alla forza dei numeri che indicano, a favore del modello SOA, una riduzione del 25% dei costi di sviluppo di cui potranno avvantaggiarsi le maggiori 2000 aziende nei prossimi 3 anni. E così via, per pagine e pagine. Sono solo alcuni degli stereotipi che, conditi dell enfasi necessaria, oggi accompagnano la SOA. Altrettanto è accaduto con il web e ancora prima con il client-server, l object oriented e così via a ritroso. Tante attese, promesse più o meno mantenute, qualche disillusione. Se qualche lezione possiamo dire di avere appreso dal passato, è proprio quella di non dare niente per scontato. Per questo allora meglio partire chiarendoci le idee almeno sui concetti di base e lasciando perdere promesse, frasi apodittiche e scenari futuribili. Ecco perché abbiamo scelto, tra le tante cose che si potevano pubblicare sull argomento, di iniziare il dossier con questa serie di Domande e risposte sui concetti di base. Sono le cose di cui più spesso sentiamo parlare in giro, a volte dando per scontati concetti, sigle e conclusioni che scontati non sono affatto. Cos è una Service Oriented Architecture (SOA)? Service Oriented Architecture è un espressione ambigua perché descrive due cose diverse. Le prime due parole indicano un metodo di sviluppo software. La terza indica l insieme delle tecnologie e applicazioni software di un azienda. Per SOA quindi si intende una strategia mirata a sviluppare tutte le applicazioni software dell azienda usando metodi di programmazione orientati ai servizi. Cos è un servizio? I servizi sono pezzi di software costruiti in modo da essere integrati facilmente con altri componenti. L idea è semplice: la tecnologia deve essere disponibile in pezzi semplici di codice software condivisibili e utilizzabili in diverse parti dell azienda. Questo si può ottenere confezionando il codice in un complesso guscio che descrive ciò che fa il componente, e come connettersi a esso. E un concetto che risale agli anni 80, quando si parlava di programmazione object oriented. La differenza è che stavolta gli oggetti software sono molto più grandi e sofisticati. Nella compagnia telefonica Verizon il servizio get CSR (richiedi il record dei servizi al cliente) è un complesso pacchetto di operazioni software ed estrazioni di dati che usa l infrastruttura d integrazione di Verizon per accedere a 25 sistemi in quattro data center sparsi negli USA. In precedenza, ogni volta che Verizon implementava una nuova applicazione o funzione di CRM, gli sviluppatori dovevano creare delle interfacce per tutti i 25 sistemi. Ora il servizio get CSR risiede in un repository centrale nella intranet di Verizon, e gli sviluppatori possono semplicemente usare il protocollo SOAP e costruire un link singolo all interfaccia che avvolge il servizio: in tal modo i 25 sistemi iniziano a marciare insieme Pagina 4 di 11

5 Le cinque promesse che spingono verso un'architettura SOA inviando i dati dei clienti alla nuova applicazione e risparmiando mesi di lavoro di sviluppo ogni volta. 1 Raggiungere maggior flessibilità nei Qual è la differenza tra SOA e web services? processi aziendali Ci sono molti modi di collegare i servizi: interfacce 2 Costi ridotti nell integrazione delle applicazioni esistenti sviluppate internamente, software di integrazione EAI, 3 Costi ridotti nello sviluppo di nuove ecc. Dal 2001 però viene sempre più usato un insieme di applicazioni meccanismi software di comunicazione detti web 4 Minor tempo per sviluppare nuove services, e basati sul World Wide Web. La SOA quindi è applicazioni 5 Minor tempo per mantenere le una strategia generale per lo sviluppo di tutte le applicazioni esistenti applicazioni software di un azienda con la metodologia service-oriented. I web services invece sono un metodo di collegamento, cioè un insieme di meccanismi standard di comunicazione basati sul www. Come faccio a capire se per la mia azienda è utile una strategia fondata sulla SOA? La SOA va ben al di là del solo sviluppo software. Richiede una visione unificata a livello aziendale dell architettura IT e del metodo di sviluppo, uno staff centrale di project manager, architetti e programmatori, e un repository centrale per i servizi, che devono essere ben documentati. Ma soprattutto la necessità per l IT di capire nel dettaglio e riprodurre i processi di business aziendali. Perciò la condivisione, e soprattutto la governance, sono fondamentali: occorre facilitare il riuso, evitare che lo stesso servizio sia sviluppato più volte per settori aziendali diversi, e fissare dei livelli di performance. A tale scopo, molte aziende hanno creato un team SOA, che decide in concerto con le varie aree aziendali quali processi supportare con i servizi, e mette a punto i meccanismi di governance. Finora le migliori strategie SOA sono in aziende con alti budget IT e business basati sulle tecnologie, come le telecom e i fornitori di servizi finanziari. Non a tutti, però, conviene una strategia SOA. Le realtà piccole, o fortemente decentralizzate, o che hanno già avviato serie strategie di integrazione applicativa o hanno puntato tutto su una grande suite software integrata, devono soppesare seriamente vantaggi e svantaggi. Il problema principale è che una strategia SOA non si può portare avanti per piccoli passi: lo sviluppo di un singolo servizio dev essere sempre coerente con il piano architetturale generale, che a sua volta deve tener conto della strategia di business aziendale. Quali sono i vantaggi di una SOA? Una SOA è prima di tutto uno strumento per ridurre complessità e ridondanze. E difficile che possa essere utile se la vostra azienda non è grande e/o complessa. Dev essere ben chiaro che il metodo di sviluppo service-oriented, in sé, non porta benefici. Secondo gli esperti, una buona soluzione service-oriented richiede più lavoro dell integrazione applicativa tradizionale, quindi per essere conveniente deve eliminare sforzi e costi da qualche altra parte, per esempio consolidando o eliminando insiemi di applicazioni ridondanti e poco integrate. Per avere il quadro completo dei benefici possibili di una SOA, comunque, bisogna considerare due livelli: i vantaggi tattici dello sviluppo orientato ai servizi e quelli complessivi di una strategia architetturale enterprise. Nel primo caso, i benefici sono di tre tipi: riuso del software, aumento della produttività, maggiore flessibilità dei sistemi IT. Se prendiamo una compagnia telefonica con quattro divisioni, ciascuna con il suo sistema di gestione ordini, questi sistemi avranno alcune funzioni simili, come il controllo crediti e la ricerca dei record dei clienti, ma spesso non condivisibili. Con lo sviluppo service-oriented si può creare una versione di controllo del credito condivisibile da tutti i sistemi. Il servizio può essere composto di codice totalmente nuovo, o preso da alcuni o tutti i sistemi: non conta il grado di complessità, conta solo che la prossima volta che un applicazione necessiterà della funzione credit check, basterà creare un link al servizio. I punti critici sono due. Uno è assicurare il riuso: occorrono appositi meccanismi di governance. L altro è dimensionare il servizio (granularità), che va accuratamente definito proprio per facilitare il riuso. E una delle maggiori difficoltà di una strategia SOA: allo stato attuale, dice Gartner, solo una quota tra il 10% e il 40% dei servizi viene realmente riutilizzata. Pagina 5 di 11

6 I cinque maggiori ostacoli all'adozione di una SOA 1 Definire che cosa è una SOA e imparare a progettarla 2 Passare alla nuova architettura e alle nuove metodologie lavorando nel business corrente 3 Riarchitettare l infrastruttura per supportare la SOA 4 Cambiare le metodologie di sviluppo per adeguarle alla SOA 5 Cambiare le strategie di governance per supportare la SOA Quanto agli aumenti di produttività, il riuso dei servizi significa maggiore velocità dei progetti di sviluppo, nonché risparmi sui costi d integrazione (almeno del 30%, secondo Gartner). Nel caso di Verizon e del suo servizio per il processo di gestione degli ordini di nuove linee telefoniche, con l integrazione punto-a-punto ci voleva un team di progetto centrale per scrivere l interfaccia generale, e poi dei team locali per ciascuno dei sistemi da integrare spiega il vice president Shadman Zafar -; con il servizio phone-line abbiamo bisogno di un solo team che deve fare solo un lavoro di testing. Anche se i servizi non vengono riutilizzati, possono ugualmente convenire. Un esempio è ProFlowers.com, che ha spezzato la gestione ordini in diversi servizi, su ciascuno dei quali si può intervenire senza toccare gli altri per gestire i picchi di domanda. Il sistema monolitico precedente richiedeva un enorme lavoro di riscrittura del codice, il nuovo invece ricolloca la capacità di storage ai vari servizi in funzione del bisogno ed è molto più flessibile: ha eliminato le indisponibilità di sistema dovute ai sovraccarichi. Passando ai benefici di una strategia architetturale a livello enterprise, uno è il miglior allineamento con il business. Le persone del business possono vedere come i loro processi e attività sono riprodotti dalle tecnologie in modo molto più immediato delle complesse applicazioni software tradizionali. Tra qualche anno, saranno forse in grado anche di comporre da soli i servizi a disposizione, senza ricorrere a tecnici. Un altro vantaggio è la possibilità di vendere meglio al business il concetto di architettura enterprise, che per le valenze molto tecniche e i ritorni difficili da definire è sempre stato piuttosto malvisto fuori dal dipartimento IT. Ora invece concetti come il riuso e la tecnologia cablata sui singoli processi lo rendono molto più vendibile. Sempre a patto di ricordare che una strategia SOA non conviene a tutti. Come bilanciare i tempi lunghi di pianificazione di una SOA con la necessità di portare velocemente valore al business? La pianificazione di un architettura richiede tempo. Lo sviluppo service-oriented invece si basa su concetti e standard tecnologici ben conosciuti (SOAP, HTTP, ecc.) e può essere molto più veloce. Le due cose però, dicono gli esperti, devono andare in parallelo. E importante mettere a punto piccoli servizi e nel contempo portare avanti il piano architetturale, la mappatura dei processi e lo sviluppo di servizi enterprise su tutta l impresa. Concentrarsi soltanto su una strategia pluriennale può far fallire tutto, perché occorre anche presentare dei risultati nel breve termine. Come scegliere i servizi che possono produrre il massimo valore per la mia azienda? Nel dubbio, iniziate dai processi che riguardano direttamente i clienti o le vendite, e/o da quelli che toccano direttamente un punto critico del vostro business. I processi rivolti all esterno sono quelli che apportano il maggior valore, e di solito cambiano molto spesso spiega Daniel Sholler, vice president di Gartner -: un 10% di miglioramento qui porta più valore di un progresso del 50% in aree back office. Non sempre SOA dà più valore di un buon pacchetto, ma se si deve comunque sviluppare, è meglio farlo in modalità service-oriented. Che impatto ha la SOA sulla funzione IT? Una SOA richiede e crea centralizzazione: il lavoro di sviluppo va attentamente controllato e guidato. Man mano che il portafoglio di servizi cresce, il processo di sviluppo inizia ad assomigliare a una catena di montaggio, e la produttività dei programmatori aumenta. Un approccio SOA poi richiede molte competenze e professionalità nuove, per cui occorre un forte investimento in formazione. Secondo una recente ricerca di CIO e Computerworld USA, solo il 25% delle aziende ritiene di disporre già delle competenze più adatte a implementare una SOA. Pagina 6 di 11

7 E' QUESTIONE DI MATURITÀ? Diversi approcci alla qualità dei processi possono applicarsi anche alle implementazioni SOA Dal punto di vista delle metodologie di sviluppo, affrontare le SOA e i web services significa gestire in maniera più rigida il processo di creazione del codice. Ragionando a livello di singoli servizi da veicolare in rete e non di applicazioni monolitiche ciò che conta sono le interfacce: ogni servizio mostra la sua, che deve essere consistente con quella degli altri. Bisogna essere disciplinati nella programmazione, restando aderenti alle specifiche di progetto e ai flussi di processo che si sono definiti all inizio dell implementazione. Non stupisce quindi che negli ultimi tempi, quando si tratta di architetture orientate ai servizi, si parli molto più che in passato dei modelli e dei processi che possono portare qualità, in senso lato, nell implementazione del software. Per le SOA stanno in particolare avendo una certa diffusione i maturity model che valutano la maturità dell azienda utente in quanto a implementazione e diffusione delle architetture orientate ai servizi. Sono modelli - proposti da fornitori di settore, analisti e consulenti - tutti buoni per capire dove si è rispetto a dove si vuole arrivare e per dare una certa disciplina allo staff IT. Con una premessa importante, però: i maturity model e le SOA possono certamente essere collegati, ma non bisogna mai dimenticare che modelli di questo genere nascono soprattutto per valutare i processi, mentre chi lavora sulle SOA è interessato soprattutto alla valutazione delle architetture software e delle loro implementazioni. La triade della qualità Tre approcci riconosciuti dal mercato alla qualità dei processi si dividono in questo momento l attenzione delle software house e dei dipartimenti IT: CMMI, CobiT e ITIL. Il Capability Maturity Model Integration (CMMI) parte dal presupposto che la qualità di un sistema, e quindi anche di un architettura software, dipende dalla qualità del processo usato per implementarlo. In questo senso è un modello di riferimento che permette a un impresa di collocare la qualità di un suo processo o dell impresa nella sua globalità in una ipotetica scala, dando in più le indicazioni necessarie per migliorare. Nella visione a stadi del CMMI si valuta il livello di maturità globale dell azienda o di una sua parte, in una scala a cinque step (Initial, Managed, Defined, Quantitatively Managed, Optimizing). Il modello si può applicare anche alla implementazione di una SOA? Sì, tanto che alcuni fornitori IT ne hanno creato un derivato specifico battezzato proprio SOA-MM (SOA Maturity Model). Ma non è, come dicevamo in precedenza, il solo. CMMI nella parte di sviluppo del software riprende concetti già collaudati dagli anni Settanta, quando i linguaggi e gli strumenti di programmazione erano complessi e prima di scrivere codice veniva fatta un analisi funzionale e tecnica molto accurata. E ben diverso l approccio di CobiT: la metodologia Control Objectives for Information and related Technology è incentrata sul controllo ex-post più che sull analisi preventiva delle implementazioni. CobiT, spiega Paolo Pasini, Vice Direttore Area Sistemi Informativi di SDA Bocconi, Spinge a ragionare in una logica di produzione dei servizi applicativi, a crearne un catalogo in una logica di mercato: chi li comprerà in azienda? Ciascuna delle sue aree diventa un area di misurazione di quello che faccio e genera i suoi indicatori chiave. Per chi guarda alla implementazione delle SOA il fulcro di CobiT è infatti rappresentato da un sottoinsieme della parte di Framework, la quale prevede una trentina obiettivi di controllo ad alto livello. Alcuni di essi sono collegabili all infrastruttura IT e a come essa rispecchi e supporti i processi aziendali. Dato che non tratta direttamente lo sviluppo software, non fornisce roadmap immediate per il miglioramento continuo dei processi informatici: il modello va digerito e declinato in base alle proprie peculiarità. Pagina 7 di 11

8 L'IT che cambia Con le società che si affidano sempre più a implementazioni SOA, la gestione di servizi applicativi di qualità si sta facendo disciplina critica per l'it. "E' una battaglia che è in corso, poiché si deve continuare a mantenere la connessione tra le esigenze di business e quello che realmente il software fa, e tali esigenze cambiano sempre", spiega Jason Bloomberg, senior analyst di ZapThink. Certamente l'idea che sta dietro una SOA è quella di costruire un'infrastruttura che abiliti composizioni di servizi software in genere poco connessi tra loro per, ad esempio, scambiarsi dati o coordinare funzioni di business. E le imprese stanno iniziando a comprendere il concetto che vi si cela dietro. Nel 2010 almeno il 65% delle grandi organizzazioni avranno infatti più del 35% dei propri portafogli applicativi basati su SOA, contro meno del 5% che c'erano nel 2005, prevede Gartner. Nel frattempo le aziende stanno scoprendo che il testing non è la sola area dell'it che potrebbe richiedere un cambiamento. Progettazione, implementazione e gestione delle applicazioni basate su servizi sono infatti qualcosa di molto differente rispetto al lavorare con le applicazioni tradizionali su più livelli. Per gestire tali cambiamenti, i professionisti stanno quindi estendendo i rispettivi set di strumenti con software che diano una visione più chiara dei dettagli, ad esempio a livello di transazioni, mentre chi si occupa di rete sta prendendo in considerazione l'utilizzo di appliance che possano occuparsi dei carichi elaborativi su XML (Extensible Markup Language). E sul mercato sono in tal senso diverse le proposte che offrono strumenti di testing e validazione SOA, gestione delle policy e loro applicazione, nonché apparati per la sicurezza e l'elaborazione XML. L Information Technology Infrastructure Library, o ITIL, è un approccio alla qualità dell IT che oggi gode di una popolarità simile a quella di CMMI, anche perché un po tutti i produttori di software per il system o il business service management stanno inserendo le best practice ITIL nelle proprie piattaforme. ITIL è in effetti proprio questo: un insieme di best practice e linee guida che coprono vari aspetti dell Information Technology in azienda e che, conseguentemente, possono essere adattate anche all implementazione delle SOA. Il framework ITIL è diviso in otto macrosezioni, ciascuna delle quali può avere un collegamento con i processi di implementazione di middleware. Cambiare pesa Le esperienze mostrano che tutti i modelli indicati comportano, in diversa misura, un cambiamento culturale nello staff IT, specie se questo non ha sperimentato in passato metodologie particolarmente attente alla qualità dei processi informatici. Proprio la resistenza al cambiamento è l ostacolo più frequente alla diffusione di questi approcci: è facile pensare che seguire certe prassi, per quanto positive, non è indispensabile quando si hanno persone qualificate o tecnologie ad alto livello. E altrettanto facile impuntarsi sul fatto che le prassi siano un limite alla creatività o alla velocità di risposta alle esigenze degli utenti esterni o interno. Per tutti questi motivi ci vuole una forte sponsorship dei vertici che attraversa il middle management e arriva sino ai singoli. Pagina 8 di 11

9 QUANDO I WEB SERVICES SPOSANO I SISTEMI LEGACY Le opportunità per riutilizzare dati e logica di business su host negli ambienti orientati ai servizi Con lo sviluppo delle service oriented architecture (SOA) basate su web services, l'integrazione sta diventando una componente strutturale delle nuove infrastrutture aziendali, ed è naturale che molti responsabili IT guardino in questa direzione per integrare i dati da host mainframe. I modi d'integrazione possono essere differenti anche se il più tipico, che non richiede interventi sulle applicazioni originali, prevede l'utilizzo dello 'screen scraping' (cattura di schermo). Un tool commerciale permette di esporre la logica delle applicazioni legacy come componente COM (Component Object Model), Java,.Net o web service. Componenti che possono essere usati in applicazioni web o sfruttati, per esempio, nell'ambito del CRM (Customer Relationship Management). Gli adattatori permettono agli utenti azioni 'punta e clicca' per collegare le funzioni legacy come componenti SOA. L'esposizione dei servizi legacy come web services consente inoltre il riuso delle funzioni, per esempio, per riproporre visure specifiche dei dati clienti a operatori diversi nell'ambito delle vendite o della contabilità. Altre componenti tecnologiche utilizzabili vengono impiegate da alcune realtà utenti per integrare dati CICS verso applicazioni client, come per esempio un foglio elettronico. I dati possono così essere utilizzati dagli operatori di un call center per avere informazioni in tempo reale sullo stato dei clienti, mentre il foglio elettronico consente di impostare calcoli su tasse e sconti. In passato queste elaborazioni avrebbero richiesto la scrittura di codice COBOL dedicato. Comprimere i tempi Usare i web services per accedere a dati e logica applicativa su sistemi legacy può drasticamente ridurre il tempo necessario per integrare i dati con le nuove applicazioni. Secondo gli osservatori i tool sul mercato sono in grado di ridurre da sei a dieci volte il tempo di un progetto d'integrazione a livello d'impresa. La necessità d'integrare a livello globale i processi di ammortamento ha portato alcune realtà a creare un'interfaccia web services al mainframe per il call center. Questo approccio non solo ha permesso l'integrazione, ma ha consentito di rendere più semplici i processi di migrazione. Il livello di astrazione consente infatti all'impresa portare avanti una strategia incrementale di aggiornamento. Secondo un analista di Forrester Research la capacità di gestire migrazioni mentre i sistemi continuano a erogare servizi è il motivo principale che rende i web services interessanti. "Le aziende sanno che possono essere necessari degli anni per rimpiazzare totalmente i sistemi esistenti. Con i web services è possibile isolare le componenti funzionali e quindi facilitare la sostituzione". Secondo Forrester ci sono però alcune applicazioni che non traggono vantaggio dall'esposizione come servizio: "Per esempio quelle che operano in tempo reale. Non è inoltre possibile gestire in questo modo dei numeri elevatissimi di transazioni al secondo". L'integrazione dei dati legacy attraverso le interfacce dei web services non elimina la necessità di dover inserire nel processo dei sistemi per la trasformazione dei dati. In ogni caso, comunque, i web services costituiscono un punto di arrivo per l'integrazione legacy. Pagina 9 di 11

10 GLOSSARIO ASP Application Service Provider. Fornitore che consente l'utilizzo di un'applicazione da remoto residente all'interno del suo data center e pagabile in diverse modalità: canone fisso, a tempo, pay per use. CUSTOM SOFTWARE Con tale denominazione si intendono quelle applicazioni che vengono sviluppate o modificate ad hoc per le esigenze di un'impresa ENTERPRISE RESOURCE PLANNING Un insieme di moduli software, completo di funzionalità specifiche, che consente all'azienda di integrare in tempo reale i dati e di gestire funzioni e processi operativi LEGACY Quei sistemi informativi (hardware, applicazioni) che vengono utilizzati da diverso tempo in un'impresa senza essere aggiornati o sostituiti, svolgendo ancora diverse funzioni importanti pur mancando in certi casi di compatibilità e integrazione con i sistemi più moderni SERVICE ORIENTED ARCHITECTURE Approccio software che permette l'utilizzo di componenti applicativi riutilizzabili, componibili e integrabili, programmati anche per svolgere solo una particolare funzionalità. Tra questi ci sono anche i cosiddetti web services. Pagina 10 di 11

11 . Documento reperibile, assieme ad altre monografie, nella sezione Dossier del sito Documento pubblicato su licenza Periodici Italia Pagina 11 di 11