Elke vaardigheid en elke wetenschap – evenals elke handeling en elke keuze – is, zo neemt men algemeen aan, gericht op iets goeds. Daarom heeft men terecht het goede gedefinieerd als datgene waarop alles is afgestemd. Natuurlijk verschillen de doeleinden onderling: soms is het een handeling, soms een daarvan onderscheiden product. (1094a 1-4).

Onze uiteenzetting zal toereikend zijn als zij de graad van helderheid bereikt die bij de gegeven inhoud past. Men mag immers niet bij alle discussiepunten dezelfde precisie eisen, evenmin als men dezelfde graad van afwerking eist bij alle ambachtelijke producten. (1094b 12, 13)

Aristoteles, Ethica (Historische Uitgeverij, Groningen, 1999)

Ingenieurs zijn er niet om de werkelijkheid vast te leggen, maar om de werkelijkheid te maken.

Tibor Lapiskas

eBusiness is bij een sterk groeiende economie een hype geweest waar een beperkt aantal personen veel geld aan heeft verdiend. Enkele geleerden spraken van de ‘nieuwe economie’ met nieuwe wetmatigheden gebaseerd op beschikbaarheid van informatie ongeacht tijd en plaats. Heel veel mensen hebben geld verloren en ook zijn grote ondernemingen in grote financiële problemen gekomen. eBusiness zet echter door. Meer en meer organisaties uit de ‘oude’ economie maken zich op om met nieuwe technologie hun producten en diensten in te kopen en te verkopen.
Er zijn verschillende technieken en softwarepakketten beschikbaar voor eBusiness. Het ontbreekt echter aan een integrale visie die tegemoet komt aan de uitdagingen van organisaties. Wij presenteren die visie in dit boek met bestaande en mogelijk nog niet aanwezige technologie. Wij bieden geen standaard, maar een praktische oplossing met beschikbare technische middelen. Daartoe lichten wij eerst de uitdagingen voor organisaties toe om vervolgens oplossingsrichtingen als EDI, webservices en ebXML te schetsen. Gebaseerd op tekortkomingen in deze aanpakken voor de uitdagingen van organisaties sluiten wij dit hoofdstuk af met onze visie op een oplossingsrichting. Een overzicht van de inhoud van dit boek volgt als laatste in dit hoofdstuk.

1.1 Bestellen op het internet
Iedereen is onderhand bekend met het fenomeen van een internet winkel. Het is mogelijk een groot scala aan artikelen via internet te bestellen en ook geleverd te krijgen. Voor een consument speelt daarbij leverbetrouwbaarheid een grote rol. ‘Krijg ik wat ik heb besteld’ is naast de vraag ‘kan ik op een betrouwbare manier betalen’ wellicht de meest gestelde vraag. Andere vragen zijn ‘voldoet de kwaliteit van het gekochte wel aan de verwachtingen’ en ‘is een product dat niet voldoet met geringe moeite terug te sturen’. Dit soort vragen speelt niet als een consument een fysieke winkel binnengaat en een product koopt. Het product is te bekijken, de kwaliteit direct te bepalen, een consument betaalt met fysiek geld en gaat een winkel uit met het betaalde product.
Een internetwinkel heeft volledig andere zorgen. Eén van de eerste problemen die dit soort winkels moet oplossen, is ‘hoe kunnen klanten mij vinden’. De tweede vraag die direct opkomt is ‘hoe kan ik mijn producten op een overzichtelijke manier aanbieden’. Een fysieke winkel is aanwezig en consumenten besluit al dan niet die winkel binnen te gaan. Vervolgens ziet een klant de producten en maakt een keuze. Een internet winkel stalt zijn producten niet fysiek uit. Een consument krijgt een catalogus aangeboden om uit te kiezen. Elke consument zoekt op zijn manier zijn weg in deze catalogus.
Stel dat een consument een internetwinkel heeft gevonden en een product wenst te kopen. Als eerste moet deze consument zich de condities voor levering en betaling eigen maken. Als hij of zij akkoord gaat met de condities, bestaat veelal de mogelijkheid uit verschillende betaalvormen te kiezen. Een normale acceptgiro, zoals wij die in Nederland kennen, behoort in verschillende gevallen ook tot de mogelijkheden. Een internationaal georiënteerde winkel biedt in de meeste gevallen geen landenspecifieke betaalvormen. Eén van de meest gebruikte methoden is het aanmaken van een rekening met alle adresgegevens, waarna een consument vervolgens een creditcardnummer ingeeft. Dit soort rekeningen is beschermd met een gebruikersnaam en een wachtwoord. Vragen bij consumenten zijn ‘hoe beheer ik de verschillende wachtwoorden bij verschillende internetwinkels’, ‘is de combinatie van naam en wachtwoord veilig’, ‘kan ik mijn creditcardnummer veilig over internet uitwisselen’ en ‘is het creditcardnummer in vertrouwde handen bij een internet winkel’. Beveiliging en vertrouwen spelen hier een grote rol. In de meeste gevallen volstaan internetwinkels om creditcard gegevens via een beveiligde verbinding uit te wisselen. Een browser geeft dan weer dat het een zogenaamde ‘https/..’ adres is, terwijl een onbeveiligde verbinding een ‘http/..’ adres heeft.
In de meeste gevallen geeft een internet winkel na betaling van een besteld product een leveringsbevestiging. Een goede internet winkel boekt vervolgens het bedrag alleen af, als levering volgt. Figuur 1 toont een conceptuele interactie tussen een consument en een internet winkel in zijn rol als leverancier. In werkelijkheid zal een consument met zijn browser een website zoeken en via een ingevuld HTML-formulier een order plaatsen. Elk afzonderlijke interactie is daarmee een zogenaamde internet pagina. Een leverbevestiging volgt vaak per e-mail.


Figuur 1: interactie tussen consument en internetwinkel

