---

Settembre andiamo, è tempo di migrare (e integrare) le applicazioni

Con la ripresa dell'attività è giunto il momento di progettare nuove soluzioni applicative e valutare le esigenze aziendali più pressanti allo scopo di incrementare la produttività aziendale, un tema che sarà sempre più importante nelle aziende italiane. Il più delle volte emerge la necessità di sostituire le vecchie applicazioni migrandole a nuove ma, più frequentemente, ci si accorge che la soluzione meno costosa è integrarle strettamente con altre (interne o esterne) in modo da usufruire di maggiore velocità di caricamento, evitare ridondanze nei dati o sfasamenti temporali negli aggiornamenti dei database.
Quando viene svolta questa attività di "ristrutturazione" esiste sempre un coro di lamentazioni che accompagna l'abbandono del vecchio ambiente per intraprendere un cammino verso uno diverso che, seppure magnificato o razionalmente compreso come migliorativo, non è certamente familiare come quello che si utilizza normalmente. L'inserimento di nuovi moduli e l'implementazione di un nuovo sistema software (di base o applicativo), il trasferimento delle applicazioni preesistenti sulla nuova piattaforma e l'avvio in produzione di un sistema informatico migrato non si sottrae a questa logica.
Il problema della migrazione/integrazione verso un nuovo sistema operativo può essere associato a tre tipi di intervento sulle applicazioni: la ristrutturazione, la conversione e la riprogettazione. La ristrutturazione coinvolge modifiche di alcune caratteristiche operative native del software origine (tipicamente dipendenti dalla release del sistema operativo di partenza) ma che non corrispondono necessariamente a nuove funzionalità disponibili nel nuovo ambiente. La conversione riguarda la modifica (o la riscrittura) di alcune parti del software migrato, accuratamente selezionate, per rimpiazzare determinate funzionalità dell'ambiente origine con funzioni native del nuovo sistema operativo. La riprogettazione indica l'attività di completo rifacimento del software di partenza per consentire l'utilizzo di tutte le potenzialità del nuovo ambiente che può comprendere parti preesistenti oppure essere totalmente nuovo.
Di norma un nuovo ambiente software presenta un'architettura diversa, tanto che potrebbe essere utile almeno un processo di ristrutturazione dato che modifiche strutturali relativamente semplici potrebbero determinare un incremento delle prestazioni. La conversione può essere la soluzione più indicata quando le applicazioni necessitano di accedere a funzionalità assenti nell'ambiente origine o se le aspettative sono di significativi miglioramenti in termini di produttività o di prestazioni. La riprogettazione può produrre benefici significativi in diverse aree e dovrebbe essere presa in considerazione per applicazioni altamente utilizzate, che richiedono tempi di risposta ridotti o portano significativi benefici per l'azienda (applicazioni mission critical).
Normalmente risulta possibile riutilizzare alcuni segmenti di codice preesistente e, talvolta, una riprogettazione "light" potrebbe essere più economica, in termini di risorse, della conversione soprattutto se supportata da adeguati tool software. Alcuni benefici ottenibili con una accurata riprogettazione possono essere: tempi di risposta ridotti; logica di programmazione semplificata grazie all'uso delle nuove funzionalità; riduzione della necessità di mantenimento di competenze nell'ambiente origine con accrescimento dell'esperienza e della cultura del personale; strumenti migliori e più veloci di sicurezza, backup, di restart e di logging.
Per contro, una riprogettazione "pesante" implica una tale mole di attività che si giustifica solo per applicazioni stabili, soggette a poche modifiche adeguatamente pianificate e notevolmente significative o strategiche per l'impresa.
La decisione di migliorare l'esistente - ristrutturando, convertendo o riprogettando le applicazioni - deve sempre essere inquadrata in una prospettiva evolutiva a medio o lungo termine. Come regola generale, si può affermare che maggiore è il grado di completezza della conversione o della riprogettazione, maggiori saranno i benefici ottenibili.
Sebbene sia prevedibile che l'insieme dei passi da eseguire in un processo di questo tipo sia piuttosto rilevante, molti accorgimenti sono inevitabili per ovviare a situazioni che potrebbero portare ad anomalie successive.
Prima di passare alla versione definitiva, è sempre consigliabile sperimentare un'applicazione pilota, dimensionalmente circoscritta e non determinante per i processi vitali di un'impresa, sì da poter definire in dettaglio i passi salienti del processo. Questa sperimentazione potrebbe anche costituire un test per la corretta stima dei costi finali di conversione e bilanciare questi con i benefici che potrebbero essere ottenuti.
Il passaggio da un ambiente d'origine ad uno di destinazione è un'attività molto frequente per gli specialisti informatici, sia che riguardi semplici conversioni di un file, da un formato ad un altro, sia che coinvolga importanti trasferimenti di software applicativi da un'architettura ad un'altra. Infatti, a causa dell'evoluzione tecnologica, l'unica certezza è che, in un futuro più o meno lontano, l'incubo di un passaggio diventerà una realtà da affrontare razionalmente ed efficientemente.
Le modalità organizzative con cui viene gestito il progetto costituiscono senza dubbio uno dei fattori critici di successo. Per l'utenza la necessità di eseguire delle attività addizionali, il fatto di non poter disporre immediatamente di livelli di servizio comparabili con la situazione precedente o, più semplicemente, l'imposizione d'abbandonare un ambiente noto sono delle anomalie percepite come elementi di disturbo, alle quali reagire spesso con un atteggiamento ostile e negativo.
E' molto importante, in questi casi, coinvolgere direttamente l'utenza stessa spiegando le finalità del progetto, esponendo in modo realistico sia gli eventuali svantaggi nel breve termine, sia sottolineando i vantaggi attesi nel medio e lungo termine. Si deve cercare, in ultima analisi, di "socializzare" le responsabilità del cambiamento in atto, enfatizzando gli aspetti organizzativi e relazionali necessari per il successo e trascurando gli aspetti riconducibili alle sole competenze "tecniche".
Le riviste della Duke Italia hanno organizzato su questo tema importante un incontro della durata di una giornata il prossimo 18 settembre intitolato: "Enterprise Application Integration 2003, Linguaggi, tool e soluzioni best-of-breed per l'integrazione dei processi". Il convegno è gratuito (è richiesta una iscrizione preventiva) e si terrà a Milano presso il Centro Congressi dell'Hotel Executive (zona Stazione Centrale).
http://www.eventiduke.it/pagine/giugno_milano/enterprise.shtml
http://techrepublic.com.com/5100-6265-5030577.html
http://whitepapers.informationweek.com/data/rlist?t=1052162723_38911498
http://www.sei.cmu.edu/publications/documents/01.reports/01tn012.html

 

