Banken bytter «motor» – gjør seg mindre avhengig av stormaskin og Cobol

[Gjest Marius B. Jørgenrud]

Milliardavtale vunnet av Evry.

Banken bytter «motor» – gjør seg mindre avhengig av stormaskin og Cobol

[0laf]

Alt blir bedre med Evry bak spakene ........ bazinga !

 

Det er flere grunner til at COBOL benyttes, det er et enkelt språk som er uovertruffent til tall som representerer valutaer, altså med to desimaler, det er tross alt laget kun for dette formålet, og det er bunnstabilt og har vært benyttet til omtrent alle transaksjoner de siste 30 årene, og har eksistert i 57 år nå, nærmest uten feilslag.

 

Dette er ikke rakettforskning, poenget er å gjennomføre transaksjoner så enkelt og sikkert som mulig, punktum.

 

Det er liksom ingenting annet som kommer i nærheten av COBOL når det gjelder finansielle transaksjoner, men en overgang til mer Java er sikkert vel og fint, det er sannsynligvis uansett kun snakk om ytre lag, selve kjernen av systemene skal vel fremdeles benytte mainframe og COBOL.

 

Samtidig tilsier all erfaring at det å slippe til Evry med sine "nye og bedre løsninger", stort sett er ensbetydende med "epic fail", Evry har vel enda ikke klart å gjennomføre et prosjekt til angitt tid, pris og spesifikasjon, og alt de er borti ser ut til å krasje støtt og stadig.

[quantum]

Det er én grunn til at cobol fortsatt benyttes, og det er at det koster penger å bli kvitt. Hvor vanskelig er det å implementere en datatype som representerer et beløp i en gitt valuta? Ikke veldig ...

[0laf]

Vanskeligere enn man skulle tro, i og med at datamaskiner ikke har tall, men kun estimerer tall ved bruk av flytende punkt.

 

Det er fort gjort at små feil blir til store følgefeil, i et slikt system, og man må ha en nøyaktig representasjon av tall.

 

For eksempel : https://jsfiddle.net/oj68ow4f/

[ATWindsor]

Vanskeligere enn man skulle tro, i og med at datamaskiner ikke har tall, men kun estimerer tall ved bruk av flytende punkt.

 

Det er fort gjort at små feil blir til store følgefeil, i et slikt system, og man må ha en nøyaktig representasjon av tall.

 

For eksempel : https://jsfiddle.net/oj68ow4f/

 

Brukes "flytende punkt" på norsk? Jeg er vant til flyttall. (er genuint nysgjerrig)

 

AtW

[0laf]

Flyttall er det korrekte ordet, men det både skrives og sies "flytende punkt" en hel del, sannsynligvis fordi det heter "floating point" på engelsk.

[quantum]

Vanskeligere enn man skulle tro, i og med at datamaskiner ikke har tall, men kun estimerer tall ved bruk av flytende punkt.

 

Det er fort gjort at små feil blir til store følgefeil, i et slikt system, og man må ha en nøyaktig representasjon av tall.

 

For eksempel : https://jsfiddle.net/oj68ow4f/

 

 

OK. Hvis du mener Cobol er et bedre alternativ enn JS/Node til finansielle transaksjoner skal jeg ikke protestere ... eller applaudere. Men generelt, bruker man den tilnærmingen du viser til der er det ikke programmeringsspråket det er noe galt med, for å si det sånn ...

Endret 7. november 2016 av quantum

[0laf]

bruker man den tilnærmingen du viser til der er det ikke programmeringsspråket det er noe galt med, for å si det sånn ...

Det er jo kun et veldig enkelt eksempel som viser at en datamaskin ikke klarer den enkleste aritmetikk på flyttall (<- tada).

 

Det er ikke språket som er problemet i det eksemplet, det er et underliggende problem som bygger på hvordan datamaskiner fungerer, og som er gjeldende i alle språk, og derfor er det viktig at språket man benytter klarer å behandle tall på en sikker og konsistent måte, og COBOL er laget for nettopp dette, og dette alene, og har gjort det i 30 år.

 

De underliggende finansielle transaksjonene er jo generelt noe man ikke trenger å oppdatere til nye fancy ting, så lenge det virker, det er jo tallknusing som har endret seg lite opp gjennom årene.

[quantum]

Uhm, Cobol er vel også laget for hullkort mener jeg å huske ... 

 

Ellers har du jo forsåvidt rett i if-it-aint-broken-dont-fix-it-tankegangen, problemet er bare det at verden går framover, også finansverdenen, slik at de transaksjonene som fortsatt tygges av gammel cobol-kode egentlig ikke lengre fyller de behovene vi har. Regler og lover endres, behov endres og så videre, og tildels kan man komme unna med å implementere ny funksjonalitet i f.eks. Java oppå gammel i f.eks. Cobol, men sistnevnte blir mer og mer en brems og må til slutt erstattes.

