Amsterdam Airport Schiphol heeft het Centrale Informatiesysteem Schiphol (Ciss) in ruim een jaar van de grond af opgebouwd. Gebruikmakend van moderne technieken is de organisatie erin geslaagd in recordtempo een van de kernsystemen van de luchthaven succesvol te vervangen. Essentieel daarbij waren de architectuur van de gerealiseerde oplossing, inclusief de aanpak en belangrijkste keuzes. Dankzij de gekozen aanpak zijn diverse valkuilen vermeden.
| Ciss In totaal gebruiken twintigduizend Schiphol-werkers het Ciss (Centrale Informatiesysteem Schiphol) actief. Het systeem verzorgt de planning van tal van operationele processen en levert actuele informatie rechtstreeks aan onder andere NOS en RTL Teletekst, de 2500 publieksmonitoren in de terminal en http://www.schiphol.nl. De gegevensverwerking van luchtvaartmaatschappijen, toewijzing van bagagebanden, luchtverkeersleiding, douane, afhandelaren, schoonmaakbedrijven en andere partijen verloopt grotendeels geautomatiseerd. 42 (http://www.2en40.nl, gespecialiseerd in Java-, XML- en integratie-trajecten variërend van bedrijfsbrede architectuur en ontwerp tot projectmanagement en ontwikkeling) was als externe partij bij Ciss betrokken. Amsterdam Airport Schiphol neemt met zo’n veertig miljoen passagiers per jaar en bijna vierhonderdduizend starts en landingen de vierde plaats in op de Europese ranglijst van luchthavens. Passagiers kunnen kiezen uit meer dan negentig luchtvaartmaatschappijen om naar 250 bestemmingen in meer dan tachtig landen te vliegen. Schiphol is herhaaldelijk gekozen tot beste luchthaven in Europa en de wereld. Het is een belangrijke economische motor voor de regio met meer dan 540 bedrijven en ruim 57 duizend werkzame personen op het luchthaventerrein. |
Het bestaande Ciss voldeed prima en kende weinig tot geen storingen. Vanwege veroudering van de systemen en de wens voorbereid te zijn op de toekomst is besloten het toch 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 is gebruik gemaakt van de kennis en ervaring die was opgedaan met het bestaande systeem.
Uitgangspunten
Voor het nieuwe systeem zijn een aantal uitgangspunten gedefinieerd: de invoering moet plaatsvinden zonder verstoring van de operatie, zodat de continuïteit gewaarborgd is; het systeem moet een fundament bieden voor de toekomst en flexibel en open zijn, zodat eenvoudig nieuwe processen, externe partijen en zakelijke mogelijkheden te verwezenlijken zijn; en het mag geen leverancier- en platformafhankelijkheid opleveren.
Amsterdam Airport Schiphol is al een aantal jaren bezig met het opzetten en invoeren van een bedrijfsbrede architectuur. Het Ciss is een van de eerste vingeroefeningen om de gekozen aanpak in de praktijk te testen en zo gegevens te leveren voor toetsing en aanscherping van de architectuur. Kijkend naar de applicatie-eisen is gekozen voor een meerlagenarchitectuur met een strakke scheiding tussen data-aanlevering en -afname, dataverwerking (bedrijfslogica) en dataopslag.
De eerste laag is een ‘integratiemakelaar’ (integration broker) die zorgt voor de communicatie van en naar de externe partijen. De tweede laag is een J2EE applicatieserver die de bedrijfslogica herbergt en zorgt voor de grafische eindgebruikersinterface. De interfaces en gebruikers communiceren met de bedrijfslogica die in de applicatieserver draait. De derde laag is een XML-server, die zorgt voor het handhaven 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 om zowel nieuwe ‘automatische’ interfaces als nieuwe gebruikersinterfaces (zoals pda en mobiele toepassingen) te realiseren.
Flexibiliteit
De integratiemakelaar 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. Alleen voor de externe partijen vindt conversie plaats naar de gewenste dialecten. Hierdoor ontstaat een duidelijke scheiding, met de gewenste flexibiliteit om eenvoudig en zonder impact nieuwe koppelingen te realiseren.
Voor de uitgaande berichten geldt dat de integratiemakelaar 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.
De applicatieserver vormt de kern van het systeem. Hij 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 en deels online ingevoerd in een volledig webgebaseerde invoeromgeving. Vanuit zowel de gebruikersinterface als de ‘automatische’ interfaces wordt één gestandaardiseerde XML-structuur gebruikt om berichten met de bedrijfslogica 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 die bedrijfslogica en de aanleverende omgeving.
De bedrijfslogica 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 functioneel- (mag wijzigen, mag toevoegen), inhoudelijk- (mag gate wijzigen, mag route aanpassen) en gebeurtenis-gebonden (na gebeurtenis x mag gebruiker y niet meer wat hij voorheen wel mocht). De beveiliging is volledig doorgevoerd in de webinterface. Gebruikers zien en mogen alleen doen waartoe zij op dat moment zijn geautoriseerd.
De wijzigingen en gegevens worden centraal opgeslagen in de XML-server. Om het aantal conversieslagen te minimaliseren en flexibiliteit te waarborgen is ervoor gekozen ook de opslag in XML te doen. Daarnaast worden de wijzigingen naar de integratiemakelaar gestuurd voor verdere distributie onder de ‘abonnees’.
Blauwdruk
Het lijkt erop dat techniek de enige bepalende factor is binnen de architectuur. De techniek is echter niet meer dan een uitvloeisel van de behoeften die door de gebruikers (de bedrijfsactiviteiten) zijn geformuleerd. Dit is een 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 nauw contact geweest tussen de ‘bedrijfsexperts’, 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 begin tot eind. De ervaringen zijn vervolgens verwerkt in een blauwdruk architectuur die naast de technische basis ook de opzet van het kernteam herbergde. Daardoor zijn de belangen van alle betrokken partijen gewaarborgd en een integraal onderdeel van de architectuur.
Door op voorhand rekening te houden met mogelijke wijzigingen in de architectuur en iedereen daarvan bewust te maken en te houden ontstaat een flexibel geheel dat wijzigingen als vanzelfsprekend absorbeert. Deze stap is een van de cruciale succesfactoren binnen het project gebleken. De blauwdruk is gehanteerd als basis en pragmatisch gegroeid vanuit een meer academisch model naar een realistisch model.
Kwaliteitsgarantie
Een voorbeeld van samenwerking tussen bedrijfsactiviteiten en techniek, gebruikmakend van flexibiliteit in de architectuur, is de garantie op berichtvolgorde. Vanuit de bedrijfsactiviteiten vormt dit een keiharde eis, waarbij geldt dat wijzigingen van gegevens in de volgorde van aanlevering verwerkt moeten worden. Praktisch betekent dit dat alle binnenkomende berichten sequentieel afgehandeld moeten worden, waardoor een knelpunt 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 bedrijfszijde in combinatie met technische mogelijkheden is gekozen voor een praktische architectuuraanpassing gericht op een maximaal resultaat zonder impact op de bedrijfsactiviteiten. De aanleverende interfaces zijn geanalyseerd en gegroepeerd naar wijzigingen. Het was mogelijk een aantal groepen te formeren met wijzigingen die geen impact op elkaar hebben, waardoor er een aantal sequentiële wachtrijen is.
Binnen de architectuur is veel aandacht besteed aan de mogelijkheid om met minimale inspanning de kwaliteit van de gerealiseerde oplossing te garanderen en te bewaken. Het systeem wordt vanuit diverse bronnen gebruikt, wat de mogelijkheid biedt om de oplossing automatisch te testen via de interfaces. Om te voorkomen dat de ‘geautomatiseerde testen’ te veel fouten zouden opleveren en de kwaliteit van de vrijgaven voor de test te maximaliseren, is vanuit de architectuur gekozen om alle hoofdcomponenten binnen het systeem uit te breiden met een bijbehorende onderdeeltest. In eerste instantie brengt dit een aardige tijd- en kostenpost met zich mee. Deze is tijdens de bouw (minder testwerk nodig) al terugverdiend. Bovendien garandeert dit in de toekomst stabielere en kwalitatief betere opleveringen.
Zonder verstoring
Een belangrijk onderdeel binnen de architectuur was de keuze voor een modulaire cbd-aanpak (component-gebaseerde ontwikkeling), zowel binnen de J2EE-applicatie als op een hoger niveau, waar een strakke scheiding is aangebracht tussen bedrijfsactiviteiten, interface en schermlogica. In combinatie met de mogelijkheid om beide systemen parallel te draaien zorgde deze strakke scheiding 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, waarbij na oplevering een snelle inhaalslag gemaakt wordt gebruikmakend van de flexibiliteit en uitbreidbaarheid van 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 actualiseringfunctionaliteit voor de online gebruikers. Dankzij het opleidingsplan en de geleidelijke invoering, waarbij alle bedrijfslogica al ‘in productie’ was getest via de interfaces, is in recordtijd een bedrijfskritisch systeem vervangen met een zeer hoge gebruikerstevredenheid, beschikbaarheid en flexibiliteit zonder noemswaardige verstoring.
Leermomenten
Amsterdam Airport Schiphol kan drie leermomenten uit het project, gericht op de architectuur, aangeven. Allereerst is architectuur 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; de bedrijfsactiviteiten zijn een minstens zo belangrijk onderdeel.
Ten tweede zijn veel problemen voorkomen door de uitgangsarchitectuur op hoofdlijnen duidelijk te stellen, met ingebouwde flexibiliteit om nieuwe mogelijkheden en uitzonderlijke situaties te absorberen. Daarnaast is het raadzaam de gekozen architectuur regelmatig te laten beoordelen door een externe architect; die kan met een frisse blik aanbevelingen doen.
Ten derde zijn kosten bespaard door de architectuur breed in te steken, bijvoorbeeld door het testen en de testaanpak een integraal onderdeel te maken van de architectuur, zodat een groot deel van het testwerk geautomatiseerd wordt.< BR>
Eric Lansbergen, (Schiphol), Paul van der Horst (Schiphol), Marcel Noordzij (42), kernteam realisatie Ciss-project
