Voor de gebruiker is het al jaren duidelijk: De ideale bedrijfssoftware bestaat uit leveranciers-onafhankelijke ‘legosteentjes’. Met dat soort lego kun je namelijk elk bedrijfsproces ondersteunen, door de daarvoor benodigde steentjes plug-and-play op elkaar te klikken. Alle problemen rond flexibilisering en applicatie-integratie zijn daarmee verleden tijd. 

Markeert de introductie van het fenomeen web services het begin van het legotijdperk? Nee, maar het is wel de volgende stap in een langzame evolutie daar naar toe. Dit artikel verklaart het fenomeen web services, en legt het verschil uit tussen software-integratie op de 'traditionele' manier, via een centraal softwareplatform voor Enterprise Application Integration (EAI), en software-integratie via een business proces platform (BPP), dat gebruik maakt van web services technologie.

Bedrijfsprocessen veranderen voortdurend, bijvoorbeeld omdat bedrijven elkaar overnemen of omdat ze gaan samenwerken.  Die veranderlijkheid vraagt om dynamische bedrijfssoftware.ERP-leverancier SAP noemt het xApps, CRM-leverancier Siebel noemt het Universal Application Network, en Microsoft spreekt van DotNet (.Net).
Al die initiatieven beogen echter hetzelfde: om de starheid te doorbreken, moeten de bedrijfsprocessen het uitgangspunt gaan vormen bij industriële automatisering.

Daartoe kunnen de bedrijfsprocessen het beste worden gemodelleerd en onderhouden op een overkoepelend niveau. Dus, zonder te kijken naar de onderliggende applicatiesoftware voor Enterprise Resource Planning (ERP), Customer Relation Management (CRM) en Supply Chain Management (SCM). De afhandeling van een bedrijfsproces, bijvoorbeeld het accepteren van een order, verloopt dan als volgt: Een programmaatje dat dit bedrijfsproces beschrijft, activeert de daartoe benodigde delen van de onderliggende softwareapplicaties. Bijvoorbeeld eerst een module uit een systeem voor klantbeheer, en daarna de verkoopondersteuning uit een ERP-pakket.

Dynamiek
Een overkoepelend besturingssysteem dat de bedrijfsprocessen aanstuurt is echter niet voldoende. Ook de applicaties zélf moeten flexibeler worden, door ze op te bouwen uit zelfstandig functionerende en gestandaardiseerde ‘legosteentjes’. Met dit soort leveranciersonafhankelijke bouwstenen kun je dan plug-and-play netwerken bouwen, gebruik makend van delen van verschillende applicaties, om daarmee wisselende bedrijfsprocessen aan te sturen.

Nieuw is dit lego-ideaal, dat sinds kort wordt aangeduid met de term Enterprise Services Architecture (ESA), niet. Wél nieuw is, dat dit nu niet alleen door de klant, maar ook door de softwareleveranciers wordt beleden. Nog maar enkele jaren was het immers normaal om tijdens een ERP-implementatie te spreken van een ‘fixed scope’. Met andere woorden: wijzigingen in de bedrijfsprocessen waren tijdens (en zelfs na!) de invoering van het systeem taboe.

Een ander nieuw aspect is, dat bedrijven voortaan alleen díe softwarefunctionaliteit hoeven bij te kopen die echt nodig is. ‘Nieuwe bedrijfsprocessen kunnen ook worden ondersteund met bestaande software’, aldus Shai Agassi, lid van de raad van bestuur van SAP. Bij de introductie van J.D.Edwards 5 in juni vorig jaar meldde Onno Draaisma, algemeen directeur Benelux bij J.D.Edwards: ‘ERP-systemen leken tot voor kort op spaghetti. Omdat je die niet kunt ontwarren, moest je als klant altijd het gehele systeem kopen. Nu hoeft dat niet meer. Wij bieden nu de keuze uit driehonderd ingrediënten die je als macaroni kunt mixen.’

En er is nog meer nieuws: voor het eerst zijn alle softwareleveranciers het eens over de technologie die het lego-ideaal mogelijk moet maken. De nieuwe naam hiervoor, enterprise service architecture, verwijst naar een systeem waarbij softwarebouwstenen elkaars diensten via het web, dus via webservices, aanroepen.

Applicatie integratie
Het toepassen van webtechnologie voor software-integratie is niet nieuw. De gangbare softwarepakketten voor enterprise application integration (EAI) ondersteunen naast traditionele koppelingstechnologieën zoals het file transfer protocol en electronic data interchange, reeds geruime tijd XML en webservices.

