Risposta.

Storia della domanda:

La necessità di specifiche di integrazione chiare è emersa con lo sviluppo del panorama IT delle aziende, quando i loro processi aziendali hanno cominciato a fare affidamento su molti prodotti software e servizi diversi. Negli anni '90, per lo scambio di dati si utilizzavano ampiamente documenti cartacei e esportazioni manuali, in seguito sono apparsi gli scambi EDI e le piattaforme di integrazione. Oggi, la specifica dell'interfaccia gioca un ruolo centrale nell'organizzazione di un'interazione efficace.

Problema:

Senza una specifica di integrazione ben elaborata, spesso sorgono malintesi tra i team, elaborazione errata dei dati, lavoro duplicato o addirittura guasti nei processi aziendali. Si pone la domanda: Come documentare e mantenere la specifica affinché entrambe le parti (o più parti) comprendano i requisiti in modo chiaro durante l'intero ciclo di vita del sistema?

Soluzione:

L'analista di sistemi sviluppa la specifica di integrazione utilizzando standard di descrizione generalmente accettati (ad esempio, OpenAPI, WSDL, XSD, BPMN), modelli e strumenti di modellazione. La specifica deve includere:

• Struttura dei messaggi, formati dei dati, regole di gestione degli errori
• Descrizione degli scenari di business per l'interazione e requisiti di sicurezza
• Requisiti di SLA, monitoraggio e registrazione degli eventi
• Regole di aggiornamento e mantenimento della documentazione ad ogni rilascio

Caratteristiche chiave:

• Chiarezza nella delimitazione delle responsabilità di ciascun sistema partecipante.
• Utilizzo di linguaggi formali per la descrizione delle interfacce.
• Supporto e aggiornamento delle specifiche durante l'intero ciclo di vita dell'integrazione.

Domande trabocchetto.

Qual è la differenza tra interazione sincrona e asincrona tra sistemi, e l'approccio asincrono è sempre più resiliente ai guasti?

Lo scambio asincrono riduce effettivamente il coupling delle applicazioni e può essere più resiliente grazie alle code, ma non in tutti gli scenari è ottimale: per le richieste con elevati requisiti di risposta o transazionalità è meglio utilizzare interazioni sincrone.

Basta una descrizione dell'API e della struttura dei dati per comprendere appieno l'integrazione tra i sistemi?

No, è necessario anche documentare gli scenari di business, i modelli di gestione degli errori, i requisiti per il monitoraggio, SLA, tolleranze sui ritardi e la gestione delle versioni.

Si può fare affidamento esclusivamente su accordi verbali tra i team quando si modifica il formato di integrazione?

No, tutte le modifiche devono essere formalizzate nella specifica e concordate per iscritto, altrimenti si corre il rischio di disallineamenti nelle implementazioni e potenziali incidenti.

Errori tipici e anti-pattern

• Insufficiente allineamento delle versioni delle specifiche tra i team
• Negligenza nella documentazione delle eccezioni e delle situazioni non standard
• Non aggiornare la specifica dopo l'implementazione delle modifiche

Esempio della vita reale

Casi negativi: Il cliente ha modificato il formato dei dati nell'API, avvisando solo il team partner via email. Gli sviluppatori di un altro sistema integrato non hanno tenuto conto di questo, e parte delle transazioni ha smesso di essere elaborate. Punti positivi:

• Rapida implementazione dell'innovazione Punti negativi:
• Si è verificato un guasto, è stato necessario un recupero urgente dei dati, sono stati persi tempo e denaro

Casi positivi: L'analista ha aperto una richiesta di cambiamento, ha aggiornato la specifica Swagger, ha avvisato tutti i team interessati tramite chat interna e ha atteso la conferma dell'implementazione delle modifiche. Punti positivi:

• Tutte le parti erano a conoscenza delle modifiche in anticipo
• Ridotto il rischio di errori Punti negativi:
• È servito più tempo per il coordinamento