Managed hosting door True
Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Cloud lost legacy problematiek niet op

 

Cloud leveranciers zien cloud computing als de heilige graal. Maar cloud computing is geen oplossing voor verouderde it-systemen (legacy) waar zo veel organisaties nog mee worstelen. En soms is het ook geen oplossing voor nieuwe systemen. Er zijn erg veel voetangels en klemmen die opgelost moeten worden voordat cloud computing een succes kan worden, ondanks de vele beloftes die deze nieuwe techniek potentieel in zich herbergt.

Dat grote organisaties te kampen hebben met grote, verouderde, it-systemen is geen nieuws. Met name grote organisaties, overheid, multinationals, banken, verzekeraars, die in de jaren zeventig systemen hebben gebouwd op de klassieke wijze met een groot datacenter, moeten jaarlijks vele miljoenen betalen om de oude systemen in de lucht te houden. De systemen zijn enerzijds de motor, die deze organisaties hun regelmatige inkomsten verschaffen (zoals salarisstrookje, bankovermaking, belastingaangifte, rekeningovermakingen), anderzijds de ballast die vernieuwing in de weg staat en miljoenen opslokt aan onderhoud.

Vergane glorie?

Het zijn systemen die in de loop van de jaren al maar uitgebreid zijn om steeds meer mogelijk te maken, die onderling gekoppeld zijn of worden, om er meer informatie uit te halen of andersoortige berekeningen mogelijk te maken, maar in wezen zijn veel van deze systemen in de kern niet veranderd sinds de jaren zeventig. De vergelijking met oude binnensteden, waar we een metro of andere nieuwe infrastructuur willen aanleggen terwijl het gewone leven doorgaat dringt zich op.

De verouderde besturingssystemen waarop de it-systemen draaien worden in de lucht gehouden door de klassieke leveranciers met hun consultants en een veelal verouderende groep werknemers. Het is onder andere de wereld van algol, een programmeertaal uitgevonden in de jaren zestig met vele varianten.

De eerste keer dat de problemen met legacy in de openbaarheid kwamen was tijdens de millennium wisseling. Vele gepensioneerde werknemers werden toen teruggehaald, om de oude systemen in hun kern aan te passen aan de millennium problematiek, waar bij de bouw van de systemen nooit rekening mee was gehouden. Hoewel dat in enkele gevallen geleid heeft tot een grondige vernieuwing van de systemen met nieuwe technologieën, liet de korte reparatietijd tot de millennium wisseling meestal niet toe om de grootste en meest complexe systemen daadwerkelijk te vernieuwen.

Wel zijn en worden allerlei technologieën toegepast om het onderhoud op legacy te verminderen. Bijvoorbeeld door systemen ‘in te pakken’ in een nieuwe applicatie laag en de benodigde data er uit te halen en te verwerken in een ander systeem. Dit alles neemt niet weg dat ooit de legacy spaghetti moet worden ontmanteld. Totale nieuwbouw is echter erg duur en veel bestuurders zien er vanwege alle risico’s als een berg tegen op.

Architectuur ontbreekt

Wat zich hier ook vaak wreekt is dat vrijwel overal een behoorlijke architectuur ontbreekt, waardoor het erg moeilijk is delen van oude systemen te vervangen zonder risico’s voor andere delen van het systeem. Wat wel gebeurt, en dat heeft alles te maken met de digitalisering van de samenleving, is dat nieuwe concurrerende bedrijven zonder legacy ballast met nieuwe systemen uiteindelijk oude bedrijven met legacy uit de markt prijzen. Zo worden Internetbanken of bankieren via Google ongetwijfeld op termijn een serieuze bedreiging voor klassieke banken en datzelfde zien we in andere sectoren.

Het verplaatsen van de legacy spaghetti naar de cloud lost uiteraard het onderhoudsprobleem op de legacy niet op. Wel kunnen schaalvoordelen behaald worden in de infrastructuur. Immers je bent verlost van je eigen datacenter en de cloud provider kan een gemeenschappelijk center vaak efficiënter draaien voor meerdere klanten.

