Applicatie Integratie is de sleutel om maximale waarde te halen uit de hoge investeringen gedaan in aankoop en ontwikkeling van softwareapplicaties.

Uit verschillende schattingen blijkt dat tussen de 30 en 50% van de implementatiekosten van een applicatie besteed wordt aan het integreren met andere applicaties.

Het mag dus duidelijk zijn dat enige significante reductie van de kosten voor integratie niet alleen zal resulteren in een reductie van kosten, maar ook een versnelling van de doorlooptijd voor oplevering van een nieuw systeem zal opleveren.

---

Dit artikel bevat een analyse die ten tijde van publicatie (2002) actueel was. De wereld verandert, dus sommige stellingen in dit artikel kunnen achterhaald zijn. Desalniettemin bevat het artikel vele elementen die nog steeds het lezen meer dan waard zijn.

---

Spagetti of applicatie-integratie?

We zien op dit moment dat het aantal systemen waarmee een gemiddelde applicatie moet communiceren erg hoog geworden is.

Ook is de onderlinge afhankelijkheid tussen deze verschillende systemen, door veranderde business eisen, erg complex geworden. Bijna iedereen kent wel de term ‘spaghetti-code’ als het gaat om applicaties die verschillende malen zijn gepatched en geüpgraded. Echter dit probleem wordt nog vele malen groter als we al die spaghetti-codes nu ook nog eens met elkaar laten integreren en communiceren. Dit macrokosmische probleem wordt het probleem van de applicatie- integratiespaghetti genoemd. De interapplicatiespaghetti is het gecompliceerde netwerk van verbindingen dat de verschillende applicaties, programma’s en databases met elkaar verbindt middels de ondernemings- en e-business netwerken. Een voorbeeld van deze spaghetti is gegeven in figuur 1.

Figuur 1. Applicatie-integratiespaghetti.

Om die reden zal het ook geen verbazing meer wekken dat applicatie-integratie door vele ondernemingen als een ondernemingsrisico gedefinieerd wordt. Daarom is applicatie integratie door vele ondernemingen verheven tot een strategisch IT-gebied.

Bijna ieder systeem kent een vorm van applicatie-integratie. Het is eerder uitzondering dan regel, dat een commercieel beschikbare applicatie 100% van de behoefte voor een bepaalde bedrijfsfunctie afdekt. Laat staan dat er een applicatie bestaat die alle bedrijfsprocessen van een (middel)grote onderneming zal afdekken. Voorheen werd de oplossing gezocht in maatwerksoftware. Nu er is gebleken dat ondernemingen, markten en ondernemingsmodellen dynamisch en niet statisch zijn, blijkt maatwerk van gehele systemen ook geen oplossing te zijn. Het gebruik van standaardpakketten was een eerste stap in de richting om beter te kunnen inspelen op de dynamiek van de omgeving. Echter de koppeling tussen de verschillende standaardapplicaties blijkt in veel gevallen nog traditioneel ‘statisch’ gemaakt te worden. Doordat standaardapplicaties ook mee evolueren, blijken deze ‘statische koppelingen‘ niet altijd zo onderhoudsvriendelijk te zijn. Moderne applicatieintegratie heeft tot doel de kloof die er ligt tussen de behoefte vanuit de (dynamische) bedrijfsprocessen en het aanbod van (dynamische) standaardsystemen te dichten.

Het is belangrijk te onderkennen dat de aandacht voor applicatie-integratie niet tijdelijk is. Zoals gezegd, de wereld is en blijft dynamisch. Daarom is het zo goed als onmogelijk dat (specialistische) applicatieleveranciers al deze veranderingen kunnen voorspellen, laat staan erop kunnen anticiperen. Daarom komt applicatie-integratie niet alleen bij een implementatietraject naar voren.

Ook gedurende het operationeel traject van een informatiesysteem zullen de integratievraagstukken blijven opkomen. Dit door veranderingen in de eisen van de markt en onderneming, maar dit zal ook worden gedreven door veranderende technologie. Een voorbeeld hiervan is dat er vijf jaar geleden over real-time integratie voornamelijk gesproken werd en het slechts mondjesmaat werd toegepast. Vandaag de dag is dit een doodgewone eis in iedere RFQ of RFP.

De technische levensduur van een willekeurige standaardapplicatie is vaak technologisch beperkt tot circa drie jaar. Aan de andere kant ligt de economische levensduur van de totale toepassing vaak tussen de vijf en de zeven jaar. Om mee te kunnen blijven draaien, moeten de verschillende componenten en applicaties tussentijds zonder teveel meerkosten geüpgraded kunnen worden. Dit houdt in dat een integratieoplossing mogelijkheden moet bieden om eenvoudig aanpassingen te kunnen realiseren. Ook moet het aantal koppelingen naar systemen makkelijk uitbreidbaar zijn. Tot slot dient de integratieoplossing een duidelijk onderscheid maken tussen de functionele c.q. businesseisen, de implementatie-eisen en de onderhouds- c.q. IT-eisen.

