Per molti versi una architettura IT non è diversa dall’architettura degli edifici. Si parte con una idea generale e si arriva a un piano preciso che comprende tutti i dettagli dei componenti.
Allo stesso modo, quel piano così perfetto e funzionale sulla carta si scontra con la realtà dei fatti e man mano cambia, accettando compromessi e modifiche.
La differenza fra l’IT e un edificio è che la “costruzione” della prima è un processo in divenire che può, nel quotidiano, ulteriormente allontanarsi dall’idea iniziale.
Gli indicatori chiave di quanto la concezione di partenza dell’IT aziendale si stia erodendo sono due e vanno quasi sempre insieme: frammentazione e ridondanza.
Più l’IT si frammenta e le informazioni vengono duplicate, più il sistema nel suo complesso perde efficienza o rischia seriamente di farlo.
Il primo punto di vulnerabilità per la coerenza di una architettura IT sono le applicazioni. La loro frammentazione arriva quando passa il concetto del best-of-breed a tutti i costi.
Anche se è comprensibile che gli utenti interni vogliano la soluzione considerata ideale per le loro necessità, se questo approccio prende piede per qualsiasi esigenza ci si trova a gestire decine di software molto verticali che quasi certamente non sono stati pensati per collaborare fra loro.
Il passo successivo è la presenza in azienda di applicazioni non solo molto verticali ma addirittura ridondanti.
Applicazioni cioè che svolgono compiti simili e in parte si sovrappongono, ma che vengono tutte mantenute perché ciascuna ha una sua particolare funzione o caratteristica che viene ritenuta importante.
Si tratta di uno scenario che si verifica frequentemente dopo fusioni e acquisizioni, se l’IT non riesce a definire un’applicazione “dominante” rispetto alle altre per i vari processi aziendali.
La conseguenza della frammentazione e della ridondanza delle applicazioni è la ridondanza dei dati che esse usano. Difficile che applicazioni simili ma disparate possano condividere la medesima base dati – cosa che potrebbe non essere possibile anche per motivi diversi, architetturali o di privacy – ed ecco quindi che i dati si duplicano.
Cosa che, ovviamente, non favorisce per nulla la coerenza e l’affidabilità delle informazioni in azienda.
Mettere mano all’integrazione. Di nuovo
A questo punto il problema principale dell’IT aziendale diventa non lo sviluppo di nuovi servizi ma l’integrazione dell’esistente, quindi di fatto la manutenzione di ciò che c’è rallenta il nuovo.
In quanto a integrazione il dibattito poi è sempre lo stesso da decenni: punto-punto o trasversale. Nessuna delle due alternative evita lavoro allo staff interno.
Da un lato ci sono la creazione e la manutenzione di interfacce dirette fra applicazioni e/o fra database, dall’altro la gestione di un prodotto in stile EAI (Enterprise Application Integration).
Sono due strade entrambe non banali, che richiedono un lavoro di ripensamento dei flussi dei processi e dei dati aziendali. Lo stesso che, in fondo, aveva portato a quell’architettura IT da cui non si sarebbe dovuti deviare.