[0laf]

COBOL er på ingen måte en brems, for enkle finansielle transaksjoner er det sannsynligvis langt raskere enn for eksempel Java, og det kjører helt fint på hardware som støtter hotswapping og som klarer enorme mengder I/O osv.

 

Det er jo derfor COBOL er å foretrekke, det er bunnstabilt, og har bevist at det klarer å holde tritt med verdens finansielle transaksjoner uten de helt store problemene, men jeg forstår selvfølgelig at bankene ønsker å bygge mer moderne ting, men jeg er ikke helt sikker på at Java nødvendigvis er noe bedre?

 

Så er det jo som det står i artikkelen slik at man ikke skal bytte ut grunnsystemene, Sparebank 1 er jo avhengig av å kommunisere med resten av verden.

 

Så å si alle finansielle transaksjoner går gjennom en mainframe, og det er ikke bare snakk om nettbank, men all bruk av kort, minibanker og lignende.

Totalt kan enkelte core-mainframes prosessere millioner av transaksjoner i sekundet, til sammenligning tar Google i mot 50-100k søk i sekundet, slik at høy I/O og 110% tilgjengelighet er helt livsviktig for finanssektoren.

 

Resten av systemet er jo basert på COBOL, enten det er minibanken, kortterminalen eller serveren som tar i mot transaksjonen, så er COBOL stort sett i bruk over alt, slik at når Sparebank 1 nå skal benytte mer Java, så er det helt sikkert ikke grunnsystemene som byttes ut, men kun et ekstra lag for å gjøre det enklere å kommunisere med mainframen e.l.

 

Nå er jo Java et forholdsvis trygt språk, det har en del innebygget håndtering av feil og lignende, men jeg vil påstå at Java er betydelig mer utsatt for feil enn COBOL, og kan i verste fall fortsette å kjøre med minnelekkasjer og det som verre er, å gjøre for eksempel feil kalkulasjoner, som ville være totalt katastrofe i et banksystem.

 

Men, ønsker Sparebank 1 å ta den risikoen, og samtidig betale milliarder av kroner for den tvilsomme æren å få ustabile moderne systemer, og av Evry av alle, som det virker som alltid står bak alle de store systemene som feiler på rekke og rad, så må de gjerne gjøre det for meg, jeg er ikke kunde der, slik at det er ikke mine penger de roter bort, og heller ikke mine kontoer som ikke er tilgjengelig på grunn av "Evry-feil", som jeg liker å kalle det.

Endret 7. november 2016 av adeneo

[quantum]

enkle finansielle transaksjoner 

 

 

 

Der traff du spiker'n.

 

Og hvis du tror en eneste krone du disponerer er "uinfisert" av Java, så tar du fullstendig feil. Skatten din, pensjonen din, lønna di, fondsandelene osv; alt avhenger av Java. Ja, det fins banker og forvaltere som kjører på andre plattformer, og nei, ingen (ihvertfall som jeg vet om) kjører homogent Java. Men det er ikke mange øre i den norske økonomien som ikke er innom en java-transaksjon i ny og ne. Så hvis du har tenkt å få panikk er akkurat nå et passe øyeblikk.

Endret 7. november 2016 av quantum

[0laf]

Der traff du spiker'n.

Systemene er kanskje ikke enkle, men transaksjonene er veldig enkle.

 

Dersom du kjøper noe med bankkortet ditt, så er det noe forenklet et nummer som representerer deg, et nummer som representerer selgeren, og et nummer som representerer bankene dere bruker, samt summen kjøpet koster.

 

Dataene sendes til en mainframe, som trekker beløpet fra din saldo, og legger det til kjøperens saldo.

 

Alle slike transaksjoner er standardisert i ISO8583, og det er ikke snakk om veldig kompliserte spørringer eller matematikk, kun et enormt stort antall spørringer som alltid må fullføres.

[quantum]

 

Der traff du spiker'n.

Systemene er kanskje ikke enkle, men transaksjonene er veldig enkle.

 

 

 

Her kommer jo gullkornene på rekke og rad! 

[tommyb]

Hvis man bruker at Cobol er laget for hullkort som et argument mot det, vil jeg minne på at alfabetet du bruker her er adskillig eldre enn Cobol. Du bør tenke gjennom argumentene du skyter ned, for de er verd å tenke gjennom. 

 

At verden går framover betyr ikke at alle endringer gir bedre resultat. Cobol er på vei ut, og det er ikke rart, men det er et verktøy som har virket etter hensikten, og gang på gang har man gjort seriøse vurderinger og ikke valgt å bytte ut Cobol med Java. 

 

Java er ikke noe mer "verden går framover" nå enn det var da Java-utviklere i mitt kull ble ansatt og omskolert til Cobol av finansinstitusjonene på toppen av IT-bobla. Da støttet man alle IT-prosjekter unntatt å bygge om disse gamle systemene til Java - fordi det var en dårlig idé. 

