Rigenerare in modo affidabile gli ambienti aziendali e IT esistenti in architetture moderne competitive e integrate non è banale. La complessità degli ambienti di business e IT si è accumulata quasi senza controllo per quarant’anni, rendendo i cambiamenti sempre più costosi. Questo perché:
- La complessità ambientale è spesso espressa in codice legacy. La carenza di competenze legacy sta facendo aumentare i costi di manutenzione e integrazione.
- Gli ambienti complessi esistenti devono essere riprogettati in fasi che abbiano un senso operativo per la loro funzione aziendale associata. Queste fasi spesso portano a sostituzioni all’ingrosso e rischiose dei sistemi, poiché l’ignoranza della complessità esistente fa sì che i potenziali cambiamenti incrementali siano troppo difficili da comprendere e progettare.
- I metodi di sviluppo accelerati hanno lasciato le imprese con sistemi legacy moderni. Le complesse applicazioni Java e .NET hanno molti degli stessi problemi delle vecchie applicazioni COBOL.
Come risultato, una proporzione crescente dello sforzo per sviluppare nuove capacità di business viene spesa per capire e integrarsi con il complesso sistema esistente e il panorama del business piuttosto che per fornire valore. È stato osservato che fino al 75% dello sforzo complessivo del progetto è ora speso per l’integrazione e la migrazione del software piuttosto che per nuove funzionalità.
L’industria IT nel suo complesso ha una scarsa percentuale di successo nella realizzazione di questi cambiamenti su larga scala per i suoi clienti. Il sondaggio CHAOS dello Standish Group ha tracciato un miglioramento generale nel successo dei progetti IT negli ultimi vent’anni, ma anche nel 2006 i grandi progetti IT sono falliti più spesso di quanto siano riusciti. L’ingegneria dei cambiamenti e in tali ambienti ha molti paralleli con le preoccupazioni dell’industria delle costruzioni nella riqualificazione di siti industriali o contaminati. Sono pieni di pericoli, complessità inaspettate e tendono ad essere rischiosi e costosi da riqualificare. La complessità accumulata degli ambienti IT li ha resi siti “Brownfield”.
Non è la complessità della nuova funzione o delle caratteristiche del nuovo sistema che sono la radice dei fallimenti dei grandi progetti – è la nostra comprensione e comunicazione del requisito generale (come identificato in The Mythical Man Month). Per avere successo, i requisiti devono includere una comprensione precisa e approfondita dei vincoli del business e dell’IT esistenti. Gli attuali strumenti e metodi “Greenfield” usano astrazioni precoci, informali e spesso imprecise che essenzialmente ignorano tale complessità. Le astrazioni precoci e poco informate sono di solito sbagliate e vengono spesso rilevate in ritardo nella costruzione, con conseguenti ritardi, costose rielaborazioni e persino sviluppi falliti. Un approccio orientato a Brownfield abbraccia la complessità esistente e viene usato per accelerare in modo affidabile il processo generale di ingegneria della soluzione, permettendo anche un cambiamento graduale e incrementale dove possibile.
Brownfield prende l’approccio standard OMG model/pattern-driven e lo capovolge. Piuttosto che prendere l’approccio convenzionale di iniziare con un modello concettuale e guidare fino ai modelli specifici della piattaforma e alla generazione di codice, Brownfield inizia raccogliendo il codice e altri artefatti esistenti e usa i modelli per astrarre formalmente verso l’alto verso il livello dell’architettura e del business.
Le tecniche standard di Greenfield sono poi usate in combinazione per definire il target di business preferito. Questa tecnica “meet in the middle” è familiare da altri metodi di sviluppo, ma l’uso esteso dell’astrazione formale e l’uso di modelli per la scoperta e la generazione è nuovo.
L’architettura concettuale sottostante di tutti gli strumenti Brownfield è conosciuta come VITA. VITA sta per Views, Inventory, Transformation e Artifacts. In un’architettura VITA, la definizione del problema dello spazio di destinazione può essere mantenuta come separato (anche se correlato) nativo “headfulls” di conoscenza conosciuto come Views. Il vantaggio principale di una Vista è che può essere basata praticamente su qualsiasi strumento formale. Brownfield non impone un singolo strumento o linguaggio su uno spazio problematico – un principio fondamentale è che le “headfulls” continuano ad essere mantenute nelle loro forme e strumenti nativi.
Le Viste native sono poi riunite e collegate in un singolo Inventario. L’inventario è poi usato con una serie di capacità di trasformazione per produrre gli artefatti di cui la soluzione ha bisogno.
Le viste possono attualmente essere importate da un’ampia varietà di fonti tra cui UML, fonti XML, DDL, fogli di calcolo, ecc. Lo strumento Analysis and Renovation Catalyst di IBM ha portato questa capacità ancora più avanti attraverso l’uso di grammatiche formali e alberi sintattici astratti per permettere a quasi tutti i programmi di essere analizzati e tokenizzati in una View per l’inclusione nell’inventario.
La rapida natura ciclica del ciclo di scoperta, reingegnerizzazione, generazione e test usato in questo approccio significa che le soluzioni possono essere raffinate iterativamente in termini di definizioni logiche e fisiche mentre si conoscono più vincoli e si raffina l’architettura della soluzione.
Lo sviluppo iterativo Brownfield può permettere il perfezionamento graduale delle architetture logiche e fisiche e il test incrementale per l’intero approccio, con conseguente accelerazione dello sviluppo, migliore qualità della soluzione e rimozione dei difetti più economica. Brownfield può anche essere usato per generare la documentazione della soluzione, assicurando che sia sempre aggiornata e coerente attraverso diversi punti di vista.
L’Inventario che viene creato attraverso Brownfield elaborato può essere altamente complesso, essendo una rete semantica multidimensionale interconnessa. Il livello di conoscenza nell’Inventario può essere molto fine, altamente dettagliato e interconnesso. Queste cose sono difficili da capire e possono fornire barriere alla comunicazione, tuttavia. Brownfield risolve questo problema astraendo i concetti tramite un’ipotesi artigianale, utilizzando modelli noti nei suoi Inventari per estrarre e dedurre relazioni di livello superiore.
Le astrazioni formali permettono di tradurre la complessità dell’Inventario in rappresentazioni più semplici, ma intrinsecamente accurate, per un consumo più facile da parte di coloro che devono comprendere lo spazio del problema. Questi modelli astratti dell’Inventario possono essere usati per rendere automaticamente rappresentazioni dell’architettura a più livelli in strumenti come Second Life.
Tali visualizzazioni permettono di condividere e sperimentare informazioni complesse da più persone in tutto il mondo in tempo reale. Questo migliora sia la comprensione che il senso di un’unica squadra.
Si tratta di un’esperienza che può essere condivisa e sperimentata da più persone in tutto il mondo.