Heel belangrijk is vervolgens levering van bestelde producten. Elke internet winkel stelt zich de vraag of hij eigen voorraden aanlegt of zelf bestelt bij een leverancier. Bij het houden van een eigen voorraad komen nog de vragen ‘volstaat één magazijn of moet ik meerdere hebben’ en ‘wat is het vastgelegde vermogen in mijn voorraden’. Bestellen bij een leverancier betekent het aangaan van een contract met die leverancier voor levering. Deze leverancier levert elke bestelling binnen de condities van het overeengekomen contract. Wat als een leverancier niet kan leveren? Mogelijk ontvangt een consument een e-mail dat producten niet direct te leveren zijn en een order te annuleren is. Het volledig uitvoeren van alle onderdelen van een bestelling of de bestelling in zijn geheel niet door te laten gaan als één van de onderdelen faalt, is van groot belang voor zowel een leverancier als een koper.
Als een internetwinkel één of meer eigen magazijnen heeft, genereert een bestelling een zogenaamde uitslagopdracht. Een werknemer of een apparaat haalt de juiste goederen uit het juiste magazijn, verpakt deze en maakt ze klaar voor verzending. De volgende logistieke vragen komen naar voren: ‘wat te doen als een minimumvoorraad wordt bereikt’, ‘welke leveranciers zorgen dat mijn voorraad voldoende blijft’ en ‘hoe regel ik het transport naar kopers’. Normale post verzorgt de aflevering van kleine pakketjes, terwijl bij een bestelling in een ander land een expresvervoerder het transport naar het land van bestemming verzorgt. Ook zorgt een winkel ervoor te bestellen bij een leverancier als het gevraagde product niet meer in voorraad is.
Het blijkt dat alleen het hebben van een webtoepassing onvoldoende is om te kunnen leveren aan elke willekeurige consument. Het is van groot belang een goede interne automatisering te hebben, het zogenaamde back-office, en ook goede afspraken te maken met toeleveranciers. Daarbij speelt ook de (semi-) automatische aansturing van deze leveranciers met berichten een rol. Een volgende ontwikkeling is een ‘nauwere’ integratie met die leverancier door direct zijn systemen aan te roepen. Denk bijvoorbeeld aan betalingsdiensten zoals Bibit (www.bibit.com) die levert, diensten voor de afhandeling van douane-aangifte door bijvoorbeeld Openharbor.com (www.openharbor.com) en kredietverleningsdiensten. Dit soort diensten is direct via een internetwinkel door een consument te activeren om bijvoorbeeld te betalen of de daadwerkelijke kosten voor levering door te rekenen. Een ander voorbeeld is een offerte voor een levensverzekering of het registreren van een polis. Deze diensten zijn online, realtime ontsloten. Een leverancier verwerkt een vraag voor autorisatie van een betaling met een creditcard direct. In toenemende mate wensen zowel consumenten als intermediairs directe ontsluiting van diensten van leveranciers. Nieuwe communicatieprotocollen en snellere verbindingen zijn middelen voor verdere directe beschikbaarheid ongeacht plaats en tijd.
Deze online, realtime beschikbaarheid noopt elke organisatie zijn diensten te specificeren en elektronisch te ontsluiten. Elke andere organisatie stelt vervolgens zijn diensten samen met diensten van anderen als componenten. Hiervoor moeten aanbieders te vinden zijn, bovendien moeten deze aanbieders hun producten en diensten eenduidige specificeren en als laatste moet een potentiële klant eenvoudig de diensten elektronisch gebruiken. Dit is te vergelijken met het al lang bekende model van inkoop van producten en diensten om een eigen product of dienst te leveren, met gebruik van een soort Gele Gids. Standaardisatie en keuze uit verschillende diensten speelt hierbij een grote rol. Hoe beter diensten van hetzelfde type op een standaard manier zijn aan te sturen, hoe eenvoudiger een afnemer per transactie een andere toeleverancier van een dienst kiest. Op deze wijze ontstaat een soort ‘business grid’, een organisatienetwerk.
Er zijn verschillende uitdagingen bij de ontwikkeling, het gebruik en het beheer van elektronische diensten, waarvan de organisatorische uitdaging één van de grootste is. Het vereist dat medewerkers van bijvoorbeeld productontwikkeling nieuwe diensten bouwen met standaard diensten van anderen met daarbij de nodige kennis voor ICT ondersteuning. Dit vereist samenwerking tussen bedrijfsmatige en ICT medewerkers. Bedrijfsprocessen moeten snel aan nieuwe diensten aan te passen zijn met ondersteuning van flexibele ICT toepassingen. Processen en datastructuren i.c. berichten staan hierbij centraal. Op welke wijze richt bijvoorbeeld een internet winkel zijn processen in om eenvoudig een bestelling om te zetten in een daadwerkelijke levering.

Voorbeelden