[quantum]

Skal vi dra den ennå litt lengre og minne om at de fleste programmeringsspråk, Cobol inklusive, faktisk programmeres i det samme alfabetet vi bruker nå? Minus æøå og litt til? For sånn er det jo. Betyr det at ethvert programmeringsspråk basert på samme alfabet er vaksinert mot utdatering? Du bør tenke gjennom argumentene du skyter ned, for de er verd å tenke gjennom. 

 

Når det gjelder de andre argumentene du forsøker å skyte ned, så har jeg ikke helt registrert at jeg har fremsatt dem. 

[uname -i]

Det skal hvertfall bli artig å følge med på den migreringen. Eldgammel kode etter fossefallsmetoden optimalisert for sin bruk på en skuddsikker plattform skreddersydd til formålet skal migreres over til noen sammenraskede x86-servere i et datasenter på Fet(eller SKYEN som det heter) av java-utviklere med postIT-lapper og en god dose optimisme. Det er hvertfall den litt flåsete kortversjonen.

[0laf]

Og hvis du tror en eneste krone du disponerer er "uinfisert" av Java, så tar du fullstendig feil. Skatten din, pensjonen din, lønna di, fondsandelene osv; alt avhenger av Java.

Joda, Java finnes overalt, og som de fleste andre språk så er det allerede innebygde datatyper som kan representere tall riktig, såkalte fixed-point typer.

I Java er vel det int, long, byte og char, eller så man kan benytte BigDecimal klassen. Float og double er selvfølgelig dårlige valg for denne typen tall.

 

Det betyr likevel ikke at Java nødvendigvis er bedre enn COBOL, sistnevnte ble tross alt skrevet den gangen man hadde magnetiske harddisker store som hus, og servere hadde prosessorer som var en brøkdel av det man finner i en av dagens kalkulatorer til 49,- spenn.

COBOL er også milevis nærmere metallet enn Java, og benytter betydelig mindre resurser. COBOL er laget for finansielle transaksjoner, og klarer enorme mengder "throughput", altså data inn, enkel aritmetikk, data ut.

 

Desto mer "stasj" man legger til i Java for å gjøre de samme kalkulasjonene som COBOL gjør rett ut av boksen, desto lengre unna metallet kommer man, og til syvende og sist er jo alt kun snakk om flytting av bits i minnet, og kortere vei gir raskere flytting.

Det som er viktig for et slikt system er hvor raskt språket kan behandle transaksjoner, og Java er greit nok til slike ting, men ikke i nærheten av COBOL.

 

Det er en grunn til at man også bruker COBOL og Fortran på diverse "supermaskiner" , disse gamle språkene som har vært her siden femtitallet har en evne til å være raskere enn mange av de mer moderne språkene, med pakker, kompilere og så videre som ikke nødvendigvis produserer den mest effektive koden for tallknusing.

 

Kanskje Sparebank 1 kunne satse på Smalltalk i stedet for Java, så kan de slå seg sammen med Politiet.

[quantum]

Kort oppsummert så er vel svaret "nei". Nei, man ønsker ikke "bare metal", nei, man vil ikke ha et simplest mulig programmeringsspråk fordi alt til syvende og sist bare er 0 og 1, nei, Cobol støtter ikke en masse ut av boksen som Java ikke gjør, nei, Java er ikke langt fra "jernet" når jvm'en har varmet opp og bytecode er oversatt til maskininstruksjoner. Nei, nei og atter nei.

Endret 7. november 2016 av quantum

[9R0IC7YD]

Mye rart i denne tråden. 

 

EVRY skal bytte ut de sentrale kjernesystemene på stormaskin (innskudd og utlån), ikke lage et nytt lag med Java utenpå (det har de forsøkt før). I tillegg skal hele transaksjonsflyten (systemene som er involvert før en transaksjon treffer en konto) byttes ut. 

 

Heldigvis skal alt kodes i India...

[0laf]

Så lenge det lages i India, så snur jeg til å være utelukkende positiv, og trekker tilbake noen av mine kommentarer.

 

Utviklerne i India er betydelig mer kunnskapsrike enn Evry's egne utviklere, og gjør langt færre feil, så de har nok dette "ironed out", som det heter, i løpet av et par tiår.

 

 

Evry skal leverer "motoren", hva enn det er, til et nytt core-banking system som ikke benytter mainframes, men som lever i en eller annen sky hos Digiplex.

Samtidig leverer altså Evry et integrasjonsgrensesnitt for denne motoren, alt skrevet i Java, alt "platformuavhengig", og sikker SOA, Agile og what not. De har gode selgere.

 

Core-banking, eller "kjernebank" som Digi kaller det, er systemene som holder orden på reskontro, altså bankenes debet og kreditt, ikke nødvendigvis kundenes "innskudd og utlån".

Endret 8. november 2016 av adeneo