Elk bedrijf en elke instelling probeert – meestal bewust, soms onbewust – meerwaarde te genereren als schakel in een keten van toeleveranciers. De bijbehorende informatiestromen zijn veelal zonder informatie- en communicatietechnologie ondenkbaar geworden. Vóór het Internet-tijdperk was de ICT-ondersteuning bij deze informatiestromen beperkt tot eilandoplossingen per schakel in de waardeketen. De schakels onderling waren verbonden via post, telefoon, fax en in beperkte mate ‘electronic data interchange’. Met de komst van Internet kan dit anders, en wordt dit anders, stelt Bert Bouwhuis.
Automatiseringseilanden kunnen via Internet over de muren van het eigen bedrijf heen communiceren met toeleveranciers en klanten. De creativiteit ten aanzien van de bijbehorende ‘e-woorden’ (e-commerce, e-business, e-service, e-speak, waar blijft e-verything?) kent geen grenzen en heeft de neiging door overdadig gebruik zelfs averechts te gaan werken.
Van alle hype ontdaan blijft het echter voor ieder bedrijf of instelling buitengewoon nuttig om de waardeketen onder de loep te nemen, en te onderzoeken in hoeverre de technologie van vandaag kan helpen bij die ICT-integratie.
De waardeketen
Veel organisaties onderkennen dezelfde elementen in het primaire proces van hun waardeketen:
- de klant (zakelijk dan wel particulier) communiceert met de front-office medewerker (telefonisch, face-to-face, per post);
- de front-office medewerker wordt ondersteund door specifieke front-office applicaties (klanten-database, callcenter-pakket, order-invoerapplicatie, ‘frequently-asked-questions’ database, enzovoort);
- de back-office organisatie begeleidt het productieproces (opdracht verwerking, productieplanning, projectbegeleiding, etc.) en communiceert met toeleveranciers;
- de back-office medewerkers worden ondersteund door specifieke back-office applicaties (erp-applicaties, planningspakketten, voorraadbeheer, enzovoort);
- toeleveranciers tenslotte leveren de gevraagde producten en diensten.
Applicatie-integratie
Internet-technologie maakt het mogelijk om de losse elementen uit de geschetste waardeketen te integreren. Het koppelen van ICT-oplossingen van toeleveranciers en afnemers is het klassieke terrein van ‘electronic data interchange’ (edi). Het integreren van die ICT-oplossingen maakt concepten als ‘supply chain optimization’ realiseerbaar.
Dit is typisch het toepassingsgebied van extranet, waarbij de beveiligde en gesloten ICT-infrastructuren van bedrijven via het publieke en onveilige Internet onderling op veilige wijze verbonden worden. Binnen de muren van bedrijven wordt dezelfde Internet-technologie gebruikt om voorheen gescheiden applicaties (zoals de front-office en back-office applicaties) te integreren. Vaak is hier alleen sprake van intranet-toepassingen, waarbij de beveiliging geen nadrukkelijke rol speelt. De klant tenslotte krijgt via Internet-technologie rechtstreeks toegang tot de front-office applicaties en zal een veel meer ondersteunende – in plaats van primaire – rol verwachten van de front-office medewerker.
Integratie-mogelijkheden
De mogelijkheden om verschillende applicaties te integreren kunnen geschetst worden aan de hand van het drie-lagen model van applicaties. Elke applicatie is conceptueel te scheiden in ‘user interface logic‘, ‘business logic‘ en ‘database logic‘.
Een goede applicatie is overigens ook feitelijk zo gescheiden ter bevordering van de onderhoudbaarheid en de uitbreidbaarheid. Equivalent aan deze drie lagen kunnen applicaties conceptueel op drie basismanieren geïntegreerd worden:
- op databaseniveau via gegevensuitwisseling;
- op functioneel niveau via berichtenuitwisseling of componenten-integratie;
- op gebruikersinterface-niveau via gebruikersinterface-integratie.
Databaseniveau
De meeste databases zijn met behulp van SQL te benaderen en ondersteunen ODBC of afgeleide interfaces om applicaties toegang tot die data te geven. Vaak wordt daarom getracht om applicaties op dit niveau te integreren. Een veel geuite kreet is dan ook ‘deze applicatie is volledig open want de database is via SQL/ODBC te benaderen’.
Er kleven echter twee belangrijke nadelen aan dit concept. Ten eerste is het vaak zo dat de ‘logic’ van de applicatie (zowel ‘database logic’ als ‘business logic’) nodig is om de database op consistente wijze te kunnen uitlezen, en nog veel meer, te kunnen wijzigen. Een applicatie die op SQL/ODBC-niveau met een andere applicatie integreert dient daarom een kopie te hebben van die ‘logic’. Dit is zowel duur bij de eerste realisatie, als duur en foutgevoelig in het onderhoud daarna. Een tweede bezwaar bij integratie op databaseniveau ligt op het terrein van de beveiliging. Verfijnde regels met betrekking tot het afschermen van delen van de database voor sommige gebruikers zijn vaak alleen mogelijk met behulp van de database en ‘business logic’. Ook hier zou dus de logica in elke andere applicatie gekopieerd dienen te worden met dezelfde bijbehorende nadelen.
Functioneel niveau
Applicatie-integratie op een functioneel niveau biedt in het algemeen meer mogelijkheden met minder nadelen dan die op databaseniveau. Er zijn hierbij twee smaken te onderscheiden: een ‘loosely-coupled’ manier op basis van berichtenuitwisseling, en een ’tightly-coupled’ manier op basis van componenten-integratie.
De ‘klassieke’ edi is een vorm van integratie op basis van berichtenuitwisseling. Hierbij wordt het formaat van de uit te wisselen berichten gestandaardiseerd, soms per industrietak, soms ook van geval tot geval. De meeste edi-koppelingen zijn gebaseerd op gesloten ‘proprietary’ netwerken. Dit maakt het gebruik vaak duur. De relatieve starheid van de edi-definities hebben ook een zekere inflexibiliteit tot gevolg.
De opkomst van XML biedt een alternatief op deze klassieke edi: definities zijn snel en makkelijk uitbreidbaar, en de technologie is volledig geënt op het Internet-tijdperk. Het kenmerk van berichtenuitwisseling – of dit nu op basis van edi of XML plaatsvindt – is dat er alleen gedefinieerd is welke berichten er uitgewisseld kunnen worden, en niet wat de bijbehorende functionaliteit is.
Het grote verschil met component-integratie is dat de nadruk daar niet op de berichten ligt, maar op de aangeboden dienst (in zekere zin vergelijkbaar met het verschil tussen SQL en ODBC). Middels component-integratie kan dus de ene applicatie een dienst aanroepen in de andere applicatie. Een voordeel hiervan is dat zo’n dienst in principe op elk niveau aangeboden kan worden, van ‘database logic’ tot ‘business’ en ‘user-interface logic’.
Een hechte integratie van componenten uit verschillende applicaties (en ontwikkeld door verschillende leveranciers) is uiteraard alleen mogelijk als de infrastructuur van die componenten gestandaardiseerd is. Twee standaards treden daarbij op de voorgrond: het leveranciersonafhankelijke Corba en de Microsoft-variant DCOM. In beide gevallen kunnen componenten elkaars diensten aanroepen, ook als ze in verschillende computers draaien, en ook als ze in verschillende programmeertalen zijn ontwikkeld. Hoewel de standaardisatie van deze infrastructuur al ver gevorderd is, staat deze op ‘business logic’ niveau nog in de kinderschoenen.
Gebruikersinterface-niveau
Applicaties kunnen ook op gebruikersinterface-niveau geïntegreerd worden. Bij legacy-applicaties waar niemand aan de software-bron kan of durft te komen is dit vaak de enige manier. In zo’n geval wordt gebruik gemaakt van ‘screen-scraping‘, wat erop neer komt dat de ene applicatie zich als gebruiker gedraagt voor de andere. Daarbij wordt ‘keyboard-input’ gesimuleerd en wordt ‘display-output’ geïnterpreteerd. Een groot nadeel van dit soort oplossingen is dat de gebruikers-interface nooit ontworpen was als applicatie-interface. Zo is het detecteren van fouten en uitzonderingen voor de gebruiker vaak een fluitje van een cent, maar voor de applicatie die via ‘screen-scraping’ werkt een crime. In de praktijk is dit dan ook vaak niet meer dan een houtje-touwtje oplossing die werkt ‘zo lang alles goed gaat’.
Een variant op ‘screen-scraping’ is die op basis van componenten-integratie. Hierbij is Active-X de meest bekende vorm, als onderdeel van de DCOM-infrastructuur. Omdat componenten ontworpen zijn om met andere componenten (dus software-applicaties) te communiceren, is de integratie veel stabieler te maken dan die middels ‘screen-scraping’.
Noodzaak groeit
De noodzaak tot het integreren van applicaties zal steeds vaker aanwezig zijn. Denk bijvoorbeeld aan een callcenter-applicatie van een telemarketing servicebureau die gedurende een marketingcampagne geïntegreerd dient te worden met de orderinvoer-applicatie van de opdrachtgever.
Het leven zou daarbij een stuk eenvoudiger worden als applicaties van verschillende bedrijven door de beheerders zelf geïntegreerd zouden kunnen worden, ondanks het feit dat ze ontwikkeld waren door verschillende leveranciers die daar vooraf geen afspraken over hadden gemaakt. Alhoewel dit walhalla nog wel even op zich zal laten wachten, zijn de contouren wel al aan de horizon zichtbaar.
Bert Bouwhuis
chief technology officer Triple-P