Luchthaven vervangt Kernsystemen

Amsterdam Airport Schiphol heeft het centrale informatiesysteem Schiphol (CISS) in een periode van ruim een jaar van de grond af opgebouwd. Gebruikmakend van moderne technieken is zij erin geslaagd in recordtempo een van de kernsystemen van de luchthaven succesvol te vervangen. Dit artikel gaat in op de architectuur van de gerealiseerde oplossing, inclusief aanpak en belangrijkste keuzes en valkuilen die door de gekozen aanpak vermeden zijn.




CISS, schoolvoorbeeld van een realistische architectuur


Amsterdam Airport Schiphol heeft het centrale informatiesysteem schiphol (CISS) in een periode van ruim een jaar van de grond af opgebouwd. Gebruikmakend van moderne technieken is zij erin geslaagd in recordtempo een van de kernsystemen van de luchthaven succesvol te vervangen. Dit artikel gaat in op de architectuur van de gerealiseerde oplossing, inclusief aanpak en belangrijkste keuzes en valkuilen die door de gekozen aanpak vermeden zijn.     



Het CISS


Het CISS vormt het logistieke systeem van de Amsterdam Airport Schiphol. De informatie wordt gebruikt om het logistieke proces van vliegtuigen op de luchthaven door de dienstverleners te faciliteren. De informatie aan de passagiers gaat verder dan alleen vluchtgerelateerde informatie, ook meer algemene informatie als openingstijden van de keukenhof, de locatie van de dichtstbijzijnde pinautomaat en de omroep via de informatiebalies wordt vanuit CISS geregeld.     



Het bestaande CISS voldeed prima en kende weinig tot geen storingen. Enerzijds door veroudering van de systemen, anderzijds door de wens voorbereid te zijn op de toekomst is besloten het CISS systeem te vervangen door een nieuwere versie. Gezien de complexiteit en uniekheid van de applicatie, de organisatorische impact en noodzakelijke wijzigingen aan beschikbare pakketoplossingen, heeft Amsterdam Airport Schiphol besloten het nieuwe CISS als maatwerk te bouwen. Hierbij gebruikmakend van de kennis en ervaring opgedaan met het bestaande systeem.     



Voor het nieuwe systeem zijn een aantal uitgangspunten gedefinieerd.     



1. Invoering van het CISS moet plaatsvinden zonder verstoring van de operatie, zodat de continuïteit van de operatie gewaarborgd is.     
2. Het CISS moet een fundament bieden voor de toekomst en flexibel en open zijn zodat eenvoudig nieuwe processen, externe partijen en business mogelijkheden te verwezenlijken zijn.     
3. Het CISS mag geen leveranciers- en platformafhankelijkheid opleveren.     

In den beginne


Amsterdam Airport Schiphol is een aantal jaren bezig met het opzetten en invoeren van een bedrijfsbrede architectuur. Het CISS is een van de eerste echte vingeroefeningen om de gekozen aanpak praktisch te toetsen en zo waardevolle input te leveren om de architectuur te toetsen en verder aan te scherpen. Kijkend naar de applicatie eisen is gekozen voor een meerlagenarchitectuur met een strakke scheiding tussen data-aanlevering en -afname, dataverwerking (business logica) en dataopslag.     

De eerste laag is een Integratie Broker die zorgt voor de communicatie van en naar de externe partijen. De tweede laag is een J2EE Applicatie Server die de business logica herbergt en verder zorgt voor de grafische eindgebruikersinterface. De interfaces en gebruikers communiceren met de business logica die in de Applicatie Server draait. De derde laag is een XML Server, die zorgt voor het persisteren van gegevens. De interne communicatie tussen de bouwstenen gaat via XML om zo een nog hogere graad van flexibiliteit te realiseren en klaar te zijn voor de toekomst. Het is eenvoudig mogelijk zowel nieuwe ‘automatische’ interfaces, als nieuwe gebruikersinterfaces (zoals PDA en mobiele toepassingen) te realiseren.     

Integratie Broker


De Integratie Broker verzorgt de communicatie met de externe systemen in de bestaande dialecten en communicatieprotocollen. Ontvangen berichten worden geconverteerd naar één (intern) gestandaardiseerde XML structuur. Deze XML standaard wordt door het hele systeem gebruikt en alleen naar de externe partijen vindt conversie plaats naar de gewenste dialecten. Hierdoor ontstaat een duidelijke scheiding, met de gewenste flexibiliteit om eenvoudig, zonder impact nieuwe koppelingen te realiseren.     

Voor de uitgaande berichten geldt dat de Integratie Broker het (interne) XML bericht analyseert en op basis van gedefinieerde beslissingsbomen de gegevens routeert en converteert naar het gewenste uitvoerdialect. De interfaces ‘abonneren’ zich op specifieke acties en wijzigingen van gegevens.     