Opbouw van een handelsdienst
Een organisatie wil wereldwijd via internet hoogwaardige producten aanbieden. Denk bijvoorbeeld aan computers, witgoed en geluidsapparatuur. Deze organisatie regelt de logistiek, verricht douane-aangifte en handelt de betalingen af als aparte componenten, uitbesteed bij drie leveranciers. Ook ondersteunt deze organisatie retourstromen en helpt om fouten op te lossen. Afrekening met de componenten kan in principe per individuele transactie, maar ook voor meerdere transacties. Dit laatste is afhankelijk van het model van dienstverlening van de leveranciers.
Eén component verzorgt de afhandeling van douane-aangiften en berekent daaraan verbonden kosten voor een koper. In feite betreft dit drie diensten: het berekenen van import- en exportkosten, het daadwerkelijk doen van aangifte en het afdragen van import- en exportkosten. Voor dit laatste maakt de douanecomponent gebruik van een betalingsdienst. Een andere component die wereldwijd verschillende transportondernemingen en overslagpunten aanstuurt, bestuurt de logistiek. De magazijnen zijn in handen van de organisatie zelf. Ook logistiek kent drie componenten, te weten het berekenen van de logistieke kosten, het afhandelen van de logistiek en het betalen van de ingeschakelde dienstverleners met een betalingsdienst. Een betalingsdienst die een koper direct aanroept, stelt een koper in staat direct te betalen. Een koper krijgt verschillende betalingsmogelijkheden aangereikt met bepaalde condities voor weigering van de ontvangen goederen en teruggestort krijgen van het bedrag.
Het afhandelen van een bestelling bestaat uit verschillende stappen. De eerste stap berekent de totale kosten bij de aanschaf van een product. De douane- en logistieke component leveren hiervoor gelijktijdig douane- en transportkosten. Mogelijkerwijs krijgt een koper ook kosten in relatie tot levertijd getoond; snellere levering brengt vermoedelijk hogere kosten met zich mee. Als een koper vervolgens als tweede stap een bestelling plaatst, stuurt een volgende processtap een eigen magazijn voor uitlevering en de logistieke – en douanecomponent aan. Zij handelen de volledige logistiek en douane af en dragen de kosten af aan de ingeschakelde diensten. Bij het plaatsen van een bestelling geeft een koper als laatste stap de betalingsvorm voor het opstarten van de betalingsdienst. Indien een koper kiest voor betaling met een creditcard, autoriseert een betalingsdienst deze eerst waarna de laatste processtap een bestelling voor uitlevering activeert. Deze authorisatie is via de betalingsdienst. Bij online betalen via de bank van de koper, vindt uitlevering bijvoorbeeld plaats na ontvangst van de overschrijving door deze bank.

Een marktplaats in de reissector
Een marktplaats in de reissector registreert verschillende aanbieders in de reissector, zowel touroperators als ook hotels en luchtvaartmaatschappijen met een typering van hun diensten en de elektronische ondersteuning van deze diensten. Een nieuwkomer benadert de marktplaats om reizen als onderdeel van zijn productenpakket aan te bieden. Deze nieuwkomer biedt als onderdeel van zijn diensten een webtoepassing voor consumenten om hun reizen te boeken. De nieuwkomer beschikt niet over een eigen elektronische reisgids, maar koppelt direct door naar de elektronische reisgidsen van leveranciers.
Een consument is in staat om bij deze nieuwkomer door ingave van gegevens een overzicht te krijgen van aanbieders met hun diensten. De marktplaats heeft tijdens de selectie van de aanbieders direct de beschikbaarheid van de producten gecontroleerd en een exacte specificatie van beschikbare producten ontvangen. Deze specificatie omvat niet alleen de prijs, maar ook gegevens uit een Content Management Systeem zoals een foto van een hotel, informatie over de omgeving, etc. Een consument kan al deze producten nader bekijken om vervolgens één te bestellen. Hij plaatst daartoe een reservering en geeft direct de gewenste betaalwijze in. De marktplaats voert deze betaalwijze uit en boekt de reis. Een consument krijgt direct een bevestiging van de reservering en ontvangt van de marktplaats alle informatie om zijn reisbescheiden af te halen. Deze bescheiden zijn bijvoorbeeld op te halen bij een reisbureau, een vertrekbalie op een vliegveld of bij een touroperator. Met bestaande producten van verschillende leveranciers is een nieuwkomer op deze manier in staat een volledig pakket van reisproducten te leveren. De ‘Gele Gids’ voor de reissector bevat alleen de wijze van koppeling en handelt vervolgens een transactie van een consument voor de nieuwe aanbieder af.

1.2 De uitdagingen
eBusiness kent naast de inrichting van logistieke processen verschillende uitdagingen om een organisatie optimaal te ondersteunen. De eerste uitdaging is de flexibiliteit in dienstverlening; de tweede heeft te maken met afhankelijkheidsrelaties tussen organisaties, de zogenaamde ‘lock-in’. Organisaties moeten eBusiness technologie zo toepassen dat zij de keuze hebben te functioneren in een vrije markt of raamcontracten aangaan. Kostenoverwegingen om vooral kleinere ondernemingen te voorzien van eBusiness in organisatienetwerken spelen hier een rol. Technologie moet niet beperkend zijn. Daarnaast willen organisaties geleidelijk veranderen, met behoud van investeringen in interne organisatie, processen en ICT. Wij lichten deze uitdagingen hier kort toe.

Organisaties wensen hun dienstverlening flexibel in te richten, in overeenstemming met hun producten en interne organisatie. Een verzekeringsmaatschappij of tour operator wil bijvoorbeeld sneller zijn dienstverlening wijzigen dan een automobielfabrikant. Een nieuw verzekeringsproduct kan voortborduren op een bestaand product of kan een combinatie van verschillende producten zijn. Ook moet een tussenpersoon in staat zijn om een nieuw product samen te stellen met twee of meer producten van één of meer verschillende verzekeringsmaatschappijen. Voor reisproducten gelden ook dit soort overwegingen. Aanpassingen in de interne organisatie zullen nodig zijn om nieuwe producten en diensten te leveren. Dit geldt zowel voor automobielfabrikanten die voor een nieuw model een nieuwe fabriek inrichten als voor een overheidsorganisatie die zijn bestaande producten via een ander kanaal ontsluit. Ook verschillen investeringen in nieuwe producten en diensten tussen dit soort organisaties.
Technologie moet geen beperkingen opleggen aan de dienstverlening van een organisatie. Wijziging in dienstverlening brengt organisatieveranderingen en daarmee mogelijk ook technologieveranderingen met zich mee, maar een organisatie zal bij eenmaal ingerichte kanalen zonder veel extra kosten en doorlooptijd nieuwe producten en diensten willen invoeren. Als verkoopkanalen met eBusiness zijn ingericht, moeten deze kanalen met geringe inspanning nieuwe producten en diensten ondersteunen. Dit geldt al voor de huidige verkoopkanalen die veelal gebruik maken van telefoon en fax, waarbij opleiding in het kanaal voor nieuwe producten en diensten natuurlijk een rol speelt.
Deze flexibiliteit stelt enerzijds eisen aan de inrichting van distributiekanalen. Anderzijds worden eisen gesteld aan de interne toepassingen. Waar menselijke tussenkomst bij een leverancier in kanalen met fax- en telefoonverkeer eventuele onoverkomelijkheden in integratie van interne toepassingen kan oplossen, is dit voor kanalen ingericht met eBusiness niet meer mogelijk. Interne toepassingen moeten ook direct een nieuw product of een nieuwe dienst verwerken. Flexibiliteit in integratie van deze interne toepassingen en natuurlijk van de toepassingen zelf speelt daarmee een grote rol. Softwareontwikkeling of pakketten moeten de interne ICT architectuur voorbereiden op dit soort veranderingen.

