EDI – de ultieme integratie

23-08-2013 door: Sjaak Pierik

Ik ben inmiddels al ruim 13 jaar bezig met EDI. Dat is best lang. Zo lang dat ik bij veel collega’s zelfs bekend sta als “Mister EDI”.

En het is ook alweer zo’n 9 jaar geleden dat ik voor het eerst te maken kreeg met het vakgebied van Integration en Middleware. In mijn geval betreft dat voornamelijk het werken met webMethods.

In al die jaren is mij een aantal zaken opgevallen. Als ik in mijn werk betrokken ben als EDI Architect dan komt heel vaak het volgende voorbij:

1. EDI? Is dat niet een beetje ouderwets? Die EDI-berichten bestaan al zo’n 20 jaar en zijn nog steeds hetzelfde. Moeten we dat niet eens gaan moderniseren?
2. Die EDI-berichten zijn wel simpel zeg. Dat is absoluut geen rocket science.
3. Wisselen we EDI-berichten uit met meer dan 1000 handelspartners? Oh, dat wist ik niet eens.
4. Hebben we minder dan 10 EDI berichttypen in gebruik om elk jaar miljoenen business transacties uit te wisselen met die handelspartners? Dat is ook niet veel zeg.

In mijn werk als Integration Architect hoor ik vaak heel veel ambities voorbij komen:

1. We moeten voor onze middleware oplossing goede standaardberichten ontwerpen. Het is belangrijk dat we dit meteen goed doen, want elke aanpassing aan deze berichten brengt, nadat ze zijn geïmplementeerd, grote kosten met zich mee.
2. Onze standaardberichten moeten generiek worden opgezet zodat verschillende applicaties en/of pakketten hiermee met elkaar kunnen communiceren.
3. Al onze bedrijfsonderdelen moeten met dezelfde set van standaardberichten kunnen werken.
4. Dat willen we inderdaad allemaal. Maar we willen dit werk natuurlijk wel allemaal outsourcen en offshoren. Dus houd alles wel enigszins overzichtelijk. We willen geen wildgroei aan berichttypen en versies daarvan.

Tja, dan denk ik soms wel eens: dat ouderwetse EDI, is dat eigenlijk al niet decennia lang de ultieme vorm van Integration?