Integratie met voorbedachten rade

Augustus 2010 - Een belangrijk aspect binnen een integratieproject en Service Oriented Architecture (SOA) is het streven naar interoperabiliteit. Interoperabiliteit is de mogelijkheid of mate waarin een systeem in staat is om gegevens uit te wisselen met andere systemen. Of met andere woorden interoperabiliteit geeft aan in hoeverre systemen met elkaar kunnen communiceren en daarmee in zekere zin compatibel zijn.

De meeste organisaties beschikken over meerdere informatiesystemen die samen de gewenste ondersteuning aan het bedrijf moeten leveren. Daarbij kan het gaan om bedrijfsprocessen die zich niet houden aan de “grenzen” van een informatiesysteem of om rapportages op basis van gegevens die nou eenmaal verspreid over verschillende systemen zijn opgeslagen. De tijd dat we de illusie hadden dat één pakket al onze problemen zou oplossen ligt ver achter ons. Geen enkele organisatie ontkomt nog aan het integreren van informatiesystemen.

In de praktijk blijkt het laten samenwerken van informatiesystemen lang niet zo eenvoudig als verwacht of gehoopt. De aansluiting levert zowel op functioneel als op technisch gebied diverse uitdagingen. Als voorbeeld aan de functionele kant: gegevens met een bepaald label in de ene applicatie kunnen een heel andere betekenis of gebruik hebben in een andere applicatie. Op het technische vlak biedt bijvoorbeeld het niet of niet goed gebruiken van (open) standaarden een grote uitdaging bij implementaties.

In dit Whitebook worden een aantal richtlijnen beschreven gebaseerd op onze ervaringen in de afgelopen jaren met integratieprojecten. Interessant voor iedereen die bij een integratieproject betrokken is.

Vooraf plannen

Integratie werkt als je het van tevoren plant. Als bij het invoeren van een pakket of maatwerksoftware niet vooraf wordt nagedacht over samenwerking met andere systemen dan is dat een groot risico en niet alleen voor het project. Er zijn vele voorbeelden bekend van de invoering van pakketten en maatwerksoftware waarbij vooraf niet naar de samenwerking met andere reeds in productie zijnde software is gekeken. Dit leidt voor organisaties tot problemen met hun gegevensbeheer: gegevens die dubbel worden opgeslagen, een klantbeeld dat op basis van een groot aantal gegevensbronnen moet worden geconstrueerd en inconsistente gegevens.

Vooraf, of aan het begin van een project, moet worden vastgelegd welk systeem primair verantwoordelijk is voor welke gegevens en voor welke functionaliteit. Daarnaast moet worden vastgelegd op welke wijze gegevens en functionaliteit door de andere applicaties benaderd kan en mag worden. Het is onwenselijk dat tegen het einde van een project pas duidelijk wordt dat de klantgegevens die al in applicatie X beschikbaar zijn toch maar gebruikt moeten worden. Het is er waarschijnlijk dat er dan geen ruimte meer is om een dergelijke integratie te realiseren, met alle consequenties van dien.

Werken onder architectuur

In de architectuur worden best practices expliciet gemaakt. Het vastleggen van randvoorwaarden en richtlijnen in een architectuur beperkt de oplossingsruimte voor ontwerpers en ontwikkelaars. Door het toepassen van architectuur worden keuzes meer consistent. Door consequent deze consistente richtlijnen toe te passen, wordt het beheer van software eenvoudiger en wordt het makkelijker om mensen in te werken.

De ervaring leert ook dat door het toepassen van architectuur keuzes meer bewust worden gemaakt. In de gevallen waarbij niet meteen duidelijk is hoe een probleem moet worden aangepakt, wordt gekeken of deze onder de richtlijnen valt. Is dat niet het geval, dan wordt binnen de principes en richtlijnen een oplossing gevonden. Daarvoor zal of in de architectuur of in de implementatie een aanpassing moeten worden gemaakt. De snelheid waarmee dergelijke keuzes kunnen worden gemaakt neemt toe door de aanwezigheid van het referentiekader dat de architectuur biedt. Dit komt de snelheid van het realisatieproces ten goede.

Incrementele aanpak

Kies bij het opstellen van de architectuur voor een incrementele aanpak. Als je probeert een architectuur van tevoren volledig vast te leggen, dan zul je er tegen aan lopen dat het beslag op mensen en middelen zeer groot is, zonder dat daar op korte termijn concrete resultaten tegenover staan. Door het team te richten op de aspecten die je nu nodig hebt, zal een beter bruikbare architectuur ontstaan. Dit zal er ook voor zorgen dat de acceptatie van de architectuur eenvoudiger is. De meeste mensen nemen richtlijnen die ze meteen kunnen toepassen makkelijker aan, dan richtlijnen die ze voorlopig niet nodig hebben.

