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

Banksaldiprobleem is gevalletje technical debt

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

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

 

Reacties

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.

Reactie van de auteur. Wat ik heb willen zeggen: It wordt steeds complexer, steeds meer van vitaal belang voor de maatschappij. Maar, aan de andere kant, wordt binnen veel organisaties it gezien als 'commodity' – iets dat gewoon z’n werk moet doen en niet veel aandacht moet vragen. In dat spanningsveld is het managen van technical debt een uitdaging die niet altijd voldoende aandacht krijgt. Of dat hier ook het geval was? Ik sluit me aan bij de oproep aan ING om openheid van zaken te geven. Zodat iedereen kan oordelen en er van kan leren.

@Jacob Brunekreef: Sympathiek dat je reageert! Zeker omdat er nogal wat kritiek tussen staat, onder andere van mij, daarom hulde!

Ik sta helemaal achter je reactie. Het is alleen jammer dat ING dan gebruikt wordt om de aandacht daarop te vestigen, effectief is het zeker gezien de reacties, maar niet sympathiek. Daarnaast zijn er wel wat meer dingen op aan te merken dat zoals PaVaKe schrijft 'dat software er een potje van maakt'.

Ik ben benieuwd naar een volgend artikel waarbij je meer in gaat op de inhoud van je reactie. Mijn aandacht heb je :-)

Nog even een reactie.

@JacobBrunekreef Wat je hier schrijft is al iets anders en daar kan ik me beter in vinden. Ben het eens met @henri dat de situatie bij de ING gebruikt (misbruikt) is voor het doen van statements over software die in dit geval misplaatst zijn. Dat vond ik kwalijk. Ik geloof niet eens zo zeer dat software als commodity beschouwd wordt, ik denk eerder dat de mens als commodity beschouwd wordt. Of het is dat je denkt door meer mensen ertegen aan te gooien je projecten kan versnellen of verbeteren of dat technici die applicaties maken, beheren en systemen beheren zomaar inwisselbaar zijn. Continuiteit op dit gebied lijkt mij belangrijk voor de kwaliteit van applicaties en systemen.

@Technicus Volgens mij noemde @PaVaKe dit ook al, de tijd die in het voordeel werkt en in software op leeftijd alle ellende er tzt wel uitgehaald is. Inderdaad, dat traject heeft nieuwe software nog niet doorlopen. Ook tijd hebben voor ontwikkeling helpt.

@maarten Ik hoop ooit hier nog iets over te schrijven, de Agile filosofie en de Scrum (Lean, Kaban,...) methode voor het begeleiden van ontwikkeltrajecten. Je geeft al aan dat de uitvoering hiervan al vragen oproept, dus naast dat vraag hoe de software te ontwikkelen is er ook nog de vraag is hoe het ontwikkelproces in te richten met Agile Scrum etc methodes. Nieuwe abstracties, nieuwe vragen en nieuwe rollen. Ik begrijp wel de achtergrond: aan een kant dat ontwikkelen van software een continu proces is waarbij voortschrijdend inzicht een rol speelt en aan de andere het nodig is voor de opdrachtgever vat te houden op de voortgang. Maar om dat op deze manier te formaliseren en micromanagement tot doel te maken? Zelf heb ik gezien dat voor een redelijk overzichtelijk project de scrum masters met bosjes werden binnengereden en leidend zijn. Het kost een hoop geld en de verkeerde mensen worden belangrijk. Door de technici die ik ken wordt het als een gruwel ervaren, gedegregadeerd tot domme uitvoerder. En dan die bizarre rituelen, zo ken ik een technicus die ieder dag met een standup meeting begint, alleen tegen de scrummaster mag praten om vervolgens te eindigen met de groepsyell. De padvinderij is er niets bij vergeleken. Praten met andere belanghebbenden is verboden, dat mag alleen via de scrummaster (leve het informele circuit!). Ik ga dan liever voor een meer basale aanpak met het liefst niet te veel mensen en rollen waarbij je je wat kan voorstellen: projectleider, technisch projectleider, project manager, ontwikkelaar, tester, informatie analist en documentatie deliverables (buiten de software) die welliswaar uit de oude doos zijn (bv reguirements document, functionele specs, technisch ontwerp, architectuur plaatje, user manual, operational manual) maar nog prima voldoen. Maak er niet meer van dat het is. Ik realiseer me dat het misschien vechten tegen windmolens is want ik zie dat het gemeengoed aan het worden is en er een hele industrie van opleidingen en certficeringen is ontstaan. Je voorbeeld van 10 chefs in een kano met 1 roeiende indiaan vind ik mooi en ook hierop van toepassing. Aan de andere kant als je er met zijn allen in gelooft komt er ongetwijfeld iets uit. Voor vrije jongens is het niets.

Nu de ontkoppeling van de ING storing is gemaakt, wil ik ook nog wel iets toevoegen:

Er is een verschil te maken tussen eenvoudige UNIX tools en complexe, organisch gegroeide bedrijfssoftware. Dat een tool na verloop van tijd foutvrij is en volledig begrijpbaar herken ik. Ook weet ik uit mijn eigen achtergrond als SW-ontwikkelaar dat in complexe code allerlei kleine, bijna verborgen afwijkingen die op het moment van implementatie logisch lijken, maar jaren later voor een probleem kunnen zorgen. En zo heb ik direct een beeld bij de 'technical debt' waar Jacob het over heeft.

Je kunt je daartegen wapenen, maar dat vergt defensief programmeren, tussenresultaten controleren en valideren. 100% dekkend kun je daarin niet zijn. En dus begin je technical debt op te sparen...

Een verlate reactie, maar wie het denkt te beweren dat code zou kunnen verouderen heeft blijkbaar geen benul van software ontwikkeling.
Software is immers een momentopname van de abstracte gedachten van de mens. Of liever gezegd de meeste software. Er zijn al diverse prototypes gemaakt van zelflerende software maar of dit ooit bij financiele instellingen gebruikt zal worden is vooralsnog niet aannemelijk.

@Lex: Ja, maar wie maakt die code dan ook complex?

K.I.S.S. is een bekende uitdrukking binnen de IT en staat voor "Keep it simple, Stupid!"

Ook Schwartz schrijft iets in zijn boek "Learning Perl" over "readability" en dat je leesbare code moet schrijven, maar goed zelf zie al vaak dat nodes de vreemdste naampjes krijgen alsof het door bijvoorbeeld een botanicus bedacht is.

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

×
×