De tweede uitdaging voor integratie betreft de ‘lock-in’ of de ‘switching costs’ om te veranderen van toeleverancier. De perceptie van vele organisaties is dat in de internet wereld nieuwe relaties snel met technologie te ondersteunen moeten zijn. Met andere woorden: de zogenaamde switching kosten voor verandering van leverancier nemen af. Een producent moet bijvoorbeeld een nieuwe vervoerder kunnen selecteren om vervolgens direct met deze vervoerder informatie uit te wisselen. Als de wensen van deze producent wijzigen, bijvoorbeeld omdat zijn producten en diensten wijzigen, gaat een organisatie een relatie met een andere vervoerder aan. eBusiness ondersteunt ook deze nieuwe relatie direct.
Dit soort gedachten gaat uit van een vrije markt met in het algemeen een groter aanbod dan vraag. Per individuele transactie gaan organisaties een relatie met elkaar aan. De transportsector is een voorbeeld van een dergelijke markt. Denk bijvoorbeeld ook aan toelevering van kantoorartikelen op transactiebasis. Wisseling van toeleverancier per individuele transactie vereist naast afspraken omtrent levering en kwaliteit van die levering ook gebruik van standaardtechnologie. Er is een beperkte tijd beschikbaar om technologie in te richten voor individuele transacties. Organisaties moeten het gedrag van een mogelijke toeleverancier of afnemer van tevoren kennen om vervolgens elektronisch transacties af te handelen.
Een kenmerk van vrije markt is ook het ontstaan van ketens per individuele transactie. Organisaties functioneren in een netwerk. Het geeft organisaties naast de vrijheid om commerciële relaties aan te gaan en onzekerheden te verwerken ook de vrijheid hun eigen processen in te richten en met ICT toepassingen te ondersteunen. Organisaties kunnen zich daarmee onderscheiden van hun concurrenten. eBusiness moet tegemoet komen aan deze autonomie van organisaties. Een optimale procesinrichting passend bij een organisatie kan een optimale dienstverlening naar klanten geven.
Het tegenovergestelde is het aangaan van onderlinge raamcontracten om leveringen en afname van producten en diensten te garanderen. Raamcontracten zijn een weergave van lange termijn relaties en vormen de basis voor ketens die de levensduur van individuele transacties overschrijden. Ook in deze gevallen richten organisaties hun procesen optimaal in voor hun doel. Zodra het onderscheid in producten is terug te vinden, is eenvormigheid van procesen en ondersteunende technologie geen probleem. Producten zullen in dergelijke gevallen een fysiek karakter en een relatief hoge aanschafwaarde voor afnemers hebben, denk bijvoorbeeld aan auto’s. Het is mogelijk om voor deze ketens zogenaamde referentiemodellen te ontwikkelen en deze vervolgens per organisatie nader in te vullen. Deze eBusiness referentiemodellen zijn analoog aan referentiemodellen voor implementatie van ERP (Enterprise Resource Planning) systemen. Mogelijkerwijs schrijft wetgeving ook referentiemodellen voor. Een voorbeeld is de Europese douanewetgeving voor doorvoer waarin bepaalde referentiemodellen voor een doorvoerketen zijn beschreven. Elke lidstaat kan deze referentiemodellen op zijn eigen wijze implementeren. Koppelvlakken tussen twee lidstaten liggen echter vast in de wetgeving.
Zowel voor raamcontracten als een vrije markt spelen kosten van de gekozen oplossing een rol. Complexe oplossingen confronteren met name het Midden- en Kleinbedrijf (MKB) met niet alleen relatief hoge aanschafkosten, maar ook hoge beheer- en onderhoudskosten. Een andere niet te onderschatten kostencomponent is kennis. Het MKB moet niet alleen investeren in kennis van toepassingen, maar ook kennis van eBusiness. Bij het aangaan van raamcontracten nemen organisaties deze kosten voor lief in relatie tot (mogelijke) opbrengsten uit die contracten. Als dit bovendien gepaard gaat met een lock-in voor het MKB, zijn zij gebonden aan hun raamcontracten.Een vrije markt vergt echter investeringen vooraf, waarvan onzeker is of deze zich ooit terugverdienen. Gekozen oplossingen moeten in elk geval de gesignaleerde lock-in voorkomen om het MKB in staat te stellen in een vrije markt te acteren.