In een alles-of-niets aanpak bij het opstellen van een architectuur, ligt de feedback tussen het opstellen van de richtlijnen en het gebruik ervan zover uit elkaar dat dit praktisch niet meer bruikbaar is. Door deze gebrekkige koppeling wordt de architectuur een dood in plaats van een levend document. De toepasbaarheid van een dergelijke aanpak laat dan te wensen over.

Open Standaarden

Door het gebruik van open standaarden neemt de interoperabiliteit tussen de verschillende systemen toe. Er zijn geen barrières voor het gebruik van open standaarden. Daarnaast neemt ook de afhankelijkheid van specifieke aanbieders en specifieke technologieën af. Om deze reden neemt ook de toekomstvastheid toe van interfaces die zijn vastgelegd in open standaarden.

Voor het specificeren van webservices worden de open standaarden XSD en WSDL gebruikt. Een XSD wordt gebruikt om de structuur van een XML bericht vast te leggen. In het geval van een integratie gebaseerd op webservice wordt in een XSD de structuur van de berichten die worden uitgewisseld vastgelegd. In een WSDL wordt de interface van een webservice vastgelegd.

Zoals op internet gangbaar is worden ook voor de uitwisseling van berichten open standaarden gebruikt. Standaarden op het niveau van HTTP, TLS en UTF-8 vallen buiten de scope van dit Whitebook.

Voor de uitwisseling van de berichten wordt SOAP gebruikt. SOAP is een open standaard gebaseerd op XML voor het uitwisselen van gestructureerde berichten.

Contract First aanpak

Gebruik bij het specificeren en realiseren van de integratiepunten een Contract First aanpak. In deze aanpak wordt eerst vastgelegd welke functies nodig zijn en onder welke voorwaarden deze gebruikt kunnen worden, los van de implementatie. Daarbij worden ook de berichten gespecificeerd die gebruikt worden om de beschreven functionaliteit aan te roepen. Hierdoor ontstaat een interface die ontkoppeld is van de implementatie en toekomstvast is.

Het biedt duidelijkheid als vooraf expliciet aangegeven wordt wat de grenzen van een systeem zijn en hoe de functionaliteit en data binnen een systeem benaderd kan worden. Het succes en gebruik van een webservice voor integratie hangt meer af van de beschrijving van de interface dan van de implementatie. Dat alleen al is een voldoende argument voor een Contract First aanpak.

In een Contract First aanpak worden in ieder geval de volgende stappen doorlopen:

1. Modelleer data in XSD files – Welke gegevens moeten worden uitgewisseld en welk type hebben de verschillende data elementen. Door typen te definiëren vóór gestart wordt met de implementatie worden deze en de ervan afgeleide berichten taalonafhankelijk;
2. Modelleer de berichten in XSD files – Welke berichten worden gebruikt om de functionaliteit van de operaties te gebruiken. Deze stap kan niet los gezien worden van de volgende;
3. Modelleer de service interface in een WSDL file – Vastleggen van de operaties die worden aangeboden door de webservice en hoe de berichten worden uitgewisseld;
4. Genereer code op basis van de WSDL.

In de voorgaande stappen wordt impliciet aangegeven dat binnen een Contract First aanpak code op basis van de WSDL wordt gegenereerd en niet een WSDL op basis van code wordt aangemaakt.

Een aspect dat nog niet aan de orde is gekomen is dat een Contract First aanpak het mogelijk maakt dat (deel)systemen kunnen evolueren zonder dat andere applicaties die er gebruik van maken daar direct hinder van ondervinden. Dit maakt het versiebeheer ook een stuk eenvoudiger.

Het voordeel van een verbeterde interoperabiliteit van de Contract First aanpak kan iets ten koste gaan van de productiviteit. Dat kan niet alleen tijdens de beheerfase worden goed gemaakt, maar ook doordat andere teams die de andere kant van de koppeling realiseren niet hoeven te wachten tot de functionaliteit volledig is voltooid.

Afsluiting

Elke organisatie krijgt vroeger of later met een integratieproject te maken, op welke schaal dan ook. In dit Whitebook zijn de volgende richtlijnen gegeven die de kans op een succesvol integratieproject aanzienlijk verhogen:

1. Integratie werkt als je het van tevoren plant;
2. Werk onder architectuur;
3. Gebruik voor het opstellen van de architectuur een incrementele aanpak;
4. Gebruik open standaarden voor het inrichten van de interfaces;
5. Kies voor een Contract First aanpak.