Færøsk migrering med kultursammenstød og timestamp-problemer

20 kommentarer.  Hop til debatten
Færøsk migrering med kultursammenstød og timestamp-problemer
Illustration: Elektron.
Proof of concept for mainframe-migrering virkede, men hvordan går det på Færøerne, når hele skattesystemet skal konverteres til en Windows-platform?
Reportage6. januar 2020 kl. 05:03
errorÆldre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Dette er den tredje og sidste del i Version2's fortælling om det store færøske migreringsprojekt væk fra mainframen.

Et lille agilt udviklerteam har arbejdet koncentreret på at få udviklet de nødvendige værktøjer og softwarekomponenter, så det færøske skattevæsen Taks' mainframe-baserede systemer kan blive konverteret til en Windows-platform.

Et tidligere migreringsprojekt blev indstillet grundet manglende fremdrift, men efter det lille teams vellykkede proof of concept bliver der givet grønt lys til at genstarte Færøernes største migreringsprojekt.

Log ind og få adgang
Du kan læse indholdet ved at logge ind eller oprette dig som ny bruger.
20 kommentarer.  Hop til debatten
Debatten
Log ind for at deltage i debatten.
settingsDebatindstillinger
20
27. januar 2020 kl. 20:18

Pointen er at en kodebase hvor der er spredt GOTO statements ud over det hele, hvor der er globale variable i stor stil, etc. ikke er en moderne kodebase.

Det har du fuldstændigt ret i, og det er derfor jeg skrev moderne sprog og ikke moderne kodebase – jeg ser moderne sprog som forudsætning for at målet om kodebase kan nås.

Der er trods alt begræsningener på hvordan GOTO kan bruges i C#, og tilgang til globale variable kan krydsrefereres – så du har muligheder for at ræssonere om kodebasen.

Jeg ville have skrevet en PL/1 fortolker til .Net. Dygtige/middelgode softwareudviklere kan nemt lære et nyt sprog og gamle sprog/udviklingsmiljøer har typisk et relativt lille medfølgende library. Dette kunne nemt implementeres i C# og de har alligevel lavet det for at få koden til at køre. Det er typisk ikke sproget der er det svære at lære - det er hele det "standard library" der kommer med der tager tiden.

Jeg er enig i at standard library (og 3. parts økosystem) typisk er den helt store tidssluger i forhold til at lære en ny platform... specielt når vi kigger på nært beslægtede sprog.

Men du skal også tænke på muligheden for at få ny arbejdskraft. "Lær et uddødt sprog, og bliv ved med at videreudvikle i det" tiltrækker nok udelukkende folk der tænker i job security. "Vær med til at bringe en legacy kodebase ind i det nye årtusind, og du kan trods alt bruge de sprogfeatures du er vandt til" sælger nok, trods alt, en del bedre :-)

19
24. januar 2020 kl. 08:27

Der er nu en kodebase i et moderne, statisk og typestærkt sprog, hvor der (med mindre de har lavet noget virkeligt dirty magi i konverteringen) nemt kan trackes referencer, laves refactoring og så videre.

Pointen er at en kodebase hvor der er spredt GOTO statements ud over det hele, hvor der er globale variable i stor stil, etc. ikke er en moderne kodebase. Uanset sprog. Det ligner det bare på overfladen.

Forhåbentligt er der også blevet oprettet et stærkt korpus af automatiske test.

Det ville være interessant at høre hvad de har gjort, men det er altid meget svært at putte automatisk test på gammel kode som ikke er designet til samme. Jeg har gennem årene set rigtigt mange ressourcer blive brugt på at forsøge at hælde magisk test-sovs ud over gammel kode uden at det gav det helt store.

Selv hvis man ikke beslutter sig for at / har held med at omskrive til grundlæggende mere moderne kodebase, er forudsætningerne da klart bedre end at snuble videre med mainframe og PL/1 :)

Jeg ville have skrevet en PL/1 fortolker til .Net. Dygtige/middelgode softwareudviklere kan nemt lære et nyt sprog og gamle sprog/udviklingsmiljøer har typisk et relativt lille medfølgende library. Dette kunne nemt implementeres i C# og de har alligevel lavet det for at få koden til at køre. Det er typisk ikke sproget der er det svære at lære - det er hele det "standard library" der kommer med der tager tiden.

