Antwoord.

Achtergrond van de vraag:

De behoefte aan duidelijke integratiespecificaties ontstond met de ontwikkeling van de IT-landschap van bedrijven, waarbij hun bedrijfsprocessen afhankelijk werden van tal van verschillende softwareproducten en -diensten. In de jaren 90 werden papieren documenten en handmatige exports veel gebruikt voor gegevensuitwisseling, later kwamen EDI-uitwisselingen en integratieplatformen. Tegenwoordig speelt de interface-specificatie een centrale rol in het organiseren van effectieve interactie.

Probleem:

Zonder een gedetailleerd uitgewerkte integratiespecificatie ontstaan er vaak misverstanden tussen teams, incorrecte gegevensverwerking, herhaald werk of zelfs storingen in bedrijfsprocessen. De vraag rijst: Hoe documenteer en onderhoud je de specificatie zodat beide partijen (of meerdere partijen) de vereisten gedurende de levenscyclus van het systeem eenduidig begrijpen?

Oplossing:

De system analyst ontwikkelt de integratiespecificatie, gebruikmakend van gangbare beschrijvingsstandaarden (bijvoorbeeld OpenAPI, WSDL, XSD, BPMN), sjablonen en modelleringstools. De specificatie omvat altijd:

• Structuur van berichten, gegevensformaten, foutafhandelingsregels
• Beschrijving van bedrijfs-scenario's voor interactie en beveiligingseisen
• SLA-vereisten, monitoring en registratie van gebeurtenissen
• Regels voor het bijwerken en onderhouden van documentatie bij elke release

Belangrijke kenmerken:

• Duidelijke afbakening van verantwoordelijkheden van elk systeem-deelnemer.
• Gebruik van formele beschrijvingssystemen voor interfaces.
• Ondersteuning en actualisatie van specificaties gedurende de levenscyclus van de integratie.

Misleidende vragen.

Wat is het verschil tussen synchrone en asynchrone interactie tussen systemen, en is de asynchrone aanpak altijd veerkrachtiger tegen storingen?

Asynchrone uitwisseling vermindert inderdaad de koppeling tussen applicaties en kan veerkrachtiger zijn dankzij wachtrijen, maar niet in alle scenario's is het optimaal: voor verzoeken met hoge eisen aan respons of transactiekwaliteit is het beter om synchrone interacties toe te passen.

Is een beschrijving van de API en de gegevensstructuur voldoende voor een volledig begrip van de integratie tussen systemen?

Nee, het is ook nodig om bedrijfs-scenario's, foutafhandelingsmodellen, monitoringseisen, SLA, tolerantie voor vertragingen en versieafstemming vast te leggen.

Kun je uitsluitend vertrouwen op mondelinge afspraken tussen teams bij het wijzigen van het integratieformaat?

Nee, alle wijzigingen moeten worden vastgelegd in de specificatie en schriftelijk worden goedgekeurd, anders bestaat het risico van inconsistentie in de implementaties en potentiële incidenten.

Typischefouten en anti-patronen

• Inconsistentie van specificatieversies tussen teams
• Verwaarlozing van documentatie van uitzonderingen, niet-standaard situaties
• Niet-actualiseren van de specificatie na veranderingen

Voorbeeld uit het leven

Negatieve case: De klant wijzigde het gegevensformaat in de API en informeerde alleen het partnerteam via e-mail. De ontwikkelaars van een ander geïntegreerd systeem hielden hier geen rekening mee, en een deel van de transacties kon niet worden verwerkt. Voordelen:

• Snelle implementatie van de nieuwe functie Nadelen:
• Er trad een storing op, er was een dringende herstel van gegevens nodig, tijd en geld zijn verloren

Positieve case: De analist heeft een change request ingediend, de Swagger-specificatie bijgewerkt, alle betrokken teams via de interne chat geïnformeerd en gewacht op bevestiging van de implementatie van de wijzigingen. Voordelen:

• Alle partijen waren vooraf op de hoogte van de wijzigingen
• Het risico op fouten is verminderd Nadelen:
• Er was meer tijd nodig voor goedkeuring