Home Architectuur De eeuwige interface

De eeuwige interface

31
Rotonde als interface

Vroeger, ruim twintig jaar geleden, las ik over een onderzoekje dat aantoonde dat 70 procent van de output van computersystemen met het handje in een ander programma werd ingevoerd. Ik wens het de mensheid toe dat dit cijfer inmiddels drastisch is gedaald, maar ben er niet gerust op. Zo plande ik vandaag in het uiterst moderne portal van mijn garage een onderhoudsbeurt en kon aan de e-mail bevestiging meteen zien dat van enige integratie met het werkplaatssysteem geen sprake is. Kennelijk verkiest de garagist de eenvoud van handmatig overkloppen en controleren van die paar webaanvragen boven een dure en misschien wel kwetsbare integratie tussen front- en backoffice.

In mijn eigen omgeving proberen we gegevens uitwisselingen uiteraard zoveel mogelijk te automatiseren. Opvallend is de enorme effort die hiermee gepaard gaat. Misschien wordt zelfs wel 70 procent van de implementatie-inspanningen en -kosten aangewend om interfaces te realiseren. Het zijn trajecten die in elk geval altijd lang duren, een hoop gedoe geven en zelden een bevredigend resultaat opleveren. En dat terwijl de techniek de afgelopen jaren juist op het gebied van integratie grote sprongen voorwaarts heeft gemaakt. De twee drieletter- woorden SOA en ESB zeggen daarbij genoeg; zij hielden de belofte in, dat via het simpel aanroepen van een service de juiste data uit een applicatie zou worden geselecteerd en probleemloos en beheerst via een enterprise serivce bus aan een andere applicatie kunnen worden aangeboden. De vraag rijst dan waarom bouw en beheer van interfaces dan toch nog steeds zo moeizaam gaat. Een korte analyse:

1. De applicaties zijn er niet klaar voor
Hoewel op menig doos van een softwarepakket kreten als SOA-ready, SAP-adapter included of ‘Open’ staan vermeld, is de realiteit dat het merendeel van de softwaretoepassingen zich slechts uiterst moeizaam laat ontsluiten. Data selectie met behulp van een querietje gaat nog net, maar data invoeren betekent al snel in de database zelf de updates wegschrijven in plaats van gebruik te maken van de intelligentie van de doel-applicaties. Om maar te zwijgen over de gebruikte technologie: we laten al snel modernismen als XML en SOAP links liggen, om terug te vallen op oude en kwetsbare bestanden in csv- format die we vrolijk heen en weer ftp-en.

2. Tijdsdruk in het project
Interfaces worden vaak aan het einde van een ontwikkelproject ontworpen en gerealiseerd. Daarmee liggen ze op het kritieke pad en gaat snelheid van opleveren boven kwaliteit en vooral robuustheid van het ontwerp. We kiezen voor een quick & dirty oplossing, met de ambitie om dit op termijn, als daar tijd voor is, anders en beter op te zetten. Helaas breekt in de meeste gevallen die betere tijd nooit aan en is het projectbudget allang uitgeput…

3. Data definities
Was het maar zo dat een factuur een factuur was, een order altijd een order en een artikel altijd een artikel. Ieder bedrijf, afdeling en ontwikkelaar hanteert net even andere definities en indelingen. Om deze entiteiten dan op elkaar te ‘mappen’ is in theorie vaak eenvoudig, in de praktijk een crime. Omdat het ene factuurnummer numeriek is, het andere alfanumeriek met voorloop-nul, moeten vaak gekunstelde oplossingen worden gecreëerd. Even een tussentabelletje maken- liefst in excel- om de benodigde conversie makkelijk te maken, en hup, weer een kind met een interface- waterhoofd is geboren.

4. De organisatie snapt het niet
Het goed opzetten van gegevensuitwisselingen is geen hogere wiskunde, maar vergt wel overzicht, inzicht in de principes en valkuilen van moderne en minder moderne technieken. Alvorens interfaces te ontwerpen en te realiseren, is veel bezinning en het neerzetten van logische en vooral ook handhaafbare en gehandhaafde architectuur-principes vereist. Dit stelt eisen aan de kwaliteit, kennis en kunde maar vooral ook vaardigheden van de betrokken ontwikkelaars en beheerders. Geregeld ben ik tegengekomen dat beheerders geen idee hadden welke foutmeldingen hun ESB-monitor allemaal gaf, werden die meldingen genegeerd en was de verbazing maar al te groot toen de gebruikers moesten constateren dat de data-uitwisselingen al weken niet hadden plaatsgevonden.

