Internetbankieren bij Britse bank ligt al zes dagen plat door softwaremigratie

TSB, een Britse bank met 1,9 miljoen klanten, heeft al zes dagen te maken met ernstige verstoringen. De omgevingen voor internetbankieren en bankieren via een app zijn uitgeschakeld. De problemen doen zich voor sinds een softwaremigratie.

Klanten van TSB kunnen momenteel niet internetbankieren of gebruikmaken van de app, maar er zijn meer problemen. Zo kregen sommige klanten per ongeluk de gegevens en rekeningen van andere klanten te zien en zouden ze daar ook toegang tot hebben gehad. Zo zegt een klant tegen de BBC dat hij toegang had tot de spaarrekening van iemand anders. De bank heeft toegegeven dat dit zondagavond het geval was en betrekking had op 402 klanten. Ook zouden er problemen zijn met pinnen en het uitvoeren van betalingen.

TSB was oorspronkelijk onderdeel van Lloyds Bank, maar werd in 2015 verkocht aan het Spaanse Banco Sabadell. Aanvankelijk bleef Lloyds de it-infrastructuur beheren, maar daar is nu een einde aan gekomen. Bij het overzetten van 1,3 miljard klantenrecords naar het bankplatform Proteo4UK, dat is gemaakt door Sabadell, zijn de problemen ontstaan.

The Guardian houdt een liveblog bij over de problemen. Daarop staat dat de ceo van de bank zegt dat de problemen te maken hebben met een gebrek aan bandbreedte. De app zou moeite hebben met een groot aantal gelijktijdige gebruikers.

Eerder op dinsdag beloofde de ceo dat de diensten 's middags weer zouden werken, maar die belofte werd niet waargemaakt. Nu zegt te hopen dat de diensten vanavond weer online zijn, hij merkt echter op dat hij de it-medewerkers heeft opgedragen de diensten pas online te zetten als ze 'echt klaar zijn'. Volgens de ceo is de migratie van klantgegevens de grootste ooit in Europa.

Banco Sabadell, eigenaar van TSB, heeft maandag een persbericht online gezet waarin het de succesvolle migratie viert. Dat bericht is inmiddels weer offline gehaald, waarschijnlijk vanwege de problemen, maar nog te lezen via de cache van Google.

De problemen bij de Britse bank doen denken aan de langdurige storing die zich begin deze maand voordeed bij de Belgische bank Argenta. Daar hielden de problemen een week aan en werd ook internetbankieren en de app voor mobiele betalingen uitgeschakeld. Ook daar was een migratie naar een ander bankplatform oorzaak van de storing.

Reacties (106)

[lenwar]

Ik spreek uit persoonlijke ervaring bij meerdere financiële instellingen dat dat inderdaad klopt. Financiële instellingen hebben te maken systemen die jaren en jaren oud zijn en nooit fatsoenlijk zijn bijgewerkt door softwareleveranciers.
Die leveranciers hebben in bepaalde gevallen (vrijwel) unieke functionaliteit en hebben daarmee hun klanten bij de ... lurven . Het wegmigreren van die systemen is extreem complex en HEEL erg duur.

Er zijn nog menig COBOL systemen bij dit soort instellingen, en aan de andere kant van die systemen zitten dus moderne applicaties aan de web-kant. Dan heb je vervolgens nog te maken met interne bedrijfspolitiek en culturele historie binnen dit soort organisaties (zoals bij elk groot bedrijf). Dit helpt in z'n geheel ook niet.

Daarnaast heb je nog te maken met internationele regelgevers. Regelgever 1 verplicht punt A en regelgever 2 verbiedt dat juist weer. Dan krijg je bijvoorbeeld te maken dat twee systemen fysiek (firewalls is veelal voldoende, maar ook niet altijd) nooit met elkaar moeten kunnen praten. (als in het mag 'niet mogelijk zijn'). Je complete infrastructuur raakt hierdoor dus compleet versplintert en zeer complex om te onderhouden.

Dit zorgt ervoor dat het eigenlijk een klein wonder is dat het allemaal zo goed werkt als dat het uiteindelijk doet.

Uiteraard is elke verstoring er één te veel, maar het is zeker niet vreemd dat het zo nu en dan is goed mis gaat. Al moet ik wel zeggen dat een verstoring van 6 dagen wel ERG extreem is. Ik vermoed dat de betreffende toko binnenkort een verslag en uitleg aan de Bank of England en de ECB mag geven, want dit gaan dit niet tof vinden zacht gezegd.
Ik heb het al-met-al te doen met de betreffende ICT'ers die dit moeten fixen.

[batjes]

Het is inderdaad bijna een waar wonder dat het grotendeels zo probleemloos verloopt voor ons gebruikers. Onze banken doen het zo slecht nog niet, de uitval die we hebben duurt maximaal een paar uur, en wij horen uit het buitenland enkel dit soort extremen.

[Cergorach]

Nou... Je heb geen flauw idee wat er allemaal mis gaat bij banken! Ik heb er zelf ook gewerkt en inderdaad zijn migraties/updates enorme zwakke punten, je kan nog zoveel testen in een schaduw omgeving maar op (oudere) productie hardware en alle productie data gaat er veel, VEEL mis. Vaak worden de meest simpele dingen over het hoofd gezien omdat het vaak een grote logge organisatie is, met veel 'vast geroest' personeel.

Omdat er tegenwoordig alles realtime moet gebeuren en we nu allemaal internet hebben, valt het veel meer op, maar vroeger (10-15 jaar geleden) was het al opgelost voordat het nieuwswaardig was. Mensen die een ochtend niet konden pinnen omdat een batchjob was uitgelopen, 's ochtends vroeg om 6-7 uur met een rotgang je omgeving terug rollen omdat een update toch niet helemaal lekker werkt. En wie zal ooit hebben gemerkt dat onze email servers er een week uit hebben gelegen (in het NT4 tijdperk duurde een Exchange cluster restoren schandalig veel tijd). Dat je toevallig tijdens het thee halen moet horen dat ze vanavond het 'systeem' tot 22:00 open laten, dat de communicatie met een half uur de deur uit gaat naar de klanten en ze niet de juiste personen van it hadden aangesproken op de haalbaarheid van het geheel. De nachtelijke backup begon al heel vroeg op de avond (19:00) en duurde tot in de ochtend 8:00-9:00 (en soms nog later), daar moest eerst een hele grote investering voor een AS400 worden goedgekeurd met nieuwe taperobots, etc. voordat we de backup terug konden dringen zodat deze na 22:00 kon beginnen...