Een speciaal geval van lock-in is die van softwareleveranciers. Organisaties willen voor eBusiness eenvoudig wisselen van product om in een veranderende omgeving in elk geval geen beperkingen van een ICT leverancier opgelegd te krijgen. Een belangrijk aspect voor onderlinge koppeling is ook het gebruik van verschillende producten van verschillende leveranciers door twee of meer communicerende organisaties. Organisaties moeten zelf een keuze maken voor een product en dit niet opgelegd krijgen door hun afnemer. Deze ‘software vendor lock-in’ kent naast aspecten als functionaliteit van een product ook beheersbaarheid en onderhoudbaarheid. Een keuze voor een bepaalde database omgeving is niet eenvoudig te veranderen en vergt een opleidingstraject voor ICT medewerkers.
De laatste uitdaging is een geleidelijke transformatie van huidige organisaties, processen en ICT naar eBusiness. Willen organisaties hun processen veranderen of verbeteren, dan moeten zij een procesbenadering voor ketens onderzoeken. Mogelijke knelpunten en voordelen voor veranderingen komen daarbij ter sprake. Willen organisaties investeringen veilig stellen en toch gebruik maken van nieuwe technologie in relaties met andere organisaties en consumenten, dan is een benadering met protocollen op koppelvlakken relevant.
Tot voor kort slaagden eBusiness initiatieven alleen als zij buiten een bestaande organisatie in een nieuwe vorm werden opgezet. Dit vergt echter grote investeringen met mogelijkerwijs lange terugverdientijd. Leidinggevenden kunnen deze financiële risico’s niet meer nemen, maar moeten zich tegelijkertijd opmaken voor eBusiness. Een methode dient aan te sluiten bij deze bestaande situaties en oplossingen te bieden voor het functioneren in een eBusiness omgeving. Daarbij is het van groot belang dat standaard software deze methode ondersteunt, zowel voor het Midden- en Kleinbedrijf (MKB) als voor grotere organisaties.

1.3 Mogelijke oplossingen voor de uitdagingen: EDI, webservices en ebXML
Zijn deze eisen nu nieuw? Er vonden in het verleden en er vinden nog steeds technologische ontwikkelingen plaats om flexibiliteit in dienstverlening te bieden en lock-in op technisch gebied te voorkomen. Electronic Data Interchange (EDI), webservices en Electronic Business eXtensible Markup Language (ebXML), zie de bijlagen B, C en D, zijn drie verschillende werelden met een onderlinge samenhang. Het gebrek aan flexibiliteit en de lock-in bij EDI hebben deze techniek alleen geschikt gemaakt voor contractuele relaties. EDI projecten kennen veelal een lange doorlooptijd met hoge kosten. Een lange doorlooptijd is verklaarbaar uit het feit dat dit soort projecten naast invoering van nieuwe techniek ook afstemming van bedrijfsprocessen met zich meebrengt. Bij ontvangst van een order moet een ontvanger wel weten dat een verzender ook een bevestiging verwacht met voor hem nuttige informatie. Daarbij komt dat bij deze projecten in het verleden veelal een technisch jargon werd gebruikt dat niet voor buitenstaanders begrijpelijk is. Bewoordingen als ‘wat doen wij met 1131 en 3055’ laten alleen bij ingewijden een bel rinkelen, terwijl anderen met de oren klapperen. Een goede technische opleiding in EDI (Electronic Data Interchange) was daarmee een noodzaak tot een succesvol implementatietraject. Veel EDI projecten zijn succesvol gebleken als betrokken organisaties dezelfde software gebruikten (‘software vendor lock-in’). EDI is daarom alleen geschikt als organisaties een langdurige relatie met elkaar in de vorm van een raamcontract hebben om investeringen te rechtvaardigen. De automobielindustrie en de vliegtuigbouw zijn voorbeelden waar afnemers hechte relaties met leveranciers aangaan en samen specificaties van onderdelen opstellen. Organisaties gaan in dit geval een samenwerkingsrelatie van meerdere jaren aan en stemmen hun bedrijfsprocessen op elkaar af. Dit betekent dat twee organisaties hun interacties tussen processen eenduidig specificeren.

XML, de basis voor webservices en ebXML, poogt een oplossing te bieden om ook integratie voor kleinere organisaties in termen van transactievolumes mogelijk te maken. XML en ook EDI zijn berichtgeoriënteerd. Organisaties koppelen hun bedrijfsprocessen per berichttype. XML legt de samenhang tussen berichten niet vast, dit moeten organisaties zelf doen. Er is veel software op de markt beschikbaar voor XML, ook browsers ondersteunen XML. Daarmee kan een organisatie zonder grote investeringen eBusiness toepassen.
Naast XML zijn andere technieken nodig om met relatief geringe inspanning toepassingen te integreren. Webservices, voor integratie van softwarecomponenten gaat uit van een gemeenschappelijk te benaderen opslag van interfacespecificaties van deze softwarecomponenten in een zogenaamde Registry. Deze Registry is te vergelijken met een Gele Gids, maar dan voor softwarecomponenten. Softwareontwikkelaars halen een interfacespecificatie van een component op en implementeren het interface in hun deel van de software. Deze interfacespecificatie is in de meeste gevallen vastgelegd in operaties op objectklassen (zie bijlage A over UML). Webservices geeft daarmee ‘tightly coupled’ toepassingen: veranderingen in een aangeroepen toepassing hebben direct invloed op een aanroepende toepassing. Webservices is gericht op ontwikkeling van herbruikbare (lego-)componenten als basis voor ontwikkeling van nieuwe software. De fysieke locatie van een component is daarmee van ondergeschikt belang. Middleware verzorgt de afhandeling van de communicatie over het internet en de verwerking van de interacties. Eventueel beschikt deze middleware over adapters voor conversies (zie hoofdstuk 3).
Figuur 2 toont een schematisch overzicht voor de werkwijze bij webservices (zie ook bijlage C).


Figuur 2: samenhang van standaarden voor webservices

Uit het schematisch overzicht blijkt dat degene die een component aanroept deze component als bouwsteen in zijn software past. Een aanroep van een component bestaat in elk geval uit één bericht heen en één terug, maar dit mogen er ook meerdere zijn. Koppelingen met een groot aantal externe componenten geeft dus een groot aantal ‘adapters’ bij een aanroepende component met het daarbij horende beheerprobleem. Ook geeft dit de nodige afhankelijkheid. Webservices bieden daarmee zeker geen oplossing voor beheersbare en uitbreidbare software gericht op flexibiliteit in dienstverlening en het voorkomen van lock-in.
Webservices overstijgen in principe organisatiegrenzen als ontwikkelaars in verschillende organisaties toegang tot elkaars Registry hebben. Een organisatie kan een webservice van een component in een willekeurig systeem van een andere organisatie aanroepen. Vraagstukken over verrekening van gebruik van webservices en beheer van één of meer Registries zijn daarmee actueel. In de praktijk verzorgen webservices alleen de koppeling tussen componenten binnen één organisatie, zodat deze vraagstukken nog niet spelen.