Integratiepatronen

Om applicatie-integratie beter te kunnen begrijpen moeten we eerst inzicht verkrijgen in de aard van de integratieproblematiek. Dit doen we aan de hand van de meest algemene integratiecases.

Gezond verstand zegt dat de verschillende typen integratieproblemen ook een verschillende integratiebenadering nodig hebben. Bijvoorbeeld, het integreren van een retail point-of-sales systeem met een warehouse management systeem, dat gebruikmaakt van synchrone communicatiemethoden, vraagt een andere benadering dan het integreren van een inkoopordersysteem met verschillende supply chain partners, die gebruik maken van asynchrone Electronic Data Interchange (EDI).

Als we deze en andere cases bekijken, dan zien we dat een beperkt aantal integratiepatronen domineert. Deze patronen hebben we in figuur 2 weergegeven.

Figuur 2. Integratiepatronen.

Uit de figuur blijkt dat de basisvormen van applicatieintegratie zijn:

1. Monolithic
2. Data consistency
3. Multi-step process
4. Composite activity
5. Autonomous distribution

Verder zien we dat er een onderscheid gemaakt wordt tussen synchrone en asynchrone communicatie. De twee begrippen en de verschillende vormen zullen in het navolgende worden toegelicht.

Asynchrone versus synchrone communicatie

Binnen systemen voor applicatie-integratie worden twee basismechanismen voor de onderlinge communicatie gebruikt: synchrone en asynchrone communicatie. Bij asynchrone communicatie wordt de informatie tussen één of meerdere verschillende systemen asynchroon bewogen. De applicatie-integratiesoftware is in staat om zich als het ware te ontkoppelen van de bron- of doelsystemen. Het gevolg is dat de verschillende applicaties, om de informatie te verwerken, niet afhankelijk zijn van de andere aangesloten systemen.

Het primaire proces bij asynchrone communicatie is als volgt.Het bronsysteem plaatst een bericht in een wachtrij. Vervolgens wacht dit systeem op de afhandeling en reactie van het doelsysteem (of de doelsystemen). Het bronsysteem kan echter wel doorgaan met andere activiteiten. Dit geeft direct het belangrijkste voordeel aan: de integratielaag blokkeert niet de applicatie in haar (andere) werkzaamheden. Doordat de systemen ontkoppeld zijn, kan de applicatie altijd doorgaan met haar werk, ongeacht de toestand van de andere applicaties.

In tegenstelling hierop, bij synchrone communicatie is de integratielaag volledig en direct gekoppeld met de andere applicaties. De andere applicaties zijn in dit model te zien als een verlengstuk van de bronapplicatie. De bronapplicatie dient dus te wachten totdat de doelapplicatie de informatie verwerkt heeft en een reactie terug heeft gegeven. Het nadeel van het synchrone model is dan ook de min of meer vaste koppeling tussen de verschillende applicaties. Omdat de applicatie afhankelijk is van de integratielaag, worden problemen in deze integratielaag, zoals netwerk- en doelserverproblemen, direct het probleem van de bronapplicatie. Deze applicatie kan niet verder met het verwerken van de informatie. Daarnaast blijkt dat de synchrone communicatie binnen een netwerk omgeving bandbreedte consumeert. Dit omdat er verschillende vormen van uitwisseling van informatie via het netwerk nodig zijn om een informatieverzoek af te handelen.

Het verschil laat zich het beste illustreren met een alledaags voorbeeld. Iedereen verstuurt wel eens een e-mail, een fax of belt iemand op. Hiervoor wordt gebruik gemaakt van het internet of het telefoonnet als transportmedium. Het e-mail proces kunnen we typeren als een asynchroon proces en werkt als volgt: je typt een e-mail, selecteert de geadresseerde en drukt op de zendknop.

Jouw computer zal, als het niet vast aan het internet verbonden is, contact zoeken met het internet (de integratielaag). Vervolgens wordt het bericht op de elektronische snelweg geplaatst en zal automatisch zijn weg vervolgen, totdat de ontvangende partij het weer oppakt.

Jouw proces is echter afgerond op het moment dat er op ‘send’ gedrukt is. Je kunt dus verder gaan met andere werkzaamheden, al dan niet gebruikmakend van de integratielaag, het internet.

Nu gaan we datzelfde bericht op een meer conventionele wijze versturen. We sturen het eerder geschreven bericht naar de faxprinter en faxen het naar de ontvangende partij. Hier is de integratielaag het netwerk van de KPN en dient er contact gemaakt te worden met de ontvangende partij. De ontvangende fax dient vrij te zijn en het netwerk toegankelijk. Gedurende het versturen van het bericht is jouw faxmachine en de bijbehorende telefoonlijn volledig bezet. De snelheid van verwerking is afhankelijk van het ontvangende systeem. Dit is een typisch voorbeeld van passieve synchrone communicatie.