De software ontwikkelaars van dergelijke systemen hebben zo vreselijk veel macht en leveren vaak zo bagger werk tegen een enorm hoge prijs dat je geen kant op. Directeuren/IT Hoofden hadden/hebben bij banken hebben vaak inhoudelijk geen kaas gegeten van de materie en huren een bedrijf in om software te ontwikkelen, maar vergeten contractueel vast te leggen dat het broncode van de bank is. Zit je voor de levensduur van het pakket vast aan die specifieke leverancier en omdat je er toch niet af kan zetten ze echt niet hun beste beentje voor.

[kidde]

Vast een domme vraag, maar dan heeft zo'n bank niet alleen 'geen broncode', maar ook geen spec en dus naar ik aanneem geen unit tests?

Komt dat dan niet ongeveer neer op reverse engineering?

[lenwar]

De broncode kan je niet per definitie wat mee. Het is leuk als je kan programmeren, maar dat kost natuurlijk gigantisch veel tijd en energie waar je je als financiele organisatie niet per definitie mee bezig wil houden. ("Want wij zijn bankiers, en geen softwarehuis")

Uiteraard heb je wel alle specs en unit tests en heel de bende, maar stel dat je core componenten gaat migreren, want de onderliggende hardware raakt uit support (en het OS waar het op draait ondersteund de nieuwe hardware niet, dus je moet je OS migreren, en je middlwarelaag ondersteund dat nieuwe OS niet, dus die moet ook, en je applicatie dus ook). Je hebt honderden systemen die als een spinnenweb aan elkaar verbonden zijn.

ZEER versimpelt voorbeeld:
Systeem A bevat NAW gegevens van klantensoort: Particulier en klein-zakelijk
Systeem B bevat NAW gegevens van klantensoort: Particulier uit oost-Azie (want de regionale regelgever verbiedt dat de gegevens 'hun volk' tussen die van de Europese staat)
Systeem C bevat NAW gegevens van klantensoort klein-Zakelijk uit oost-Azië
Systeem D bevat gegevens van alle drie de bankrekeningnummers (historisch gegroeid en toegestaan door alle regelgevers)

Stel nou dat de regelgever in oos Azië iets veranderd en daarmee een aanpassing aan systeem C vereist, heeft dit dus impact op B en A, en daarmee dus mogelijk ook D.

Dan heb je vervolgens nog te maken met honderden soorten financiele producten die er wereldwijd bestaan die je veelal gespreidt over systemen heen moet zetten ivm regelgeving en omdat het ooit een goed idee leek, en nu niet meer. Maar je zit er nu wel aan vast.
Je kan je voorstellen dat je voor je dagelijkse rapportages aan de Centrale Banken je dus ook weer alle systemen aan elkaar moet knopen en al die data moet correleren en verrijken om de juiste rapportages te kunnen opleveren.

En wat ik nu noem zijn alleen de 'hoofdlijnen' binnen functionele systemen. Onder water heb je ook nog te maken met regelgeving met betrekking tot authorisatie en controle op privileges (wie mag wat waar en onder welke omstandigheden). En daarbij komt zoals @Cergorach al aangaf politiek, vastgeroeste denkbeelden enzovoorts.

Ik blijf erbij. Het is een Godswonder dat grote bedrijven nog zo goed functioneren als dat ze doen. Mensen klagen altijd over de overheid, maar bij grote bedrijven is het allemaal net zo erg. Alleen is de overheid vanuit wetgeving verplicht openbaar te maken wat er allemaal mis gaat. Bedrijven houden hun mond. Dit geeft een vertekend beeld.

[Spacecowboy]

Uiteraard heb je wel alle specs en unit tests en heel de bende, maar stel dat je core componenten gaat migreren, want de onderliggende hardware raakt uit support (en het OS waar het op draait ondersteund de nieuwe hardware niet, dus je moet je OS migreren, en je middlwarelaag ondersteund dat nieuwe OS niet, dus die moet ook, en je applicatie dus ook). Je hebt honderden systemen die als een spinnenweb aan elkaar verbonden zijn.

In mijn ervaring heb je alleen de specs/requirements. Niet de unittests. Dat resulteert dus in het feit dat je volledig afhankelijk bent van je eigen functionele testen.

Overigens is je beschrijving van de situatie met systeem A, B, C en D precies spot on.

[spoller]

("Want wij zijn bankiers, en geen softwarehuis")

De banken die nu nog steeds zo denken bestaan over niet al te lange tijd niet meer. Want een bank is tegenwoordig grotendeels een IT bedrijf. Een boodschap die overigens bij het merendeel van de grote Nederlandse banken nog niet is aangekomen. De enige die dat vroeg genoeg heeft gezien is Ralph Hamers van de ING, die zijn salarisverhoging in mijn ogen dus dubbel en dwars waard is. Maar dat is een andere discussie.

[Cergorach]

Vast een domme vraag, maar dan heeft zo'n bank niet alleen 'geen broncode', maar ook geen spec en dus naar ik aanneem geen unit tests?

Wat ik heb meegemaakt, waren dat puur functionele tests, men zag dus eigenlijk niet wat er onder de 'motorkap' gebeurde. De technische tests werden door de leverancier uitgevoerd en die werden op hun mooie blauwe ogen vertrouwd... Totdat het natuurlijk keer op keer mis ging en je eigenlijk van leverancier/softwarehuis wil wisselen, maar dat niet kan omdat effectief je core applicatie wordt gegijzeld...

Komt dat dan niet ongeveer neer op reverse engineering?

Dat meerdere keren moeten doen om problemen te achterhalen nadat de leverancier al meerdere keren heeft aangegeven dat 'er is niets mis met onze software, we hebben het uitgezocht'... Dan ga je uit frustratie en noodzaak dingen uitzoeken die ver buiten je eigen taakgebied liggen.