Applicatie Server


De applicatie server vormt de kern van het systeem en zorgt voor het valideren en verrijken van de door de externe partijen aangeleverde gegevens. Deze worden deels volautomatisch aangeleverd vanuit de BackOffice van de aangesloten partijen, deels online ingevoerd in een volledig webgebaseerde invoeromgeving. Zowel vanuit de gebruikersinterface als de ‘automatische’ interfaces wordt één gestandaardiseerde XML structuur gebruikt om berichten met de business logica uit te wisselen. Dit om te garanderen dat alle logica slechts een keer ontwikkeld en getest hoeft te worden en een duidelijke scheiding te garanderen tussen de business logica en de aanleverende omgeving.     



De business logica zorgt dat wijzigingen gevalideerd, geautoriseerd, gecontroleerd en doorgevoerd worden. Een voorbeeld van een simpele regel is dat het niet is toegestaan de vliegtuiggegevens van een vlucht aan te passen als deze al bij de gate vertrokken is. Het beveiligingsmodel is zowel functioneel (mag wijzigen, mag toevoegen), inhoudelijk (mag gate wijzigen, mag route aanpassen) als gebeurtenis gebonden (na gebeurtenis x, mag gebruiker y niet meer wat voorheen wel mocht). De beveiliging is volledig doorgevoerd in de webinterface. Gebruikers zien en mogen alleen waartoe zij op dat moment zijn geautoriseerd.

XML Server


De wijzigingen en gegevens worden centraal opgeslagen in de XML Server. Om het aantal conversieslagen te minimaliseren en flexibiliteit te waarborgen is gekozen ook de opslag in XML te doen. Daarnaast worden de wijzigingen naar de Integratie Broker gestuurd voor verdere distributie naar de ‘geabonneerden’.     



Techniek is niet alles


Het lijkt erop dat techniek de enige bepalende factor is binnen de architectuur. De techniek is feitelijk niet meer dan een uitvloeisel van de behoeften die door de gebruikers (business) zijn geformuleerd. Dit is een mogelijke valkuil, waaraan binnen het project veel aandacht is besteed door de architectuur niet primair vanuit de techniek te benaderen.     

Om dit te waarborgen is binnen het traject zeer nauw contact geweest tussen de ‘business experts’, de gebruikers en het kernteam (de architecten). De eerste fase van het project is gebruikt om in een overzienbare periode de architectuurprincipes handen en voeten te geven. Tijdens die fase is een prototype gerealiseerd met een versimpeld proces van voor tot achter. De ervaringen zijn vervolgens verwerkt in een blauwdruk architectuur die naast de technische basis ook de opzet van het kernteam herbergde, zodat belangen van alle betrokken partijen gewaarborgd en een integraal onderdeel zijn van de architectuur.     



Door op voorhand rekening te houden met mogelijke wijzigingen in de architectuur en iedereen daarvan bewust te maken en houden ontstaat een flexibel geheel waar wijzigingen als vanzelfsprekend geabsorbeerd worden. Deze stap is een van de cruciale succesfactoren binnen het project gebleken. De blauwdruk is gehanteerd als basis en is pragmatisch gegroeid vanuit een meer academisch model naar een realistisch model.     

Slimme samenwerking


Een mooi voorbeeld van samenwerking tussen business en techniek gebruikmakend van flexibiliteit in de architectuur is de garantie op berichtvolgorde. Vanuit de business vormt dit een keiharde eis, waarbij geldt dat wijzigingen van gegevens in de volgorde van aanlevering verwerkt moeten worden. Praktisch betekent het dat alle binnenkomende berichten sequentieel afgehandeld moeten worden, waardoor er een bottleneck ontstaat. Het mag niet zo zijn dat een vliegtuig dat van gate wijzigt door een van de interfaces aangepast wordt met ‘oude’ gegevens, omdat de verwerking ingehaald is door een nieuwer bericht. Gebruikmakend van de mogelijkheden aan businesszijde, in combinatie met technische mogelijkheden is gekozen voor een praktische architectuur aanpassing gericht op een maximaal resultaat zonder business impact. De aanleverende interfaces zijn geanalyseerd en gegroepeerd naar wijzigingen. Praktisch konden er een aantal groepen worden geformeerd met wijzigingen die geen impact op elkaar hebben, waardoor er een aantal sequentiële queues zijn.     



Meten = weten