ebXML hanteert ook het principe van een gemeenschappelijk bestand met interfacespecificaties, ‘Registry’ genoemd. Er is echter een groot verschil met webservices. ebXML tracht een raamwerk te geven voor het functioneren van een organisatie in een keten met andere organisaties. Een Registry slaat specificaties van ketens op, waarna vervolgens een organisatie zijn rol in die ketens kan aangeven. ebXML heeft het streven om het tot stand komen van een overeenkomst met software te ondersteunen. Software ondersteunt vervolgens B2B (Business-to-Business) integratie conform deze overeenkomst. Een overeenkomst beschrijft bijvoorbeeld de te gebruiken internet communicatieprotocollen, de berichtspecificaties en de elektronische te ondersteunen processen. Een overeenkomst is opgeslagen in een Collaboration Protocol Agreement, vastgelegd in een ebXML Registry. Dit laatste is niet beschreven in ebXML. Figuur 3 toont een schematisch overzicht van deze werkwijze (zie ook bijlage D).

Figuur 3: ebXML procesbeschrijving

In tegenstelling tot ebXML gaan webservices uit van de realisatie van een interface van een component door de aanroepende component. ebXML bouwt voort op de EDI praktijk door onderhandelingen toe te staan. Ook maakt ebXML een scheiding tussen functionele specificaties en technische realisatie met bijvoorbeeld XML. Dit in tegenstelling tot webservices, waar elke leverancier zijn invulling geeft aan standaarden en voor het merendeel technische documentatie oplevert. ebXML heeft echter twee tekortkomingen, waarvan één ons inziens onoverkomelijk is. Ontwikkelaars van ebXML voegen zeer waarschijnlijk de eerste tekortkoming, het ontbreken van een specificatie om te komen tot een overeenkomst, toe aan de standaard. Dit zal dan ook geen belemmering vormen voor het gebruik van ebXML.
De tweede tekortkoming van ebXML heeft een relatie met het principe om ketens te modelleren. Men ontwikkelt als het ware referentiemodellen voor volledige ketens. Zoals wij eerder hebben gesteld kunnen referentiemodellen de implementatie van eBusiness versnellen, maar komt dit niet tegemoet aan de autonomie van organisaties. Organisaties implementeren referentiemodellen nooit volledig. Hooguit ondersteunen organisaties bepaalde interacties die in referentiemodellen, ontwikkeld volgens ebXML en vastgelegd in een Registry, zijn gespecificeerd.
ebXML heeft ook het beheer van Registries als belangrijk verschil met webservices. Softwareontwikkelomgevingen ondersteunen webservices met een Registry die softwareontwikkelaars zelf beheren. Een ebXML Registry overstijgt organisatiegrenzen en de grote vraag is nu: wie voert het beheer over een Registry? ebXML doet hierover geen uitspraken, maar veronderstelt net als EDI een gemeenschappelijke beheeromgeving voor ontwikkelaars in verschillende organisaties.

1.4 Een alternatief: minimale afspraken met protocollen
Elk van de hiervoor genoemde technieken heeft zijn eigen toepassingsgebied. EDI en ebXML richten zich beide op lange termijn relaties, terwijl webservices geschikt zijn voor hergebruik van softwarecomponenten, in principe binnen één organisatie. Alle drie technieken bieden onvoldoende flexibiliteit in dienstverlening en zorgen voor een lock-in. Dit boek beschrijft een alternatieve benadering gebaseerd op de volgende onderdelen:
-  Functionele specificaties voor interacties tussen organisaties zijn gescheiden van hun fysieke representatie. Interacties zijn vorm te geven met berichten of een Graphical User Interface voor directe interactie met een mens. EDIfact en XML zijn voorbeelden van een fysieke representatie, maar ook een webtoepassing is een voorbeeld.
-  Een interactie als bijvoorbeeld een bestelling roept één of meer operaties op objectklassen van een toepassing aan, waarbij die toepassing zich in de eigen organisatie of in een andere organisatie bevindt. Ontkoppeling van operaties op objectklassen en interacties geeft afscherming van de interne realisatie van een toepassing. Dit betekent dat een aanroepende en aangeroepen toepassing onafhankelijk van elkaar te wijzigen zijn.
-  Functionele specificaties beschrijven alleen de interacties op de koppelvlakken tussen organisaties of tussen een organisatie en een persoon (consument of werknemer) voor de levering van een dienst. Ontwerpers leggen enerzijds protocollen voor diensten vast en anderzijds datastructuren of klassediagrammen van de mogelijke inhoud van interacties. Er zijn standaardprotocollen te ontwikkelen voor toepassingsgebieden. Een handelsprotocol tussen een afnemer en een toeleverancier is een voorbeeld van een standaardprotocol met bijbehorende datastructuren.
-  Functionele specificaties en hun technische representatie voor levering van diensten zijn opgeslagen in zogenaamde Registries in analogie met ebXML en webservices. Organisaties kunnen hun diensten met protocollen en technische representatie in verschillende Registries opslaan. Deze Registries communiceren onderling om de juiste instellingen te leveren voor de ondersteuning van transacties.
-  Organisaties dragen zorg voor integratie van interne toepassingen en koppelen vervolgens protocollen en technische representaties aan hun interne systemen. Zij implementeren protocollen met bijbehorende datastructuren volledig. Interne toepassingen ondersteunen zeer waarschijnlijk geen generieke protocollen.
-  Zodra organisaties elkaars diensten willen gebruiken, zullen zij de bijpassende technische afspraken moeten zoeken. Organisaties dienen tot overeenstemming te komen omtrent het te gebruiken communicatiemechanisme, adressering, het niveau van beveiliging, de te gebruiken protocollen en de technische representatie van interacties (syntax, syntax versie, etc.). Deze afspraken zijn vervolgens parameters voor software, waarin protocollen en interacties zijn geïmplementeerd en gekoppeld aan interne toepassingen. Wij noemen deze afspraken een ‘Binding’ tussen twee organisaties voor een bepaalde dienst.

