Integrazione software: culture diverse che convergono

Nel mondo del software la parola “integrazione” è molto utilizzata ma non sempre il significato è univoco e condiviso tra gli interlocutori.
Tante volte sento porre dai clienti ai consulenti la domanda  “La vostra soluzione software è integrata con SAP*?” oppure  “avrete già dei connettori per SAP?“
Secondo voi, la risposta potrà essere diversa da un “certo che sì”?

Il punto è che, al netto di malizia commerciale o di una sincera volontà di dimostrare che si è all’altezza, la domanda è mal posta.

Forse è meglio ragionare su questi due aspetti: cosa significa che due sistemi software sono integrati tra loro? E, soprattutto, con che obiettivo viene posta questa domanda?

Integrare due sistemi implica far convergere due “culture” differenti.

I sistemi in gioco nascono da esperienze diverse, mindset diversi perché volti a risolvere problemi diversi in maniera differente, molto spesso specifica per dominio applicativo e settore merceologico.
Spesso i vendor ERP offrono per i loro prodotti delle API o altre modalità per consentire lo scambio di dati o l’utilizzo di funzionalità dei loro sistemi da parte di sistemi terzi: questo aspetto è solo condizione necessaria ma non sufficiente ad una corretta integrazione. Di conseguenza, l’affermazione “la nostra soluzione software dispone già del connettore per SAP” non è di per se garanzia che l’integrazione sarà migliore, più facile o meno costosa.

Capita spesso infatti che lo stesso sistema software utilizzato in due aziende diverse sia configurato in maniera molto differente. Inoltre la medesima struttura dati – ad esempio lo stesso campo del database – può essere utilizzata nelle due aziende con semantiche anche molto distanti tra loro.

Ogni entità informativa nasce in un sistema e fluisce verso gli altri per poi, a volte, ritornarvi modificata. È  l’esempio di  un codice che identifica una promo che viene utilizzato per raccogliere degli ordini: viene creato in un sistema di vendita, processato da un ERP per poi venire storicizzato in un datawarehouse e, attraverso una trasformazione, ritorna al sistema di vendita come dato di storico aggiornato.

Il processo di integrazione è simile al lavoro che fa l’interprete linguistico perchè non si limita ad una mera traduzione da un formato ad un altro ma opera una mediazione tra due culture: certi concetti possono esistere nel sistema sorgente ma non avere equivalenti nel sistema di destinazione.

Nel processo di integrazione è sempre fondamentale identificare per ogni gruppo di entità informative quale sistema è master – cioè “comanda”- e quale è “slave” – cioè “subisce” le azioni dell’altro sistema. Vanno inoltre considerate la frequenza di scambio dati necessaria ed i volumi in gioco: scambi importanti e voluminosi di anagrafiche tra due sistemi richiedono un approccio differente da quello di una “semplice” transazione che implichi il cambio di stato, come ad esempio l’invio di un documento da un sistema ad un altro.

Oltre a comprendere bene cosa significhi integrazione è opportuno comprendere gli obiettivi per cui viene posta questa domanda. Se la domanda sottintende  “quanto affidabile sei?” forse la risposta “abbiamo il connettore” è un po’ debole ed è forse più qualificante e rassicurante per il cliente condividere le esperienze e referenze maturate nei progetti di pari complessità.

Il mezzo utilizzato (connettore, tool di integrazione, tecnologia di scambio..) è condizione necessaria ma non sufficiente nel progetto di integrazione fra sistemi.

(*)abbiamo citato SAP perché è un sistema gestionale noto, molto diffuso ed apprezzato che molti dei nostri clienti utilizzano, ma i ragionamenti descritti in questo articolo si applicano a Oracle, IBM, Microsoft, etc..