Topdanmark pensionerer 30 år gammelt PL/1-system: »Vi skal skifte, før det bliver et problem«

Et hjemmebygget forsikringssystem skal erstattes hos Topdanmark, før der ikke længere er it-folk med evner til at vedligeholde det.

It-professionelle uddannes ikke længere i mainframesproget PL/1, som Topdanmarks livsforsikringssystem er skrevet i. Flere af selskabets interne eksperter nærmer sig pensionsalderen, så nu skal PL/1-systemet sammen med en selvudviklet datamodel samme vej.

»Det er imponerende, at det har kørt i så mange år,« konstaterer Brian Rothemejer Jacobsen, der er administrerende direktør i Topdanmark Livsforsikring.

Læs også: Manglen på mainframe-folk truer: Unge gider ikke Cobol

Sidste år administrerede Topdanmark forsikringspræmier for 7,5 milliard kroner på systemet. Og det havde man ikke forestillet sig dengang, systemet blev lavet i 1980’erne.

»Modellen er ikke bygget til den stigende kompleksitet, og strukturen er lavet på et tidspunkt, hvor markedet var helt anderledes. Den udviklingsindsats, der skal til, er alt for stor i forhold til et moderne system,« understreger Brian Rothemejer Jacobsen.

Ikke interesse for PL/1-udvikling

Mainframesproget PL/1 stammer fra 60’erne og har primært været udbredt i Tyskland og Skandinavien. Nu er sproget ikke længere en del af pensum på landets it-uddannelser, og det bliver mere og mere vanskeligt at finde folk, som kan og vil arbejde med PL/1, fortæller Søren Stevnsborg, der er it-direktør i Topdanmark Forsikring.

»Udfordringen er ikke mindst, at man skal kunne systemet og kunne sproget, men man skal også kende feltet omkring liv og pension. Og det er en pakke, som mange udviklere ikke er interesserede i,« forklarer han.

Læs også: Topdanmark indkalder IBM til krisemøde om Se og Hør-skandale

Over tid er 80’er-systemet blevet omkodet og moderniseret og har knopskudt. Det er dog stadig ikke et realtidssystem, hvilket betyder, at selskabet skal køre batchopdateringer hver eneste nat. Dertil kommer en hjemmelavet database, som gør det vanskeligt at at sætte nye folk ind i systemet.

»Alt i alt vurderer vi, at det er tid til at skifte. Vi skal reagere, før det for alvor bliver et problem. Vi skal nok holde det flyvende. Men spørgsmålet er, hvornår vi render ind i forretningsmæssige behov, vi ikke kan honorere,« siger Søren Stevnsborg.

Nærmer sig pensionen

Systemet skal som minimum kunne holdes flyvende i perioden, det tager at skifte til et nyt system. Derfor nytter det ikke at køre videre til sidste krampetrækning eller vente, til manglen på PL/1-eksperter bliver problematisk.

»Dem, der kan det, nærmer sig pensionen. Så hvis vi ikke gør noget, bliver vi klemt på, at vi ikke kan skaffe ressourcer til at vedligeholde og udvikle systemet,« siger Brian Rothemejer Jacobsen.

Læs også: Her er Danmarks (måske) største it-projekter

Til at erstatte det aldrende legacy-system har Topdanmark hyret det danske softwarehus Schantz Data, som om to til tre år skal levere systemet LIVA. Den præcise pris er fortrolig, men der er ifølge direktøren tale om et pænt nicifret beløb.

»Valget faldt på Schantz, fordi deres platform minder mest om et standardsystem,« forklarer Brian Rothemejer Jacobsen.

Vil udvikle software med konkurrenter

Fremover ønsker Topdanmark nemlig ikke at stå alene med alle omkostninger, når ændringer i lover og reguleringer stiller nye krav til branchen.

»Tidligere har vi skullet lave og betale alle ændringer selv. Nu vil vi gerne over på en platform, hvor vi kan dele udgifterne med andre,« lyder det fra Brian Rothemejer Jacobsen.

Læs bloggen.: Programmeringssprog: Hvad blev der af PL/1