18
23. januar 2020 kl. 21:19

Jeg er mere skeptisk over hvor brugbar og "videreudviklingsvenlig" den konverterede kode er. Dette ville være fantastisk at se nogle større kode-snippets. Men diskussionen om GOTO (i faktaboksen) viser klart problemerne ved at konvertere fra PL/1 til mederne sprog.

Jeg synes det lyder som om de har angrebet problemet på den eneste måde der giver mening whatsoever.

Der er nu en kodebase i et moderne, statisk og typestærkt sprog, hvor der (med mindre de har lavet noget virkeligt dirty magi i konverteringen) nemt kan trackes referencer, laves refactoring og så videre. Forhåbentligt er der også blevet oprettet et stærkt korpus af automatiske test.

Selv hvis man ikke beslutter sig for at / har held med at omskrive til grundlæggende mere moderne kodebase, er forudsætningerne da klart bedre end at snuble videre med mainframe og PL/1 :)

15
7. januar 2020 kl. 14:45

Interessant at man i den grad kan omprioriterer sin tekniske gæld, og samtidigt belåne lidt af friværdien :)

Jeg er udvikler på Elektron og er kommet til sidst i forløbet og har gjort mig de samme overvejeler som der skrives om her i kommentarerne. Jeg er dog nået frem til at migreringen var den rigtige løsning.

Den første udfordring vi har stået over for har været det med at vedligeholde kode i PL/1, der kommer ikke lige folk ind fra gaden i dag og har disse kompetencer. Men det er ikke kun programmering, det er også drift af Main frame, der har været en udfordring. Ved at skifte over til c# + windows miljø er vi inhouse gået fra ca 10 ansatte (alle 55+) til ca 30 ansatte, der kan programmere og drive løsningerne. Selv om koden ser lidt mærkelig ud, er den ikke umulig at forstå og den virker!!!.

Selv om Main framen var fra 2008, så var den ikke hurtig. Svartiderne på kald til Main frame backend lå før migrering på gennemsnitligt på 4-6 sekunder, efter migrering gennemføres 75% af alle kald på under 700 millisekunder. Skulle de svartider forbedres på main framen ville det kræve dyre opgraderinger. Prisen for migrering er tilbagebetalt inden for ganske få år i forhold til omkostninger til evt. main frame opgradering og licensbesparelser.

Der er ingen tvivl om, at det rigtige er at kode systemerne om, men det vil tage mange år, hvor der skulle køres parallelt på Main frame og ny platform, hvis der ikke var migreret. Vi er nu i gang med at forberede en ny platform til nyudvikling, der kan sameksistere med den migrerede platform og det er betragteligt nemmere at få til at lykkes i forhold til at skulle lave en ny platform, der skulle sameksistere med en main frame platform.

Man må håbe at de får adskildt database, API og bruger applikationer fornuftigt.

PL1 programmering på mainframe er meget anderledes end moderne systemer i cloud, microservices mm, så den nye platform vil blive helt anderledes, end det vi kommer fra. Jeg er så heldig at være med til at forberede den arkitektur, hvilket er en spændende udfordring :-)

14
6. januar 2020 kl. 22:02

Opdagede lige at denne artikel åbenbart er en af de nye vi-skal-profilere-dig-endnu-mere artikler.

Jeg har ikke set det før, da jeg har været logget ind på min arbejdspc, men da jeg lige skulle checke på en tablet, fandt jeg ud af det.

Jeg ved ikke hvad man havde forestillet sig, men jeg gider altså ikke logge ind på V2 via en telefon eller en tablet, så hvis man tror at man får mere loyale brugere på den måde, så er der vist noget man har fået helt galt fat i.

Suk!

11
6. januar 2020 kl. 15:49

de to for-løkker kan omskrives til

Jeg tror, der snarere skal en while-løkke til i den inderste for at bevare goto-logikken. Men ellers enig i, at C# koden med fordel kan gøres mere idiomatisk.
  1. for(int j = 1; j <= 10; j++)
  2. {
  3. int i = 30;
  4. while (i >= 1 && (/* betingelsen */) )
  5. {
  6. // resten som i eksemplet.
  7. i--;
  8. }
  9. }

10
6. januar 2020 kl. 14:20

Eksempelvis vil jeg tro de to for-løkker kan omskrives til:

