Cosa sono, come funzionano e a cosa servono i sistemi legacy
Nei diversi articoli presenti in questo sito web sui sistemi legacy, sono stati affrontati prevalentemente degli aspetti tecnici relativi al trattamento dei sistemi legacy, non toccando problemi di pianificazione delle attività e gli aspetti organizzativi. Comunque bisogna ribadire che l’ICT esiste per supportare i requisiti di business: senza questa relazione, l’ICT non risolve le reali necessità dell’organizzazione.
Il BPR vede il suo target in termini di business process desiderati. I “legacy” business process spesso non sono ben documentati o compresi poiché si sono evoluti durante un lungo arco temporale e sono istanziati in molte locazioni e da persone differenti. La sfida, dalla prospettiva del business, è di sostituirli con dei “target” business process. L’ICT apparentemente non entra in questo progetto di “trattamento del business” .
I legacy business process sono supportati a livello di sistema informativo da un insieme di sistemi legacy, mentre i target business process saranno supportati da un ambiente target (idealmente ad oggetti distribuiti). La sfida, a livello di sistema informativo, è ammodernare i vecchi sistemi; comunque il trattamento avviene in un contesto di business e per supportare requisiti di business. La pianificazione ed esecuzione del trattamento (con qualsiasi approccio) deve essere fatta nel più ampio contesto della pianificazione ed esecuzione del BPR.
C’è un corrispondente requisito dal livello del sistema informativo a quello dei business process: i sistemi legacy non vengono trattati “nottetempo”, e quindi la velocità del BPR deve essere consistente con quella fattibile in termini di trattamento dei vecchi sistemi. In ogni istante, l’ambiente informativo consiste di un sistema composito (soprattutto nel caso di migrazione graduale o di wrapping), e corrispondentemente i business process supportati saranno un mix di vecchi e già reengineered. Questa semplice osservazione indica forse il fattore più significativo nel determinare da quale porzione conviene partire (l’incremento nel caso della migrazione o le componenti da integrare per prime nel caso del wrapping).
Diversi approcci al problema dei sistemi legacy
I diversi approcci al problema dei sistemi legacy, presentati negli articoli precedentemente esposti, non sono in contrapposizione tra di loro e l’applicazione di uno non esclude automaticamente l’utilizzo anche parziale degli altri.
Inoltre può capitare che si cominci con uno e si passi nel tempo ad uno differente; ad esempio non è escluso che un’organizzazione, per soddisfare esigenze immediate, inizi ad esporre alcuni servizi sul Web attraverso semplici wrapper d’accesso od una migrazione delle interfacce utente, successivamente passi a sviluppare wrapper ad oggetti ed infine decida di migrare completamente l’implementazione del proprio sistema informativo, ormai nascosta dietro ad un modello ad oggetti stabile, dal mondo mainframe ad un’architettura differente. Oppure che un’organizzazione, il cui obiettivo originario era una migrazione, decida invece, dopo aver implementato un gateway – magari ad oggetti -, di accontentarsi, di questo incapsulamento del sistema dietro ad una nuova interfaccia, realizzando quindi alla fine un wrapping del proprio sistema.
Spesso i concetti di migrazione e di integrazione possono diventare interscambiabili, dato che è evidente la similitudine (non solo concettuale, ma anche tecnologica e della relativa offerta di mercato) tra un wrapper ed un gateway.
C’è da tener presente che nessun approccio è completo, nel senso che nessuno può essere applicato con successo a tutte le categorie di sistemi legacy. Ad esempio l’approccio dell’integrazione con il wrapping ha maggior senso nel contesto di un’architettura ad oggetti distribuiti, mentre altri approcci potrebbero essere più convenienti per sistemi isolati e non troppo estesi. Inoltre non ci sono ancora molti esempi sull’applicazione con successo del wrapping (anche la DOC in generale è alle prime esperienze concrete) e vanno ancora studiate metodologie e le classi di applicazioni per cui il wrapping è vantaggioso e quelle invece che richiedono approcci più tradizionali.
La scelta di un approccio, ovvero del giusto mix di aspetti di approcci differenti, non è affatto banale e solleva molti problemi che devono essere attentamente vagliati, non ultimo l’effettivo supporto del mercato. Il wrapping, anche per il modo integrato con cui aggredisce il sistema, sembra attualmente essere l’approccio più promettente e quello su cui la comunità (sia scientifica che commerciale) sembra concentrare i maggiori sforzi.