»Der er en lang række funktioner, som kræves af loven og er ens for alle selskaberne. Det vil sige, at de er konkurrence-neutrale. Der er ikke grund til, at vi alle skriver vores egen udgave af den kode,« forklarer han.

Endnu har Topdanmark ifølge direktøren ikke været i dialog med andre forsikringsselskaber om planen, som kendes fra bankverdenen.

»Men vores håb er, at andre pensionsselskaber også hopper med på denne platform.«

Version2 holder trit med landets største it-projekter. Kender du til et it-projekt, som ikke er på listen, så smid en kommentar eller en mail til mab@ing.dk

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Martin Kofoed

Jeg har kodet PL/1 en periode, og det er et struktureret sprog som så mange andre med procedurer, if/then/else-, do/while/until-konstruktioner osv. .. Altså ting man som programmør måske skal gøre lidt anderledes, men som man burde kunne lære i løbet af ganske kort tid. Så jeg synes måske ikke heeeelt, "alle vores eksperter går på pension"-argumentet er validt.

Og så er jeg klar på et raskt væddemål: det nye system kommer ikke til at holde i 30 år.

Hvis jeg skulle kassere sådan et system i dag, ville jeg gå efter at få det nye til at holde 30 år. Og det gør man netop ved at lade nogen brænde for sagen ved at bygge tingene selv - som man gjorde med det gamle system. Ikke ved at købe et SAP-system eller anden dyr hyldevareløsning, som ingen kommer til at føle noget særligt for.

  • 16
  • 1
René Nielsen

Hvis jeg skulle kassere sådan et system i dag, ville jeg gå efter at få det nye til at holde 30 år. Og det gør man netop ved at lade nogen brænde for sagen ved at bygge tingene selv - som man gjorde med det gamle system. Ikke ved at købe et SAP-system eller anden dyr hyldevareløsning, som ingen kommer til at føle noget særligt for.


Når man kommer fra en hjemmebygget system som Topdanmark’s, så tror jeg at det har spillet en stor uformel rolle, at Topdanmark hellere vil være ”en stor fisk i lille dam end en lille fisk i en stor dam”.

SAP’s brancheløsning ”Insurance” er altså et gennemprøvet produkt http://go.sap.com/solution/industry/insurance.html og problemet med at fastholde medarbejdere kan jo også anskues den modsatte vej!

PL/1 har aldrig haft den store udbredelse (i Danmark) og i de sidste mange år har Topdanmark vel været ene om at benytte sproget i Danmark så der er vel ikke mange headhuntere ”som har revet i Topdanmarks PL/1 medarbejdere med et jobtilbud lige rundt om hjørnet”.

På måde er man måske mere tilbøjelig til at finde sig i ”dårlig ledelse” end hvis dit hovedsprog var ABAP/4 fra SAP?

Om en løsning holder 30 år eller 3 år afhænger efter min erfaring i højere grad af projektet og dets evne til at fastholde medarbejderne end om det produkt man implementer.

Noget som dog afkorter løsningens levetid er efter min erfaring licensomkostninger, outsourcing og ændret lovgivning. De to første dele kræver at løsningen løbende opgraderes da licensomkostningen hhv. outsourcingprisen ellers vil stige. Den sidste kan du ikke garder dig imod, men må blot rette ind og så kan en re-implementering komme på tale pga. lovgivning.

  • 3
  • 0
Arne Raunsbæk

PL/1 har aldrig haft den store udbredelse (i Danmark) og i de sidste mange år har Topdanmark vel været ene om at benytte sproget i Danmark så der er vel ikke mange headhuntere ”som har revet i Topdanmarks PL/1 medarbejdere med et jobtilbud lige rundt om hjørnet”.

Dette er direkte forkert næsten alle bank centraler har programmer kodet i PL/I alle sags system som KMD har lavet til kommuner og stat er lavet med PL/I som back-end der ud over er store dele af skat's systemer også kodet i PL/I. så jeg ville nok lige overveje at undersøge mine fakta før der kommer sådan en udmeldelse.

PS. selve motoren i hele vores dagpenge system er også lavet i PL/I og det har nu kørt i 30+ år, og den har vist sig svær skifte.

  • 8
  • 0
Peter Larsen