Een derde manier om dit bericht naar de ontvanger te brengen laat zich illustreren door het telefoneren. Hierbij zijn beide (of zelfs meerdere) partijen direct met elkaar verbonden. Een respons kan door alle partijen op iedere moment gegeven worden. De ontvangende en de zendende partij kunnen elkaar afwisselen. Dit is een voorbeeld van interactieve synchrone communicatie.

Een vierde voorbeeld is de teleconferentie. De deelnemers zijn via verschillende telefoonlijnen met elkaar in contact. Gesprekken kunnen gelijktijdig met verschillende personen op verschillende locaties plaatsvinden. Deelnemers kunnen in principe onbeperkt afhaken en toetreden.

Het lijkt voor zich te spreken dat de nadelen van synchrone communicatie, vooral voor B2B-communicatie, groot zijn. Het asynchrone model zal daarom vaak de voorkeur genieten. Toch zien we weer een verschuiving naar interactieve synchrone communicatie. Applicaties, systemen en gebruikers communiceren interactief in steeds wisselende samenstelling en in wisselende patronen met elkaar. Was er eerst een duidelijk verschil tussen het bron- en het doelsysteem, de voortdurende interactie maakt dat onderscheid steeds moeilijker. Het doelsysteem kan ineens bronsysteem worden en vice versa. In het voorbeeld van de teleconferentie kunnen we zien dat dit heel gecompliceerd kan zijn. De complexiteit door interactie en vele (wisselende) deelnemers geeft, in combinatie met de bekende nadelen van synchrone communicatie, natuurlijk nieuwe uitdagingen voor applicatie-integratie.

Het monolithisch patroon

Monolithische systemen zijn zelfstandige systemen, meestal vanuit traditionele programmeertechnieken opgebouwd. Als er al integratie binnen dit model bestaat, vindt dit bij een typische implementatie plaats door binnen de applicatie ontwikkelde interfaces. De interfaces worden in dit geval gestart en beheerst door binnen de applicatie bestaande logica. Bijvoorbeeld, een Order Management Systeem (OMS) stuurt gevalideerde data direct naar een magazijn/locatiesysteem. Dit zal praktisch gesproken een door het OMS gegenereerde ‘flat-file’ zijn, die rechtstreeks wordt opgevangen door het magazijn/locatiesysteem.

Binnen het monolithische patroon zijn de verschillende modules van de verschillende applicaties vast met elkaar verbonden. Alhoewel deze benadering in beginsel goedkoper lijkt dan bij de andere patronen, is het door de gecumuleerde kosten van iedere aanpassing, upgrade en vervanging vele malen duurder. Een benchmark met middleware systemen over de levenscyclus van de applicaties gezien, wordt weergegeven in figuur 3.

Figuur 3. Benchmark op cost-ofownership tussen conventionele (monolithische) integratie en middleware oplossingen (bron: MARCGS).

Bij deze vorm van integratie zijn over het algemeen softwaretechnische wijzigingen nodig in alle betrokken applicaties. Dit heeft weer tot gevolg dat er gespecialiseerde kennis noodzakelijk is en dat implementatiecycli langer zijn. De monolithische integratiebenadering kent zijn oorsprong vanuit de maatwerkoplossingen voor softwareapplicaties. Vele grote ondernemingen hebben hun eigen oplossingen gebouwd en zitten nu met grote IT-afdelingen die deze oplossingen, vaak gebaseerd op oudere programmeermethoden, moeten onderhouden. In de aanloop tot het nieuwe millennium (Y2K-problematiek) en de overgang naar de Euro, zijn vele van deze systemen vervangen door standaardsoftware. De monolithische benadering is in die overgang mede vervangen door integratiebenaderingen gebaseerd op middleware oplossingen. Binnen de huidige generatie middleware oplossingen overheersen momenteel de volgende drie integratiepatronen.

Het data consistency model

We spreken van het data consistency model als de applicaties en systemen hun onderlinge gedragingen coördineren door uitwisseling van informatie via gemeenschappelijke databases. Belangrijke eis rondom deze gemeenschappelijke databases en de uitwisseling van informatie is dat de data consistent is en blijft.

Bijvoorbeeld, een applicatie dat operationele data kan extraheren, samenvatten en dupliceren, kan daardoor bepaalde managementinformatie en ondersteunende systemen voeden. Deze onderliggende systemen worden op hun beurt weer gebruikt om operationele beslissingen in andere units te ondersteunen.

