Fusies en overnames, de introductie van nieuwe distributiekanalen en de noodzaak tot kostenreductie in de administratieve verwerking dwingen banken en verzekeraars tot maatregelen in hun IT-infrastructuur. Meer dan ooit tevoren is de behoefte ontstaan aan een infrastructuur die optimale flexibiliteit en efficiëntie biedt, en waarbij een spaghettiarchitectuur wordt vermeden. Aan deze behoefte is nu en in de komende jaren te voldoen met behulp van een groep softwareproducten onder de noemer middleware, aldus een consultant.
Ten gevolge van toenemende (internationale) concurrentie is flexibiliteit voor een financiële instelling van levensbelang geworden en zal dit in de komende jaren ook blijven. De time to market van nieuwe financiële producten wordt steeds korter en in hoog tempo worden nieuwe distributiekanalen (internet, mobiele telefonie) in gebruik genomen. Deze distributiekanalen dienen volledig met elkaar en met de achterliggende organisatie geïntegreerd te worden. De geautomatiseerde uitwisseling van gegevens tussen de betrokken informatiesystemen is bij de introductie van een nieuw financieel product in de meeste gevallen de bottleneck in het realisatietraject. Door de toenemende complexiteit van het totaal aan systemen dat in gebruik is, wordt deze bottleneck steeds smaller en zorgt hij voor steeds grotere vertraging in de realisatie van nieuwe systemen. Bij veel organisaties is inmiddels sprake van een spaghettiarchitectuur: er is een enorme hoeveelheid koppelingen gerealiseerd tussen de gebruikte informatiesystemen.
Naast de tijd en moeite die het onderhoud van een dergelijke omgeving vraagt en het operationele risico dat ermee gepaard gaat, resulteert deze situatie vaak in een inefficiënte administratieve verwerking. In een ideale situatie wordt elk gegevenselement, of het nu gaat om een financiële transactie of de gegevens van een klant, altijd slechts één keer ingevoerd. Vervolgens worden deze gegevens volledig geautomatiseerd in de diverse systemen verwerkt, dit is het zogenaamde straight through processing (stp). Deze automatische verwerking beperkt zich dan niet tot de interne omgeving, maar strekt zich uit naar de externe relaties, zoals klanten, clearing- en settlement-organisaties, beurzen, enzovoort. We komen dan op het terrein van business-to-business e-handel en toeleveringsketenbeheer. Gegeven de immer toenemende transactievolumes en de stijgende druk op de marges op transacties, neemt de behoefte aan efficiëntieverbetering binnen de financiële wereld sterk toe. Ook de ontwikkeling binnen de effectenwereld richting T+1 settlement (volledige afhandeling van transacties binnen één werkdag na uitvoering van de transactie) doet deze behoefte groeien. Bij handhaving of zelfs uitbreiding van de spaghettiarchitectuur zullen IT-hulpmiddelen nooit aan al deze behoeftes kunnen voldoen.
Zware eisen aan infrastructuur
De toenemende wens om ‘de klant te kennen’ is tevens een belangrijke reden voor een gestructureerde uitwisseling van gegevens binnen een financiële organisatie. De meeste in gebruik zijnde systemen zijn gebouwd om de administratie voor een bepaald product (zoals hypotheken, verzekeringen of beleggingsportefeuilles) te ondersteunen. Dit is veroorzaakt door de productgeoriënteerde ontwikkeling van financiële instellingen en door de fusies en overnames van de afgelopen decennia. Bij deze fusies en overnames ziet men vaak dat de oorspronkelijk door de individuele organisaties in gebruik zijnde systemen gehandhaafd blijven. Om de klanten nu beter van dienst te zijn dient de informatie over klanten geaggregeerd over al deze verschillende systemen en administraties beschikbaar te komen. Om deze informatie vervolgens te kunnen analyseren en te gebruiken voor one-to-one marketing en productontwikkeling zijn verschillende oplossingen op de markt (de zogenaamde customer relationship management (crm) systemen, zoals gebouwd door Siebel, Vantive, Oracle, enzovoort). Het ontsluiten van de informatie uit de afzonderlijke systemen vraagt echter een aanzienlijke inspanning.
Al deze zaken stellen steeds zwaardere eisen aan de IT-infrastructuur van financiële instellingen. De spaghettiarchitectuur is niet langer acceptabel. Financiële instellingen die hier niet snel verandering in brengen, lopen het risico de aansluiting bij de zich in snel tempo ontwikkelende markt te verliezen. Nieuw opgerichte bedrijven (met name Internetbedrijven en softwarehuizen), die in hun ontwikkeling niet gehinderd worden door de geschetste IT-problematiek, richten hun pijlen op de financiële wereld. Deze partijen zijn door het ontbreken van een ‘IT-erfenis’ in staat in hoog tempo financiële diensten op de markt te brengen. Traditionele instellingen zien hierin een serieuze bedreiging ontstaan.
Ook de ontwikkelingsachterstand die veroorzaakt is door de prioriteit van euro- en millenniumprojecten vraagt om een snelle inhaalslag om te voorkomen dat men achterraakt op de concurrentie. Door deze euro- en millenniumprojecten zijn overigens wel zaken gerealiseerd die nieuwe activiteiten kunnen versnellen, zoals complete inventarisaties van in gebruik zijnde systemen en de koppelingen daartussen.
Vanuit de noodzaak snel systemen aan elkaar te koppelen en de daaruit voortvloeiende behoefte aan een flexibele architectuur is in de afgelopen jaren een groep softwareproducten ontstaan onder de noemer middleware. Middleware is een hulpmiddel bij wat wel genoemd wordt enterprise application integration (eai): het op gestructureerde wijze koppelen van alle in gebruik zijnde informatiesystemen en het zorgen voor een sturing van de informatiestromen.
Middlewaretechnologie
Veel typen hulpmiddelen voor de realisatie van communicatie tussen verschillende applicaties vallen onder de noemer middleware. Met name applicatieservers (van bijvoorbeeld Brokat, IBM of Microsoft) krijgen momenteel – terecht – veel aandacht. Dit artikel is vooral gericht op middelen ten behoeve van de integratie van applicaties binnen de onderneming (enterprise application integration), waarin applicatieservers een minder grote rol spelen, en daarom hier niet verder behandeld worden. Veel van de hier genoemde zaken zijn echter ook van toepassing op deze technologie.
Vanuit technologisch oogpunt is middleware een zeer breed begrip. De veelheid aan technologieën die onder deze noemer te scharen zijn, is samen te vatten in een basismodel met de volgende vier componenten: messaging, message brokerage, workflow en management & monitoring.
De berichtencomponent (messaging) is in feite de lijm tussen de diverse applicaties en biedt individuele applicaties de mogelijkheid onafhankelijk van onderliggende netwerken, besturingssystemen, enz, met elkaar te communiceren. Leveranciers als IBM (MQSeries), Tibco (TIB/Rendez Vous), BEA (Message Q) en Microsoft (Msmq) leveren hiervoor standaardoplossingen. Ook zijn veel adapters voor standaardapplicaties beschikbaar, waarmee deze applicaties aangesloten kunnen worden op de berichtencomponent. Gebruik van berichtensoftware biedt vooral voordelen op het technische vlak: de koppelingen tussen de diverse applicaties worden alle geleid via een standaard platform en niet meer via een grote hoeveelheid aan technologische ’trucs’. Koppelingen zijn daardoor sneller te realiseren en het geheel is beter onderhoudbaar. Zo kan een deal capture- en position keeping-systeem ten behoeve van de aandelenhandel met berichtensoftware gekoppeld worden aan een back-officesysteem. Traditioneel vindt dit plaats door het periodiek uitwisselen van losse tekstbestanden die zijn gemaakt op basis van extracties van de betreffende databases. Mocht nu bijvoorbeeld een applicatie voor risicobeheer ook gebruik willen maken van deze transactiegegevens, dan behoeft deze applicatie bij gebruik van berichtensoftware slechts te worden voorzien van een adapter voor deze berichtensoftware. Er zijn dan geen veranderingen nodig in de andere systemen.
Om te zorgen dat berichten die vanuit applicaties via de berichtencomponent op de juiste wijze naar andere applicaties worden verstuurd, wordt de Message Brokerage-component gebruikt. Een ‘berichtenmakelaar’ (Message Broker, ook wel genoemd Integration Broker) is software met twee functies: het op de juiste wijze routeren van informatie via de berichtencomponent en het transformeren van aangeleverde gegevens. Deze transformatie is nodig omdat de vele verschillende applicaties werken met verschillende gegevensformaten. Een bekend eenvoudig voorbeeld is het verschil in gebruik van klantnummers. Vaak worden hiervoor in verschillende systemen binnen een organisatie verschillende methodes gebruikt. De berichtenmakelaar zorgt voor de benodigde vertaalslag.
De consistentie op technisch vlak die bereikt wordt met de berichtencomponent wordt door de berichtenmakelaar aangevuld met een logische component die de gegevensstroom op een hoger niveau aanstuurt. Dit gebeurt op basis van bedrijfsregels, die aangeven hoe de genoemde routering en transformatie moeten plaatsvinden. De bovengenoemde leveranciers van berichtensoftware hebben nagenoeg allemaal berichtenmakelaars in hun productportfolio. Verder worden dergelijke systemen geleverd door ondermeer Neon (e-Biz Integrator), IBM (MQSeries Integrator, maakt gebruik van Neons rules/formatter), Mercator (Mercator Enterpise Broker) en HIE (Clover Leaf). In het voorbeeld van de koppeling van een deal capture-systeem met een back-officesysteem zal een berichtenmakelaar transacties uit het deal capture-systeem doorsturen naar het back-officesysteem. Op basis van de inhoud van de transacties, bijvoorbeeld door te kijken naar de valuta van de transactie, kan de berichtenmakelaar tevens zorgen voor aflevering in het juiste formaat aan bijvoorbeeld een systeem voor buitenlandse betalingen.
Werkstroom
De realisatie van de eerste twee componenten uit het basismodel levert dus een situatie op, waarin de gegevens tussen applicaties via een standaard platform (de berichtencomponent) worden uitgewisseld en waarbij de aansturing van de gegevensstroom centraal plaatsvindt (in de berichtenmakelaar). Een dergelijke situatie geeft al een oplossing voor veel van de problemen die eerder in dit artikel genoemd zijn: er ontstaat een flexibele, goed onderhoudbare architectuur, waarbij informatie uit aangesloten systemen relatief eenvoudig te ontsluiten is en waarin met een relatief geringe inspanning nieuwe systemen kunnen worden geïntegreerd.
Er is echter meer dan dat: boven het niveau van de berichtenmakelaar bevindt zich een werkstroomcomponent. Hierin bevinden zich faciliteiten om de bedrijfsprocessen ondersteund door de diverse applicaties aan te sturen. Nogmaals het voorbeeld van de aandelenhandel: een aankooporder voor een aandeel wordt door een handelaar ingevoerd in een deal capture-systeem. Deze order wordt vervolgens naar de beurs gestuurd, waarna een aantal uitvoeringen van de beurs terugkomt. De uitvoering van de order wordt aangemeld in het systeem van de handelaar, alsmede in het back-officesysteem, waarna de gegevens doorgestuurd worden naar de conservator. Werkstroom-tools zijn in staat dit soort processen aan te sturen en te monitoren, waarbij vaak niet alleen geautomatiseerde systemen betrokken zijn, maar ook acties van mensen. Steeds meer middleware-leveranciers ontwikkelen dergelijke hulpmiddelen (of gaan samenwerkingsverbanden aan met leveranciers van werkstroom-tools). Deze hulpmiddelen zijn voorzien van grafisch georiënteerde tools voor de inrichting van business processen. Hierdoor kan een business-manager binnen een organisatie hieraan zelf sturing geven, betrekkelijk onafhankelijk van de IT-afdeling.
Management en monitoring
Over de diverse middleware-componenten heen wordt een management & monitoring-component toegevoegd. Hierbij is te denken aan systeembeheerfuncties om alle betrokken processen op de diverse machines actief te kunnen volgen. Naast deze technische functie worden in deze component functies aangeboden die inhoudelijk gebruik maken van de gegevens die door de organisatie heen uitgewisseld worden. Deze gegevens kunnen bestemd zijn voor onder andere gegevensdelving (bijvoorbeeld het verzamelen van informatie over transacties voor een bepaalde groep klanten) of het volgen van service level agreements (bijvoorbeeld het nagaan of een afgesproken maximale verwerkingstijd voor een transactie bewerkstelligd wordt).
Zoals er veel verschillende applicaties gebruikt worden in de financiële instellingen, zo komt men in één organisatie vaak middleware tegen van meerdere leveranciers. Standaardisering op dit gebied, het gebruik van één set van middleware-producten door de gehele organisatie, zou vanuit de technologie geredeneerd, in theorie ideaal zijn. Echter, voor sommige functies zijn bepaalde middleware-producten de beste keuze, gegeven de situatie bij een gebruikersorganisatie. Er wordt dan een mix aan middlewareproducten gebruikt (best of breed aanpak). Zolang de verschillende producten voldoen aan open standaarden op het gebied van communicatie, hoeft dit geen probleem op te leveren.
Het onderscheidend vermogen van middleware-leveranciers is inmiddels niet of nauwelijks meer te vinden in de berichtenfunctionaliteit. Dit wordt meer en meer gemeengoed en de verschillende leveranciers op dit gebied groeien sterk naar elkaar toe. Deze beweging is langzaam maar zeker ook te vinden in de berichtenmakelaars, hoewel hierin aanzienlijke verschillen in de leeftijd, en dus vaak in de rijpheid, van deze producten bestaan. Leveranciers van middleware oplossingen geven allen aan zich te willen onderscheiden door steeds meer standaard adapters te ontwikkelen voor gangbare applicaties (zoals erp-en crm-systemen) – in feite is dit dus geen onderscheidende factor.
Implementatie van middleware
Zoals eerder aangegeven is er bij financiële instellingen nog niet of nauwelijks sprake van een situatie waarin de informatie-uitwisseling tussen computersystemen gebeurt via een architectuur, zoals hierboven is beschreven. Men is in veel gevallen echter wel bezig met middleware, met name bij projecten ten behoeve van de realisatie van nieuwe distributiekanalen (meerkanalenplatforms). Hierbij wordt wel degelijk gewerkt aan een architectuur die de structurele basis vormt voor alle aan te sluiten distributiekanalen en voor integratie met de achterliggende systemen. Ook bij de implementatie van een nieuw systeem (bijvoorbeeld ter ondersteuning van een nieuw financieel product of ter vervanging van een bestaand systeem) wordt vaak gebruik gemaakt van middleware om de koppeling met de al aanwezige systemen te vereenvoudigen. Hierdoor wordt voorkomen dat de spaghettiarchitectuur zich verder uitbreidt en wordt deze situatie zelfs voor een deel weggewerkt. Zo ontstaat een basis voor verdere herstructurering.
Tussen de spaghettiarchitectuur, met rechtstreekse koppelingen tussen alle applicaties, en de ideale situatie, waarin al deze koppelingen via middleware lopen, is ook een tussenvorm mogelijk. Stel in de oude spaghettiarchitectuur wordt een applicatie vervangen door een nieuwe. Alle koppelingen met de nieuwe applicatie worden dan gerealiseerd door gebruik te maken van middleware.
Zowel leveranciers als gebruikers van middleware geven aan geen projecten te kennen met als primair doel het wegwerken van de spaghettiarchitectuur. Dit is ook wel begrijpelijk, aangezien dit een aanzienlijke operatie is, zonder dat er meteen nieuwe diensten of producten worden gerealiseerd. Veel logischer is het om een dergelijke technologie daar in te zetten, waar nu een acute noodzaak bestaat om snel en volgens een consistente architectuur systemen aan elkaar te koppelen. Deze visie wordt gedeeld door zowel gebruikers als leveranciers. Als uitgangspunt bij de introductie van middleware wordt vaak aangegeven: "begin klein, en daar waar de ‘pijn’ het grootst is". Door de jaren heen zal de integratie van systemen dan steeds meer via de nieuw geïntroduceerde architectuur gaan lopen. Het is dan uiteraard wel van belang binnen een organisatie duidelijke afspraken te maken over de te gebruiken middleware oplossingen, om te voorkomen dat ook hier ‘spaghetti’ ontstaat.
Een van de belangrijkste uitdagingen bij de implementatie van middleware is van organisatorische aard. Bij gebruik van middleware is techniek niet langer de belangrijkste bottleneck. Het soort projecten waarin middleware wordt toegepast vereist vaak de koppeling van systemen die met name bij grotere organisaties zowel functioneel als technisch beheerd worden door verschillende afdelingen. Het maken van goede afspraken over de te hanteren aanpak en over verantwoordelijkheden tijdens en na de implementatie blijkt regelmatig op problemen te stuiten. Het is dan ook van belang hieraan meteen bij de aanvang van projecten voldoende aandacht te besteden.
Enige verantwoorde wijze
Middlewareproducten hebben inmiddels een stadium van voldoende rijpheid bereikt om op grote schaal ingezet te worden en als basis kunnen dienen voor de IT-architectuur van de komende jaren. Dit geldt zeker voor de berichten- en berichtenmakelaarcomponenten. De werkstroomcomponent is een zeer nuttige toevoeging, maar is eigenlijk bij alle belangrijke leveranciers nog maar heel recent in de productportefeuille gebracht. Voor dit specifieke onderdeel zouden eventueel reeds bestaande zelfstandige werkstroomhulpmiddelen ingezet kunnen worden. Dan dient echter wel van tevoren goed onderzocht te worden in hoeverre deze goed te integreren zijn met andere gebruikte middleware producten.
Gegeven de geschetste voordelen van middleware en de ontwikkelingen in de financiële wereld, kan gesteld worden dat middleware momenteel de enige verantwoorde wijze is voor het realiseren en aansturen van koppelingen tussen informatiesystemen. Dit geldt voor trajecten rond de introductie van distributiekanalen en nieuwe informatiesystemen en bij integratiewerkzaamheden ten gevolge van fusies en overnames. De vraag is niet of middleware ingezet dient te worden voor dergelijke trajecten. De vraag wordt dan welke middleware het best gebruikt kan worden in bepaalde situaties. Dit zal onder meer afhangen van de functies waarvoor deze software gebruikt dient te worden, en van de bestaande technische infrastructuur.
Leveranciers van middleware-oplossingen wekken vaak de indruk dat door toepassing van deze producten met nauwelijks enige moeite integratietrajecten te doorlopen zijn. Inderdaad zal gebruik van middleware een aanzienlijke tijdsbesparing opleveren, omdat de technische realisatie van de koppelingen tussen systemen aanmerkelijk eenvoudiger wordt. Middleware versnelt de realisatie van koppelingen tussen afzonderlijke informatiesystemen aanzienlijk. Dit is reeds het geval bij een eerste introductie van dit hulpmiddel en de tijdswinst neemt toe naarmate meer systemen worden aangesloten op de middleware.
Op technisch vlak blijven twee zaken veel tijd kosten: de analyse van de data (dus uitwerken hoe data gerouteerd en getransformeerd moet worden), en het bouwen van adapters voor applicaties waarvoor deze nog niet beschikbaar zijn. Voor vele standaardapplicaties zijn adapters ontwikkeld door hetzij de applicatieleveranciers, hetzij de middleware-leveranciers, maar in de praktijk komen bij financiële instellingen echter nagenoeg altijd (zelfgebouwde) systemen voor waarvoor geen standaardadapters beschikbaar zijn.
Op het organisatorische vlak kan tijd verloren gaan door niet tijdig te zorgen voor afspraken tussen alle binnen de organisatie betrokken partijen. Betrokkenheid van het hogere management voor de realisatie van integratietrajecten is dan ook cruciaal.
Zowel in de financiële wereld, als in vele andere bedrijfssectoren zijn in de komende jaren stormachtige ontwikkelingen te verwachten in de wijze waarop bedrijven onderling gegevens zullen uitwisselen. In de nieuwe economie zullen organisaties onderling steeds meer via elektronische weg zaken doen. De infrastructuur die het Internet biedt, gecombineerd met standaarden voor gegevensuitwisseling tussen organisaties, zoals die momenteel worden uitgewerkt (XML), gaan dit helpen bewerkstelligen. Hierbij is een snelle, accurate en flexibele verwerking van gegevens van levensbelang. Middleware kan, mits goed toegepast, gezien worden als het hulpmiddel dat organisaties hiertoe in staat stelt.
Jaco de Vroed, consultant Nexus