PL/1 er der vist aldrig blevet undervist I på IT-uddannelser.
Jeg læste IT på DIKU og der var der et meget lille COBOL-kursus som man intet lærte af. PL/1 lærte jeg I KMD ved at læse den berømte gule bog og så bare gå I gang. PL/1 er et helt normalt sprog med almindelige sprogkonstruktioner, så kan du Pascal, C, Java og mange andre - ja så kan du lære PL/1 meget meget nemt.
En zEnterprise maskine er helt igennem super at arbejde med, jeg har gjort det I små 30 år og idag udvikles programmerne I et grafisk værktøj (Eclipse), så det ligner alt muligt andet udvikling - slet ikke sværere end alt muligt andet.
I KMD har vi som en skrev mange PL/1 programmer. Faktisk betjener vores zEnterprise maskine ca. 6 mia. forespørgsler via web-services om året. Så selv om resultatet præsenteres I en flot .Net klient, web-sider eller SAP-løsninger - så er det stadig PL/1 og web-service integration der trækker det helt tunge læs.
Men indrømmer da gerne at med tiden vil flere systemer skifte til andre platforme, måske noget man fortryder i nogle sammenhænge da en zEnterprise er forholdsvis let at have med at gøre - og så er den super hurtig.
Håber der præsenteres regnestykker der kan vise at et meget stort system i f.eks. .Net er meget billigere. Men husk nu at medtage ALLE omkostninger, selv gulvplads i et serverrum, strøm til serverne og køling af samme er jo dyrt når der er mange af dem.

  • 8
  • 0
Martin Kofoed

Om en løsning holder 30 år eller 3 år afhænger efter min erfaring i højere grad af projektet og dets evne til at fastholde medarbejderne end om det produkt man implementer.

Helt enig. Men her er min pointe, at hvis man som medarbejder har følelserne med i dét, man har været med til at bygge op, og hvis man tildeles ejerskab, tillid fra ledelsen og dermed et stort ansvar, ja, så er man også mere tilbøjelig til at blive hængende. Sådan er min egen, personlige anekdotiske evidens i hvert fald ;)

  • 2
  • 0
Lars F. Jensen

Når man skal skrive en god bog, så er det historien der tæller og sproget skal bare vælges blandt et man behersker.

Indenfor programmering er det evnen til at strukturere, logisk opbygge og skrive ensartet 'pæn' kode, der tæller.
Så kan man da hurtigt lære en ny syntax og de par 'tricks of the trade', der er kendetegnende for det valgte sprog.

PL/1 er jo et meget kraftfuldt sprog, der fx kan og gør mange ting lidt rigeligt automatisk for den der ikke helt har forstået alle sprogets regler.
Men for en dygtig programmør er det da ganske brugbart.

Den største fejl ve PL/1 er vel, at der er få gode oversættere på andet end mainframes, og det begrænser naturligvis portabiliteten.

Jeg havde engang en kollega, der selv ville skrive en procedure til at DES kryptere. DES er grundlæggende noget med at ombytte en masse bits og grupper af bits udfra data og nøgle.
Hans PL/1 program brugter både arrays af bits og bytes. Det virkede, men der blev konstant konverteret frem og tilbage mellem datatyperne og proceduren kostede en 'halv mainframe' at afvikle.
Det gjorde den ikke længere, da vi fik kikket på og rettet hans kode.

Lars :)

  • 2
  • 1
Morten Bøgh

Diskussionen her cirkler - med gode indspark - omkring et andet problem: Er der fremover nogen der kan udvikle backend-systemer i Danmark? Er der i fremtiden programmører med fokus på den slags systemer, eller må vi fremover bygge nationens kærnesystemer på tilpassede SAP-brancheløsninger? Erfaringen viser - som Topdanmark også nævner - at den slags globale standard-systemer er meget tunge at tilpasse til dansk lovgivning og sædvane. Topdanmark satser fornuftigt nok på noget andet: At opnå nogle synergi-effekter i hele forsikringsbranchen ved at satse på en ekstern, dansk, hjemmeprogrammeret løsning. Hvilke odds det har, har jeg ingen ide om, men opgaven er da krævende. TopDanmark får et tæt afhængighedsforhold til Schantz data - for så vidt et større problem end at være afhængig af en pulje af egne PL/1 programmører.