Juridische effecten

Er is echter een nog veel fundamenteler probleem met cloud computing dat nu met name op Europees niveau aandacht krijgt. Het verplaatsen van je bedrijfsdata naar de publieke cloud heeft allerlei juridische effecten. De huidige wetgeving in vrijwel alle landen gaat er van uit dat de locatie waar data staat bepaalt welk juridisch regime geldig is. Deze wetgeving is logisch in de oude wereld, waarin informatie schriftelijk is opgeslagen in gebouwen die eventueel bewaakt worden. Maar deze juridische benadering is onzinnig in een tijd waarin data op grond van technische of efficiency overwegingen in een split second verhuist van Almere naar China, India of Opper Mongolië. Immers dat is één van de grote voordelen van de cloud.

Maar Amerika met zijn Patriot Act behoudt zich het recht voor op grond van terrorisme bedreiging, inzage te mogen hebben in de data van alle Amerikaanse bedrijven, ongeacht waar die gevestigd zijn of waar ze data van hun klanten bewaren. Veel landen verbieden het om data van burgers buiten de landsgrenzen te bewaren.

Wetgevingsregime

De Europese Commissie streeft met grote ijver naar een situatie dat we tenminste in Europa tot één wetgevingsregime komen rond bijvoorbeeld Data Protection. Maar Europa zou Europa niet zijn als niet vrijwel alle landen zelf bezig zijn met eigen cloud wetgeving. Alsof een digitale cloud zich kan houden aan landsgrenzen. De voordelen van de cloud dreigen zo kapot gemaakt te worden door nationaal denkende politici, die het maar niet lukt op het gebied van it tot minimaal Europese, maar bij voorkeur wereldwijde afspraken te komen. Door al deze perikelen zijn grote bedrijven, maar overigens ook overheden zelf, buitengewoon terughoudend om hun data in een publieke cloud-omgeving te plaatsen. De vele technische en efficiency voordelen ten spijt zien we dat grote organisaties nog vrijwel geen gebruik maken van de mogelijkheden van de cloud, behalve met minder kwetsbare applicaties of uiteraard binnen hun eigen private (juridische) cloud omgeving. 

Peter Hagedoorn, secretaris-generaal van de European CIO Association

