Middleware neemt verschillen op alle niveaus voor lief; zij gaat zelfs uit van onderscheid. De oplossing is te verkiezen boven het onderling aan elkaar koppelen van systemen, meent Michel van den Hoek van DCE Consultants.
Van den Hoek sprak op een seminar over middleware dat DCE had georganiseerd. De consultant was onlangs als ad interim integratiemanager van de nationale luchthaven verantwoordelijk voor de implementatie van een nieuwe applicatiearchitectuur op basis van middleware. Zijn bijdrage, ‘Ervaringen met grootschalige migraties’ kreeg de ondertitel ‘Recept voor lasagne’. De Italiaanse keuken blijkt bijzonder geschikt om computersystemen te duiden. Volgens Van den Hoek bestaat een gemiddelde architectuur bij grote ondernemingen (tweeduizend werknemers) tegenwoordig uit een samenstel van dertig tot veertig systemen met ongeveer 250 verschillende interfaces. Er is weinig tot geen documentatie en er zijn minstens twintig voltijds it’ers nodig om het geheel aan de praat te houden.
"Er is sprake van superdure systemen en eindeloos vertragende projecten, waardoor managers van bedrijfseenheden hun vertrouwen in ict-afdelingen verliezen. We hebben het dan over een spaghetti-architectuur waarbij tal van systemen volledig met elkaar vermaasd zijn. Centraal staat een applicatie, bijvoorbeeld het grootboek, en dat is gekoppeld aan een reeks andere systemen. Er zijn verschillen in technologie, protocol, dataformaat, data-inhoud, objectlayout, authenticatie, autorisatie, verrijking, procesflow-controle en noem maar op. Zelfgebouwde programmaatjes zorgen ervoor dat die verschillen worden overbrugd. Maar zodra ook maar ergens iets wijzigt, en dat gebeurt vrijwel dagelijks, heb je de poppen aan het dansen. Niemand zit er dan ook op de wachten om nieuwe applicaties in te voeren of bestaande te wijzigen."
Zijn oplossing is een lasagne-architectuur, waarbij diverse lagen keurig gerangschikt zijn. Middleware zorgt daarbij voor transport, interpretatie en verwerking van data via een message broker. Randvoorwaarden zijn wel dat een integratie- en een architectuurbeleid worden ontwikkeld.
"Voordelen zijn dat er een standaard koppelstuk op de plank ligt, dat kosten en doorlooptijd verminderen bij systeem(interface)bouw, dat er meer ruimte is voor aandacht voor functionaliteit, en dat er een bakermat is voor verdere centralisering van interfacecomplexiteit." Hij waarschuwt er wel voor niet via de datalaag te integreren en screen schrapping uit het hoofd te laten, omdat je dan weer elementen uit de spaghetti-structuur inbrengt.
Big Bang
Bij Schiphol draaien meer dan honderd systemen. Er zijn er al tien verschillende voor facturering. Begin 1998, vertelt Coen Reinders, is men begonnen daarin meer lijn te brengen. Reinders is business controller van de bedrijfseenheid Airlines. Drijfveer tot aanpassing van de systemen was de wens tot beter contact met de klanten en invoering van e-zakendoen. Tevens was vervanging van SAP R2 de aanzet tot het onder de loep nemen van de architectuur. "We konden nauwelijks nog mensen vinden voor onderhoud van R2."
Een volledige overstap naar R3 zat er niet in, omdat SAP te duur was tegenover Oracle. R3 is er wel gekomen voor de personeelsmodule, personeelscrediteuren en de contante geldstroom. "Achteraf heb ik toch mijn twijfels over de keuze voor Oracle, omdat de koppeling tussen Oracle en Maximo (voor schade en onderhoud) een nachtmerrie bleek."
Schiphol is in één keer overgegaan op een middleware-architectuur; de Big Bang, zoals Reinders dat noemt. Hij zou er niet meer voor kiezen, hoewel hij eigenlijk als R2-gebruiker weinig keus had. Ook heeft hij zijn twijfels over de keuze om per deelsysteem te kiezen voor best of breed, omdat dit een opeenstapeling van interfaces en dus complexiteit met zich meebrengt.
De belangrijkste voorwaarde is en blijft betrokkenheid van het management bij het project. "Als dat er niet was gekomen, was het project nog steeds niet live gegaan."