Kærnen i puddelhunden er, at Topdanmark føler behov for et nyt backend- system. Et backend-system er en relationsdatabase samt en programmeret logik omkring ajourføring af denne. ‘Kontoføring' er oftest det centrale i et backend-system, dvs at vedligeholde kundeinformationer. Sådanne systemer kan være enormt omfattende og komplekse, antallet af transaktioner pr sekund gigantisk, etc.

Udenfor og ovenpå backend-systemet har vi så brugergrænsefladerne. I vore dage er dette browser-baserede og app-baserede systemer mod kunderne, og oftest mere traditionelle PC-systemer mod sagsbehandlere og analytikere internt i firmaet. Et backend-system servicer således typisk en række helt forskellige brugergrænseflader, hvilket også bidrager til at give backend-begrebet selvstændig mening: Det skaber sammenhæng på tværs af brugergrænseflader.

DIKU underviser ikke i dette. DTU har et enkelt kursus i IBM mainframe. Om det indgår andre steder i undervisningssystemet ved jeg ikke. I gamle dage havde især Datacentralen en undervisnings-afdeling med adskillige kurser omkring backend-systemer.

Problemet er nok også, at de backend-systemer vi programmerede i 1980’erne har fungeret så godt, og nogen af dem har vi sågar været ferme til at videreudvikle. Dvs. der har i en årrække ikke været det helt store behov for at få bygget samfundets grundlæggende it-infrastruktur - den var stort set på plads. Dermed har undervisnings-sektoren heller ikke haft den store trang til at udbyde kurser i udvikling af backend-systemer, beskæftigelsesmulighederne var begrænsede.

Men problemet popper op. Hvis vi alle går på pension, må nogen tage over, og det er svært at oparbejde tværgående viden om et stort backend-system. Og: Ikke alle backend-systemer kom på plads i 1980’erne: Mærsk var (omkring år 2000?) ved at kuldsejle på grund af et nyt system til container-styring, hvor containerne i en længere periode sejlede tilfældig rundt i verden. Lars Larsen fik i foråret 2015 eksistentielle problemer med fusionen mellem Ilva og Idé-møber, hvor tilsvarende et nyt it-system betød at ingen anede hvor sofabordene befandt sig, hvor mange man havde af dem, og hvem der havde købt dem. I pipelinen (til nye problemer?) har vi så Topdanmark, Nordea mv.

Om backend-systemet programmeres i COBOL, PL/1 eller Java er ikke det helt store issue. Det afgørende er at det er et data-centreret system. Dataanalyse er en central teoretisk disciplin i den forbindelse. Data skal ligge rigtigt, og nøglestrukturer skal være gennemtænkte. Begreber som ‘No-sql-databaser’, ‘databank’, ‘objekt-orienteret-programmering’, ‘use-case’ er det rene hedenskab i denne sammenhæng. Kærnen i et backend-system er en relations-database, og en meget stor del af logikken i systemet er programmeret i SQL (og hverken i COBOL, PL/1 eller Java). Tilsvarende er 'database-administrator' en nok så vigtig rolle, lige så vigtig som ‘programmør’.

PS: At objekt-orienteret programmering er den rene hedenskab i denne forbindelse: Det bliver for småt, for hjemmestrikket, for integreret, man kan ikke erstatte SQL-kontohåndteringen i fx. VISA-systemet med et Java-kompleks med get og put metoder mod instanser af konto-objekter som svømmer rundt i cpu’en forfulgt af garbage-kollektoren. SQL-databasen udgør en dekobling mellem datalagring og backend-programmel, en orthogonalisering af forholdet: Databaseadministratoren kan optimere accesveje uden at indblande backend-programmernes programmører - og omvendt: programmørerne kan programmere uden at have skaleringsmuligheder og performance konstant i fokus. Dvs. COBOL og PL/1 har i denne forbindelse én fordel i forhold til JAVA: De er ikke objektorienterede sprog. Og COBOL og PL/1 har i øvrigt meget rationelle interfaces til SQL.

  • 3
  • 2
J. Martin Petersen