Dit artikel is afkomstig van Computable.nl (https://www.computable.nl/artikel/4978513). © Jaarbeurs IT Media.

?


Lees meer over



Lees ook


Partnerinformatie
 

Reacties

Gedegen stuk al is dit al regelmatig de revue gepasseerd. Zoals ik al een tijdje roep zijn de twee grootste obstakels Legacy en Privacy. En inderdaad, een nieuwe onderneming zonder deze legacy kan het de huidige grootmachten zeer moeilijk maken als zij zelfde producten aan gaan bieden op basis van nieuwe architectuur.

Persoonlijk ben ik in theorie erg voor 1 Europa en zie ik de voordelen, aan de andere kant wantrouw ik het "centrale regime" omdat zij niet transparant is, er allerlei machten op de achtergrond spelen en de lokale (NL) regering inzichtelijker is dan die van Europa. Dus of we ooit echt gaan profiteren van schaalgrootte, ik zie het nog niet goed gebeuren en als ik als voorbeeld de het SEPA gedrocht zie houd ik mijn hart vast.... Ik heb niet het idee dat "Europa" zijn inwoners centraal stelt.

Hear, hear!

Oude code en nieuwe infrastructuur lost inderdaad niet de problemen op, server virtualisatie was leuk om de fysieke footprint in datacentra te verkleinen maar liet veel problemen onbenoemd. Even voor de duidelijkheid, de legacy zit niet alleen in 40 jaar oude code zoals COBOL maar ook in nieuwere oplossingen zoals bijvoorbeeld Visual Foxpro of andere RAD tools die ondertussen al lang niet meer door leveranciers ondersteund worden. En afhankelijk hoe je legacy definieert kan het ook systemen betreffen die nog nog wel ondersteund worden maar waar onderhoudskosten zo hoog van zijn dat het economisch niet rendabel meer is, het domino effect zullen we maar zeggen.

Misschien dat je deze last naar de cloud kunt schuiven - lees uitbesteden - maar dat is net als met eerdere virtualisatie uitstel van executie. Vroeg of laat zul je legacy toch moeten migreren of uitfaseren en ervaringen leren dat je dat beter in-huis kunt doen, bijvoorbeeld om eerst de technische, juridische en organisatorische impact inzichtelijk te maken. Dat je data in een split-second kunt verplaatsen is tenslotte maar een halve waarheid, niet alleen de omvang is bepalend maar ook de ontsluiting en beveiliging tenslotte.

P.S.
Europa is helemaal niet bezig met Data Protection, ze zijn vooral druk met het redden van alle banken die jaren lang de legacy in hun datacentra genegeerd hebben maar nu met de neus op de feiten gedrukt worden. Feiten die een beetje anders liggen dan hier gesteld wordt want het is nogal goedkoop om leveranciers de schuld te geven. Als dat spelletje gespeeld wordt zullen ze met de billen bloot moeten om alle producten die ze zelf geleverd hebben.

Ik volg hier graag mijn twee voorgangers Henri en Ewout. Maar dat dan eigenlijk meer vanuit een wat recentere ervaring waarbij een legacy PC bij de NS omviel van antiquiteit en plots het hele wisselnet van Utrecht e.o. plat ging. dat als voorbeeld in de marge.

Terecht word opgemerkt dat dergelijke legacy nog ruimschoots voor handen is. Ik wijt dit overigens ook wel een beetje aan een flinke dosis 'laidback' mentaliteit van sommige IT grossiers en IT professionals die uit angst voor een bepaald politiek veld niet hun mond open durven doen in de angst dat....

PS Ewout
Ik begrijp een beetje dat Banco Popular op omvallen staat. Ik volg die berichtgeving in het kader van ons EU dominospel van heel dichtbij. Zou ik dan toch een weddenschapje winnen? (1e bank die echt om gaat een Spaanse, inzet € 100,- 1: 20) ;O)

Ik sluit me aan bij NumoQuest. Goede toevoegingen Ewout en Henri!

Verbaas me wel enigszins op de algemene aanname dat legacy perse vervangen zou moeten worden. Als het nog werkt, rendeert en iedereen er nog blij mee is dan hoeft dat niet. Met wat je uitspaart kan je bewaren voor het moment dat het wel verstandig is om te vernieuwen.

Wat dat betreft maken ons teveel druk om het moeten veranderen omdat de IT nou eenmaal gaat om veranderingen. En vanwege het feit dat de software leveranciers ons min of meer dwingen met hun update regiment mee te gaan.

"Bijvoorbeeld door systemen ‘in te pakken’ in een nieuwe applicatie laag en de benodigde data er uit te halen en te verwerken in een ander systeem."

Voorbeelden graag.

@Johan. Het artikel geeft volgens mij prima antwoord op je vraag. Het onderhoud is duur, miljoenen lees ik. Men heeft dus het gevoel dat er bespaard kan worden omdat nieuwe technologie goedkoper is, beter schaalt etc. Maar migireren is lastig, door technische en nontechnische zaken.
Misschien inpakken een deel van de oplossing zijn :-P

Typisch een ICT gedachte om legacy vooral te blijven koesteren. Het mainframe, cobol, achterhaalde protocollen, inefficiëntie in systemen en om over changes en vertragingen in business proces innovatie nog maar te zwijgen.
Er is maar 1 motto, legacy zo snel als mogelijk uitfaseren door moderne systemen, dus niet vervangen voor nieuw maatwerk. Met deze aanpkla komt de clouid dan ook sneller in beeld.