Het data consistency model is een goede vorm van integratie, indien we spreken over relatief autonome systemen die informatie per batch kunnen verwerken en waarbij asynchrone communicatie tussen de deelnemende applicaties acceptabel is. Dit integratiepatroon is verder zeer goed indien informatie als bulk verwerkt dient te worden of indien er herhaaldelijk gebruikgemaakt wordt van dezelfde informatie uit een van de applicaties.

Het multistep proces model

Het multi-step proces model, is het model waarbij verschillende applicaties communiceren door een asynchrone uitwisseling van transacties waarbij steeds een bepaalde volgorde wordt aangehouden en de blauwdruk van een business proces de volgorde van de stappen aangeeft. Bij een multi-step proces, in bijvoorbeeld een inkoopsysteem, vindt het creëren van het aanvraagformulier, de goedkeuring van de inkoopaanvraag en productie en uitgifte van de inkooporder plaats in een reeks van gecoördineerde transacties. Multi-step integratie is een goede oplossing voor de meeste toepassingen waarbij integratie van verschillende bedrijfsprocessen, over verschillende applicaties heen, een belangrijke rol speelt.

Een goed voorbeeld hiervan is de integratie van verschillende ‘best-of-breed’-applicaties gebruikt in de verschillende bedrijfsonderdelen. Met ‘best-of-breed’ wordt hier bedoeld dat een bedrijf voor het specifieke proces een applicatie kiest die het best aan de specifieke kenmerken van het proces voldoet. Dit resulteert bijna altijd in systemen van verschillende leveranciers waarvan misschien zelfs maar een deel van de aanwezige functionaliteit gebruikt wordt. Als tegenhanger hierop kan men bijvoorbeeld de ‘product-suite’-benadering kiezen, waarbij in principe alle functionaliteit in het gekozen systeem en modules van een leverancier zitten.

Bij toepassing van de multi-stepmethode wordt de business logica ingebracht in de integratielaag. De gebruiker wordt dan, vaak zonder dat hij het weet, door verschillende applicaties heen geleid. Een voorbeeld van architectuur wordt weergegeven in figuur 4.

Figuur 4. Multi-step applicatie-integratie.

Bij multi-step integratie communiceren applicaties meestal indirect met elkaar, waarbij ze gebruikmaken van berichtenservices, transport via het internet of van data warehouses. Hierbij zal een afzonderlijke ‘integration broker’ waarnemen indien een bepaalde applicatie output genereert, vaststellen of andere applicaties deze output nodig hebben, en zal tot slot deze output omvormen naar het gewenste formaat en vervoeren naar de juiste applicatie.

Het multi-step model is vandaag de dag het meest toegepaste integratiemodel binnen grote (multinationale) ondernemingen. Belangrijke reden hiervoor is dat het voorziet in zowel interne (application-to-application of A2A) als externe (business-to business of B2B) integratieproblemen. Daarnaast is het grote voordeel dat er geen (maatwerk) aanpassingen in de gekoppelde systemen nodig zijn.

Het composite activity model

Binnen het model van samengestelde activiteiten (composite activity) maken de betrokken systemen om informatie te verkrijgen automatisch gebruik van andere ‘externe’ systemen. Het duidelijke verschil met een multistep proces is dat bij een multi-step benadering de verschillende stappen sequentieel doorlopen worden. Hier wordt iedere afzonderlijke stap door een afzonderlijke applicatie, systeem of persoon verwerkt. Een composite activity applicatie kan gezien worden als een high speed multi-step proces. Het voornaamste verschil met multistep wordt gevonden in het feit dat alle afzonderlijke acties of stappen onderdeel zijn geworden van een overall bedrijfsproces. Voorbeeld hiervan is een orderafhandelingssysteem dat:

• kan toetsen of de klant kredietwaardig is,
• aangeeft welke vorm van transport het meest gunstig is,
• de betrokken transporteur selecteert,
• de transportkosten kan calculeren en
• een aflevertijd kan geven.

Dit alles gebeurt niet door het aanbrengen van algoritmes in het afhandelingssysteem, maar door het aanroepen van verschillende gespecialiseerde (externe) systemen.

Het composite activity model is de laatste tijd sterker naar voren gekomen in de vorm van webservices. Het idee achter webservices is om zogenoemde meta-applicaties te creëren, waarbij de kracht en toegevoegde waarde gevormd worden door de som van de ingekapselde diensten en de integratielogica. De diensten zelf mogen verwezenlijkt zijn in afzonderlijke onderdelen van de applicatie, in de samengevoegde applicaties of zelfs combinaties van applicaties of onderdelen van applicaties.

