Principieel slopen Jan Mulder Slopen in onze IT wereld – vergelijk dat eens met slopen in de wereld van gebouwen. Hoe slopen wij, hoe gaat het met gebouwen? Een voorbeeld dat ik regelmatig gebruik in gesprekken met vakgenoten: de brandweerkazerne, gelegen naast ons kantoor in Utrecht. De gemeente heeft een paar jaar geleden besloten dat er een nieuwe kazerne moet komen in Leidsche Rijn. De huidige kazerne voldoet blijkbaar niet meer, ligt niet centraal genoeg of misschien is de reden ook gewoon de waarde van de grond. Op een goede dag verhuist de brandweer. Het oude gebouw wordt gesloopt – de kantoortoren die op die plek komt staat al op de billboards. Ik kan het verhuis proces als buitenstaander volgen, maar het maakt op mij een goed geplande en doordachte indruk. De brandweer moet voor, tijdens en na de verhuizing voldoen aan zeer hoge beschikbaarheids eisen. Getuige hun missie: Het redden van mens en dier bij brand en het verlenen van hulp bij incidenten. Het waarborgen van de fysieke veiligheid van inwoners van Utrecht en haar gasten staat hierbij centraal. Dus wel een verhuizing waarbij de brandweer gewoon moet blijven door functioneren! Vakgenoten reageren vaak met: ‘ja maar, in onze wereld van informatie systemen ligt het heel anders; daar is migratie zo speciaal en moeilijk’. Ik vind dat we ons in de IT wereld veel te vaak erg bijzonder wanen. Het lijkt me dat er in onze wereld vaak sprake is van conservatisme waarin zo’n ‘kazerne’ aanpak vooral met tegenwerpingen begroet wordt. In deze bijdrage poneer ik een aantal principes die relevant zijn voor slopen. De scope waarin deze principes spelen is ‘vervangen van wat er is door migratie naar iets nieuws’.
Referentiekader Ook bij slopen is er behoefte aan een referentiekader. De beschrijving van de track ‘Slopen onder architectuur’ heeft het over processen, applicaties en infrastructuur. Dat referentiekader moet uitgebreid worden met andere relevante invalshoeken: informatie/gegevens, organisatie en cultuur. Hopelijk zijn we volgend jaar op het LAC zo ver dat we vanuit een gemeenschappelijk referentiekader kunnen werken. Ook dit jaar is het nog niet zo ver – getuige de verschillen in definitie van architectuur die in de verschillende tracks opduiken.. Het afgelopen jaar heb ik regelmatig gebruik gem aakt van de volgende inspiratiebronnen: 1. het belang van het migratieproces Nieuwenhuis en Nooteboom hebben op het vorige LAC de architectuur aanpak bij de 1 Politie gepresenteerd. Daarin geven ze de situatie weer waar vele organisaties zich in bevinden; in een spagaat tussen: • wat mogelijk is: het actuele aanbod van leveranciers • wat gewenst is: het beeld van de gewenst IT voorzieningen • wat bestaand is: de nu aanwezige IT voorzieningen Het kiezen van de juiste strategie in dit krachtenveld is letterlijk de kunst. Wat vervangen we, wat houden we in stand, welke van de vele mogelijkheden op IT gebied kiezen we:
1
Marcel Nieuwenhuis en Alvin Nooteboom, Architectuur als managementinstrument. Presentatie op het LAC 2002
Krachtenvelden Aangeboden
Wat verwerven
Gevraagd
Wat vernieuwen
2.
2
Bestaand
Wat vervangen
enterprise architectuur Een praktische invulling van het begrip enterprise architectuur is ontleend aan 2 Victor van Reijswoud . Enterprise architectuur ‘gaat over’: • Strategie: de missie en strategie van de organisatie. • Processen: wat doet het bedrijf • Informatie: die bij processen hoort, feedback voor de strategie. • Workflow: sturing van gedetailleerde werkprocessen, eventueel over verschillende informatie processen heen. • Applicaties: informatie systemen • Gegevens • Infrastructuur: technisch, organisatie, externe uitwisseling, applicatie integratie • Cultuur: de identiteit van de organisatie en medewerkers Een kanttekening bij deze invulling van enterprise architectuur: het suggereert een hiërarchische wereld, waarin de strategie bepaald wordt, en de rest daarvan afgeleid. Als we er vanuit gaan dat andere gebieden in de enterprise architectuur hun eigen dynamiek hebben, kunnen die net zo goed aanleiding geven tot verandering. Denk aan ontwikkelingen in de harde IT (infrastructuur) en veranderingen in cultuur van een organisatie na een fusie of overname. Impulsen tot verandering kunnen dus uit meerdere hoeken komen.
Dr. Victor van Reijswoud, Architectuur in Nederland en daarbuiten. LAC 2001
Strategy
supports
Process
Work flow
Enterprise architectuur als raamwerk
Infor mation
Appli cation
determines
Data
Infrastructure integrates Culture
Het eerste model maakt ons er van bewust dat niet alles wat vervangbaar is, ook per se vervangen moet worden. De architect heeft een eigen verantwoordelijkheid bij het zoeken naar een positie tussen de krachtenvelden. Het tweede model maakt duidelijk dat architecten verder moeten kijken dan ‘processen, applicaties en infrastructuur’.
Principes De track gaat over principes die van belang zijn bij slopen onder architectuur. Hier poneer ik enkele principes die relevant zijn voor het onderwerp:.
1. Slopen en verhuizen De enterprise architectuur beschrijft een aantal gebieden. Er zijn vele varianten van sloop of verhuizing, afhankelijk van het gebied. Vervanging van een applicatie (sloop) gaat over het algemeen gepaard met verhuizing van gegevens. Onze klantgegevens zijn een waardevol bezit, ongeacht de vorm, formaat, database, opslag waarin ze staan. Moraal: het enterprise architectuur model maakt het mogelijk om per gebied aan te geven wat er verandert bij een vernieuwing. Waar wordt gesloopt en vernieuwd, waar wordt verhuisd, waar verandert niets. Een goede analyse daarvan vergemakkelijkt het plannen van sloop en migratie zeer!
2. Data moeten ontdaan worden van hun legacy beperkingen
Het is algemeen geaccepteerd dat applicaties verouderen. De term die daarbij hoort is: ‘legacy’. Legacy applicaties zijn applicaties die achterhaald zijn wat betreft technologie en functionele mogelijkheden. Legacy applicaties die soms nog uit het tijdperk stammen van voor de (relationele) database hebben heel vaak een zeer sterke relatie met de bijbehorende gegevens: de legacy data. Het is bij slopen daarom niet genoeg de aandacht uitsluitend op de vervanging van de legacy applicatie te richten. Zonder aandacht voor de kwalijke kanten van legacy data is het investeren in een nieuwe applicatie - tot op zekere hoogte - geld weggooien! De legacy data in de nieuwe omgeving frustreren het gebruik van nieuwe mogelijkheden. Een voorbeeld uit de praktijk. Op het mainframe wordt het bestand met leveranciers onderhouden. We implementeren een ERP module met daarin opgenomen het beheer van leverancier gegevens. De functionaliteit voor leveranciers wordt dus voortaan door de ERP module geleverd. Als we de legacy data 1 op 1 overzetten naar de ERP module, houden ze hun problemen, zoals: • Vervuiling door onvoldoende beheer op de gegevens. B.v. een 20 jaar oude applicaties waarin gegevens niet op een geordende manier zijn gearchiveerd bevat een heel scala aan leveranciersrecords, van actueel tot totaal achterhaald • Beperkingen opgelegd door de oude data formaten. B.v.: in de legacy applicatie konden gegevens niet genormaliseerd worden. 1 op 1 overzetten van die gegevens naar de ERP module levert dus meteen een valse start op waardoor de functionaliteit van de ERP module minder bruikbaar is. Dubbele leveranciergegevens maakt beheer van die gegevens lastiger Moraal: neem bij migratie het gebied ‘gegevens’ als volwaardig aandachtsgebied mee. 1 op1 migratie levert bijna altijd beperkingen op in het gebruik van de nieuwe voorzieningen – waar de migratie juist om begonnen was.
3. Sta open voor de mogelijkheden van het nieuwe Waarom investeren we in een nieuwe voorziening? Kosten kunnen een reden zijn maar vaak is het nieuwe en uitgebreidere functionaliteit die ter beschikking komt. We moeten de flexibiliteit hebben om de totale enterprise architectuur in beschouwing te nemen..Vernieuwing op 1 gebied kan nog veel effectiever worden als we bereid zijn ook op andere gebieden verandering te accepteren. Het belang van volwaardige data migratie hebben we hierboven al aangegeven: een nieuwe applicatie vullen met legacy data is geen goed idee. Het implementeren van een nieuwe applicatie zonder oog voor de mogelijkheden in de aanpalende gebieden - informatie, processen, workflow – ook niet. De krachtenvelden maken duidelijk dat ‘vernieuwen omdat het nu eenmaal kan’ ook beperkingen heeft. Moraal: maak optimaal gebruik van nieuwe mogelijkheden, binnen de grenzen van de krachtenvelden. De keuze daarin zal per situatie verschillend zijn.
4. Periodiek opfrissen maakt slopen makkelijker Alles wat gebouwd wordt, zal vroeg of laat gesloopt worden (op een enkele uitzondering na). In de IT wereld lijkt dit besef te ontbreken. We doen meestal alsof wat nu ingevoerd wordt, het eeuwige leven zal hebben. Periodiek opfrissen is vaak arbeidsintensief, maar maakt sloop makkelijker en verlaagt kosten. Denk aan het implementeren van nieuwe versies, het onderhouden van documentatie en kennis, het actief beheren van data inclusief opschonen, archiveren. Moraal: actief beheer helpt als er gesloopt moet worden.
Tot slot De brandweer bouwt een nieuwe kazerne, verhuist en sloopt. In onze wereld moeten we meer oog hebben voor verhuizing: data zijn het geheugen van een organisatie; die kun je maar beter niet kwijt raken. Slopen is dan zonder meer een misleidende term. De kasten uit de oude kazerne passen niet zonder meer in de nieuwe. In onze wereld geldt dat voor data: migreer ze maar zo dat ze optimaal bruikbaar zijn in de nieuwe omgeving. Glijden we in de nieuwe kazerne nog steeds langs palen naar beneden, als de auto’s moeten uitrukken? Of zijn daar veel betere methoden voor? Regelmatig de zolder opruimen helpt, als je gaat verhuizen.
Auteur Jan Mulder is als solution architect werkzaam bij HP Services. Zijn expertise ligt op het gebied van systeem integratie en het verwante gebied van data migratie.