@Johan Duinkerken
Is mijn idee ook. Legacy systemen zijn meestal vrij stabiel. Als iets goed werkt, moet je er niet aan komen. Een goed draaiend legacy systeem is vaak pure winst. End of support dates geven vaak het einde al aan, maar soms kan extra support voor een kleine meerprijs worden geregeld. Meestal is dat tevens het sein om dringend aan iets nieuws te gaan denken.

Wat betreft de cloud : virtualisatie en consolidatie zijn mooie begrippen maar hebben als een nadeel dat het bijna onmogelijk is om hypervisorlaag te patchen omdat dat de beschikbaarheid van de systemen die erop draaien, aantast. Ook hypervisors zijn gevoelig voor hacks, zoals onlangs bij OpenSSL.org is aangetoond.

@JohanDuinkerken Legacy lijkt wel het kwaad van alles. Onterecht, ben het ook zo eens met wat je schrijft, de allereerste en meest essentiële vraag die gesteld zou moeten worden is of het voldoet. Heb het al een paar keer geschreven, legacy kan ook staan voor bewezen en betrouwbaar. Het zal even slikken zijn voor de continu verander coach.

Als het over legacy gaat dan komen vaak de termen, groot, oud, traag, spaghetti, verloren kennis naar voren. Alsof er een paar oude rokende piepende machines in een hoekje staan. Een leuke karikatuur die het goed doet maar niet waar is. Natuurlijk zijn er ook op hardware en software gebied ontwikkelingen geweest. Alles gaat mee.

De schrijver schrijft ook dat bestuurders het niet aandurven om maar even de grote legacy systemen, inderdaad de motor van veel organisaties, te vervangen. Dat lijkt me heel slim van de bestuurders, dat zijn pas ICT professionals dacht ik. Vervanging en nieuwbouw van systemen is een heel risicovol pad. Er zijn voorbeelden te over van dit soort ambitieuze geldverslindende gedrochten die niet brengen wat je ervan verwacht. Heel terecht om daar conservatief mee te zijn, zeker als het om zulke belangrijke systemen gaat.

Er is legacy en legacy in de voorbeelden die genoemd worden. Met grote cobol mainframe systemen zal weer anders zijn dan de visual foxpro applicatie. Maar legacy is een rekbaar begrip, het kan inderdaad ook opgaan voor de applicaties die gisteren ontwikkeld zijn. Als alle kennis niet meer aanwezig is dan kan je zelfs de software gisteren gebouwd met al die nieuwe middelen al legacy noemen. Zeker met nog ingewikkeldere omgevingen en de trend dat documentatie niet zo belangrijk is zou je je wat dat betreft meer zorgen moeten maken over de legacy van vandaag.

Als legacy en het gebrek aan kennis een probleem is dan lijkt me het verstandig om juist te investeren in die kennis. Want ik vraag me ook af, hoe wil je nu iets opnieuw bouwen of onderdelen vervangen als je niet eens weet wat je opnieuw moet bouwen? Het idee mag wel leven dat technische ICT'ers volledig uitwisselbaar zijn maar dat is natuurlijk niet het geval. Daar zit vaak ook de kennis van de systemen in des te belangrijker om dat te koesteren en daarin te investeren. Continuiteit is belangrijk voor de kwaliteit van software. En met reverse engineren is niets mis, het is zo een beetje waar je mee begint als je weer op een nieuwe klus terecht komt. Gooi daar dan je geld tegenaan.

Verder lijkt me dat als je denkt dat er verbeteringen aan de systemen nodig zijn dat je dat eerder stapsgewijs doet en met beleid dan in ene alles proberen te vervangen. Mocht er een externe leverancier of consultant langskomen die zegt dat de software niet deugt, de mensen niet deugen en alles moet anders: dan moet je als CIO op je tellen passen lijkt me.

De cloud lijkt me niet zo relevant voor het legacy 'probleem', hooguit een verplaatsing van het probleem en extra complicerende factor. Gedoe om niets.

@Louis