Het verschil tussen de multi-step benadering en de webservices ligt in het gegeven dat multi-step zich voornamelijk richt op een logische integratie van verschillende systemen (A2A) gericht op het ondersteunen, structureren en het beheersen van bedrijfsprocessen (B2B). De webservices richten zich voornamelijk op de afhandeling van klantcontacten en klantbehoeften (business-tocustomer of B2C integratie) en dan nog in die gevallen waarbij een synchrone en real-time afhandeling van de vraag noodzakelijk is of een duidelijk concurrentievoordeel biedt. De webservices en het daaraan gekoppelde model van composite activities zijn sterk in opkomst gekomen gedurende de internethype van eind jaren 90.

Alhoewel het model op dat moment sterk verspreid werd, zien we momenteel dat het slechts beperkt wordt toegepast in geval van andere applicatie-integratieproblemen.

Het model van autonome distributie

Het internet heeft een aantal (technologische) ontwikkelingen in gang gezet die ook hun weerslag hebben gehad in de wereld van de applicatie-integratie. Waren eerst de hiervoor behandelde modellen de status-quo in het land van applicatie-integratie, de webservices leiden een totaal nieuw model in. Dit model wordt het model van autonome distributie genoemd.

Het model van autonome distributie lijkt sterkt op het framework van webservices. Dit model is te zien als een uitbreiding op het model van samengestelde activiteiten (composite activities). Een belangrijke karakteristiek is dat verschillende applicatieservices worden gecombineerd om een nieuwe uitgebreidere webservice te bieden.

Het gaat echter nog een stap verder dan de traditionele webservices, omdat de verschillende services dusdanig geëxploiteerd worden dat ze bepaalde diensten dynamisch uitbuiten. Dat uitbuiten gebeurt op het moment dat ze nodig zijn. Dit impliceert een grote mate van synchroniteit, flexibiliteit en beschikbaarheid van diensten. Een voorbeeld van een dergelijke toepassing zou kunnen zijn dat we in het inkoopsysteem direct een link hebben naar een ‘gouden gids’ service op het internet om leveranciers van kantoormiddelen te lokaliseren.

Vervolgens, gebaseerd op de prijslijsten welke die leveranciers via het web openstellen, automatisch winkelen voor het benodigde artikel dat voor de laagste prijs beschikbaar is.

Alhoewel er nog weinig toepassingen van autonome distributie operationeel zijn, is het concept niet alleen veelbelovend maar ook fascinerend.

Integratiepatronen vandaag de dag

Alle hiervoor genoemde integratiepatronen zijn vandaag de dag, weliswaar in verschillende vormen en verhoudingen, in gebruik. Wat we zien is dat het model van data consistency beweegt naar een multi-step model. Beide vormen in nieuwe implementaties momenteel de meest toegepaste integratieoplossingen.

Echter dat kan misleidend zijn, ieder model kan een juiste oplossing vormen voor een integratieprobleem. Er bestaat dan ook niet slechts één goede oplossing voor een integratie probleem. Andersom bestaat het ook niet dat één model de oplossing is voor alle integratieproblemen. Er zullen altijd integratieproblemen zijn (en blijven) die met een ander model (beter) opgelost worden. Denk bijvoorbeeld aan het integreren van machinebesturingen en PLC’s met de bovenliggende besturende applicaties. Hiervoor zal de monolithische benadering nog steeds de beste resultaten bieden.

Ook zien we dat door de overweldigende aandacht voor het internet de webservices en het model van autonome distributie enorme aandacht kregen. Dit zijn echter geen vervangingen geweest voor de data consistency en de multi-step benadering. Er is door de mogelijkheden rondom het internet een nieuw type integratieprobleem ontstaan en daarvoor is een oplossing gekomen.

Als we alle modellen op een rijtje zetten dan zien we dat ieder model wel aspecten heeft die een deel van de integratieproblematiek oplossen. We leggen dan ook de stelling neer dat applicatie-integratie vandaag de dag niet bestaat uit een probleem. Feitelijk is moderne applicatie-integratie een combinatie van het kiezen tussen drie verschillende uitdagingen, te weten data consistency, multi-step proces en composite activities.

In figuur 5 geven we een aantal kenmerkende verschillen tussen deze drie modellen weer. Gezien het beperkt aantal toepassingen op dit moment van het model van autonome distributie, hebben we deze uit de vergelijking weggelaten.

Figuur 5. Drie integratiepatronen vergeleken (bron: Gartner).

Tussen de verschillende modellen is een bepaalde evolutie waar te nemen. Er is een duidelijke tendens dat men meer van éénrichting asynchrone communicatie naar tweerichting synchrone interactie overgaat. Vroeger was het nog gebruikelijk dat er verschillende beeldschermen op een bureau stonden. De gebruiker riep toen zelfstandig meerdere systemen aan. Nu wil men dat de gebruiker niets merkt van in welk systeem hij aan het werk is. Ook moet er geen tijd zitten tussen vraag en respons. Om die reden zie je dat het multi-step model in B2B-oplossingen en het webservices model in B2C-omgevingen steeds meer toegepast worden.