Voorbeelden van EAI-systemen zijn IBM’s Websphere, Webmethods, Tibco, Seebeyond en Microsoft’s Biztalk Server. Evolutionair gezien kom je door het gebruik van EAI-software al een behoorlijk eind in de richting van het legosteen ideaal. Bij EAI worden alle softwareapplicaties echter met elkaar verbonden via één softwarepakket. Dit EAI-pakket fungeert dus als een ‘centrale legosteen’, waarop alle applicaties passen. De koppeling tussen een software-applicatie en het EAI-pakket komt tot stand via een connector. Die vertaalt de berichten uit de betreffende applicatie naar een standaardformaat en weer terug. De EAI-software vormt binnen het stervormige netwerk dat zo ontstaat het knooppunt, en leidt het berichtenverkeer in goede banen.

Het succes van de EAI-software heeft te maken met het feit, dat je bij zo’n systeem diverse connectoren krijgt meegeleverd. Gangbare bedrijfssystemen zoals SAP en Oracle kun je dus vrij gemakkelijk aankoppelen.

EAI is een mooi en bewezen concept, maar het is nog weinig dynamisch. De bedrijfsapplicaties praten immers alleen via het EAI-pakket met elkaar. Rechtstreekse communicatie tussen de software-applicaties, dus zonder EAI-software, is in theorie mogelijk door webservices te gebruiken. Dit betekent, althans op papier, de verwezenlijking van de legosteen-gedachte. Dit verklaart de ophef rondom dit onderwerp.

Revolutie
Een webservice oftewel webdienst is een website, die specifiek is ontworpen voor communicatie tussen softwareapplicaties. Bill Gates verwoordt dit in DotNet Magazine als volgt: ‘Het world wide web bracht een revolutie teweeg in de communicatie tussen mens en software. Dankzij XML en de daarop gebaseerde webdiensten herhaalt dit proces zich nu voor de communicatie tussen softwarepakketten’.

Het gebruik van webdiensten heeft tenminste twee voordelen boven de gangbare technieken voor software-integratie. Ten eerste kan een webdienst vanuit elke software-applicatie worden aangeroepen, hetzij via een bedrijfsintern netwerk, hetzij via het internet. Ten tweede kunnen computerprogramma’s die via een webdienst met elkaar zijn verbonden, meer dan alleen gegevens uitwisselen. Ze kunnen ook direct op elkaar reageren, bijvoorbeeld om de vraag: ‘wat is het voorraadniveau van product X’, te beantwoorden. Met webdiensten kun je dus gedistribueerd berekeningen (laten) uitvoeren, zie figuur 2.  Dit is noodzakelijk om zaken als collaborative planning en vendor managed inventory, onderdelen van supply chain management, mogelijk te maken.

Standaarden
De evaluatie van de verschillende standaarden rond het gebruik van webdiensten ligt in handen van het World Wide Web Consortium (W3C) en OASIS. Daarnaast bestaat er de Web Services Interoperability Organisation (WS-I). Die laatste club houdt zich onder meer bezig met het ontwikkelen van testgereedschappen.

De twee standaarden die beschrijven hoe een webdienst eruit ziet, worden inmiddels breed geaccepteerd. De eerste norm is het Simple Object Access Protocol (SOAP), een op XML gebaseerd communicatieprotocol waarmee je op afstand softwarefuncties kunt aanroepen.  De tweede norm is de Web Service Definition Language (WSDL), een taal waarmee wordt beschreven wat een webdienst doet.

Webdiensten vormen op zich echter niet meer dan een intelligente interface tussen twee softwaresystemen. Om tot software-integratie te komen is er extra software nodig. Een gebied waarop nog veel werk verzet moet worden is de reliability, denk hierbij aan protocollen voor het controleren van het berichtenverkeer. En verder ontbreekt nog een standaard voor het overkoepelende besturingssysteem, dat reeds werd genoemd in de inleiding. Met zo’n business proces management systeem (BPM) kun je aangeven welke webdiensten bij een bepaald bedrijfsproces horen, en wanneer de betreffende ‘legostenen’ in actie moeten komen. Bij de uitvoering van een bedrijfsproces speelt het BPM een softwareprogrammaatje af, dat de juiste webservices activeert. Bovendien zorgt het BPM ervoor, dat berichten worden vertaald naar een vorm die voor de aangeroepen webdienst begrijpelijk is.

Orkestratie
De taak die het BPM uitvoert – verbinden en vertalen - lijkt sterk op de functie van EAI-software. Een belangrijk verschil is echter, dat webservices niet via een specifieke interface met het BPM hoeven te worden verbonden. Ze kunnen zonder meer via het internet worden aangeroepen, net zoals iedereen informatie van welke website dan ook kan opvragen.