Per chiarimenti sui termini usati

---

Il mondo del software applicativo: abisso fra visioni future e dura realtà quotidiana

La visione più accreditata dei maggiori esperti internazionali circa il futuro del software applicativo è presto detta: tutto indica che nel breve termine avremo in circolazione un software completamente diverso dal tradizionale, sia per effetto della creazione di nuove soluzioni avanzate nel mondo del wireless e del mobile computing, sia per la necessaria sostituzione del software più fatiscente con nuove soluzioni di tipo web-based.
Grazie alle nuove architetture basate sui web service, i prodotti disponibili saranno sempre più ricchi di funzionalità, performanti, interdipendenti, integrati o integrabili fra aziende diverse; spesso saranno costruiti assemblando componenti acquistabili via Internet con carta di credito ed opereranno in un ambiente che renderà l'utente "più intelligente" e informato.
I vecchi moduli di programma con dimensioni "monstre", le mega-suite applicative, i sistemi di archiviazioni e database tracimanti di ridondanze (che impongono continue espansioni delle piattaforme hardware) si estingueranno al più presto come i dinosauri, sostituiti da prodotti flessibili e plastici, in grado d'adattarsi ad ogni esigenza o modifica.
L'attuale realtà è molto diversa, purtroppo. Nonostante l'espansione e la pervasività promessa dai nuovi prodotti di sviluppo, la spada di Damocle del passato che grava sugli sviluppatori software rimane sempre la stessa, anzi cresce in termini di peso (impatto) e di dimensioni (portata). Realizzare e far funzionare i sistemi informatici avanzati (che richiedono studio e investimenti), riuscendo a rispettare i vincoli concorrenziali imposti dal "time to market" e quelli economici (che impediscono adeguati test), entrambi imposti dal mercato appare ancora come una "mission impossible", riservata a pochi eletti.
Alcuni anni or sono si sviluppavano, per lo più, dei sistemi software partendo da zero ed in maniera assolutamente indipendente dagli altri. Il problema della valutazione e quello, più generale, del controllo di gestione dei sistemi software emerse immediatamente ma la scienza, la tecnologia e l'industria del software, nel loro insieme, non riuscirono mai a risolverlo completamente.
Nel 1998, cioè prima del boom di Internet e della applicazioni Web, un rapporto dello Standish Group mostrava che circa tre quarti dei progetti di una certa dimensione "sforavano" sia i limiti di budget sia i termini di consegna previsti oppure terminavano con notevoli ridimensionamenti dei requisiti originali previsti.
Implementare del software per supportare i megatrend del momento (e-business, mobile computing, Web, CRM, ERP, Business Intelligence, etc.) significa sottoporre le aziende ad uno sforzo ben superiore a quello che era richiesto negli anni passati. Esiste il ragionevole dubbio che coloro che operano nel settore ICT per far fronte alle esigenze dovranno aumentare ulteriormente i propri frenetici orari e ritmi di produzione, e, quand'anche riuscissero a farlo, la qualità del risultato sarebbe inevitabilmente scarsa per effetto del sovraccarico.
Questa evoluzione del settore ICT potrebbe trovare ostacoli nella carenza di tecnici, un fenomeno da sempre evidente che sembra non trovare soluzione in una nazione troppo orientata agli studi umanistici. Nonostante la elevata disoccupazione giovanile, molti segnali (negativi) emergono dal mondo della formazione, dove autorevoli testimoni (Rettori di Università, Direttori di Dipartimenti tecnici o scientifici), sostenuti nelle loro argomentazioni da incontestabili "numeri" statistici, avvertono preoccupati che un numero sempre minore di studenti decide di specializzarsi in informatica o nelle specializzazioni professionali collaterali. I giovani, in sostanza, hanno paura degli alti e bassi del mondo produttivo e tendono a preferire le lauree in legge, psicologia, materie letterarie, ecc.
Dulcis in fundo, schiere di professional senior che potrebbero fare una preziosa opera di formazione sia agli utenti che alle giovani leve, nel recente periodo sono stati espulsi dal settore dell'Information Technology a causa dei drastici piani di riduzione del personale provocati dalla crisi di interi settori della nostra economia.
Curioso, dunque, il contesto nel quale si dovrebbero sviluppare i nuovi rivoluzionari megatrend: a fronte di una tendenza inarrestabile verso sistemi software sempre più sofisticati in termini qualitativi e quantitativi, gli specialisti senior sono in fase di espulsione dal mondo del lavoro a causa della contrazione degli investimenti aziendali e contemporaneamente non si preparano in numero sufficiente le nuove leve sostitutive.
http://www.mondodigitale.net/Rivista/03_numero_due/Camussone_p._3-14.pdf
http://www.sdmagazine.com/
http://www.sdtimes.com/
http://agilemanifesto.org/