Als we deze ontwikkeling doortrekken, dan zal de toepassing van meer synchrone communicatie in autonome gedistribueerde toepassingen in de directe toekomst meer gemeengoed worden. Dit is weergegeven in figuur 6.

Vijf megatrends in applicatie-integratie

Applicatie-integratie zal plaatsvinden via een afzonderlijke applicatie

Op dit moment zien we dat de aanbieders van integratiesoftware duidelijk de pioniersfase voorbij zijn en een volwassen oplossing kunnen bieden. Verder zien we duidelijk dat er ervaring is opgedaan met verschillende projecten en dat de integratietechnologie toegepast wordt op grotere en meer gevarieerde problemen. Nog maar minder dan tien jaar geleden richtte de beschikbare integratiesoftware zich bijna exclusief op data consistency applicaties. Belangrijke voorsprong op de monolithische benadering was de toepassing van transformatie en routing brokers, waardoor de feitelijke integratie iets flexibeler werd.

Op dit moment worden alle integratiemodellen en de daaraan gekoppelde eisen gevonden in het scala van softwareaanbieders. Vandaag de dag:

• is het multi-step proces in grote mate toegepast;
• zijn het composite activities model en de webservices gemeengoed in integratieland; en
• beginnen de ideeën rondom autonome distributie wortel te schieten.

Dit reflecteert duidelijk een bredere scope rondom integratieproblematiek in het algemeen en een toegenomen belangstelling voor integratietechnologieën in het bijzonder.

Beschouwen we de visie van Gartner rondom de (verwachte) evolutie van de integratietechnologie (figuur 7), dan zien we een soortgelijke trend zich doorzetten. Was de technologie eerst gericht op het mogelijk maken en standaardiseren van transport en integratie van informatie; vanaf nu richten partijen zich meer op de technologieën rondom business process management en business activity monitoring. Technologieën die goed aansluiten bij de modellen van autonome distributie en composite activities.

Natuurlijk hebben alle partijen op de softwaremarkt zich gerealiseerd dat integratie met andere systemen een key-issue is. Daarom zien we integratiemogelijkheden in vele vormen terugkomen. Mogelijkheden worden geboden als ingebouwd onderdeel van verschillende applicaties. We zien het terugkomen als optie of standaard in verschillende infrastructurele oplossingen. Bijvoorbeeld server platforms, messaging systemen, web portal servers.

Daarnaast zien we een groot aantal standaardadapters op (grotere) standaardapplicaties (bijvoorbeeld SAP) op de markt verschijnen. ‘Connectivity’ was het ‘buzz-word’ enige jaren geleden en de markt heeft dat goed opgevangen. Hierdoor is de integratieproblematiek duidelijk voor het voetlicht gehaald en is het minder een probleem geworden van de techneuten alleen.

Alhoewel het een positieve ontwikkeling lijkt dat de ‘connectivity’ nu vele oplossingsvarianten kent, is het hierdoor voor de gebruiker niet makkelijker geworden. Binnen de reeds aangeschafte systemen zijn er vele opties voorhanden om te integreren met andere systemen. De vraag blijft echter of dit de juiste oplossingen zijn.

Momenteel zien we de tendens dat integratie zich meer zal gaan richten op de integratie van businessprocessen en ondernemingsoverstijgende applicaties. Het lijkt dan ook onwaarschijnlijk dat een applicatieafhankelijke integratieoplossing zal overleven.

Daarnaast zien we dat de integratietechnologie een sterk in beweging zijnd veld is. Het zal voor de meeste applicatieaanbieders niet rendabel zijn om continu te (blijven) investeren in nieuwe integratieoplossingen. Vooralsnog lijkt het erop dat de applicatie-integratie in de toekomst zal plaatsvinden in een afzonderlijke applicatie, de zogenaamde ‘middleware tools’.

Integratieoplossingen zullen een meer keten en/of branche gespecialiseerde richting aannemen

Een organisatie opererend in een specifieke industrie of in een specifieke ‘supply chain’ heeft specifieke integratieproblemen die niet ondersteund worden door de huidige standaardoplossingen. Denk hierbij bijvoorbeeld aan het straight-through processing in de financiële wereld, collaborative product design in productieomgevingen, aan collaborative planning, forecasting en replenishment in distributieomgevingen, consolidated billing bij de telecommunicatieaanbieders.

Al deze initiatieven hebben een karakteristiek business proces, functies, B2B-standaarden, communicatieprotocollen, beveiligingseisen, typen applicaties en technologieleveranciers. Voortbordurend op de trend van maatwerk, kennen al deze sectoren ook maatwerkoplossingen in integratieoplossingen.