Mooi betoog en een goed onderbouwde mening

"Legacy kan ook staan voor bewezen en betrouwbaar", inderdaad Legacy staat in mijn ogen voor een bewezen systeem... wat echter verouderd is.

Wat betekent die verouderd? Dat de kosten jaarlijks oplopen, dat de performance lastig te verbeteren is, dat kennis over het systeem steeds minder beschikbaar is (ook een kostenaspect) en dat de uitbreidbaarheid of aanpasbaarheid klein is.

Of legacy beter vervangen kan worden is totaal afhankelijk van de business case.

Legacy vervangen is een risico, juiste omdat systeem bewezen werkt. Maar legacy is vaak ook een "technical debt". Er zijn keuzes gemaakt om iets aan te houden, maar al die keuzes bouwen een schuld op die exponentieel hoog kan worden. Dat maakt het aan de ene kant nog moeilijker om over te stappen omdat alles met alles verbonden is. Vergeten kennis over een systeem is ook technical debt overigens, en technical debt is een serieus probleem bij systemen die lang aangehouden worden.

Legacy aanhouden is ook een groot risico, juist omdat het die oplopende kosten met zich mee draagt. Het gevaar is namelijk dat de legacy die een primaire bedrijfsproces ondersteund ook goedkoper opnieuw kan worden aangekocht door een concurrent waardoor die zijn proces kan (kosten) optimaliseren en jij met je legacy jezelf dus uit de markt plaatst.

Het legacy probleem is dus meer dan een stukje techniek.

Elk systeem wordt uiteindelijk legacy, alleen sommige systemen hebben langere lifecycles dan andere. Banken weer als voorbeeld. Omdat die legacy heel erg in de business verweven is en dus alle banken hetzelfde probleem hebben is deze legacy een lang leven gegeven. Andere proposities hebben blijkbaar geen ingang om legacy systemen te omzeilen en hiermee een betere propositie kunnen maken naar de klant. Dit is ook de reden waarom Google nog geen bank is en ook nieuwkomers zoals PayPal in feite nog steeds volledig leunen op legacy systemen.

Nu de relatie naar cloud.

Cloud belooft flexibiliteit, betalen naar gebruik, goedkoper dan niet cloud, oneindige wendbaarheid, maar cloud is in de praktijk vaak gestoeld op infrastructuur en infrastructuur is een andere propositie dan een legacy systeem. Legacy heeft vaak veel meer functionele waarde-het is een systeem- terwijl cloud een utility is.

Dus cloud heeft geen directe relatie moet het afscheid nemen van legacy.

Er zijn echter cloud diensten die steeds functioneler worden, een ander type database of service bus of gewoon echt invulling geven aan bijvoorbeeld boekhouden of ERP. Dit zijn echter diensten en hebben vaak niet zoveel te maken met cloud anders dan uitbesteden en over het internet.

However, de diepere propositie die cloud computing biedt is een opzet mogelijk maken die schaalbaar, veerkrachtig en duurzaam is. Door systemen te laten landen op SDI of cloud computing diensten en door diensten te ontwerpen die hier goed op aansluiten verleng je de mogelijke life-cycle van systemen en kunnen deze automatisch meebewegen als bijvoorbeeld de processoren of dataopslag sneller worden. Door te denken in architecturen voor cloud computing maak je systemen die veel toekomstvaster zijn.

Kortom: Legacy *is* een groeiend probleem wat een keer aangepakt moet worden, anders doet de concurrent het wel. Maar cloud computing is niet per se de oplossing alswel een hint in welke richting je moet denken....

Kleine aanvulling op "dat de uitbreidbaarheid of aanpasbaarheid klein is. " en de relatie tot technical debt.

Wat ik bedoel is dat bijvoorbeeld de legacy van banksystemen enorm zijn uitgebreid met internet bankieren, mobiel pinnen et cetera, maar dat deze verbeteringen nog wel gestoeld zijn op legacy en dus ook vervangen of aangepast worden als de legacy vervangen wordt en dat elke "verbetering" en aanvulling ook weer een extra technical debt is. Met andere woorden; het wordt *nog* moeilijker en duurder om afscheid te nemen van legacy.

