In questa puntata del Caffè Sospeso, Gian Franco Stucchi propone alcune considerazioni sulle applicazioni di prossima generazione che permetteranno la coesistenza di best practice consolidate con processi di management ancora in divenire.
Lo sviluppo applicativo, un tempo focalizzato sulla realizzazione di nuove funzionalità operative destinate agli utenti finali, oggi tende alla realizzazione di sistemi di business integrati, composti da una molteplicità di funzioni che, in gran parte, sono ancora realizzate da uno o più moduli software, più o meno “best-of-breed” ma in genere piuttosto datati. Parallelamente, nel settore dei servizi professionali di Information and Communication Technology (ICT) si assiste alla comparsa di una nuova generazione di sviluppatori, spesso geniali, formati nelle scuole e nelle università, i quali, armati di metodi, tecniche e tool di tipo collaborativo, tentano di aprire nuove strade alla soluzione di un problema di origine antica: l’integrazione delle applicazioni, appunto.
Chiunque abbia praticato per qualche tempo l’affascinante ma turbolento mondo dello sviluppo del software riconosce che una preparazione teorica di base, unita a una forma mentis, nativa o inculcata, orientata alla collaborazione, è di fondamentale importanza (quasi un prerequisito) per recepire ed esprimere nei programmi le dinamiche che hanno origine nell’attuale contesto socio-economico e agitano in modo turbolento le modalità con cui vengono condotte le relazioni e i processi di business. Ne discende che le discipline afferenti, inerenti o consequenziali allo sviluppo applicativo – la realizzazione di software ad hoc, l’implementazione di suite ERP di prima generazione, estese o postmoderne, l’attualizzazione dei sistemi legacy (i retaggi o lasciti del passato), e così via – stanno vivendo un periodo di crescente importanza nelle costruzione e nella rappresentazione dei moderni modelli e delle pratiche di gestione aziendale. Talvolta la loro valenza è tanto rilevante che diventano strategiche per l’impresa che li adotta o, addirittura, assurgono esse stesse ad area di business. E’ questo il caso tipico delle società di consulenza, un fenomeno esploso nell’ultimo ventennio, poi attenuatosi a causa dei postumi di alcuni clamorosi flop verificatisi nel corso delle implementazioni di alcune suite ERP.
Governare l’evoluzione dello sviluppo applicativo non è – e men che meno sarà – un processo facile e routinario. La prossima generazione di applicazioni “new age” richiederà capacità professionali in grado di combinare tra loro, in modo sinergico, risorse di varia natura, metodi, architetture e tecnologie secondo nuove modalità che produrranno una serie di soluzioni che dovranno coesistere sia con la vasta gamma di best practice ormai consolidate, sia con filosofie di management e processi ancora in divenire. La sfida principale per le imprese sarà di gestire con successo la transizione da “Old” a “New”, dalla Società Industriale alla Società della Conoscenza, un cammino che dovrà aver luogo senza che nelle organizzazioni dedite allo sviluppo applicativo (imprese, enti, poli, centri di ricerca, etc.) vengano meno le esigenze imposte dai principi del time-to-market, pur facendo fronte alle pressioni dell’evoluzione del settore ICT.
Questa poi sarà trainata dalla domanda delle aziende e investirà pesantemente nella nuova generazione degli sviluppatori. La metamorfosi dello sviluppo applicativo continuerà senza sosta – magari tra alti e bassi, tra migrazioni trans-nazionali o trans-continentali – e lascerà alle aziende che non saranno in grado di adattarsi in maniera adeguata alla turbolenza ambientale e socio-tecnica ben poche alternative, anzi solo una: l’outsourcing, con tutte le conseguenze del caso.
Diverse sono le strategie d’azione che sono state proposte nell’ampia letteratura e nella casistica disponibile sullo sviluppo dei sistemi d’impresa. Si riportano nel seguito alcuni consigli, desunti dalle analisi condotte da alcune società di ricerca, manifestamente ispirate dal “sano buon senso”.:
- Pianificare l’evoluzione (che avverrà comunque)
- Mantenere gli aspetti più solidi del processo di sviluppo applicativo, adottando le best practice per supportare il trasferimento tecnologico dai “legacy programmer” agli sviluppatori di nuova generazione
- Concentrarsi sul capitale umano, supportando contemporaneamente gli obiettivi di business
- Cercare nuovi metodi (robusti e sperimentati) per le integrare le funzioni innovative con quelle di back-office di tipo legacy
- Utilizzare nuovi metodi di progettazione che includano la collaborazione tra domini di conoscenza diversi al fine di creare catene del valore eterogenee
- Adottare discipline e tecniche di modellizzazione dei processi di business per identificare quelli business-critical
- Classificare le applicazioni in base all’impatto che producono sia a livello locale, di processo, sia globale, d’impresa
- Sviluppare una strategia di interoperabilità basata sulle architetture componentizzate orientate ai servizi (SOA) e sul supporto di più modelli di programmazione applicativa e del middleware
- Valutare in che modo i sistemi di storage svolgeranno un ruolo significativo nelle strategie di e-business (i big data e la business analytics incombono).
- Puntare su componenti associabili tra loro in maniera molto libera e su modelli architetturali diffusi (standard de facto) o in rapida diffusione (cloud/mobile computing)
- Pensare sempre in maniera strategica, anche quando si sceglie una soluzione per la gestione del software legacy
- Creare un piano di addestramento per ogni generazione di sviluppatori (e rispettarlo … compatibilmente con le esigenze di budget).
Il prezzo che i team di sviluppo applicativo dovranno pagare per integrare nuove linee di business sarà certamente molto alto, anche in termini di stress personale o di gruppo. In effetti, i ritmi di lavoro stanno diventando sempre più intensi, a tutto svantaggio della qualità. Ovviamente, di norma il management è poco sensibile a queste argomentazioni, quindi gli sviluppatori dovranno inventarsi un percorso personale per trasformarsi in integratori esperti, sviluppando una profonda sensibilità per le urgenze e un’immediata reattività alle situazioni stressanti.
Il processo di evoluzione dello sviluppo applicativo, per trasformarsi in integrazione dei processi, deve iniziare immediatamente – appena presa coscienza della sua necessità – e richiederà alle generazioni future di individuare le competenze necessarie per dar luogo a tale transizione. Pertanto, ogni impresa deve definire un obiettivo minimo in termini di competenze professionali da acquisire (internamente o esternamente) ed evolvere, in termini di risorse umane, verso questo livello di competenza generalizzata, senza trascurare le problematiche che tali cambiamenti origineranno a livello organizzativo.
Nel corso dei primordi dell’era dell’elaborazione dei dati (anni Sessanta e Settanta del secolo scorso), l’attenzione progettuale dei team di programmazione era rivolta all’accesso ai dati. A questo primo passo ha fatto seguito un periodo nel quale il focus era costituito dal tentativo di migliorare la connettività tra i sistemi eterogenei tramite Remote Procedure Call (RPC), Application Programming Interface (API) e Reti con Protocollo Point-to-Point (PPP).
Più recentemente, l’attenzione è stata rivolta all’integrazione inter/intra-aziendale, quindi i settori nei quali si è concentrata l’innovazione sono stati i servizi erogati dal middleware – cioè il recapito dei messaggi, gli adattatori delle applicazioni ai vari ambienti, la trasformazione dei dati e l’elaborazione rule-based – soluzioni che con l’andare del tempo si sono rivelate sempre più inadeguate in termini di valore, tempismo e flussi operativi.
Gli analisti prevedono che, nel corso dei prossimi anni, si verificherà un aumento dell’attenzione rivolta al workflow “trainato” dai processi di business [Per un approfondimento si rimanda il lettore al Caffè Sospeso “Workflow, una panoramica funzionale”]. Ciò sarà reso possibile dall’affermazione dei sistemi per la modellizzazione dei gruppi di lavoro (groupware), la gestione del workflow e l’integrazione dei servizi via Web e XML.
Altre evoluzioni, facilmente prevedibili, sono le seguenti:
- Elaborazione globale. I progetti di elaborazione globale (cioè ultra-estesa) utilizzeranno molte funzionalità di Internet al fine d’offrire una visione di tipo “inside-out” del sistema-impresa, realizzata grazie ad applicazioni focalizzate sull’ambiente esterno anziché orientate verso l’interno dell’impresa. Gli aspetti chiave dell’elaborazione globale emergeranno dalle transazioni multi-proprietario e multi-operatore (cloud computing). Le applicazioni di portata globale dipenderanno sempre più da transazioni svolte in ambienti applicativi diversi e in imprese diverse.
- Le transazioni OLTP (On Line Transaction Processing) rimarranno un elemento fondamentale delle applicazioni di livello globale. Si affermerà il concetto di interazione, che dominerà gli stili delle applicazioni. Le interazioni sono elenchi di attività, di accessi a informazioni e ad altre transazioni OLTP volte a soddisfare le esigenze degli utenti. Il flusso processuale di un’interazione incorporerà contenuti – sia non strutturati che strutturati – con la logica di business necessaria per produrre le risorse e i servizi richiesti.
- Esperienze utente personalizzate. Le interfacce utente personalizzate enfatizzeranno l’unicità di una certa user experience derivata da una o più interazioni tra un utente con un sistema di livello globale (come accade nel caso del cloud computing).
- E-service onnipresenti. Gli e-service costituiranno la futura generazione dei servizi di fornitura delle informazioni all’utente finale tramite periferiche client indipendenti dalla posizione (mobility computing). I servizi Web saranno implementati tramite Internet a livello di trasporto e mediante un protocollo o linguaggio standard (per esempio XML su HTTP). Trascinato dalla crescita delle implementazioni Business-to-Business (B2B), il modello di business promosso dall’e-service catturerà probabilmente investimenti molto significativi sia dai vendor di middleware e di strumenti di sviluppo, sia dalle imprese. I servizi Web sono essenzialmente dei componenti software collegati tra loro in maniera molto “lasca”, libera, e vengono resi disponibili tramite tecnologie Internet.
Mentre queste infrastrutture si stanno realizzando, le aziende prendono in costante considerazione anche un percorso evolutivo dell’informatica d’impresa che prevede l’utilizzo di risorse legacy come elementi nel “nuovo ordine dei servizi” sfruttando il wrapping via XML delle interfacce grafiche, delle transazioni, dei programmi, dei componenti legacy e dei dati. Normalmente queste risorse legacy non dispongono di tutti gli attributi di un’applicazione di livello globale, tuttavia sono in grado di funzionare egregiamente nel contesto attuale (e lo saranno ancora per diversi anni).
Si vengono così a creare le cosiddette “compond application” che presentano alcune particolarità, come indicato nel white paper “Ensuring Operational Integrity of Web Services and Services-Oriented-Architecture (SOA) Applications”. Infatti, come riportato in questa pubblicazione:
<<There are significant differences between applications implemented as Web Services (or to SOA) and previous more monolithic (legacy) applications: these new applications are much more likely to be compound applications – there are, in fact, a number of legacy applications combined and integrated via SOA into a Web Service; compound applications are much more complex than even the sum of their parts, since a single transaction now has to flow through multiple applications (and their supporting infrastructure)>>.
Le applicazioni composte sono una potente modalità di rappresentazione della realtà aziendale perché sono in grado di realizzare la combinazione di implementazioni legacy dei processi di business con nuove implementazioni o nuovi processi. Esse possono essere considerate una risposta – conforme alle indicazioni degli analisti – alla domanda di “latenza zero” per l’e-business, resa possibile dall’accesso indifferenziato alle informazioni da parte di clienti, fornitori e partner aziendali. Essenzialmente, in un’applicazione composta, due o più applicazioni progettate indipendentemente vengono “incollate” tramite una nuova logica per dar vita a un’applicazione virtuale. Le applicazioni composte tentano di sfruttare le implementazioni correnti della funzione di business, anziché ri-sviluppare da zero delle nuove implementazioni di un processo, in fondo “dèjà vu”. Ciò che può essere sfruttato è la logica di business, tuttavia, di norma, si rende necessario ristrutturare la logica di interfaccia.
L’esigenza di rispettare i tempi di progetto – la spada di Damocle alla quale sono soggette le organizzazioni dedite allo sviluppo applicativo – unita alla crescente disponibilità di software preconfezionato, indicano che il problema è (e sarà) l’assemblaggio o l’integrazione delle applicazioni. L’assemblaggio implica l’assunzione di una decisione importante, spesso vitale, in merito al meccanismo di comunicazione. Sviluppare o assemblare applicazioni distribuite, e successivamente gestirle, richiede disciplina, coerenza e ripetibilità. Uno dei fattori critici di successo è il livello di accessibilità delle applicazioni da assemblare, che, a loro volta, sono una funzione dell’infrastruttura tecnica disponibile, ovvero delle reti, del middleware, dei sistemi di gestione di database, dei sistemi operativi e dell’architettura dell’applicazione legacy.
Lo sfruttamento dei sistemi legacy per realizzare applicazioni nuove o composte può avvenire a vari livelli, come elencato nel seguito:
- gli screen-scraper, gli strumenti host-to-Web o gli strumenti di estensione dei dati utilizzano il livello di presentazione o il livello dei dati come interfaccia verso i sistemi legacy
- gli strumenti di estensione dei dati offrono la possibilità di accedere alle strutture informative legacy direttamente dalle nuove applicazioni
- per eseguire il wrapping del codice legacy sono disponibili strumenti di comprensione della conoscenza della logica dei sistemi e dei programmi, di suddivisione del codice, di estrazione e ristrutturazione delle regole di business.
Quando si realizzano nuove infrastrutture di e-business è di fondamentale importanza poter dedicare molta cura all’esame dell’insieme delle architetture presenti sia nel proprio portfolio applicativo che nel “portafoglio innovativo” aziendale onde evitare di ingessare l’azienda a causa della presenza di tecnologie poco flessibili, che possono provocare ritardi nel time-to-market.
L’utilizzo di infrastrutture monolitiche e immutabili, tipiche di alcuni sistemi legacy mal progettati e peggio realizzati, sta rapidamente scomparendo, dato che gli attuali campioni di questa specie non sono affatto flessibili. Essi congelano le regole di business oppure richiedono uno sforzo eccessivo per cambiare i parametri incorporati, hanno un’applicabilità limitata e hanno ormai raggiunto l’ultimo stadio della loro maturità. Le strutture basate sui componenti (oggetti, web-services, etc.) costituiscono invece un insieme di architetture e tecnologie in rapida evoluzione.
In futuro, gli scenari di business e i rapidi mutamenti da questi introdotti costituiranno il modello predominante. Il processo di re-engineering dei componenti da sistemi legacy dovrebbe essere di tipo evolutivo, pertanto le aziende dovrebbero iniziare a modellare e a implementare le attività business-critical con componenti di alto livello, perfezionandoli gradualmente nel tempo tramite un processo istituzionalizzato e appositi strumenti di transizione.
Come requisito minimo, gli analisti consigliano di isolare il livello di presentazione, ovvero di riconoscere quali parti compongono realmente un livello di interfaccia progettata per la presentazione. Quando i destinatari di tali informazioni aumenteranno, non essendo più limitati a utenti interni, ma comprendendo anche elementi esterni – che utilizzano tecnologie di presentazione diverse, per esempio il Web, le tecnologie wireless e così via, o interfacce di programmazione diverse, per esempio i partner aziendali o i fornitori – la componentizzazione faciliterà notevolmente l’integrazione delle applicazioni.
Per passare dall’estensione dei sistemi legacy alla loro riutilizzazione sono disponibili quattro approcci di base, che possono essere suddivisi a loro volta in due categorie: approcci invasivi e approcci non invasivi.
Gli approcci non invasivi mantengono immutati il codice dei processi di base, i dati, le transazioni e le interfacce utente e solitamente “interpretano” il comportamento di una o più di queste fonti legacy per rendere disponibili ulteriori funzioni (integrazione apparente o wrapping). La maggior parte delle aziende utilizza attualmente approcci non invasivi, a meno che non si impieghino tecnologie molto datate, che probabilmente non sarà possibile conservare in futuro. Il mercato delle estensioni dell’interfaccia grafica utente, nota anche come GUI (dall’inglese Graphical User Interface ), si sta sviluppando sempre più velocemente ed è verosimile che imprese prediligeranno quei vendor che forniranno una serie di funzionalità atte a garantire la flessibilità e la facilità di sviluppo o di integrazione.
Due sono le classi di requisiti richiesti:
- Requisiti operativi: riguardano le capacità di gestire volumi elevati di dati (i big data), numerose opzioni server, multi-threading [NdA. Il threading consente di eseguire elaborazioni simultanee in un programma in modo da poter eseguire più di un’operazione alla volta], monitoraggio del traffico, oltre a funzionalità di registrazione, tracciamento visuale, workflow integrato e varie opzioni di emulazione.
- Requisiti di sviluppo: includono le normali funzionalità di sviluppo delle applicazioni, la cattura (semi)automatica delle schermate, la cattura di regole o di modelli, la manutenzione automatica, le interfacce aperte, lo sviluppo condiviso, il mapping delle schermate many-to-many, le interfacce grafiche dinamiche a valore aggiunto, etc.
La conoscenza dei sistemi legacy, di natura non invasiva, non è un approccio nuovo, né tanto meno è specifico per l’e-business. Molte aziende hanno infatti adottato i prodotti di questa specie durante la conversione all’anno 2000. La maggior parte dei vendor presenti in questo mercato è nel settore da molti anni e può fornire un supporto qualificato nell’identificazione delle regole di workflow implicite nella logica legacy o da questa implicate.
Gli approcci invasivi prevedono la modifica, più o meno massiccia, di una o più fonti legacy. Esempi di modifiche massicce sono le espansioni dei file e la ristrutturazione del codice. I prodotti di natura invasiva si applicano ugualmente bene alle iniziative di miglioramento dei processi software tradizionali, senza conversioni di sorta (molte aziende li stanno valutando proprio a questo scopo). La maggior parte dei prodotti viene offerta all’interno di un’offerta globale di adattamento all’e-business di un sistema informativo “attivo”, cioè fortemente orientato al marketing e alle vendite. Ovviamente questa è una buona ragione per potenziare l’attualizzazione di un sistema software, dato che le pressioni più forti alle quali sono sottoposte le software house sono correlate alle opportunità offerte delle tecnologie Web di aumentare l’accesso ai sistemi legacy da parte di clienti, partner commerciali e fornitori.
I sistemi legacy racchiudano un’immensa e preziosa conoscenza di business, ma estrarre tale “tesoro” rimane un’impresa molto difficile. Per di più, molte aziende non amano aprire all’esterno i propri sistemi legacy, preferendo approcci di estensione dei propri confini meno invasivi. Estendere a nuovi ambienti, in modo regolato e controllato, solo le applicazioni è la soluzione più diffusa, meno rischiosa e spesso meno invasiva. Consente inoltre di realizzare una soluzione immediata, di breve termine e poco rischiosa, per la problematica (tipica dell’e-business) di rendere le applicazioni aziendali, che sono tradizionalmente disponibili ai soli soggetti interni, accessibili senza traumi a nuovi soggetti esterni. Si sta lavorando sui metodi di conoscenza dei sistemi legacy per poter estrarre con successo la logica di business in essi intrappolata (e spesso dimenticata).
I rischi intrinseci della trasformazione completa di un’applicazione legacy in una equivalente, destinata a operare su una nuova piattaforma, costituisce un limite per quelle aziende che dispongono di piattaforme meno recenti, le cosiddette piattaforme “che scottano”, per le quali non esiste più alcuna speranza di crescita o di evoluzione futura.
Diverse aziende stanno cercando di trasformare i vecchi sistemi informativi anche per ragioni diverse da quelle legate alla longevità della piattaforma corrente. In alcuni casi tali aziende sono indotte alla migrazione dalla crescente scarsità di risorse professionali adeguate. Un esempio è dato dai programmatori COBOL, la cui carenza imporrà inevitabilmente lo sviluppo ex novo delle applicazioni scritte in questo linguaggio su mainframe in un altro linguaggio di tipo Object Oriented, come Java.
Il ruolo della tecnologia legacy nel futuro di un’organizzazione deve essere compreso e valutato già nelle prime fasi del ciclo di pianificazione di un nuovo sistema informativo o di una ristrutturazione del sistema esistente. Un’attenta pianificazione è di fondamentale importanza per evitare che una soluzione di breve periodo diventi un problema nel medio-lungo periodo.
Considerazione ovvia, … ma di difficile assimilazione da parte di alcuni CEO purtroppo corrotti da certa “informatica da rotocalco” che banalizza l’integrazione tra le applicazioni (un problema che affligge anche le mitiche app, che pure hanno il dono dell’ubiquità)
Di Gian Franco Stucchi