In het meest gunstige geval is een standaardoplossing voorhanden die door maatwerk branchespecifiek gemaakt is. Deze methode van probleemoplossing biedt een goede oplossing voor de huidige integratieproblematiek. Het valt te betwijfelen of dit voor de integratiebehoefte over bedrijven en/of over ketens heen voldoende zal zijn. Binnen de grotere (multinationale) ondernemingen heeft dit al geleid tot verschillende integratieoplossingen van verschillende aanbieders.

Het ligt in de lijn der verwachtingen dat deze ondernemingen het voortouw gaan nemen in het ontwikkelen van branche- of ketenspecifieke, maar toch generieke integratieoplossingen. Het ontwikkelen van een marktspecifieke oplossing vereisen een significante ontwikkelcapaciteit en doorwrochten kennis van de branche en/ of activiteiten in een bepaalde sector. Als gevolg daarvan ligt voor de hand dat de middleware aanbieders zich steeds meer zullen gaan specialiseren in een bepaalde branche of keten.

Het multi-step proces model zal meer een balans vinden tussen informatie- en procesintegratie

In de vroegere vorm van het multi-step model moesten de bedrijfsprocessen zeer nauwkeurig gedefinieerd worden. Tussen de verschillende applicaties werden de connecties aangebracht en de integratielaag zorgde voor een adequate afhandeling. De belangrijkste noodzaak was om de verschillende applicaties met elkaar te laten praten. Hierbij lag de nadruk op het oplossen van verschillen in de interface structuur, inhoud en semantiek.

Nadelen in deze benadering waren:

• er waren te weinig mogelijkheden voor het doorlopen van incidentele (manuele) processen,
• een procesmodel gericht op het totale bedrijf ontbrak; en
• er waren beperkte of afwezige mogelijkheden voor beheer en tracking van statusinformatie.

Vanuit de wereld van work-flow management (procesintegratie) zijn methoden en technieken overgewaaid die essentieel waren voor de ontwikkeling van een business proces integratiebenadering. Hierdoor werden nieuwe maatstaven neergelegd waaraan een multi-step integratiebenadering moest voldoen.

Het zou ook mogelijk geweest zijn dat (informatie-)integratieproblemen vanuit de ‘work-flow management’ software werden opgepakt. Echter de eerste oplossingen op dat gebied hadden geen mogelijkheden om, zonder dure maatwerk aanpassingen, verbindingen te leggen tussen de verschillende automatische systemen.

Op dit moment zien we een duidelijke toenadering tussen enerzijds de meer business proces georiënteerde modellen en anderzijds de meer interface georiënteerde informatietransfermodellen. Door deze twee benaderingen samen te smelten tot een multi-step proces model, kunnen ondernemingen gebruikmaken van de voordelen van beide: het modeleren van businessdoelstellingen en eisen op ondernemingsniveau. Hierbij kan zelfs gedacht worden aan processen met een lange looptijd die over de bedrijfsgrenzen heen gaan. Denk hierbij aan collaborative product design.

Aan de andere kant kunnen er ook sneller interfaces gerealiseerd worden voor verschillende toepassingen. Denk hierbij aan: back office applicaties, webservices en -applicaties, generieke datawarehouses, systemen van handelspartners (waaronder die van klanten, leveranciers, dienstverleners, etc.) en vele andere systemen. Tot slot maakt dit huwelijk tussen twee modellen het mogelijk om de bedrijfsprestatie en het operationele resultaat beter te beheersen en te monitoren. Dit door gebruik te maken van gelaagde modellen van de bedrijfsprocessen.

Al met al, er is niet meer sec een scheiding tussen informatie- integratie en procesintegratie. Beide werelden zie je naar elkaar bewegen en op een bepaald moment zullen ze waarschijnlijk tot een gemeenschappelijke wereld versmelten.

De integratiemodellen ‘webservices’ en ‘autonome distributie’ zullen de standaardmodellen in de toekomst zijn

Het model van webservices is een nieuw model wat door de komst en de mogelijkheden van het internet een enorme toekomst lijkt te krijgen. De belangrijkste verdienste van dit model was dat het een eerste stap was tot een dynamische vorm van applicatie-integratie.

In het voorgaande hebben we gezegd dat het model van autonome distributie een dynamische integratie voor ogen heeft. Hierbij kunnen internetservices, volgens een vooraf min of meer gedefinieerd patroon, automatisch benaderd worden. Bij dit model is het mogelijk om leveranciers van producten en/of diensten real-time te benaderen. Tegelijkertijd is het mogelijk bij niet beschikbaarheid eenvoudig een alternatief aan te bieden. In de businesslogica zijn hiervoor verschillende (dynamische) algoritmen opgenomen.