Jo ... men skal det overhovedet være for-løkker? C# har iterators. Eller skal data overhovedet ligge i arrays (jeg går ud fra at det er arrays)? Det ligner noget som kunne ligge fint i et HashMap/Dictionary. Og det der mystiske med BuiltIn.Substr ... burde det hele ikke være et metode på LYKYL-klassen? Ovenstående er småting. Baseret på hvad vi kan se ud af 5 linjer kode.

I lidt større perspektiv: nu kører koden i et objekt-orienteret miljø. Hvordan udnytter koden samme? C#/.NET har en fantastisk generics feature (som er uendeligt meget bedre end den i Java) ... hvordan er det brugt til at sikre kodegenbrug?

Og hvis vi zoomer endnu mere ud: Hvad med Microservices, SOA og alle de andre buzzwords der basalt dækker over at lave distribuerede systemer? Vi kunne fortsætte ...

9
6. januar 2020 kl. 13:45

... som viser at den konverterede kode bibeholder det abstraktionsniveau man havde med PL/1 (men på en markant grimmere måde). Der er så mange ting man ville skrive anderledes og mere læseligt hvis koden var native C# kode.

Jeg er helt enig i at koden kunne godt bruge en omskrivning til ren C#, men jeg tror desværre at dette projekt er mindst lige så omfattende, som konverteringen fra PL/1 til C#.

Der er dog nogle dele der er lettere at oversætte end andre dele.

Eksempelvis vil jeg tro de to for-løkker kan omskrives til:

  1. for(int j = 1; j <= 10; j++)
  2. {
  3. for(int i=30; i >= 1; i--)
  4. {
  5. // resten som i eksemplet.
  6. }
  7. }

... men hjælper dette på læsbarheden på koden? Ville det ikke være bedre at loope imellem veldefinerede konstanter?

Og så er der navnene på variablerne: LYK, TAINCLYK, LYKIL.

Her gætter jeg på at man skal være færing, før de giver mening. :-)

8
6. januar 2020 kl. 12:58

Tak for en spændende serie, hvor der også bliver fortalt om problemer, og konkrete løsninger. Absolut et projekt for de modige :)

Helt enig.

Hvordan ser løsning ud fysisk? Jeg forstod at hele løsningen kørte på én mainframe, som er købt i 2008. Og at resultatet kører på 45 Windows maskiner, som er købt løbende de 6 år hvor systemet er udviklet. Umiddelbart lyder det som om systemet fysisk fylder ca. det samme.

Hvordan ser det ud med oppe tid? En mainframe er kendt for at have god tollerance for hardware fejl, sådan at softwaren ikke bliver berørt af det. Og derfor tager mainframe udviklerne heller ikke højde for hardware fejl. Hvad gør I på det nye systemet? Bruger I VMWare, HyperV eller lignende til fejlover for at håndtere hardware fejl og opdateringer? Fordi softwaren tager vil stadig ikke højde for at en maskine kan være nede?

7
6. januar 2020 kl. 12:56

Det store spørgsmål er hvad målet med projektet var:</p>
<p>Var det at reducere licensomkostningerne?
Var det at få et mere moderne udviklingsmiljø og afviklingsplatform, hvor man så kan arbejde videre på koden?

Ja til begge. Det var både licensforhøjelserne for mainframe-software og de aldrende PL/1-programmører, der fik Elektron igang med migreringen, så de kunne spare penge og tiltrække yngre programmører.

Jeg håber næste skridt er at omskrive de enkelte applikationer til rigtig C#. Ikke fil for fil, men applikation for applikation.

Det er planen at Elektron går igang med et pilotprojekt for en applikation, hvor de ser på arkitekturen, blandt andet formentlig udskifte 3270-brugergrænsefladen og tilrette underliggende datamodel. Som jeg forstod det, vil de også se på PL#-koden og gøre den til "rigtig" C# i den forbindelse. For PL/1-udviklerne har den valgte fremgangsmåde været med til at lette overgangen til C#.

6
6. januar 2020 kl. 11:58

