Integrazione completa di un sistema informatico

Integrazione completa di un sistema informatico

L’avvento della DOC promette, oltre di cambiare radicalmente il modo con cui progettare i nuovi sistemi informativi, anche di cambiare l’approccio con cui fronteggiare il trattamento dei sistemi legacy.

Enterprise Architecture

Prima di passare a spiegare il concetto di integrazione completa di un sistema informatico è necessario soffermarsi sull’Enterprise Architecture (architettura d’impresa). L’enterprise Architecture costituisce un framework significativo all’interno  del quale i vari livelli dello sviluppo del sistema informativo dell’organizzazione vengono considerati:

  • Business Architecture: prende in considerazione la strategia di business dell’organizzazione, i suoi fini a lungo termine e gli obiettivi immediati, l’ambiente tecnologico e quello
  • Information Architecture: è una mappa delle necessità informative basate sulla business strategy (quest’ultima viene tradotta in una information system strategy); essenzialmente è come un “progetto dell’edificio”. Descrive il contenuto, il comportamento e l’interazione degli oggetti di business; modella le informazioni e le attività dell’organizzazione e fornisce l’astrazione nel dominio di business; definisce i blocchi costituenti per lo sviluppo applicativo ed un framework per i componenti informativi di business.
  • Data Architecture: serve a definire le necessità correnti e future per l’accumulo, l’uso, il rinnovo, il mantenimento ed il trasferimento dei dati inter ed intra i confini dell’organizzazione.
  • Application Architecture: definisce i servizi fondamentali richiesti per la costruzione di soluzioni nel dominio di business: questi servizi forniscono un’interfaccia astratta, business domain-oriented; i componenti dell’Information Architecture vengono modellati in termini dei ruoli fondamentali e delle regole di processamento sviluppati in questo livello.
  • Computer / Technical Architecture: riguarda l’hw/sw che costituiscono la base tecnologica per i livelli superiori (ad esempio a questo livello si considera un Sistema Legacy come un modo potenziale per implementare i livelli superiori): la scelte sono determinate anche dal mercato e dal budget, e le decisioni sul “make or buy” vengono fatte a questo livello, anche se guidate da aspetti degli altri.

Talvolta gli ultimi livelli vengono accomunati nella complessiva System Architecture.

Nuove enterprise architecture

Le nuove enterprise architecture non considerano più, come nel passato, tanti diversi sistemi informativi isolati (ognuno  afferente ad una diversa unità dell’organizzazione) che poi dovevano essere messi in comunicazione tra loro, ma tendono ad immaginare un unico grande Sistema Informativo Distribuito (utilizzato, localizzato ed anche gestito in modo non centralizzato): un unico grande organismo di cui gli equivalenti, vecchi o nuovi, dei sistemi legacy costituiscono i vari organi.

In questo contesto assume minore importanza l’idea di sostituire il sistema legacy, poiché anche se progettato con metodologie e tecniche moderne, il nuovo sistema tenderà a riprodurre quello vecchio e quindi a rimanere un “organo”.

La DOC è ora sufficientemente matura per supportare un approccio differente: sottoporre i sistemi legacy a trasformazioni black box, cioè non modificarli, ma attraverso tecnologie ad hoc, dette di contorno (mediatori), farne un object wrapping in modo che il sistema presenti un’interfaccia ad oggetti verso il “mondo distribuito” in cui vive. Questo è valido in quanto l’organizzazione moderna deve essere sempre pronta al cambiamento, i tempi di migrazione/sviluppo dei sistemi non sono  compatibili  con queste esigenze “frenetiche” (mentre il wrapping, una volta costruita l’infrastruttura ad oggetti, è molto più rapido), i costi sono troppo alti, ed infine nella realtà le organizzazioni non vogliono più spendere per i vecchi sistemi (anche un approccio incrementale, per non parlare di uno studio completo di reverse engineering e di rifacimento del sistema, ha un costo proibitivo rispetto a quello del wrapping).

Integrazione di un sistema

Nel contesto informatico, integrare significa usare il sistema ed i dati legacy nel più ampio contesto del business e della sua architettura informativa. Il focus principale è il business, i processi, le informazioni e come il vecchio sistema può contribuire ad implementare l’architettura senza propagare le debolezze del design passato e dei metodi di sviluppo. L’integrazione nasconde (incapsula) il sistema dietro interfacce consistenti che si riferiscono al vocabolario/processi di business, nascondono i dettagli implementativi ed abilitano (side-effect non sottovalutabile) anche successivi cambiamenti o sostituzioni senza intaccare tutta l’architettura.

Obiettivo dell’integrazione è il far leva sulle informazioni e sul codice  del  sistemi legacy durante lo sviluppo dell’enterprise architecture: il sistema deve essere in grado di cooperare con gli attuali sistemi (altri legacy) e soprattutto con quelli di successiva generazione. Predire il tipo ed il livello di cooperazione richiede all’organizzazione lo sviluppo di un’architettura informativa nella quale il sistema legacy è una risorsa, disponibile sia durante il design che l’implementazione dell’architettura. Questa disaccoppia e decompone il vecchio sistema nei suoi componenti service – based e partiziona i processi di business in domini distinti ma cooperanti. Per ripartire il legacy è necessario capire il contenuto semantico e gli usage pattern del sistema e quindi implementare interfacce astratte che rendono questi due aspetti disponibili in altri domini.

Precedente Framework per la migrazione completa di un sistema informatico Successivo Il sistema Wrapper (livello software)

Lascia un commento

*