De webservices blijven potentieel interessant in een aantal gebieden. Te denken valt hierbij aan webportals van een onderneming en marktplaatsen. Een ondernemingsspecifiek webportal zal traditioneel standaarddiensten en producten etaleren en aanbieden. Ondernemingen kunnen de webservices exploiteren door gepersonifieerd te reageren op basis van de identiteit, klanthistorie en momentafhankelijke omstandigheden van de bezoeker. Zowel besloten en openbare marktplaatsen op het web kunnen op dezelfde wijze de mogelijkheden exploiteren. Echter daar bestaat ook nog de mogelijkheid om vrager en aanbieder pro-actief bij elkaar te brengen, op basis van toepassingsspecifieke heuristieken.

Zoals reeds eerder gesteld zijn de webservices sterk opgekomen door de internethype. Het model van autonome distributie kent zijn oorsprong vanuit het webservices framework. Alhoewel je beide modellen eenvoudig zou kunnen scharen onder het multi-step proces model, is het onze overtuiging dat deze beide modellen zullen ontwikkelen tot een duidelijk nieuw en afzonderlijk integratiemodel.

De technologie om te integreren zal sterker gaan evolueren omdat het integreren een bedrijfskritisch proces geworden is

De meeste organisaties ontdekken de voordelen van het implementeren van nieuwe (deel)systemen waarbij bestaande systemen en diensten geïntegreerd worden.

Hierdoor wordt applicatie-integratie een niet weg te denken onderdeel van een moderne IT-architectuur. We zien ook dat de scope van applicatie-integratie toeneemt van enkele systemen tot integratie van honderden of zelfs duizenden systemen. Hierdoor kunnen we stellen dat integratie een essentiële activiteit gaat worden. Deze trend stelt natuurlijk nieuwe eisen aan de integratietechnologie. Denk hierbij aan aspecten als betrouwbaarheid, beschikbaarheid en prestatie van het totale te integreren systeem. De belangrijkste technologische uitdagingen die hieruit volgen zijn:

• het beheersen van de dynamische werklast,
• het waarborgen van de integriteit van de transacties,
• het elimineren van zwakke schakels en
• het creëren van echt enkelvoudige processen.

In de afgelopen jaren zagen we dat middelware systemen bewogen van het simpele client/server model, naar een model waarbij één of meerdere servers worden opgenomen in een netwerk. De verschillende applicaties waren min of meer statisch gebonden aan een bepaalde server en via het netwerk gekoppeld. Deze benadering zorgde in ieder geval voor een zekere mate van integriteit tussen systemen, maar was afhankelijk van een redelijk constante werklast. Echter ook deze keten blijkt zo sterk te zijn als haar zwakste schakel. Hierdoor gaf deze vorm onvoldoende waarborgen in geval van storing of overbelasting.

De volgende stap in de evolutie zou kunnen zijn dat twee of meerdere servers de integratiesoftware bevatten en dat daaraan applicaties gekoppeld worden die niet vast aan een server gebonden zijn. Hierdoor krijgen we een dynamisch model dat beter om weet te gaan met variaties in werklast en minder storingsgevoelig is. In geval van niet-beschikbaarheid van een server kan de vraag (automatisch) doorgestuurd en afgehandeld worden door een andere server. Hierdoor komt wel weer het integriteitsprobleem naar voren, maar dat is op te lossen door een eenduidig delen van transactie- maar ook van statusinformatie. Het probleem van een dynamische werklast kan opgelost worden door gebruik te maken van zogenaamde ‘server pools’.

Een stap in een meer dynamische benadering zou een clustergeoriënteerde benadering kunnen zijn. Clustering vormt een goede basis voor het verwezenlijken van een dynamisch werklastbeheersing en storing op een enkelvoudig platform. Daarnaast blijft het natuurlijk een voorwaarde dat om dynamisch gedrag tussen verschillende platforms en locaties te bewerkstelligen, de integratieoplossing een dynamische benadering moet kunnen ondersteunen.

Om de grote technologische stappen te nemen die nodig zijn voor deze verwachte evolutie, is het noodzakelijk dat er een dringend probleem is dat opgelost moet worden. Nu applicatie-integratie de slagkracht en prestatie van de onderneming significant kan beïnvloeden, kan het probleem op de juiste niveaus de aandacht krijgen. Dit zal resulteren in een versnelde technologische ontwikkeling.

Tot besluit

De markt van integratie-applicatie en de integratietechnologie is sterk in beweging en zal voorlopig nog in beweging blijven. Het waarnemen van een trend is dan ook slechts te interpreteren als een momentopname. Echter de aandachtsgebieden die hierdoor blootgelegd worden, zullen wel degelijk consequenties hebben voor (grote) ondernemingen en hun leveranciers. Het verdient dan ook aanbeveling om meer nadruk te leggen op de visie en strategieën van leveranciers hoe zij deze uitdagingen benaderen.

---

Dit artikel is in 2002 verschenen in het Handboek voor Logistiek en Informatietechnologie van TenHagen Stam Uitgevers. Auteur: Paul Denneman.