[ajolla]

Ja, dat had allang gebeurd moeten zijn door een aantal fatsoenlijke mensen.

[Spacecowboy]

Ligt er aan wat voor software je gebruikt, maar bijvoorbeeld bij Base24 van ACI wat je kan gebruiken om geldautomaten mee te beheren, dan heb je geen toegang tot de broncode. Die blijft afgeschermd en van ACI. Je kan wel modificaties op de software aanvragen voor jouw specifieke situatie (moet een prijskaartje), maar ook daarbij krijg je geen inzicht in de code.

In geval van een migratie dus een absoluut risico. De ontwikkelaars van de leverancier kennen de code heel goed, en de ontwikkelaars/IT aan bij de bank kennen het IT landschap binnen de bank, maar iemand die beide situatie door en door kent, ontbreekt.

[YouryDW]

Het probleem dat zich vaak stelt is dat TDD niet echt de standaard was bij het opzetten van de systemen lang geleden en dat net zoals in alle sectoren new features voorrang krijgen op testing van bestaande zaken. De new features krijgen zelf ook maar een basic testing met meestal enkel een happy flow scenario dat maar half een happy flow omvat inzake de checks.
Probleem is ook dat unit tests allemaal goed en wel zijn, maar dat er eigenlijk een nood is aan E2E testing binnen de verschillende omgevingen zowel pre- als postproduction!
Sommige bedrijven zien dit pas in nadat het fout is gelopen en zullen dit dan slechts een bepaalde tijd toch aanhouden, tot het woord besparingen de kop weer opsteekt...

[wiseger]

Ik heb er een heel goed idee van en er prima zicht op en ik herken me totaal niet in jou verhaal.

De belangrijkste reden voor problemen bij de banken is de voordurend wijzigende regelgeving van de toezichthouders en de wetgever. Die zorgen voor bijna 65 procent van alle change kosten. Al dat geld had anders gespendeerd kunnen worden aan extra hardware, failover datacenters en betere applicaties.

Als een systeem inhuis ontwikkeld wordt ontwikkeld door ingehuurd personeel, dan is de broncode altijd eigendom van de bank. Koopt men een off-the-shelve pakket dat men configureert, dan is de broncode eigendom van de leverancier, daar is niets raars aan.

De laatste variant die bestaat is dat men een pakket geheel laat ontwikkelen door een derde partij. Dan geldt dat het goedkoper is als het pakket eigendom blijft van de leverancier, na ontwikkeling word thet dus een off the shelve pakket. Maar je kan er ook voor kiezen dat de code jouw eigendom wordt, echter dan betaal je vaak een hogere prijs. Men denkt vaak dat het beter is het toekomstig onderhoud samen met andere banken te betalen. Daarmee is het in eigendom laten van een applicatie bij een leveracier een keuze, het zijn geen foutjes of over het hoofd gezien.

[Reactie gewijzigd door wiseger op 24 juli 2024 01:58]

[Cergorach]

De laatste variant die bestaat is dat men een pakket geheel laat ontwikkelen door een derde partij. Dan geldt dat het goedkoper is als het pakket eigendom blijft van de leverancier, na ontwikkeling word thet dus een off the shelve pakket. Maar je kan er ook voor kiezen dat de code jouw eigendom wordt, echter dan betaal je vaak een hogere prijs. Men denkt vaak dat het beter is het toekomstig onderhoud samen met andere banken te betalen. Daarmee is het in eigendom laten van een applicatie bij een leveracier een keuze, het zijn geen foutjes of over het hoofd gezien.

Nee, een pakket, exclusief ontwikkeld voor een enkele partij, waarvan ze niet het broncode bezitten. Het was ook iets unieks in Nederland waar men geen concurrentie op wilde. En goedkoper was het zeer zeker niet. Er werd de volle mep betaald voor externe software ontwikkeling. En ook het hoofd van IT die de positie had overgenomen van de persoon die het contract heeft getekend zat zich op het hoofd te krabben.

[batjes]

Daarom zei ik ook "voor ons gebruikers"

Maar bedankt voor de toelichting.

[boyette]

Ik geloof alleen niet dat dit een verstoring is maar een migratie die niet volledig geslaagd en op het moment dat het systeem in de lucht ging zijn is het proces begonnen waarbij data verkeerd is weggeschreven zoals eerder werd beschreven en dan gaat het balletje rollen. Dat wordt een sneeuwbaleffect.
Stekker eruit was nog de enige oplossing.

[lenwar]

Als klant/bankdirecteur/handelaar interesseert het je niet wat de onderliggende oorzaak is. Het systeem moet gewoon doen. En als het systeem het niet doet is er een verstoring van de dienstverlening.
Je zou het uiteindelijk op een taaldingetje kunnen gooien, maar onder aan de streep doet het systeem het niet.

(( zoals mijn ex-schoonvader ooit zei: Wat is een computer: "Een kloteding als ie het niet doet." - En dat is onderaan de streep natuurlijk gewoon waarheid als een koe ))

[FreezeXJ]

Voor de klant of handelaar ben ik het met je eens, maar de directeur zou wel dgelijk moeten (laten) uitgraven wat de oorzaak is, en of dit een ingeschatte of onverwachte oorzaak is. In het eerste geval krijgen de mensen die de migratie ondanks risicos doorduwen op hun donder, in het andere geval degenen die de risico-analyse deden.

In alle gevallen denk ik dat er iets aan de migratie-procedure veranderd mag worden, want we leven nu in 2018, en zelfs iets logs en archaisch als een bank moet in staat zijn om een blue-green-migratie uit te voeren.

[lenwar]

Met die directeur doelde ik op de Raad van Bestuur. Die houden zich doorgaans niet bezig met de 'details' op de werkvloer. De IT/Operatie/etc-directie zal uiteraard wel met een zweep klaar staan in dit geval

We kunnen natuurlijk alleen maar gissen wat er allemaal mis is gegaan bij de betreffende organisatie, maar aangezien al zes dagen er mee bezig zijn kan ik me zo voorstellen dat het in elk geval diep in hun systemen zit. (anders hadden ze na een dag (waarschijnlijk korter) wel teruggedraaid)