Det er fint nok med denne her romantisering af et gammelt system, der har overlevet sig selv. Men TopDanmark har i næsten halvdelen af dets levetid ønsket sig noget andet, fordi det er dyrt og besværligt for dem at tilpasse sig ændringerne i samfundet (bl.a. lovgivning). Livsforsikringsprodukter er komplekse størrelser og de konstant ændrede krav til bl.a. solvens-opgørelser kræver en nogenlunde fleksibelt platform.

  • 2
  • 3
Lars F. Jensen

et gammelt system, der har overlevet sig selv.

Men et dårligt systemoplæg, der er alt for lidt abstrakt og alt for 'konkret til 1980 lovgivning' har intet med PL/1 at gøre.
Det har alt med oplæg og planlægning og ikke nødvendigvis med den mere praktisk implementering og slet ikke med PL/1.

Vi er mange, der har nye set systemer, der aldrig blev gode eller færdige - og jeg har set flere 20-30 år gamle systemer, der fra starten var ændringsparater, kunne skaleres, kunne ......

Jeg har set gamle, men gode systemer blive aflyst af ringere produkter.

Lars :)

  • 3
  • 0
Jonas Høgh

Om backend-systemet programmeres i COBOL, PL/1 eller Java er ikke det helt store issue. Det afgørende er at det er et data-centreret system. Dataanalyse er en central teoretisk disciplin i den forbindelse. Data skal ligge rigtigt, og nøglestrukturer skal være gennemtænkte. Begreber som ‘No-sql-databaser’, ‘databank’, ‘objekt-orienteret-programmering’, ‘use-case’ er det rene hedenskab i denne sammenhæng. Kærnen i et backend-system er en relations-database, og en meget stor del af logikken i systemet er programmeret i SQL (og hverken i COBOL, PL/1 eller Java). Tilsvarende er 'database-administrator' en nok så vigtig rolle, lige så vigtig som ‘programmør’.


Det er helt rigtigt, at der har været mange forsøg på at "modernisere" traditionelle backend systemer, som er endt i fiasko, fx pga. bloatede Enterprise Java-stakke og elendigt ydende Object/Relational Mapping værktøjer. Men jeg tvivler på at de gamle teknologier vil holde stand meget længere. Hvis ikke de eksisterende finansdinosaurer evner at mestre nyere teknologier, vil moderne IT-virksomheder, enten i form af eksisterende giganter som Amazon eller Google, eller nye FinTech startups, udkonkurrere dem. At holde styr på nogle få hundrede tusind kunder i et dansk pengeinstitut er jo nærmest et legetøjsproblem i forhold til de datamængder som fx Google håndterer.

  • 1
  • 1
Lars F. Jensen

....ingen af de halvfærdige eller ikke-skalerbare systemer fra for 20-30 år siden, der stadig er kørende.

De meget ringe og helt umulige er naturligvis væk.

Men jeg tror du vil blive overrasket, hvor mange systemer, der alligevel er, som humper afsted på bedste (værste) beskub.

Det er naturligvis en lidt nyere historie, men se på det uhyggelige antal WinXP, der fortsat anvendes i sygehusvæsnet.

Lars :)

  • 1
  • 1
Denny Christensen

Nu forventer TopDanmark næppe at skalere fra nuværende antal kunde til hele verden lige om lidt - så der er nok stadig lidt tid at løbe på inden det gamle system løber tør for kapacitet.

For dem der ikke har arbejdet med mainframes vil overraskelsen over evnerne til at masse-behandle data overraske.

At systemet så ikke arkitektur mæssigt ikke er bygget til mange af de nyere krav er noget andet og det er i min verden stort set teknologi uafhængigt.

  • 0
  • 0
Peter Christiansen

Fordi man ikke uddanner folk i PL/1 og det ikke er en del af pensum,
er da et super dårligt argument for at stoppe med systemet.
Enhver der er uddannet datalog, datamatiker og andet har kva studiets
all round pensum meget hurtigt mulighed for at tillære sig andre sprog.

Med lidt hjælp fra de gamle programmører med erfaring med systemet,
skulle det da være muligt at holde puljen af udviklere nogenlunde ajour.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize