Ingewikkeld en duur, maar pure noodzaak – zo typeert Gartner ‘enterprise application integration’. Bij meer en meer organisaties ontkomt de ict-afdeling er niet meer aan om op steeds grotere schaal te streven naar integratie van bestaande en nieuwe informatiesystemen. Alleen op die manier ondersteunt de ict de zakelijke werkprocessen optimaal. Met een ‘enterprise service bus’ kan een ict-afdeling grip krijgen op het integratieprobleem.
| Integratiestrategie: tien regels Volgens Gartner-analist Massimo Pezzini gelden tien regels voor het tot stand brengen van een succesvolle strategie op het gebied van applicatie-integratie.
|
Pezzini is gespecialiseerd in applicatieservers, component-gebaseerde ontwikkeling, webservices en dergelijke. Hij ziet steeds meer organisaties het eai-pad (enterprise application integration) op gaan. Tegelijkertijd twijfelt hij wel eens aan de redenen waarom bedrijven aan dit soort projecten beginnen. Er zijn in zijn ogen ook verkeerde motieven, zoals orde scheppen in rommelige gegevensstromen, consolidatie van allerlei middleware en het verbeteren van documentatie.
Zakelijke behoefte
Ict-afdelingen moeten applicatie-integratie alleen aanpakken wanneer dit vanuit zakelijk oogpunt noodzakelijk is, meent Pezzini. Redenen zijn bijvoorbeeld de vele nieuwe overheidsreguleringen (Basel II; IAS, International Accounting Standards; Sarbanes-Oxley) en een zakelijke behoefte aan het uitwisselen van gegevens. Ook kan een overname noodzaken tot integratie van applicaties.
Hij hanteert een ruime definitie van het begrip ‘applicatie-integratie’: het met elkaar laten samenwerken van los van elkaar ontwikkelde applicaties. Dit betekent dat niet alleen strak op elkaar afgestemde en van een ‘vraag en antwoord’-mechanisme gebruikmakende systemen eronder vallen, maar bijvoorbeeld ook methoden die werken met een batch-gewijze uitwisseling van bestanden.
Het complexe van applicatie-integratie ligt in het feit dat alle betrokken toepassingen een eigen informatie-, proces- en objectmodel kennen. Daarbij wordt bovendien veelal gewerkt met een nogal gevarieerde lijst van dbms’en (database management systeem), programmeertalen, besturingssystemen en andere middleware. Dat levert een stevige uitdaging op, meent Pezzini. In veel gevallen maakt het integratiestuk dan ook 35 procent of meer uit van de totale kosten voor het ontwerpen, ontwikkelen en onderhouden van een nieuwe toepassing.
Ict-afdelingen doen er dus verstandig aan om de effectiefste ontwerppatronen, softwarematige hulpmiddelen en organisatorische procedures te kiezen. Zo overtuigt als we inmiddels ervan zijn dat applicatie-integratie noodzakelijk is, zo onduidelijk is het antwoord op de vraag ‘hoe doen we dat’. De minimale benodigdheden zijn volgens Pezzini: een weldoordachte strategie, eigen kennis en kunde in de vorm van een integratieteam en duidelijk keuzes ten aanzien van de toe te passen programmatuur.
Relatiepatronen
We kunnen tegenwoordig stellen dat ieder applicatie-ontwikkelproject in feite een integratieproject is. Tegelijkertijd geldt dat geen enkel project enkel en alleen uit integratie bestaat. Er bestaat altijd de behoefte om extra functionaliteit toe te voegen. Bij applicatie-integratie, stelt Pezzini, hebben we te maken met één van de volgende drie ‘relatiepatronen’. De eerste is het bewerkstelligen van gegevensconsistentie over meerdere applicaties heen, waarbij aan elkaar gerelateerde gegevens in meer dan één database vastliggen. De tweede is het ‘multistap proces’. Hierbij bestaat een werkproces uit meerdere handelingen die ieder met een aparte toepassing worden ondersteund. In het derde geval gaat het om samengestelde toepassingen. In Pezzini’s visie zijn dit de strakst aan elkaar gekoppelde applicaties, waarbij iedere component een stap in een werkproces ondersteunt op basis van een eigen informatiearchitectuur. Iedere ontwikkelaar moet deze patronen kennen en kunnen inschatten wanneer hij welk patroon het best kan toepassen. Want, zo stelt Pezzini, geen van deze drie patronen is ‘goed’ of ‘fout’.
Een belangrijke doelstelling van een integratiestrategie is het optimaliseren van de ‘end to end’ stroom van handelingen en gegevens in een proces dat uit meerdere stappen bestaat. Deze multistap processen zijn niet nieuw. Ook het denken in horizontale processen over meerdere afdelingen en hun applicaties heen is geen recente ontwikkeling. Kijk alleen al naar bpr (business process re-engineering), dat in de jaren tachtig op kwam. Het gebeurt tegenwoordig wel steeds vaker, terwijl de softwarematige hulpmiddelen om dit soort processen te ondersteunen steeds beter worden. Hierbij kunnen ‘engines’ gebruikt worden die het mogelijk maken de bedrijfsregels die de samenwerking tussen applicaties regelen geautomatiseerd uit te voeren. Tools voor het ontwikkelen van processen worden steeds meer in deze bpm-engines (business process management) geïntegreerd, zodat procesontwerpen niet meer vanuit losstaande ontwerpprogramma’s overgeheveld hoeven te worden naar de bpm-engine.
Verticale integratie
Samengestelde applicaties wijken duidelijk af van een multistap proces. Waar bij een multistap proces sprake is van een horizontale integratie over meerdere applicaties heen, is bij een samengestelde toepassing juist sprake van het langs verticale weg integreren. Met andere woorden: er is binnen één stap sprake van een verticale integratie over meerdere lagen of ’tiers’ heen. Een dergelijke toepassing combineert de logica of gegevens van twee of meer los van elkaar ontwikkelde applicaties ter ondersteuning van één stap in een bedrijfsproces. Bij zo’n toepassing is dus altijd sprake van nieuwe functionaliteit die dient als aanvulling op het aangeschafte pakket of de zelf ontwikkelde legacy applicatie.
|
De soa (service-oriented architecture) speelt bij dit alles een belangrijke rol. Een soa is gebaseerd op twee principes: het opsplitsen van een grote klus in kleine stapjes (modulariteit) en het gebruiken van een goed gedefinieerde interface om individuele modules af te schermen van de buitenwereld (inkapseling of encapsulation). Het voordeel van op basis van soa-principes ontwikkelde applicaties is dat de ontwikkelaar zich volledig kan concentreren op de functionele kant van zijn module; de communicatie met de buitenwereld is immers al geregeld. Dit betekent dat een soa-applicatie zich veel makkelijker in een samengestelde toepassing laat opnemen dan een oud monolitisch systeem.
Een soa bevordert bovendien het hergebruik van functionaliteit. Ontwikkelaars moeten deze opnieuw te gebruiken brokken functionaliteit zelf aangeven en daarbij duidelijk in de gaten houden wat praktisch is. Met andere woorden: hoe beperkt of uitgebreid is een stukje functionaliteit nog interessant voor hergebruik? XML zal veelal de taal zijn waarmee de onderlinge communicatie wordt geregeld. Vooral Wsdl (Web Services Description Language) zal op dit vlak de komende jaren hoge ogen gooien.
Eda of soa
Naarmate ict-afdelingen zich nadrukkelijk op een soa richten, zullen zij ook ontdekken dat er behoefte bestaat aan een tweede ontwerpaanpak: eda (event driven architecture). Soa en eda hebben veel gemeen maar verschillen op één belangrijk punt: de manier waarop ze de relatie tussen modules structureren. Waar een soa in twee richtingen een ‘vraag en antwoord’-mechanisme toepast, gebruikt eda voor het communiceren met twee of meer procedures die een andere applicatie uitvoert berichten die slechts in één richting worden verstuurd.
De principes achter eda zijn al tientallen jaren bekend. Ze worden onder andere in systeemsoftware en grafische applicaties toegepast. Volgens Pezzini wordt eda ‘de volgende hit’ aangezien deze aanpak een krachtig hulpmiddel is om dynamische bedrijfsprocessen te ondersteunen. Eda is volgens hem geen concurrent van soa, maar juist een aanvulling daarop. Bovendien zijn beide methodieken in combinatie met webservices toepasbaar, al is dit niet noodzakelijk.
Het gebruik van soa en eda zal voor veel ict-afdelingen betekenen dat zij hun middleware-infastructuur moeten aanpassen. Geen nood, stelt Pezzini gerust, veel bedrijven hoeven hier pas over enkele jaren aan te beginnen. Duidelijk is wel dat momenteel veel gebruikte protocollen als tcp/ip, smtp, soap en ftp, en middleware-producten als orb’s, rpc’s, soap-stacks, mom en traditionele integratieservers niet over de uitgebreide functionaliteit beschikken die op soa en eda gebaseerde applicaties nodig hebben.
Esb is dichtbij
Leveranciers reageren op deze trends met het ontwikkelen van een aanpak die soms esb (enterprise service bus) wordt genoemd. Een esb ondersteunt onder andere standaarden op het gebied van webservices en kent faciliteiten voor berichtenverkeer, een aantal basisvoorzieningen voor gegevenstransformatie, mogelijkheden voor intelligente ‘routing’, een ‘interface repository’, en de nodige hulpmiddelen voor het ontwikkelen en beheren van functionaliteit. Soms zullen esb’s als losse producten verkrijgbaar zijn, maar ze kunnen ook opgenomen zijn in bijvoorbeeld applicatieservers, ‘applicatie platform suites’ of het besturingssysteem.
Een esb maakt het voor een ict-afdeling mogelijk om bij een multistap proces of een samengestelde applicatie componenten toe te voegen, weg te gooien en aan te passen, zonder dat de te ondersteunen werkprocessen hiervoor stilgelegd moeten worden. Hiertoe moet een esb de communicatie tussen twee of meer programma’s regelen, standaard interfaces, formaten en protocollen ondersteunen (zoals XML, Java Message Service en soap), een ‘discovery’ en registratie van services mogelijk maken, voorzieningen voor beveiliging en beheer kennen en ontwikkelhulpmiddelen omvatten.
Esb’s zijn dichterbij dan we wellicht geneigd zijn te denken, zegt Pezzini. IBM zal zijn Websphere esb in de eerste helft van volgend jaar op de markt brengen. Indigo van Microsoft maakt nog steeds deel uit van Longhorn, waarvan de server-variant in 2007 wordt verwacht. Kijk ook naar BEA voor een eigen esb (X-Bus). Daarbij gaat het dan wel om esb’s die gebaseerd zijn op webservices. Een ander type esb is geheel gebaseerd op soap en http. Al beschikbare voorbeelden daarvan zijn Network Director van Titan Software, Cape Clear Integration Server van Cape Clear Software en Talking Blocks soa van Hewlett Packard. Pezzini verwacht dat in 2006 beide types esb in elkaar opgaan.
Twee stromingen
Er bestaan bij applicatie-integratie twee belangrijke stromingen, de een met de nadruk op ontwikkeling, de ander meer gericht op inzet. In het eerste geval wordt een zo nauw mogelijke integratie tussen softwareontwikkeling en applicatie-integratie nagestreefd. In dit geval is het dus het beste, meent Pezzini, om een esb te kiezen die goed geïntegreerd is met de applicatieserver. Bij een op de inzet gerichte aanpak van de integratie wordt het ontwikkelen van applicaties en het integreren van toepassingen zoveel mogelijk van elkaar gescheiden. Dan is het dus verstandig om een esb te selecteren die onafhankelijk is van de applicatieserver.
Een integratiestrategie kan niet zonder hulpmiddelen die de data bij elkaar te brengen. Etl-hulpmiddelen (extraction, translation and loading) maken het mogelijk om een ods (operational data store) of een applicatiedatabase te laden. Bedrijven als SAP (Master Data Management), Ascential Software en Oracle (Single source of truth) kiezen ervoor één fysieke ods te creëren. Het is ook mogelijk om te werken met een virtuele ods ofwel eii. Eii is echter een doel en geen technologie. Het moet alle vormen van data-integratie omvatten. Deze ‘virtual federated views’ worden vooral gebruikt in ‘alleen lezen’ bedrijfsintelligentie-toepassingen.
Pezzini is van mening dat een weldoordachte strategie voor applicatie-integratie zowel batch als realtime communicatiemechanismen moet omvatten, evenals een combinatie van op data en op berichten gerichte hulpmiddelen en -ontwerpen. Bovendien geldt dat voor iedere situatie een andere aanpak noodzakelijk is. Bij eai is nu eenmaal geen plaats voor ‘one size fits all’.< BR>