[FreezeXJ]

Zoals je al zei, ze liggen nu 6 dagen plat, dus da's meer dan een falende IT-actie, dit faalt ook hogerop, in de aansturing van IT. Dat is nou net wel het domein van die RvB, want het raakt hier de bedrijfsstructuur en continuiteit van operaties. Ze zullen er niet zelf in moeten duiken, maar wel een flink onderzoek + consequenties moeten starten denk ik.

[r_j]

Vergelijkhet is met telefonie. Daar moeten we max 3min/jaar downtijd garanderen (inclusief software updates), en dat haalden we gemakkelijk. Maar, dan heb je wel compleet dubbele systemen, met allerhande kruisverbindingen tussen de systemen op verschillende niveaus en disks die aam beide zijden dan weer dubbel uitgevoerd waren, met dubbele controllers etc.
Dat soort fail-safe systemen bestaan echt, maar...
Als je software te wensen overlaat gaat all die hardware op dezelfde wijze fout natuurlijk.
Bovendien, als ze het zo belangrijk vonden, waarom hebben ze dan niet een possje schaduw gedraaid om te zien of alle systemen dezelfde resultaten gaven? En, big-bang overgangen zoals heir kennelijk is gebeurd verhoogt het risisco aanzienlijk.

[boyette]

juist

[jpsch]

Wordt vaak over maatwerk van leveranciers geklaagd, terwijl die vaak is ontstaan door de wensen van de opdrachtgever. Nee het moet echt zo, want we zijn als bedrijf uniek.

[SuperDre]

Dat was ook mijn gedachte toen ik zijn opmerkingen las. Meeste is gewoon maatwerk in opdracht van de bank naar aanleiding van samen overeengekomen specificaties.

[Cergorach]

Erm... Ja, de specificaties... Wellicht dat de banken daar nu wat beter mee omgaan, maar 10-15 jaar geleden was dat een echt drama. Vaak waren er functionele eisen, maar geen over hoe deze geïmplementeerd zijn, waarom denk je dat de meeste interne bank applicaties een UI om te huilen? En vaak al helemaal niets over performance: "Dat lag immers aan de hardware!" *facepalm* Of wat had je gedacht aan stabiliteit van de software, niemand dacht aan maar x% downtime en hoe dat dan berekend moest worden, etc.

[Tokkes]

Ik ben zelf klant bij de bank en krijg zo rond deze tijd betaald. Maar sinds vrijdagnacht is het een gevalletje "I'll just wing it" want ik heb dus geen idee wat er nog op de rekening staat (mijn budgetapplicatie doet meteen met de bank integreren )

[lenwar]

Je ziet dus ook bij de meeste financiele instellingen dat ze een 'eind-van-de-maand-change-freeze' hebben. Juist zodat alle salarissen goed worden overgemaakt, en omdat iedereen om een één of andere reden 10 keer naar z'n saldo wil kijken.

Zelfde geldt in mei (vakantiegeld) en januari (eerste loon nieuwe jaar wat vaak anders is door nieuwe belastingregels of loonsverhoging). Dan is het nog extremer

[Tokkes]

Belastingswijzigingen gaan hier in de UK in vanaf April.... dus het salaris van deze maand

[WhiteDog]

Het zou me eerlijk gezegd niet verbazen dat er een bank bestaat waar iemand met een USB key elke dag gegevens overzet tussen 2 platformen omdat ze niet met elkaar verbonden mogen worden.

Langs de andere kant maken ze het zelf vast onnodig ingewikkeld. Voor een app kan je bv. het saldo en de laatste 5 transacties cachen in 1 tabel wat razendsnel resultaat zou moeten geven. Als ik gewoon het saldo wil zien bij mijn bank heb ik echter het gevoel dat ze de transacties van de laatste 10 jaar gaan uitrekenen in de achtergrond 😜

[R4gnax]

Het zou me eerlijk gezegd niet verbazen dat er een bank bestaat waar iemand met een USB key elke dag gegevens overzet tussen 2 platformen omdat ze niet met elkaar verbonden mogen worden.

Waarom schiet me nu het beeld te-binnen van een Lego Mindstorms set, die een swivel arm aanstuurt welke beurtelingsom een USB stick in en uitplugt en wisselt tussen twee tegenoverstaande systemen.

Ik bedoel; dat is maar twee stappen verwijderd van de echt-bestaande remote-reboot truc om scripted een CD-drive te laten openen waarna de tray de reboot knop indrukt op een tegenoverliggende server.
Ja echt heh...

[Cergorach]

Duidelijk nooit bij een bank gewerkt. Dat mag natuurlijk niet via een usb key, en als het welk mocht dan kon het systeem niet omgaan met USB devices. Nee, twee aparte PCs, eentje op het interen netwerk, eentje aan een externe modem. Naast elkaar en iemand die dagelijks de opdrachten over typte van de ene PC naar de andere... Oh en een hele keyring aan RSA rokens om aan te kunnen melden in elke omgeving...

[lenwar]