Wij gebruiken dus verschillende elementen uit webservices en ebXML. Er zijn twee grote verschillen. Allereerst is dit de modellering van protocollen en de volledige implementatie van protocollen door organisaties. Deze ‘implementatie-vooraf’ betekent dat het aantal afspraken om bedrijfsprocessen en toepassingen van verschillende organisaties onderling elecktronisch te koppelen veel eenvoudiger is in vergelijking met ebXML. Ten tweede speelt een Registry in de voorgestelde aanpak ook een actieve rol bij het tot stand komen van een Binding, in tegenstelling tot een ebXML Registry die alleen vastlegging van modellen ondersteunt. Figuur 4 toont de verschillende stappen om te komen tot transacties tussen twee organisaties. Veel stappen gaan vooraf aan de daadwerkelijke 'Binding' die in de stappen 5, 6 en 7 plaatsvindt.

Figuur 4: verschillende fasen in de voorgestelde aanpak

Wij doen in dit boek geen uitspraken over de ondersteuning van onze aanpak met softwarehulpmiddelen. Technologie is continu aan wijzigingen onderhevig. Wel biedt de aanpak een handvat voor niet alleen de ontwikkeling van eBusiness toepassingen, maar ook voor softwareselectie.
Een vraag die zowel bij ebXML als ook bij de hier voorgestelde werkwijze te stellen is, is de initiële vulling van een Registry. Dit kunnen individuele organisaties of samenwerkingsverbanden doen. Het is ook mogelijk dat een overkoepelende organisatie als UN/Cefact of Oasis komt tot standaardisatie van protocollen voor handelsrelaties. Beide organisaties zijn actief op dit gebied, waarbij met name UN/Cefact zich richt op vereenvoudiging van internationale handel. Hoofdstuk 2 van dit boek doet een (beschrijvende) aanzet voor een protocol dat hiervoor als basis kan dienen.

1.5 Modellering van protocollen
Protocollen beschrijven elektronische uitwisseling van informatie tussen systemen van twee organisaties. Deze interne systemen communiceren via integratiesoftware onderling en met systemen bij andere organisaties. Systemen ondersteunen het leveren van producten of diensten, bijvoorbeeld levering van kleding of een beleggingsdienst. Eenvoudige protocollen met alleen een vraag en een antwoord zijn snel te ontwikkelen. Elektronische ondersteuning en inpassing van verschillende diensten in interne operationele processen eist een gestructureerdere aanpak gebaseerd op concepten. Tabel 1 toont de concepten met een verwijzing naar de te gebruiken modelleringstechniek (zie bijlage A). Deze concepten zijn de basis voor onze methode om interacties in organisatienetwerken mogelijk te maken.

Tabel 1: concepten voor modellering van primair - en informatieverwerkend proces

Een model van een systeem geeft een structuur van een systeem. Een model is altijd een abstractie van de werkelijkheid. Door bij de opzet van een model zoveel mogelijk rekening te houden met het verwachte gedrag (behaviour) wordt de kwaliteit van dat model hoger. Wij maken dan ook een onderscheid tussen structuur van bijvoorbeeld een organisatienetwerk en zijn mogelijke gedrag in verschillende ketens.
De laatste kolom in de vorige tabel geeft een opsomming van de te gebruiken technieken. Deze technieken zijn afzonderlijk in bijlage A beschreven. Zij vormen de basis voor het vastleggen van de diverse ontwerpen. Deze technieken resulteren in samenhangende modellen, waarbij UML de volledigheid (completeness) en correctheid (correctness) van die modellen niet ondersteunt. Dit doen wij met Petrinetten. Verificatie is nodig bij complexe ontwerpen voor veel interacties tussen meerdere partijen. Complexiteit wordt veroorzaakt door vertragingen in de uitwisseling over een extern netwerk (internet), asynchrone communicatie, foutafhandeling en annulering. Dit betekent niet dat alle ontwerpen zo complex zijn dat formele verificatie nodig is. De volgende figuur toont de onderlinge samenhang van de verschillende technieken.


De hiërarchie waarin organisaties een keten van (fysieke) processen afhandelen wordt met een transactieboom gevisualiseerd. Hiervoor gebruiken wij de techniek ‘collaboration diagram’ uit UML. State diagrams geven de samenhang van interacties van een dienst op het koppelvlak van een organisatie met zijn buitenwereld, het zogenaamde protocol van die dienst (zie verder). Het begrip koppelvlak (Engels: interface) duidt het raakvlak tussen twee organisaties of componenten aan. State diagrams zijn ook af te leiden uit een Petrinet door het gedrag van een dienst op een koppelvlak te isoleren. Petrinetten zijn ook te gebruiken om ontworpen procedures te valideren op hun ondersteuning van een bepaald protocol. Dergelijke procedures, weergegeven met de techniek ‘activity diagrams’, specificeren tenslotte de interne verwerking van protocollen en ondersteunen daarmee meerdere state diagrams. Natuurlijk zijn er ook andere technieken met ondersteunende hulpmiddelen. UML is één van de meest gebruikte technieken voor ontwikkeling van softwarecomponenten en sluit daarom het best aan bij interactie-modellering.
Voor de uitwerking van een interactiemodel is het onderscheid tussen de begrippen ‘protocol’ en ‘procedure’ van groot belang. Een protocol heeft een relatie met een koppelvlak tussen twee organisaties. Een koppelvlak is als het ware de functionaliteit die twee organisaties gemeenschappelijk hebben. Elk koppelvlak is op zich weer een systeem met twee procedures die onderling volgens een protocol communiceren. Deze onderdelen van communicerende systemen zijn verder op te splitsen naar twee functies. Eén van die functies vormt een onderdeel van het koppelvlak, terwijl de andere er buiten ligt. Het gedrag van de eerste functie is te beschrijven met een externe procedure en dat van de tweede met een interne. De functie in het koppelvlak communiceert met een andere functie in het koppelvlak volgens een protocol. 
 
