Software doet bijna altijd wat het moet doen. Soms doet de software het niet, dan kan je even niet bij de webpagina van een leverancier. En heel soms maakt de software er een potje van, dan verandert ineens zonder aanleiding het saldo op je bankrekening. Een paar dagen geleden overkwam dat de klanten van een grote Nederlandse bank. Het gevolg: veel ophef, veel emotie, veel imagoschade voor die bank.
Wat was er nu eigenlijk aan de hand? We mogen hopen dat de organisatie zelf inmiddels de oorzaak achterhaald heeft. Op haar website spreekt de bank over ‘een technisch probleem in het boekingsproces’. Voor de buitenwereld blijft het gissen wat dat betekent. In het 8-uur journaal van donderdag 4 april deed hoogleraar informatica Jan Friso Groote een poging:
‘Miljoenen regels oude code met daarin nog duizenden fouten, niemand die meer precies weet wat die regels code doen. En dan moet het soms wel mis gaan.’
Een interessante observatie. Veroudering van code houd je niet tegen, de tijd schrijdt voort. Veroudering van mensen ook niet. It-medewerkers met kennis van zaken gaan met pensioen of gaan ergens anders werken. Een proces dat zich sluipenderwijs voltrekt. Totdat je als organisatie op een onverwacht moment hardhandig geconfronteerd wordt met de gevolgen.
Wat we zien gebeuren komt veel vaker voor, alleen (gelukkig) niet vaak met zo verstrekkende gevolgen. De aanwezigheid van fouten in code, de afnemende kwaliteit van code en kennis over die code (in documentatie of hoofden van mensen) staat in de it bekend onder de term ’technical debt’. Een schuld die met het verstrijken van de tijd steeds groter wordt, als je er niets aan doet.
De problemen van afgelopen week lijken daarmee gekwalificeerd te kunnen worden als een ‘gevalletje technical debt’. Had dit nu voorkomen kunnen worden? Dat zal ik niet zonder meer beweren. Maar, het zou mij niet verbazen als de bank in het verleden onvoldoende haar technical debt heeft gemanaged. Want daar komt het op aan: technical debt is op zich niet onoverkomelijk (en zelfs acceptabel), maar je moet het wel goed managen. Dus tijdig oude software vervangen, tijdig het weglekken van kennis opvangen, et cetera. Op dat vlak kunnen banken, net als veel andere organisaties, wellicht nog wat verbeterslagen maken.
Jacob Brunekreef
Senior adviseur en trainer softwarekwaliteit
Inspearit en Cibit Academy
Ik voel een allergische reactie, maar kan niet precies de vinger erop leggen hoe dit komt. Misschien als ik mijn gedachten deel komt dat vanzelf boven water.
Ten eerste worden er hier heel wat aannames gedaan. Bijvoorbeeld dat de software er een potje van maakt. Ik denk dat dit niet zo is. De reden waarom ik dat zeg is simpel: Hoe hebben ze het dan 100 procent sluitend weer goed gekregen? Als software er een potje van maakt kan het nooit zo zijn dat je dit zomaar op de juiste manier een rollback kunt doen. De software lijkt me dus wel degelijk robuust en stabiel en bovendien beheersbaar. Van technical debt lijkt in dit geval geen sprake.
Ik zie dus ook niet goed wat nu de verstrekkende gevolgen zijn.
Het lijkt ook alsof dit incident gebruikt wordt in combinatie met de recente DDoS-aanvallen.
‘Maar, het zou mij niet verbazen als de bank in het verleden onvoldoende haar technical debt heeft gemanaged.’
Dit vind ik ook weer zeer suggestief en kwalijk. Waarom zou je het niet verbazen? Onderbouw dat dan! In mijn beleving is bankautomatisering zeer robuust en solide. Modern misschien niet, maar ik kan me niet 1 verstrekkend incident herinneren dat de bank er een potje van heeft gemaakt op technisch gebied (crisis heeft andere oorzaak). Dat er bankstoringen zijn heeft tal van redenenen, maar dit zijn vaak de schillen die liggen op de robuuste onderliggende software die in mijn ogen uiterst robuust is.
Wat nu tijdig oude software vervangen? Dit is alleen zinvol als de businesscase zich er voor leent! Wat kost het? Wat levert het op?
Nu weet ik best wel dat de mainframes van banken in relatie tot de complexe materie van geldstromen gedateerd zijn en daarom (zeer) kostbaar, maar blijkbaar zijn er nog geen goede alternatieven omdat dit een wereldwijd probleem is en niet iets wat een bank in zijn uppie even op kan pakken.
Kortom, onterecht stuk, slecht onderbouwd en suggestief.
De principes achter technical debt sta ik helemaal achter. Een prachtige term met diepe inhoud, maar om die materie op deze manier toe te passen lijkt mij zonder onderbouwing kwalijk.
Proof me wrong.
Met mijn eigen ervaring bij een grote organisatie (geen bank) in het achterhoofd kan ik me nauwelijks voorstellen dat een grote bank dermate slecht met de documentatie van zijn software omgaat, dat technical debt bij verwerkingsprocessen in het betalingsverkeer echt een probleem zou kunnen zijn.
Heel bijzonder stuk. Zonder enige bewijs wordt er met de vinger naar de software gewezen. Die is verouderd! Daar ligt het aan. Zit nog bordevol fouten, moet in geïnvesteerd worden, ING investeert te weinig, er ligt een technical debt.
Terwijl niemand nog weet wat er gebeurd is? Wellicht gewoon een gevalletje van een batch twee maal verwerkt? Daarna verkeerd terug gedraaid? Misschien wel gewoon menselijk falen i.p.v. software falen?
Oh wacht, de auteur verdient zijn geld met het adviseren en het trainen in softwarekwaliteit. Wij van WC eend adviseren WC eend.
Ik sluit me graag aan bij de reactie van Henri. Vooral onderstaande zinsnede riep bij mij een allergische reactie op:
*** En heel soms maakt de software er een potje van ***
Tenzij er hier sprake is van zichzelf re-genererende software is dit zo ongeveer onmogelijk. Software wordt bij mijn weten nog steeds door mensen gemaakt, dus als er een potje van gemaakt is, is dat door een mens gebeurd, en niet door de software.
Voor de rest inderdaad zeer suggestief. Hoezoe zou verouderde code een probleem zijn? Ik ken apparaten, draaiend op Windows NT, met miljoenen regels code, die nog steeds al een tierelier werken.
Ik zou het zelfs om durven draaien: de hedendaagse operating systemen zijn van zoveel toeters en bellen voorzien dat ze per definitie al vol met fouten zitten. Hoe kun je daar ooit een stabiel product op laten draaien?
De verouderde producten van miljoenen regels code draaien inmiddels al zo lang, dat daar het gros van de fouten ondertussen wel uit is. Nieuwe producten moeten die cyclus eerst nog door.
Nieuw is misschien wel mooier, maar niet per definitie beter!
@HenriKoppen
Ik kan me vinden in je reactie en ik word zeer knorrig van dit soort ongefundeerde artikelen zonder te weten wat er nu gebeurd is. De quote van de hoogleraar over ‘miljoenen regels code met duizenden fouten waarvan niemand meer weet wat het doet’ die aangehaald wordt is een onverantwoordelijke schot in het duister en als het werkelijk zo zou zijn dan had er nooit iets geklopt van onze saldi en hadden we zelden kunnen internetbankieren. Angstzaaierij. Bovendien, niet te bewijzen en hard te maken ook al is het een feit dat van veel sofware maar weinigen zijn die exact weten hoe en wat het werkt. Fouten zullen er overigens zeker bestaan maar er moet niet overdreven worden. Hetzelfde zou je kunnen zeggen van het operating systeem wat je dagelijks gebruikt, van welk merk ook. Alle software dus. We moeten ergens op vertrouwen en wat je zegt, deze banksystemen werken in de regel prima.
Het enige waar ik me wel in kan vinden is dat het behouden van de technische kennis en het up to date houden van documentatie belanrijk is en altijd aandacht behoeft. Snijden in technisch personeel is dan ook een slechte ontwikkeling. Wat dat betreft vind ik de huidige ontwikkelingen op het gebied van projecten uitvoeren met Agile en Scrum veel zorgelijker. Procesbegeleiders en IT bureaucraten zijn belangrijker geworden dan de technici en van statements als ‘werkende software belangrijker dan documentatie’ wordt ik ook heel naar. Natuurlijk is juiste documentatie belangrijk en essentieel. Een andere slechte ontwikkeling is het outsourcen van belangrijke processen en dat is niet alleen de verantwoordelijkheid over de schutting gooien maar erger nog, je verspeelt je kennis en creeert een dubieuze afhankelijkheid. Een organisatie als de ING zou dat niet moeten willen. Dan heb ik meer vertrouwen in die oude cobol spulletjes, leve de legacy systemen. Die vervang je zoals je zegt niet zomaar en bovendien, ga nooit iets zomaar fixen wat niet stuk is. De gouden regel van de IT.
We weten inderdaad niet wat er nu gebeurd is vorige week. Wat ik las was dat door de veelheid aan transacties in het paasweekeinde in de verwerking een en ander was misgelopen. Ik kan me dan iets voorstellen dat periodieke batchprocessen in het hart van het banksysteem zijn misgelopen (uit het timeslot?) zijn met als uiteindelijk resultaat een verrabbezakt systeem wat het dagelijkse bankieren ondersteunt (dat is niet waar je echte saldo staat). Maar ook dit is suggestief, een insider met verstand van zaken zou daarover mee moeten kunnen zeggen. Maar laten we inderdaad wel het walletje bij het schuurtje houden, de systemen werken vaker wel dan niet en dat is nog een understatement. Dan is dit soort ongefundeerde paniekzaaierij niet op zijn plaats.
Geheel eens met het gegeven commentaar hierboven. Suggestief, niet onderbouwd artikel dat bol staat van de aannames.
Ik ben het niet met Louis eens dat Agile toepassen (btw, Scrum is een Agile methode, net als XP of Crystal Clear) een bedreiging vormt. Het heeft bewezen zeer veel potentie te bieden, maar het vraagt ook wat van de organisatie. Tenzij de invoering van Agile methoden leidt tot de situatie die hij schetst, tja dan kan ik me voorstellen dat het fout afloopt. Maar dan voert een organisatie het ook compleet fout in of op de verkeerde gronden.
Wel ben ik het met je eens dat ik bij veel organisatie een tendens zie om meer te doen met minder mensen waar de grenzen wel langzaam zijn bereikt. Bij ING zie ik dat (it-)personeel met veel ervaring en kennis van hun complexe omgeving (die helaas niet altijd goed gedocumenteerd is) de deur wordt gewezen. Waarbij management vaak ontzien wordt. M.a.w. de situatie van de tien chiefs in de kano met één roeiende indiaan dreigt zo wel te ontstaan. En dat is zorgelijk!
@Louis Kossen, fijne reactie. ‘Dan heb ik meer vertrouwen in die oude cobol spulletjes.’ Het is niet geschreven door programma generatoren waar echt niemand van weet welke transacties er feitelijk plaatsvinden. ‘Old school’, nou en. Kijk naar de gemiddelde internetsite die door een generator of tool is gebouwd, er gebeurt van alles maar ook van alles niet. Maar het initiële doel is vaak niet behaald, en de bouwers hebben geen idee meer. Grote stappen snel thuis…
@Louis Kossen: Zoals Oskar zegt ‘Een fijne reactie.’
De reden overigens waarom ik wel vertrouwen heb in die ‘oude Cobol-spulletjes’ is niet dat ik Cobol nu zo goed vind. Maar dat de mens en het proces erachter zo degelijk was. Tegenwoordig staat alles onder druk en vooral budget en deadline waardoor de scope en kwaliteit het slachtoffer zijn. Dat zie je terug in software, maar ook in de bouw. Laatst kwam ik nog in zo’n oude school van honderden jaren oud. Brede trappen, ornamenten, trapleuningen van steen en zo verder. Zulke dingen worden nauwelijks meer gebouwd.
Sofware ontwikkelingen in nieuwe frameworks zoal bijvorbeeld .Net hebben echt wel ‘leverage’ en zijn best robuust waardoor je sneller kunt programmeren dan als je alles zelf moet doen in Cobol, maar door tijdsdruk en budget is software gewoon minder robuust geworden.
Als je kijkt op de site van Werner Vogels: http://www.allthingsdistributed.com/ dan heeft hij de laatste weken blog posts over ‘Back to basic’ weekend readings. Hij haalt daarin oude artikelen en papers aan die over Transactions en Constraints gaan en dergelijke.
*alle* software ontwikkelaars zouden deze materie moeten lezen. Sommige dingen kunnen nu inderdaad sneller en makkelijker (en solide), maar de principes erachter zijn niet veel veranderd. De tool of taal bepaalt niet de kwaliteit van software, het is de mens en het proces erachter. Daarin zijn geen ‘short cuts’.
Maar nogmaals bedankt en ik hoop dat je vaker reageert!
Nabrandertje: Die suggestie van batchprocessen en timeslots vind ik overigens scherp opgemerkt! Mooie analyse. Ik hoop overigens niet dat dat het was, want dat is echt weer iets wat niet het probleem zou mogen zijn. Of misschien is het een wel een batch/timeslot probleem maar dan van het niet kritische proces. Dus dat de staging area van het internet bankieren slachtoffer werd van de drukte en dat ‘hun’ proces afgebroken werd. En dat het proces opnieuw gestart werd toen er weer ruimte was.
Ik ben gek op dat soort analyses en het zou chic zijn als ING hierover een postume root cause analysis zou publiceren.
Henri is mooi gestart de grootste manco’s van dit stuk aan te halen.
Echter wat ik nog niet genoemd zie worden, is de ‘uitgekristalliseerde’ fase van de programmatuur. Kijk naar sommige van de GNU-tools die ondertussen 25 jaar oud zijn. Daar worden bijna geen nieuwe bugs meer in gevonden.
Nieuwe programmatuur betekent nieuwe fouten, kinderziekten en tekortkomingen die overwonnen moet worden. Feitelijk moet deze problematiek meegenomen worden in de kosten/baten-analyse.
Dit omdat nieuwe programmatuur eigenlijk ontwikkeld zou moeten worden om nieuwe functionaliteit te bieden.