Over het algemeen ben ik nooit een groot voorstander van het benoemen van ICT–architecten, omdat het vaak een naar binnen gekeerde functie is, waarbij theoretische modellen belangrijker zijn dan de praktische invulling ervan. Toch kan een IT-architect zich juist op het gebied van interfaces bewijzen en zijn geld terugverdienen door goede en praktisch werkbare richtlijnen, principes en definities op te zetten en te bewaken. Wellicht dat menig IT-architect zijn eigen salaris kan terugverdienen door de kosten van interfaces te decimeren!

François van Heurn is als econoom gefascineerd door de toegevoegde waarde van informatietechnologie en de enorme moeite die de mensheid zich moet getroosten om die toegevoegde waarde in de praktijk te realiseren. Hij werkt als zelfstandig project- en interimmanager onder de vlag van www.baileybridge.nl, adviseert vanuit het Cloud Expertisecentrum (www.cloudec.nl) over de kansen, risico’s en organisatorische gevolgen van Cloud technologie en probeert als docent Bedrijfskunde en strategie aan een hogeschool de jongere generatie aan het leren, denken en ontdekken te zetten.

2 REACTIES

  1. Jan Til reageerde op deze tekst met de bijdrage De Clou van Interface, zie de vermelding in de lijst met gerelateerde artikelen.

  2. Een goede analyse. ESB verkopers (ESB in-a-box) verdienen veel aan te complexe producten die zelden de beloften waarmaken. Het is dan ook meestal niet de techniek die het struikelblok vormt maar de communicatie tussen mensen.
    Een interface tussen twee systemen is een formaliseerde communicatie tussen meerdere groepen personen (gebruikers, developers, etc.) Hoe meer tijd wordt besteed aan de communicatie tussen deze groepen hoe meer kans dat ook hun machines goed gaan communiceren (middels een interface).
    Zodra je de gegevens uitwisseling tussen twee personen probeert te automatiseren zul je goed moeten kijken wat deze personen doen om fouten te herstellen; de zogenaamde uitvalverwerking. Het is juist de verwerking van deze uitval die complex is en vaak niet gestandariseerd.

    Een moeilijk punt blijft altijd de ‘nomenclatuur’. Iedere groep heeft zijn eigen definities en waarderingen. Om dit op 1 lijn te brengen kost tijd en energie. In de jaren 90 is hiervoor EDIFACT ontwikkeld als vervanger van de transportbrieven. Vooral de standaard nomenclatuur heeft hier een grote invloed gehad op het succes.
    Een voorbeeld waar dit misgaat is het EPD. Er zijn veel kleine partijen betrokken, hierdoor mist de centrale regie.
    Pas als de artsen onderling tot overeenstemming komen over hoe welke informatie gedeeld kan en mag worden, pas dan is een IT-partij in staat om het delen van deze informatie te automatiseren.

    In de on-line wereld van Amazon, Google en Facebook is de beschikbaarheid van interfaces een belangrijke oorzaak van het succes. Dit zijn grote partijen waar de kleinere partijen zich conformeren aan de standaarden die worden opgelegd door de grote partijen.

    Bij integratie tussen partijen van dezelfde grootte is in veel gevallen geen van de beide partijen bereid of instaat om zich te conformeren aan de ander. En dan is daar nog het belang van de producent van softwarepakketten. Deze heeft er belang bij dat zijn software niet uitwisselbaar is met die van de concurrent.

    Een persoon die zich vanuit de organisatie naar buiten richt om zo een succesvolle integratie mogelijk te maken is zeker zeer waardevol. Deze persoon zal moeten onderhandelen over een consensus van de nomenclatuur en de te gebruiken technologie. En goede onderhandelaars zijn waardevol.

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here