Voor jouw beleving. Met die USB-stick zou al niet mogen, want dan komt de data het data-centre uit. (het mag niet op de PC's komen, en er mogen geen mensen zomaar een data centre in)
Je zal dus volledig uitgekauwde dataverbindingen moeten maken die door alle regelgevers zijn goedgekeurd en aantonen dat je niets meer en minder doet.

Het saldo dat jij ziet je in bank-appje is vaak het resultaat van een dagelijkse export uit de betalingssytemen (saldo van gisteren) verrijkt met de transactiedata uit andere systemen. Daarnaast zijn de transacties die je ziet ook weer een export uit een ander systeem aangevuld met de gereserveerde transacties die die dag gebeurd zijn.

En wat anders:
Probeer je is voor te stellen hoe iDeal werkt:
De klant bij bank A
De winkel is klant bij bank B
Bank B weet mijn saldo niet, maar moet wel de transactie voorschieten van bank A (want banken betalen elkaar aan het eind van de dag in één keer - anders blijven ze bezig)

Dus - extreem versimpeld:
Winkelier doet een transactieverzoek bij bank B met een unieke transactiecode
Bank B controleert of het lijkt op een echte transactie *
Klant logt in bij bank A en geeft onder water dezelfde transactiecode
Bank B doet een validatieverzoek bij bank A voor die transactiecode
Bank A doet al z'n controles (voldoende saldo van gisteren, alle transacties van vandaag erbij en eraf, niet teveel uitgegeven vandaag, enz. enz. enz)
Bank A zegt tegen bank B dat het akkoord is (voldoende saldo enzovoorts)
Bank A maakt een reservering op de rekening van de klant
Bank B zegt tegen de winkelier dat het akkoord is
Bank B maakt een reservering op de rekening van de winkel
De winkelier voltooid de transactie in haar eigen systeem de transactie

(* houd er rekening mee dat een winkelier alleen 'echte transacties' kan doen. De winkelier kan niet 'at random' rekeningen checken voor saldo. Dit zou fraude/privacygevoelig zijn)

Er komt meer bij kijken maar dit geeft een versimpeld beeld en zo zie je dat het eigenlijk ook al een klein wonder is dat dit werkt tussen banken onderling.

En nu voorstellen dat dit dus 'on the fly' gebeurd en met een stuk of acht banken door elkaar die elkaar 'niet vertrouwen' (dus je hebt een soort pulic/privatekey systeem nodig) en een miljoen keer per dag (in maart 2018 waren er ongeveer 39 miljoen iDeal transacties, en om 03:40 zijn er wat minder per seconde dan om 19:30 )

[GB2]

Zeker als sommige systemen oud zijn en de personen die alles wisten al lang en breed met pensioen zijn of zijn weggegaan.

Documenteren en techneuten,.. Dat gaat vaak lastig samen.

[Dalyxia]

plus dat hoger op nooit word geluisterd naar de IT-ers, die waarschijnlijk van te voren al hebben aangegeven dat er grote problemen zullen ontstaan bij zo'n migratie omdat ze met te weinig man zijn, de personen die de oude systemen echt goed kenden met pensioen zijn en er geen documentatie is

[Anoniem: 583079]

Het probleem van dit soort projecten zit meestal net bij de “pure” IT-ers, die de neiging hebben complexiteit te onderschatten en migraties teveel als een puur technisch traject te zien, en uitgebreide testen “saai” en onnodig vinden. Je hebt bij dit soort projecten vooral erg ervaren project/programma managers nodig die de klappen van de zweep kennen.

[xxxneoxxx]

De gemiddelde 'pure' it'er is ook vaak niet zo in staat spullen inhoudelijk te testen. Daar heb je mensen op de werkvloer voor nodig, en een goed draaiboek. Mijn ervaring met grotere projecten is dat de it'er vaak genoeg wel goed inzicht heeft in de technische zaken, het draaiboek er oom wel min of meer is, maar de bereidheid tot testen na een migratie vaak.. Ontbreekt vanuit de organisatie.

[gepebril]

Meeste mensen kunnen niet een paar stappen vooruit denken. Anders waren er wel meer schaakgrootmeesters.

[ajolla]

Dat is niet 'puur', dat is lapswanzerij.
(Zo, even lekker stangen. )

[morten]

Het belang van een goede projectmanager wordt inderdaad vaak over het hoofd gezien, maar uiteindelijk blijft een project gewoon de som van de componenten. Als je een zwakke schakel hebt in het technisch personeel dan ga je problemen krijgen. Als een zwakke schakel hebt in het management ofwel ondersteunend personeel zal dat zich ook uiten.

[MrMarcie]

Helemaal mee eens. Erg jammer.

[Nicap]

Bij ons ook gebeurd idd. Heel triest, maar waar. Heeft aardig wat centjes en klanten gekost.

[Anoniem: 998261]

Dat er niet wordt geluisterd naar it-ers komt omdat de meeste it-ers niet in staat zijn het it beleid naar management niveau te vertalen. Andere disciplines kunnen dat veel beter. Het interesseert management niet hoe iets werkt (ongeacht of dat nu it, marketing, productie is) maar wat bijdraagt in de overall bedrijfsresultaten.

[rboerdijk]

"Documenteren en techneuten,.. Dat gaat vaak lastig samen."
Meh, da's een beetje eenvoudig.. Management wil vaak genoeg "resultaten zien" en documentatie, tja daar is nu geen tijd voor, doen we "straks" wel.

... en als de techneut dan weg is, dan is plots de documentatie niet voorhanden en is het gemakkelijk een schuldige aan te wijzen.

[Reactie gewijzigd door rboerdijk op 24 juli 2024 01:58]

[ajolla]

Als je nu geen tijd hebt, waarom denk je dan dat je 't later wel zult hebben?

[rboerdijk]

Goede vraag aan het management. Argumentatie lijkt mij dat documentatie *nu* niet belangrijk is - dus waarom zou je er tijd aan "verspillen"?

( het wordt pas belangrijk als je het nodig hebt en het er niet is - maw als het te laat is ).

[Reactie gewijzigd door rboerdijk op 24 juli 2024 01:58]

[SuperDre]

tja, toen ik eens een opmerking maakte over gebrek aan documentatie/commentaar, zei iemand een heel tijd geleden tegen mij 'goed geschreven code wijst zichzelf', waarop ik antwoorde 'slech geschreven code ook' en daarna meteen zei 'goed geschreven code is in the eye of the beholder, wat jij goed vindt hoeft een ander niet goed te vinden'.

[TheekAzzaBreek]

Documenteren en techneuten,.. Dat gaat vaak lastig samen.

Documenteren en project managers... gaat ook vaak niet zo best.

[Keypunchie]

Dit soort migraties zijn zeer complex en luisteren vrij nauw. Over het algemeen is aan te raden om een scenario met ‘big bang’ te vermijden. Beter om eerst een paar klanten over te zetten en dan telkens meer en meer, dan om in 1x iedereen te doen.

Het is een stuk duurder, maar dit is natuurlijk ook niet goedkoop.

[RobbieB]

Big Bang hoeft geen probleem te zijn als je goede proefmigraties uitvoert en de juiste controles (operationeel en financieel) in place hebt... daarnaast zorgen voor goede fallback scenario’s (en deze ook testen!) voor iedere stap in het proces...

Als je je proces op orde hebt zou het niet uit moeten maken of je 10 of 1000000 records migreert..

[ID-College]

Moet zeggen dat dit nooit mijn voorkeur heeft.. dergelijke grote wijzigingen doen wij altijd met A/B testen waar we steeds verder uitrollen.. zo beperk je de impact enorm tot een klein clubje en kan je stelselmatig zien of je landschap t houdt.

Dit soort projecten big/bang doen is haast onmogelijk omdat je dan ook goede performance tests moet hebben.. Gefaseerd uitrollen is dan vaak praktischer omdat je kan zien aankomen dat het begint te kraken waarop je kan inspelen..

[RobbieB]

Het probleem waar je mee kan zitten met bv spaarrekeningen/beleggingen/etc. is het verrekenen van de rentes/rendement. Als je de migratie van de hele portefeuille verspreid over meerdere dagen, moet je er bij je financiële aansluitingen rekening mee houden dat je dus ook de renteberekeningen per migratie anders moet controleren. (Technisch gezien is de controle hetzelfde, maar de uitkomst anders). Vanuit dat perspectief heeft het dus de voorkeur om big bang te gaan.

Het blijft altijd een risico afweging, maar ik heb al genoeg financiële migraties meegemaakt die big bang zijn gegaan en allen goed zijn verlopen. Simpelweg om dat er goede draaiboeken lagen met goede fallback scenario’s (die gelukkig niet nodig waren).

Áls een big bang niet nodig is, dan moet je het niet doen, maar er zijn dus ook gevallen waar het wel gewenst is en dan moet je gewoon zorgen dat je het goed voorbereid en test...

[Reactie gewijzigd door RobbieB op 24 juli 2024 01:58]

[ajolla]

Als een IT afdeling van een bank problemen heeft met het berekenen van rentes tijdens een migratie kun je beter naar huis gaan en websites gaan ontwerpen.
En dan druk ik me nog heel vriendelijk uit.

[aadje93]

het voordeel is, de meeste banken staan al op 0% of daar praktisch tegenaan. En inderdaad, het duurt geen 24uur om 1000 record om te zetten lijkt mij?, dus dat maakt niet uit, beginnen om 0:01 tot een uur of 6, en dan 's avonds om 20:00 weer een husje zodat men er overdag geen last van heeft dat het ineens verspringt qua UI als ze bezig zijn. (ING is ook met A/B testen bezig om de nieuwe web interface te doen, alleen triest dat ze dan niet eerst even zorgen dat ie volledig werkt (beleggen kan nog niet in nieuwe interface).

[mvh]

Het voordeel van eilandjes is wel dat je niet ineens "de hele bank" een update hoeft te geven. Maar volgens mij is dit alleen interface, zoals je zegt, een niet core landschap.

[Reactie gewijzigd door mvh op 24 juli 2024 01:58]

[batjes]

Gaat net zo zeer om het proces, het risico vergroot met het aantal records, want meer records = meer gebruikers = meer kans op dat er iets stuk gaat. Het verwerken zelf kan wel probleemloos verlopen, de acties die erna komen alleen niet.

[neographikal]

Eigen ervaring; big bang migraties met dit soort kritieke onderdelen van je infrastructuur die zeer bewerkelijk/complex zijn, zijn zelden een goed idee. Het is praktisch niet te managen, de load en scenario's die je in productie voor de kiezen krijgt is bijna niet te simuleren. Je denkt aan alles te hebben gedacht en vaak krijg je toch een konijn uit de hoge hoed.

Door het geleidelijk te doen kun je eventuele fouten in de voorbereiding nog oplossen alvorens de gehele populatie aan gebruikers er last van heeft. Als het even kan heb ik altijd de voorkeur voor het opknabbelen van functionaliteit dan wel pluksgewijs gebruikers overzetten richting het nieuwe systeem.

Helaas is het niet altijd mogelijk...

[Bensimpel]

Er is geen enkele migratie dat 100% goed gaat. Je kunt testen in een test omgeving totdat je een ons weegt. Maar als je erg complexe systemen hebt gaat er sowieso wat mis.

[Anoniem: 998261]

Als het allemaal binnen 1 service window past, inclusief roll back indien nodig, dan is big bang een optie. Praktisch betekent het dat de daadwerkelijke migratie zo'n 2 a 3 uur nag duren.

[Iblies]

Big Bang hoeft geen probleem te zijn als je goede proefmigraties uitvoert en de juiste controles (operationeel en financieel) in place hebt... daarnaast zorgen voor goede fallback scenario’s (en deze ook testen!) voor iedere stap in het proces...

Als je je proces op orde hebt zou het niet uit moeten maken of je 10 of 1000000 records migreert..

Mits alles 100% functioneert.

Je hebt een OS daf niet perfect is, je hebt software dat niet perfect is, je hebt apps en browsers die ook niet perfect zijn.

Een protocol dat ergens in een bepaalde versie verkeerd wordt geïnterpreteerd kan bij jou flink wat koppijn bezorgen. Had je het kunnen voorzien als software-bouwer bij een compleet nieuwe versie, dat is niet realistisch.

[SteveWoz]

Goed punt, maar de tijd dringt voor de banken: binnenkort gaat de PSD2 in en moeten banken APIs aanbieden zodat derde partijen gegevens kunnen uitwisselen. Ik denk dat deze migraties daarmee samenhangen. Waarschijnlijk zijn ze veel te laat begonnen en nu moeten ze wel.

[Coolstart]

Klopt, en net de kleinere banken komen hierdoor in moeilijkheden omdat ze niet over dezelfde budgetten beschikken als de grootbanken.

Psd2 is idd een goed voorbeeld van hoe de banksector heel grondig hervormd wordt. Wetende dat nu ook andere kapers op de kust zijn zoals Google en Apple pay en nog wat andere services die uw betalingen online en offline zullen overnemen wil zeggen dat ze mee moeten evolueren en zich gaan specialiseren om nog usp’s over ge houden buiten het klassieke bankieren.

Op men KBC app kan ik nu al leningen of kredieten aanvragen, limieten verhogen en, budgetten beheren tot zelfs webcam gesprekken voeren met de bankier en natuurlijk rekeningen betalen

Er komt een tijd dat je geld kan overmaken via andere apps zoals whatsapp of in groep sparen voor een reis of een virtuele geldpot samen leggen of uw vermogen beheren (panden, pensioen, aandelen, venootschappen sierraden, maar ook cryptocurrencies)

Het is nu soms nog moeilijk om het OV te betalen met uw gsm op een parkeer ticketje. Dat zal allemaal beter worden met psd2 maar de vraag is of de kleine banken onze digitale noden van de toekomst kunnen blijven vervullen.

[gepebril]

Denk dat banken zich drukker moeten maken over blockchain. Wil vanaf volgende maand overuren etc ook niet meer in Euros zien. Ĺaat ze maar lekker bijdrukken in Frankfurt en er een nog grotere bende van maken als in 2008. Want wie moet de rekening gaan betalen......Ik hopelijk niet meer

[Reactie gewijzigd door gepebril op 24 juli 2024 01:58]

[119961]

Hoe is bij PSD2 enige privacy gewaarborgd als een bijna willekeur aan bedrijven van dergelijke API gebruik gaat maken, of is dat straks gewoon een data mining festijn ?

[Anoniem: 998261]

Je moet als klant toestemming geven aan de bank en 3pp om jouw gegevens te gebruiken. Praktisch betekent het dat als jij zelf een 3pp toepassing wilt gaan gebruiken je die toestemming geeft.

[Blokker_1999]

Argenta², ook bij de migratie van Argenta enkele weken terug bleek bandbreedte een issue te zijn.

[Frituurbaas]

Bandbreedte... het sleutelwoord voor iedere persvoorlichter in 2018. Ik denk dat men doelt op de beschikbare threads, niet op bandbreedte in de zin van "internet".

[Anoniem: 1322]

Hoeft niet. Vaak moeten transacties redundant worden weggeschreven over verschillende (fysieke) netwerklocaties, datacenters en databases. Hier is veel bandbreedte en zeer lage latency voor nodig en dit wil nogal eens verkeerd gaan. Het platform wordt namelijk van tevoren nooit echt belast tot men in productie gaat. En dan gaat het fout.

[neographikal]

Ik heb nog nooit gehad dat een tekort aan bandbreedte gegevens lekte van andere gebruikers. Idem voor een tekort aan computing power cq threads. Dit soort ongein komt meestal uit queries die niet goed zijn, threadingproblematiek (staticjes her en der) of rechten die niet goed zijn ingeregeld.

[gepebril]

Of onnodige lock op tables..... Zelfs bij erg grote software partij in NL meegemaakt.

[ajolla]

Door 'bandbreedte' kunnen klanten bij elkaars rekeningen? Geloof je 't zelf?

[aCCuReRaS]

Bij Argenta konden klanten niet bij elkaars rekeningen. Maar na de update van de software vereiste de DB replicatie veel meer bandbreedte dan voorheen waardoor alles trager ging.

[TheCaptainFordo]

Wat zit jij nu weer te zeggen? Heb je een bron voor dit soort stellingen?

[ajolla]

Huh? Artikel niet gelezen?
"Zo zegt een klant tegen de BBC dat hij toegang had tot de spaarrekening van iemand anders."

[TheCaptainFordo]

Je zegt dat dit zo is bij Argenta, maar nu zeg je dat het de andere bank is

[boyette]

Bandbreedte kolder propaganda. Je kan gewoon de rem erop zetten.

[The Bula King]

Ik lees dat sommige klanten toegang hadden op de rekeningen van andere klanten.
Ik wil wel eens weten hoe dit dan juridisch in elkaar zit als jij dan "toevallig" enkele duizenden euro's doorsluist?

[SuperDre]

Dan komt intentie om de hoek kijken, als jij dan ineens duizenden euro's over gaat schrijven naar je eigen rekening, dan is het goed mogelijk dat JIJ gewoon aangeklaagd zal gaan worden voor diefstal, immers heb je bewust (zoveel) geld overgemaakt naar je eigen rekening. Als je een betaling gedaan zou hebben richting een instantie (rekening betalen), dan zal het allemaal anders afgehandeld worden omdat dat dan een echte vergissing geweest kan zijn.
Is hetzelfde als dat een bank ineens miljoenen op je rekening stort, en jij het er meteen vanaf haalt en niet wilt terugbetalen, dan wordt JIJ gewoon aangeklaagd voor diefstal want je had het kunnen weten dat het een vergissing was van de bank. Had je kunnen bewijzen dat je eerst netjes contact had opgenomen met de bank, en zij aangaven dat het geen vergissing was, en je dan alles opnam (just in case), DAN wordt het een ander verhaal..

[ajolla]

Maakt weinig uit. Laat de klant het maar eens bewijzen als 'ie niet na iedere transactie de boel uitprint.
Is er 1 bankapplicatie die je na afloop alles wat je hebt gedaan naar keuze laat uitprinten?
Opzettelijke en kwaadwillige nalatigheid als je 't mij vraagt.

[boyette]

Dat mag niet.

[pharmacist]

Het lijkt wel op de toestanden bij het Belgische Argenta.

[R4gnax]

Het lijkt wel op de toestanden bij het Belgische Argenta.

... zou het om dezelfde software-stack gaan?
Dat zou werkelijk hilarisch zijn...

[sugarlee89]

Wel dezelfde eisen waar straks alle banken aan moeten voldoen, dus denk dat alle banken hier tegenaan gaan hikken in de toekomst.

[Doxie]

Bij Argenta zou de oorzaak geweest zijn dat de Oracle databases op een niet gesupporteerd file systeem zou zijn geinstalleerd... Gevolg een overvloed aan lees en schrijf opdrachten en disken die niet meer volgde...

[TheCaptainFordo]

Welk filesysteem zou dat zijn? Ik ben wel benieuwd eigenlijk.

[A-star]

Misschien moeten ze daar even advies gaan vragen.

[Mit-46]

Ergens fijn om te lezen dat niet alleen onze banken last hebben van "storingen".

Ergens is het ook onoverkomelijk wanneer je op zn grote schaal IT services aanbiedt.

Ik kan mij voorstellen dat die systemen enorm complex in elkaar steken aan de achterkant.

[ajolla]

Als ik bankdirecteur was en mijm IT hoofd met zo'n verhaal zou komen aanzetten zou ik me genoodzaakt zien de migratie uit te stellen en een nieuwe migratie afdeling op te richten met de opdracht het hele systeem met 100% grondigheid te analyseren, dan een migratie te ontwerpen, danwel een compleet nieuw systeem parallel op te zetten, testen en dan migreren.
En dan de overblijfselen van de oude afdeling die je zo te kakken heeft gezet ontslaan.

[Reactie gewijzigd door ajolla op 24 juli 2024 01:58]

[boyette]

Dat gaat dus niet meer. Dit is ook niet echt een migratie maar meer een soort van emigratie. Er is geen weg terug . Er is geen oud systeem dat is losgekoppeld. Afgekoppeld.
Dat is van een andere bank.
Je vaart met een boot met je klantgegevens naar een nieuw eiland en daar staat een fabriek. Maar die fabriek die is nog niet klaar.

[Reactie gewijzigd door boyette op 24 juli 2024 01:58]

[ajolla]

En je weet geeneens welke machines je erin moet zetten en aan welke specificaties de grondstoffen moeten voldoen.
En of er misschien nog een paar machines bij moeten voor, wat is het, aluminium- of koperbewerking?
Handig hoor.

[Mit-46]

Ik denk dat je totaal geen idee hebt (met alle respect). Allereerst niet mbt de kosten. Je hebt op zo'n grote schaal al gauw over tonnen dan wel miljoenen dus even overnieuw of parallel is natuurlijk niet zo simpel. Ook een directeur moet zich verantwoorden.

Wij hebben vorige maand een migratie afgerond en dat is vergeleken met deze peanuts. Van on premise opslag naar "de cloud". Dit heeft bijna een jaar geduurd en dan heb je het over een bedrijf met maar +\- 750 man en +\- 25 afdelingen.

Wij hebben hier uiteraard de tijd voor genomen, zijn tegen onverwachte issues aangelopen waardoor er tussentijds vertraging optrad en dingen uitgezocht moesten worden alvorens wij verder konden. Je kan immers niet migreren en de gebruikers (klanten) met een slechtere ervaring opzadelen omdat functionaliteiten ontbreken of toch niet goed blijken te werken (als of onprettig ervaren worden) etc. etc.


Sommige dingen kom je pas tegen wanneer je op grote schaal bezig bent. Het is onmogelijk om de "productie omgeving" (zoals dat bij ons heet) compleet na te bootsen in de testomgeving. Wij hebben logischerwijs geen 750 klonen van onze collega's.

Zoveel zaken welke er bij komen kijken. Techniek die niet meewerkt, kosten die daardoor weer de pan uitreizen, misschien toch een cruciale factor die over het hoofd is gezien waardoor er weer meer kosten gemaakt worden, ontevreden klanten en managers, tussentijdse wijzigingen omdat men het toch weer anders wilt vanwege ontevredenheid, verzin het maar.

Verbeeld je nu eens zo'n grote instelling als een bank in. Ik voel de stress van die IT afdeling daar al door mijn lijf heen bij de gedachte.

Ik begrijp heel goed dat je zegt, het moet goed of anders niet, maar de complexiteit is soms ongekend en bij een bank (met klantgegevens, geldzaken, security, aandeelhouders, verzin het maar) is dit bijna eng (en haast onmogelijk om zonder problemen in 1 keer goed te doen)

[Reactie gewijzigd door Mit-46 op 24 juli 2024 01:58]

[ajolla]

Ik weet van een bedrijf waarvan de directeur in het geniep een research-opdracht aan een ander bedrijf uitbesteedde omdat z'n eigen R&D-afdeling er niets van bakte.
Nou raad ik niemand aan om een softwareopdracht uit te besteden, want we zien regelmatig wat daar van komt, maar de huidige stand van plakken, scheuren en bidden is verre van ideaal.
Als je je eigen system niet kunt doorgronden is er iets grondig mis, met alle respect voor de moeilijkheidsgraad hoor, maar je eigen opsomming is al een aardig begin van zaken die in kaart gebracht moeten worden en zo universeel mogelijk moeten worden aangepakt.
Het is in principe een gelimiteerd problem, dus moet te structureren en volledig te beschrijven zijn.
En die stress..., ja ik hoef dat ook niet meer, ik ga liever paddestoelen kweken dan zo door een baas machteloos gemaakt en opgefokt te worden. Ze werken in op je diepste Existenzangst (is m'n Duits een beetje ok? ) om maar zoveel mogelijk geld te besparen. Die rijke banken hebben dat echt niet nodig.

[mocean]

Ach de DUO (ook een soort bank) gaat gewoon een maand offline voor een migratie, omdat het niet sneller kan....

[T_E_O]

Onjuist: ze doen dat, omdat het aanzienlijk goedkoper was het op deze manier aan te pakken.

[ari]

Betaalbaarheid, kwaliteit, snelheid; je mag er precies twee kiezen.

Het kan uiteraard sneller of met veel minder downtime, maar dan moet je je systemen live gaan houden tijdens de migratie of parallel gaan draaien. Dat is gruwelijk duur. Het gaat hier om de overheid. Zouden ze daarvoor kiezen, dan is iedereen boos over het prijskaartje. Nu is men boos over de bereikbaarheid, maar als we de overlast afzetten tegen het prijsverschil dan is dit een zeer verdedigbare keuze.

[Frituurbaas]

Reken maar dat deze bank op dit moment geen "storing" heeft maar dat de bank de boel express uit heeft geschakeld ter voorkoming van verdere chaos. Als ik een bankbaas was, zou ik dit besluit ook genomen hebben. Database records die verschuiven is zo'n beetje het ergste dat je als bank kan gebeuren.

[mesa57]

Ze waren al gewaarschuwd in 2015 volgens een artikel in de financial times.
Dit soort big bang conversies brengt enorm veel risico's met zich mee, ook financieel.

[Reactie gewijzigd door mesa57 op 24 juli 2024 01:58]

[Zidane007nl]

Leuk zo'n paywall die via Google als referer te omzeilen is.