Bedrijven kunnen echter pas bedrijfsprocessen delen als hun BPM dezelfde taal spreekt. Daarom moet er een universele programmeertaal worden ontwikkeld waarmee je bedrijfsprocessen kunt modelleren, de zogenaamde orkestratiestandaard. Eén van de talen die meedingt bij de selectie van een orkestratiestandaard, is de Business Proces Execution Language for Web Services (BPEL4WS) van IBM en Microsoft. Daarnaast zijn nog ‘in de race’ de Web Service Choreography Interface (WSCI) van Sun, en de door een consortium van leveranciers ontwikkelde Business Proces Modelling Language (BPML).

DotNet
Microsoft’s nieuwe softwarearchitectuur, .Net, wordt meestal in één adem genoemd met webservices. Webdiensten kun je echter ook ondersteunen met andere platforms. Bijvoorbeeld met applicatieservers van Oracle, mits die zijn ontwikkeld op basis van Java 2 Enterprise Edition (J2EE). Dit laatste is een leveranciersonafhankelijke specificatie voor een gedistribueerde computeromgeving.  ‘Als je J2EE aanvult met softwareondersteuning voor webtechnologie, zoals bijvoorbeeld IBM doet, krijg je een architectuur die dezelfde scenario’s kan invullen als DotNet. Grote bedrijven zullen daarom te maken krijgen met beide concepten. Dat is echter geen probleem, want J2EE en .Net gaan goed samen’, aldus Fred Verboon. Hij is verantwoordelijk voor de introductie van Microsoft’s .Net in Nederland. ‘Het gebruik van .Net is geen vereiste voor het ontwikkelen van webdienst-applicaties. Dit kan ook door een SOAP-toolkit, Microsoft levert er één, toe te voegen aan een “oud” ontwikkelplatform. Gebruik je echter .Net, dan wordt het ontwikkelen van webdienstapplicaties stukken eenvoudiger. Een software-applicatie die je maakt met .Net, bestaat namelijk uit onafhankelijk functionerende objecten, zeg maar de legostenen in dit artikel. Wil je zo’n steen beschikbaar maken als webdienst, dan kun je dit met één druk op de knop realiseren’.

Volgens de marketingtaal van Microsoft, die inmiddels zelfs via de TV-reclame weerklinkt, is .Net bedoeld om ‘mensen, informatie, softwaresystemen en apparaten tot elkaar te brengen’. Dit maakt duidelijk dat Microsoft met de webdiensttechnologie niet alleen mikt op applicatie-integratie. Het softwarebedrijf voorziet een wereld waarin apparaten zoals PC’s, mobiele telefoons en koelkasten voortdurend on-line zullen zijn, en dan via het internet met elkaar zullen communiceren.

Luchtballon
Die wereld is echter nog ver weg, want in de praktijk worden webservices nog betrekkelijk weinig gebruikt.  Is dit fenomeen wellicht niet meer dan een luchtballon, die binnenkort wordt doorgeprikt?

Nee, want toepassingen zijn er wel. Hierbij gaat het vooral om reserverings- en besteldiensten bij reisbureaus, postorder- en internetbedrijven, boekhandels, overheids- en financiële instellingen, of om tracking-systemen waarmee klanten via het internet kunnen achterhalen wanneer hun product wordt afgeleverd.

Implementaties bij productiebedrijven zie je echter nog maar zelden.

Eén van de uitzonderingen is Stork N.V. Dit bedrijf liet onlangs een .Net applicatie bouwen door Microsoft-partner VX Company. De applicatie heet Working Capital Program en fungeert als een web-portaal. Dankzij dit portaal kan het werkkapitaal binnen de verschillende Stork-bedrijven met elkaar worden vergeleken. Dit gebeurt aan de hand van Key Performance Indicatoren voor uitgaande facturen, inkomende facturen en onderhanden werk. De verschillende ERP-systemen van Stork geven via een interface de benodigde gegevens door. 

Knooppunt Akzo Nobel Coatings implementeerde in 2001 een ‘messaging hub’. Dit is een knooppunt op het web, dat enerzijds de ERP-systemen van Akzo Nobel Coatings verbindt met die van haar toeleveranciers, en anderzijds de berichten vertaalt van het ene naar het andere formaat. Het betreffende project heet pAccess, oftewel ‘Procurement Akzo-Nobel Coatings Common Electronic Sourcing Support’. Als basis voor het systeem diende BizTalk, het EAI-pakket van Microsoft.