Binnen de architectuur is veel aandacht besteed aan de mogelijkheid om met minimale inspanning de kwaliteit van de gerealiseerde oplossing te garanderen en bewaken. Het systeem wordt vanuit diverse bronnen gebruikt, wat de mogelijkheid biedt om de oplossing automatische te testen via de interfaces. Om te voorkomen dat de ‘geautomatiseerde testen’ teveel fouten zouden opleveren, en de kwaliteit van de releases richting test te maximaliseren, is vanuit de architectuur gekozen om alle hoofdcomponenten binnen het systeem uit te breiden met een bijbehorende unittest. In eerste instantie brengt dit een aardige tijd- en kostenpost met zich mee, die tijdens de bouw (minder testwerk nodig) al is terugverdient en ook richting de toekomst stabielere en kwalitatief betere opleveringen garandeert.     



Geruisloze invoering


Een belangrijk onderdeel binnen de architectuur was de keuze voor een modulaire CBD aanpak. Zowel binnen de J2EE applicatie, als op een hoger niveau waar een strakke scheiding is aangebracht tussen business, interface en schermlogica. Deze strakke scheiding zorgde in combinatie met de mogelijkheid om beide systemen parallel te draaien ervoor dat de applicatie stap voor stap in te voeren was. Een groot winstpunt, zeker omdat in het begin nog gevreesd werd voor het moeten uitvoeren van een ‘big-bang’. Het parallel draaien is mede mogelijk gemaakt door te kiezen voor een ‘één-op- één’ vervanging, waar na oplevering een snelle inhaalslag gemaakt wordt gebruikmakend van de flexibiliteit en uitbreidbaarheid van het CISS.     



Achtereenvolgens zijn de raadpleegfuncties en wekelijks een aantal automatische interfaces geactiveerd. De finale bestond uit het aankoppelen van de laatste interfaces en het activeren van de update functionaliteit voor de on-line gebruikers. Dankzij het opleidingsplan en de geleidelijke invoering waarbij alle business logica al ‘in productie’ was getest via de interfaces is in recordtijd een bedrijfskritisch systeem vervangen met een zeer hoge gebruikerstevredenheid, beschikbaarheid en flexibiliteit zonder enige noemswaardige verstoring.   

Leermomenten


Als Amsterdam Airport Schiphol aan moet geven wat de drie leermomenten zijn uit het project, gericht op de architectuur dan luiden deze als volgt:     



1. Architectuur is een must voor het stabiel en toekomstgericht opbouwen van applicaties. Het zorgt voor het realiseren van een inzichtelijk en gestructureerd beheer. Het gaat niet alleen over techniek, maar de business is een minstens zo belangrijk onderdeel.     
2. Door de uitgangsarchitectuur op hoofdlijnen duidelijk te stellen, met een ingebouwde flexibiliteit om nieuwe mogelijkheden of uitzonderlijke situaties te absorberen, zijn veel problemen voorkomen. Daarnaast is het raadzaam de gekozen architectuur regelmatig te laten ‘reviewen’ door een externe architect die met frisse blik aanbevelingen kan doen.     
3. Door de architectuur breed in te steken zijn kosten bespaard. Bijvoorbeeld door het testen en de testaanpak een integraal onderdeel te maken van de architectuur zodat een groot deel van het testwerk geautomatiseerd wordt.     



Eric Lansbergen    
Paul van der Horst    
Marcel Noordzij      



Paul, Eric (beide Schiphol) en Marcel (42) vormden het kernteam tijdens de realisatie van het CISS project. Zij leverden de benodigde technische en business kennis om de architectuur en geleverde oplossing scherp te krijgen en te sturen.     



CISS


In totaliteit zijn er 20.000 Schipholwerkers die het CISS systeem actief gebruiken. Het CISS verzorgt de planning van tal van operationele processen en levert de actuele informatie rechtstreeks naar o.a. NOS en RTL Teletekst, de 2500 publieksmonitoren in de terminal en www.schiphol.nl. De gegevensverwerking van luchtvaartmaatschappijen, toewijzing van bagagebanden, luchtverkeersleiding, douane, afhandelaren, schoonmaakbedrijven en andere partijen verloopt grotendeels geautomatiseerd.     

Amsterdam Airport Schiphol


Amsterdam Airport Schiphol () neemt met zo’n 40 miljoen passagiers per jaar en bijna 400.000 starts en landingen de vierde plaats in op de Europese ranglijst van luchthavens. Passagiers kunnen kiezen uit meer dan negentig luchtvaartmaatschappijen, om te vliegen naar 250 in meer dan 80 landen. Schiphol is herhaaldelijk gekozen tot beste luchthaven in Europa of in de wereld en is een belangrijke economische motor voor de regio met meer dan 540 bedrijven en ruim 57.000 werkzame personen op het luchthaventerrein.     



42


42 is een organisatie die zich heeft gespecialiseerd in het realiseren van complexe Java-, XML- en integratietrajecten, variërend van bedrijfsbrede architectuur en design tot projectmanagement en ontwikkeling.