Åh nej. Det er grunden til at man skal holde sig langt væk fra at konvertere gamle systemer med mindre kunden i praksis giver en blankocheck på opgaven: Det er helt ufatteligt hvad man kunne finde på af håbløse ting i det sidste årtusinde</p>
<blockquote>
<p>Løsningen bliver at lægge kunstige forsinkelser ind i systemerne</p>
</blockquote>
<p>Hahahaa. Jeg gætter på, at vi om ca. 30 år læser stort set den samme historie igen

Det store spørgsmål er hvad målet med projektet var:

  • Var det at reducere licensomkostningerne?
  • Var det at få et mere moderne udviklingsmiljø og afviklingsplatform, hvor man så kan arbejde videre på koden?

Der er ingen tvivl om at dette reducerer licensomkostningerne. Jeg er mere skeptisk over hvor brugbar og "videreudviklingsvenlig" den konverterede kode er. Dette ville være fantastisk at se nogle større kode-snippets. Men diskussionen om GOTO (i faktaboksen) viser klart problemerne ved at konvertere fra PL/1 til mederne sprog. Ingen skriver i dag kode med GOTO statements.

Der er også denne snippet fra artiklen ...s3_do_leave.png

... som viser at den konverterede kode bibeholder det abstraktionsniveau man havde med PL/1 (men på en markant grimmere måde). Der er så mange ting man ville skrive anderledes og mere læseligt hvis koden var native C# kode.

På sigt vil det gøre koden svær at videreudvikle. Vi kommer sikkert til at høre historier om få år om at der nu skal bruges 4 gange så mange udviklere for at vedligeholde systemerne. Jeg håber næste skridt er at omskrive de enkelte applikationer til rigtig C#. Ikke fil for fil, men applikation for applikation. Med fornuftige opdelinger mellem applikationer. Med veldefinerede interfaces. Etc. etc. Men jeg gætter på at alle nu sætter sig ned og vedligeholder C# koden i dens nuværende form de næste 30 år.

Måske er det også det rette forventningsniveau. Færøerne har deres egne love og regler hvilket medfører at meget/alt skal laves specielt til Færørerne. Og givet at der kun bor 50.000 borgere på færøerne med tilhørende begrænsede skattegrundlag, så bør forventningerne også være derefter.

5
6. januar 2020 kl. 11:38

Interessant at man i den grad kan omprioriterer sin tekniske gæld, og samtidigt belåne lidt af friværdien :)</p>
<p>Det er nok billigere at finde en bunke C# programmørere, frisk fra fad, til at rette i kodebase. Så kan den måske nå at blive pæn og fejlfri, til næste gang, deres vendor-lock-in, bliver et problem.

Også et skræmmende eksempel på hvordan politikere verden over er ved at nedbryde samfundene.

For når nu man har så komplekst et skattesystem, ville det så ikke være en overvejelse værd at lave en radikal skattereform - altså træde et skridt tilbage og se på hvordan man drastisk simplificerer systemet, i stedet for at fortsætte med at tro at jo mere magisk IT sovs man hælder ud af flasken des bedre.

New Zealand lavede manøvren i 80'erne, hvor man var sovset ind i et bureaukratisk, men så lagde om til et meget simplere (og effektivere) skattesystem.

4
6. januar 2020 kl. 11:29

Interessant at man i den grad kan omprioriterer sin tekniske gæld, og samtidigt belåne lidt af friværdien :)

Det er nok billigere at finde en bunke C# programmørere, frisk fra fad, til at rette i kodebase, end erfarne og måske pensionsmodne PL/1 folk. Så kan den måske nå at blive pæn og fejlfri, til næste gang, deres vendor-lock-in, bliver et problem. (Der går nok lidt tid, inden de kan få nye funktioern, uden alt for mange katastrofale fejl i )

Man må håbe at de får adskildt database, API og bruger applikationer fornuftigt.

3
6. januar 2020 kl. 11:12

Tak for en spændende serie, hvor der også bliver fortalt om problemer, og konkrete løsninger. Absolut et projekt for de modige :)

1
6. januar 2020 kl. 10:56

Åh nej. Det er grunden til at man skal holde sig langt væk fra at konvertere gamle systemer med mindre kunden i praksis giver en blankocheck på opgaven: Det er helt ufatteligt hvad man kunne finde på af håbløse ting i det sidste årtusinde

Løsningen bliver at lægge kunstige forsinkelser ind i systemerne

Hahahaa. Jeg gætter på, at vi om ca. 30 år læser stort set den samme historie igen