Jouke Eijssen, supply chain projectmanager bij Akzo Nobel Coatings: ‘Met pAccess wilden we twee zaken realiseren. Ten eerste wilden we één centraal contactpunt opzetten voor de gegevensuitwisseling met onze toeleveranciers. Ten tweede wilden we daarbij een laagdrempelige webinterface opzetten, die het onze toeleveranciers mogelijk maakt om zonder kosten elektronisch met ons te communiceren.’

Naast een website omvat pAcces een aantal internetopties die directe communicatie tussen ERP-systemen mogelijk maken. ‘De manier waarop dat gebeurt komt technisch overeen met het gebruik van webdiensten, hoewel wij formeel geen gebruik maken van het SOAP-protocol’.

Twee typen inkoopprocessen kunnen via pAcces worden ondersteund. De eerste optie is e-catalog. Hierbij bestellen Akzo Nobel-medewerkers producten uit een aantal elektronische catalogi.

De tweede mogelijkheid is vendor managed inventory (VMI). Toeleveranciers controleren dan via pAccess, of de voorraad van hun product bij Akzo Nobel Coatings nog voldoende is, en vullen die voorraad zonodig aan.  Bij het realiseren van VMI via pAccess zijn inmiddels al twintig fabrieken van Akzo Nobel Coatings en dertig toeleveranciers betrokken.

‘Nu pAcces twee jaar in de lucht is worden de voordelen voor ons zichtbaar. Minder voorraden in de keten, minder transportkosten, en een veel eenvoudiger administratie’, besluit Eijssen.

Onvolwassen
‘De toepassingen van webdiensten zullen voorlopig beperkt blijven tot niet-kritische bedrijfsprocessen, want de techniek is nog onvolwassen. Niettemin is deze technologie een blijvertje’, aldus wetenschapper Marc Lankhorst. Bij het Telematica Instituut onderzoekt hij de mogelijkheden van nieuwe computerarchitecturen, zoals .Net van Microsoft.

ERP leverancier SAP biedt via het integratieplatform NetWeaver ondersteuning voor de implementatie van webservices. Robbert Haakmeester, productconsultant webportals bij SAP Nederland: ‘Een van de grootste uitdagingen bij het succesvol maken van webservices, is het geschikt maken van bestaande systemen en applicaties voor deze nieuwe vorm van gegevensuitwisseling. Dit gaat gepaard met hoge kosten. Dit is, samen met de onvolwassenheid van de technologie, een van de belangrijkste redenen voor bedrijven om terughoudend met de invoering van webservices om te gaan. Webservices worden pas een succes, als ze 
deel uitmaken van een totaalvisie voor integratie. Het is niet voldoende als applicaties goed kunnen samenwerken. Het is minstens zo belangrijk, dat de gebruikers goed kunnen samenwerken met de applicaties. Gebruikers-specifieke interfaces spelen daarbij een belangrijke rol.’

Bij de introductie van het begrip webdiensten lag het accent op bedrijfs-externe software-integratie. Op dit moment is verschuift de aandacht echter naar software-integratie bínnen bedrijven. Door hierbij webdiensten te gebruiken kan dit flexibeler en goedkoper, zo is het idee. En dat is in deze tijd van economische malaise zeer welkom.

Enterprise Service Bus
Een nieuwe categorie softwareleveranciers waaronder Software AG, Spiritsoft, Kenamea en Sonic speelt hierop in, door het aanbieden van Enterprise Service Bus (ESB) systemen. ESB is een soort light-versie van de eerder genoemde EAI-software, waarbij er á priori van uit wordt gegaan dat webdiensttechnologie wordt gebruikt voor de applicatie-integratie. De standaardinterfaces voor het aankoppelen van applicaties zoals SAP en Oracle, zoals die in EAI-systemen zitten, zijn derhalve geen onderdeel van ESB.

ESB lijkt vooral geschikt voor omgevingen waarbij integratie met legacy-systemen geen grote rol speelt. ESB-leveranciers claimen niet alleen goedkoper te zijn dan EAI-leveranciers (dit klopt), maar ook dat het gemakkelijker is om hun systemen onderling te verbinden omdat ze volgens een standaardmethode (de webdiensttechnologie) werken. Die laatste claim lijkt echter twijfelachtig. Immers, zolang er geen orkestratiestandaard is voor het ‘afspelen’ van bedrijfsprocessen via webdiensten, zal elk ESB-pakket hiervoor zijn eigen methode hanteren.