Per chiarimenti sui termini usati

---

La filosofia XP ( …nel senso dell'Extreme Programming)

Fra i tentativi in atto per velocizzare lo sviluppo di software con criteri nuovi è rivelatore, già dal nome, il modello di sviluppo applicativo denominato Extreme Programming. Nel suo libro "Extreme Programming Explained" (editore Addison-Wesley), l'ideatore di questo modello di programmazione, Kent Beck, afferma che la ragione della scelta di tale nome deriva dal fatto che questo tipo di programmazione estremizza - ovvero porta a livelli estremi - i principi del buon senso comune. Si affermano, per esempio, delle "regole assiomatiche" quali le seguenti:
? Dato che la revisione del codice è una buona norma, è consigliabile rivedere in continuazione il codice (pair programming).
? Poiché il testing è un'ottima pratica, tutti dovranno testare continuamente i propri moduli (unit testing).
? Siccome la progettazione è un passo fondamentale, la si renderà parte del lavoro quotidiano (refactoring).
? Se la semplicità è essenziale, si dovranno realizzare sistemi con la struttura più semplice possibile in grado di supportare le funzionalità correnti (la cosa più semplice in grado di funzionare).
? Quando l'architettura è importante, tutti dovranno lavorare continuamente per perfezionare l'architettura (metafora).
? Poiché il testing di integrazione è necessario, si integrerà e si testerà più volte al giorno (continuous integration).
? Siccome le iterazioni brevi sono una buona pratica, esse si dovranno rendere sempre più brevi, (secondi, minuti e ore anziché settimane, mesi e anni).
L'Extreme Programming non è legato ad uno specifico insieme di prodotti, in quanto ciò sarebbe in contraddizione con la filosofia di base. L'approccio XP suggerisce strategie di sviluppo, regole e principi.
Per esempio, non dovrebbe esserci alcuna documentazione al di fuori del codice sorgente e il testing deve essere eseguito durante tutto il corso dell'intero progetto, a partire dal primo giorno. Inoltre il software sviluppato viene fornito al cliente-utente in modalità incrementale non appena è possibile e può evolvere alla luce dell'esperienza, con l'implementazione di modifiche in modalità controllata. Questo è chiaramente in linea con i tre principi di base dell'iterazione, dello sviluppo incrementale e dell'evoluzione del software considerati ormai da tempo gli elementi chiave di ogni realizzazione software di successo.
Si tratta quindi di un deciso cambiamento rispetto a molti degli approcci teorici precedenti, specialmente quelli basati sul ciclo "a cascata", che fanno l'errore di avviare il testing troppo tardi, con conseguenze disastrose.
Come gran parte delle attuali metodologie snelle, XP enfatizza il lavoro di squadra ovvero la comunicazione, la semplicità, il feedback e la collaborazione. Ma una cosa è affermare di seguire un'idea, quale può essere il collective ownership, un'altra è metterla in pratica. Il collective ownership, ovvero il possesso collettivo, significa che ciascuno può modificare qualsiasi parte del codice nel sistema in qualunque momento.
L'enfasi posta da XP sull'integrazione continua (continuous integration) è intesa a garanzia contro qualsiasi problema in tale ambito. Ma l'impatto culturale non è indifferente, dato che molti programmatori tendono a trattare il proprio codice in maniera piuttosto gelosa, anche per paura di essere criticati.
I principi della democrazia applicati al codice richiedono invece un certo grado di cameratismo e fiducia, ma non basta: dal punto di vista logistico richiedono un numero ridotto di programmatori.
Il risultato è che, per quanto l'XP presupponga normali livelli di competenza tecnica, l'approccio impone in realtà un cambiamento radicale di alcuni atteggiamenti mentali che presuppongono nuove competenze culturali.
Tra queste la più significativa è la capacità di "accogliere il cambiamento" (come recita il sottotitolo del libro di Beck) ed è proprio il cambiamento che caratterizza principalmente gli attuali progetti software. L'XP ha attirato l'attenzione sul significato delle "competenze sociali" nei progetti software e ha fornito importanti euristiche per incoraggiare tali competenze. Un aspetto fondamentale è trovare gli individui giusti per guidare progetti XP in modo che i partecipanti possano acquisire le giuste competenze sociali e venga a crearsi l'etica giusta.
Esiste tuttavia un aspetto ancora più importante da considerare. Purtroppo le competenze tecniche e sociali non sono solitamente allo stesso livello all'interno di un team. A tale proposito è necessario rendersi conto che lo sviluppo software riguarda l'interazione umana almeno quanto la capacità di programmare in Java. Molte società hanno capito da tempo l'importanza di investire nelle competenze culturali per il software. Si tratta di una sfida da non prendere alla leggera, in particolare in un mondo di scadenze rigide in cui i membri del team spesso lavorano fisicamente distanti ed in modalità virtuale.
http://www.extremeprogramming.org/
http://www.cutter.com/consortium/consultants/allenp.html
http://ootips.org/xp.htm

Per chiarimenti sui termini usati