Dit boek richt zich op de verdere uitwerking van protocollen en externe procedures. Interne procedures gebruiken van externe procedures. Deze laatsten bieden een ‘service’ aan de eersten, waarbij deze service op verschillende manieren in te vullen is. Eén van de invullingen is als webservice; een andere is als schermen in een browser. Externe procedures zelf zijn ook op verschillende manieren vorm te geven. Een centrale en een gedistribueerde vormgeving zijn de twee uitersten. Figuur 6 toont de gedistribueerde implementatie, waar elk systeem of organisatie externe procedures zelf invult. Een centrale implementatie is bijvoorbeeld in de vorm van ASP (Application Service Provision).
De verschillende technieken spelen ook een rol in de communicatie met gebruikers. Deze zijn in vele gevallen niet in staat een model op hun juistheid te controleren, maar zijn zeer goed in staat hun wensen voor operationele gegevensuitwisseling te formuleren. Zij kunnen sequence diagrammen beschrijven, waarna ontwikkelaars vervolgens deze diagrammen omzetten naar een ontwerp. Gebruikers valideren vervolgens de gegenereerde sequence diagrammen tegen hun wensen. Mogelijkerwijs genereert een Petrinet voor de weergave van procedures meer sequence diagrammen dan gebruikers konden bedenken (zie ook figuur 5). Een oorzaak is dat gebruikers veelal denken in juiste operationele afhandeling, terwijl een model van informatieverwerking ook rekening moet houden met foutafhandeling en annulering.
Bij ontwikkeling van modellen is een top-down methode altijd het streven. In de praktijk hanteren ontwikkelaars veelal een bottom up benadering, zoals de vorige figuur ook aangeeft. Dit betekent ook dat eerst transactiebomen en gedrag met sequence diagrammen wordt gemodelleerd om daar vervolgens protocollen en procedures aan toe te voegen. Dit resulteert vervolgens in één Petrinet model voor formele verificatie. Deze werkwijze vormt het uitgangspunt bij de opbouw van de concepten voor interactiemodellering voor diensten. Dit hoofdstuk beschrijft daarom de verschillende concepten en hun onderlinge samenhang en modelleringstechnieken.
Er is een aantal manieren om protocollen en procedures te ontwikkelen, afhankelijk van de uitgangssituatie. Alle manieren hebben echter een aantal aspecten gemeenschappelijk. Wij bevelen aan als eerste een protocol te specificeren om vervolgens procedures te ontwikkelen. Elk protocol moet voldoen aan verschillende eigenschappen.Voorbeelden van eigenschappen zijn volledigheid en correctheid. Volledigheid vertaalt zich naar ondersteuning van de normale werkwijze en foutafhandeling, terwijl correctheid weergeeft dat er geen patstelling mag ontstaan (‘deadlock’).

1.6 Indeling van dit boek
Dit boek beschrijft alle onderdelen om te komen tot beveiligde en betrouwbare verwerking van business transactions in organisatienetwerken met internet technologie. Hoofdstuk 2 geeft een algemeen overzicht van software voor de inrichting van ICT binnen een organisatie, terwijl hoofdstuk 3 verder ingaat op integratiesoftware. De verschillende componenten voor integratie en hun configuratie voor een open eBusiness architectuur vormen de kern van dit hoofdstuk.
Hoofdstuk 2 en 3 zijn goed leesbaar voor degene die inzicht in integratiesoftware wenst te krijgen.
Gebaseerd op de functionaliteit van deze integratiecomponenten beschrijven de hoofdstukken 4 en 5 procesaspecten. Hoofdstuk 4 beschrijft de opbouw van protocollen voor de ondersteuning van business transactions. Deze protocollen leggen afspraken voor integratie vast en specificeren de interactietypen en hun onderlinge samenhang. Een generiek protocol voor onderlinge samenwerking van organisaties dient ter illustratie voor de uitwerking van protocollen. Ondersteuning van protocollen door interne procedures komen in hoofdstuk 5 aan bod, terwijl hoofdstuk 6 de data-aspecten van integratie toelicht.
Beveiliging vormt een apart aandachtspunt. Hoofdstuk 7 toont de verschillende beveiligingsdoeleinden en technieken, waarna hoofdstuk 8 de toepassing in standaarden toelicht.
Twee laatste onderwerpen die een grote rol spelen voor integratie, met name over organisatiegrenzen heen, vormen beheer (hoofdstuk 9) en het testen op de juiste ondersteuning van protocollen door organisaties (hoofdstuk 10). Beheer is gebaseerd op samenwerking tussen organisaties in verschillende domeinen. Testen is noodzakelijk om voorafgaand aan operationele uitwisseling te zorgen dat een toepassing goed werkt. Testen voorkomt fouten tijdens operationele uitwisseling en zorgt dat organisaties onafhankelijk van elkaar standaarden kunnen implementeren.
De bijlagen gaan in op de verschillende technieken als EDI, webservices en ebXML. Onze aanpak is gebaseerd op alle kennis opgedaan uit deze technieken. Om aan te sluiten bij investeringen in softwareontwikkeling, passen wij UML toe voor ontwerp van protocollen. Een aparte bijlage vat de gebruikte modelleringstechnieken van UML samen.