Eerst was er gewoonweg applicatie-integratie. Twee applicaties, die totaal onafhankelijk van elkaar ontwikkeld waren, moesten alsnog gekoppeld worden om gegevens en instructies onderling uit te kunnen wisselen. Over het algemeen werd hiervoor iets in elkaar geflanst. Het motto was meestal: als het maar werkt!
Daarna volgde een grotere uitdaging: bedrijfsbrede applicatie-integratie. Tientallen applicaties moesten geïntegreerd worden. Veel bedrijven ontdekten bijvoorbeeld bij het ontwikkelen van websites dat hun gloednieuwe systeem gekoppeld moest worden aan het voorraadsysteem en het factureringssysteem, die beide gebouwd waren in de tijd van Julius Ceasar, met dat afgrijselijke Cics en op dat nog huiveringwekkendere mainframe. Het aanschaffen van bijvoorbeeld een crm-pakket (customer relationship management) vereist altijd integraties met vele operationele systemen. Even iets in elkaar flansen is er ineens niet meer bij.
U bent misschien nog niet klaar, maar de rest van de wereld is reeds aanbeland bij de volgende fase. Applicaties worden gekoppeld over de grenzen van onze organisaties heen. De populaire term die hiervoor gebruikt wordt is b2b-applicatie-integratie (business-to-business). Het voorraadbeheerssysteem wordt bijvoorbeeld gekoppeld aan dat van onze toeleverancier. Een ander voorbeeld is die waarbij onze website, bij het opstellen van offertes, een website van één van onze partners online raadpleegt.
Al deze vormen van integratie kunt u zelf bouwen. Net zo goed als dat u uw eigen databaseserver en besturingssysteem zou kunnen bouwen. Maar het kan misschien geen kwaad om eens te kijken naar de nieuwe generatie producten voor applicatie-integratie, waaronder Bea Systems’ Wlpi, e-Xcelon’s B2B, IBM’s MQSeries Integrator, Microsofts Biztalk, Silverstream x-Commerce en Webmethods’ B2B.
Globaal is de werkwijze van deze producten identiek. Er is een ontwerp- en een verwerkingsomgeving. In de ontwerpomgeving, die vaak grafisch is, worden de gegevensstromen tussen applicaties in kaart gebracht. Tevens is aan te geven wat er met die gegevensstromen moet gebeuren. Is het bijvoorbeeld nodig transformaties, conversies en, berekeningen uit te voeren? Integriteitregels zijn te specificeren en men kan aangeven hoe incorrecte gegevens afgehandeld moeten worden. In feite worden de applicaties op een werkstroomachtige wijze aan elkaar gekoppeld.
Uiteindelijk zal veel cruciale bedrijfslogica in deze omgevingen vastgelegd worden. Helaas is in alle producten voor een leverancierafhankelijke taal gekozen. Zelfs leveranciers die erom bekend staan standaarden te volgen, hebben zelf iets moeten definiëren. De reden hiervoor is simpel: op dit terrein bestaat namelijk nog geen standaard. De organisatie genaamd Bpmi.org (Business Process Management Initiative) is wel bezig hiervoor een standaard te ontwikkelen. Het goede nieuws is dat veel van de genoemde leveranciers betrokken zijn bij deze organisatie.
De verwerkingsomgeving van de integratieproducten vormt het werkpaard, ofwel de motor. Deze omgeving, deels gegenereerd vanuit de ontwerpomgeving, is verantwoordelijk voor het daadwerkelijk overhevelen van de gegevens en instructies tussen de applicaties. In deze omgeving zit veel technologie verwerkt. Ze moeten ten eerste technologie bevatten om gegevens heen en weer te bewegen. Dit kan op basis van bijvoorbeeld message queuing, of met behulp van componentenbussen, zoals COM, Java RMI of Corba, of met applicatieservers. Bij de aanschaf van een dergelijk product is het van belang dat zijn schaalbaarheid, beschikbaarheid en robuustheid getest worden; vergelijkbaar met de eisen die we aan database- en applicatieservers stellen.
Ten tweede wordt bij deze producten meestal voor een hub-oplossing gekozen. In plaats van alle applicaties onderling te koppelen (wat kan leiden tot een onbeheersbaar spinnenweb aan koppelingen) zijn alle applicaties aan de centrale verwerkingsomgeving gekoppeld.
En een derde technologisch gebied heeft betrekking op het ondersteunen van adapters. Adapters maken koppelingen mogelijk met oudere applicatieservers zoals Cics, message-queuing producten als Msmq en Oracle AQ, erp-systemen als SAP en Peoplesoft, crm-producten en nog veel meer. Wederom geldt dat u deze adapters zelf kunt bouwen, maar het leven is veel eenvoudiger als u ze direct kunt inzetten.
Indien uw integratieproduct op Java is gebaseerd, is voor de J2EE-omgeving versie 1.3 een standaard adapter-interface ontwikkeld, genaamd JCA (Java Connection Architecture). Dit moet de ontwikkeling van adapters versnellen. Leveranciers als Bea Systems en Silverstream hebben reeds ondersteuning aangekondigd.
Het wordt tijd dat we onze gereedschapskist, die reeds gevuld is met onder andere programmeertalen, case-tools en databaseservers, uitbreiden met deze integratieproducten. De hedendaagse wensen vanuit onze bedrijven leiden vaak tot applicatie-integratie. Ga niet elke keer wat in elkaar flansen, maar kies een oplossing op strategisch niveau en vul dat in met een applicatie-integratie-product.
Applicatie-integratie is zeker geen vluchtige trend. Het is een behoefte ontstaan vanuit het bedrijf zelf (en niet vanuit de it-afdeling) en veel organisaties zullen naar oplossingen moeten gaan kijken. Maar pas op, het feit dat de technologie klaar en beschikbaar is, impliceert nog niet dat uw organisatie er klaar voor is. Integratieprojecten falen soms vanwege dwarsliggende bureaucratie (maar we doen het al twintig jaar zo!), decentrale bedrijfsculturen (ik wil niets met die andere club te maken hebben!), of vanwege privé-agenda’s (dit project is misschien wel goed voor het gehele bedrijf, maar niet voor mijn eigen afdeling!). De technologie van uw product zal dan niet het struikelblok zijn, maar eerder uw eigen mensen of uw eigen organisatie. Houdt daar rekening mee.
Rick van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken. Hij is gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