Zoals Peter van Eijk eens mooi quote (bron ontbreekt): "The better your fourwheel drive, the further out you get stuck in the jungle"

@Henri Uiteraard eens met je opmerking dat de cloud geen directe relatie heeft me legacy maar ook dat het meer is dan techniek alleen. Ik twijfel over je opmerkingen over performance en verder ben ik benieuwd waar die oplopende kosten in zitten. Kosten lijken mij normaal. Ik verzet me tegen de mening dat legacy een probleem is omdat het legacy is. Het zou mooi zijn als iemand ingevoerd in deze oudere systemen hier iets over kan zeggen.

En het is inderdaad meer dan techniek, deze legacy systemen vormen ihgv banken het hart van de administratie en zijn bepalend. Het zijn volgens mij vaak batch georienteerde systemen. De systemen waarop wij realtime bankieren is volgens mij niet de echte administratie en wordt er ongetwijfeld met schaduwsystemen gewerkt die min of meer los hiervan staan. Dus geloof ook niet dat legacy daarin beperkend is. Ik twijfel of organisaties er wel op zitten te wachten dat die cruciale adminstratie rechtstreeks aan het inerntet gehangen worden. Ik denk het niet, in die zin is die legacy het slot op de deur en is dit model wenselijk. Maar ook daarover zou een kenner vast meer over kunnen zeggen.



@Louis,

Hierbij nog even de kenmerken van legacy waardoor migratie naar een gelaagde architectuur op den duur noodzakelijk is:

1. Dataredundantie:
hetzelfde gegeven is in meerdere applicaties vastgelegd, hetgeen inconsistenties tot gevolg kan hebben; denk bijvoorbeeld aan het vastleggen van adresgegevens binnen verschillende applicaties.
2. Functieredundatie:
dezelfde functionaliteit komt op meerdere plaatsen in dezelfde en/of andere applicaties voor, wat de gevolgen van aanpassingen steeds ondoorzichtiger maakt.
3. Verwevenheid van functionaliteit en data:
functionaliteit is geprogrammeerd in 3GL of 4GL in combinatie met platformafhankelijke databasetechnologie.
4. Verwevenheid van functionaliteit en flow/procesbesturing:
functionaliteit bevat instructies voor de afwikkeling van de workflow, bijvoorbeeld de status verwerking van een bepaalde entiteit, waardoor hergebruik van deze functionaliteit sterk wordt bemoeilijkt.
5. Verwevenheid van applicaties:
door veel 1-op-1 koppelingen tussen applicaties hebben wijzigingen een sneeuwbaleffect in een oerwoud van processen.
6. Batchverwerking:
Legacy is vaak sterk batchgeorienteerd, hetgeen haaks staat op het realtime afhandelen van klantwensen door middel van selfservice (zoals jij ook opmerkt in je tweede reactie).
7. Ontbreken van een architectuur - zie opiniestuk - heeft de punten 1 tot en met 5 als gevolg, maar maakt het ook onmogelijk om optimaal gebruik te maken van de mogelijkheden van cloud-computing (riching een hybride cloud); niet voor niets wordt een ESB als voorwaarde voor SOA soms een ‘pré-cloud broker’ genoemd.
8. En tot slot het punt wat jij in je eerste reactie als kenmerk van legacy aanduidde:
Functionaliteit is soms slecht beschreven of ontbreekt en bovendien is de kennis niet (altijd) meer aanwezig.

Als gevolg van deze kenmerken is legacy dus steeds moeilijker aan te passen aan veranderende bedrijfsomstandigheden, zoals veranderingen in de markt, de wetgeving en de technologie.

In die gevallen is conservatisme dus geen optie.

Vacatures

Stuur door

Stuur dit artikel door

Je naam ontbreekt
Je e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×