Sådan implementerer Netcompany Skats digitale inddrivelse

30. oktober 2018 kl. 05:1115
Sådan implementerer Netcompany Skats digitale inddrivelse
Illustration: Tania Andersen.
Oracle-produkt samt hjemmelavede Java-applikationer skal få pengene til at rulle ind i Skat igen efter EFI-katastrofe.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Under den dramatiske overskrift: 'Red det danske velfærdssystem,' fortalte Dan Strang Søndergaard, som er Principal i Netcompany, sammen med Michael Vognsen Nielsen, Manager i samme firma, om arkitekturen bag Skats nye system, der skal afløse EFI, i regi af Implementeringscenter for inddrivelse (ICI).

Det skete på Red Hat Forum, der blev afholdt i København i sidste måned.

Det skandaleombruste EFI-system blev delvist lukket efter seks år. EFI kører dog stadig videre, men inddrivelsen er delvist manuel.

Skat ville undgå et stort vandfalds-projekt og kæmpestore kravspecifikationer til det nye system. Netcompany blev udvalgt som leverandør efter en ‘proof-of-concept’-test. De første dele af systemet gik i produktion sidste år og startede med at inddrive licens til DR.

Container-teknologi hjælper Netcompany med at få Skats nye inddrivelsessystem op at køre. Det gør det blandt andet nemmere at teste, fortæller Michael Vognsen Nielsen fra Netcompany.

Netcompany tager én myndighed af gangen på en agil facon. 150 udviklere arbejder hos Netcompany sammen med 150 fra Skat og andre partnere, såsom ERP-firmaet Visma. Til arbejdet benyttes udviklingsmetodikken SAFe, Scaled Agile Framework.

Artiklen fortsætter efter annoncen

Det er ikke nemt at bygge et teknisk kompliceret produkt, som bygger på lovgivning, med et stort antal udviklere.

Det kræver en masse på det styringsmæssige plan af den underliggende platform, som er Red Hats Open Shift-produkt, fortæller Dan Strang Søndergaard.

Strikker eget værktøj til konfiguration

Michael Vognsen Nielsen beretter, at firmaet har bygget et website oven på Open Shifts api, som også snakker med automatiseringsplatformen i integrationsserveren Jenkins.

Sysemet bygger på Oracles produkt PSRM, Public Sector Revenue Management, sammen med hjemmelavede Java-applikationer, der benytter en række forskellige frameworks. 50 til 70 udviklere arbejder med PSRM, mens yderligere 50 er på Java-applikationerne.

Artiklen fortsætter efter annoncen

Blandt udfordringerne var mangel på gode værktøjer til at flytte PSRM-konfigurationen fra et miljø til et andet. Eksisterende løsninger var værktøjer, der behandlede konfigurationen som en sort kasse, hvilket var i modstrid med ønskerne.

Det betød, at Netcompany skabte sit eget værktøj, ‘PSRM-to-Git.’ Det serialiserer konfigurationen til opmærkningssproget YAML, og anvendelsen af kodestyring gør det muligt at se ændringer i konfigurationen, ligesom med almindelig kode, i form af Git-branches.

Containere giver nemmere test

Projektet benytter automatiserede brugerfladetests i browseren, som er regressionstests, der skal sikre, at funktionaliteten er uforandret, når ny kode kommer til.

Tilbage i 2017 benyttede Netcompany ikke container-teknologien Docker i projektet. PSRM understøtter tidsrejser, for eksempel for at tjekke rentetilskrivning over tid. Når den ene tester arbejder med denne funktion, kan det kan skabe problemer for de andre testere. I stedet får hver tester sit eget miljø, men det var devops-holdet ikke glade for.

Det skyldtes, at udviklerne kunne finde på at pille ved middlewareprodukterne i forbindelse med fejlsøgning, så miljøerne ikke længere var helt ens. Det betød også, at tilliden til miljøet faldt. Og det var baggrunden for, at Skat og Netcompany besluttede sig for at anvende Docker.

Det skal forhindre, at systemet ender som forgængeren EFI. Der er to sæt af test, der skal bruges til at undgå fremtidige katastrofer. Det er almindelige tests, som tjekker, at funktionaliteten matcher de valgte user stories.

Men herudover er der også et sæt test, der handler om at validere at systemet er lovligt, da der er juridiske paragraffer under systemet. Kammeradvokaten har til det formål fastsat en række regler for systemet.

Arkitekturen benytter på flere punkter på Apache Camel, som er et open source kø- og besked-system. Nu tager det 22 minutter at provisionere et nyt miljø med alle applikationer kørende, hvor processen før i tiden tog dagevis.

15 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
15
11. oktober 2019 kl. 07:18

I min bog er det offentligt ombud, så det bør være dygtige folk fra både private og offentlige organisationer, som sammen finder de bedste løsninger.

Det er bare lidt svært at finde dygtige folk i det offentlige, når lønningerne ligger 20-30.000 kr under den private sektor, og det offentlige skal spare 2% om året...

“If you pay peanuts..” som de siger.

14
31. oktober 2018 kl. 17:07

Jeg tror man skal se i retning af de dyre, dyre, dyre konsulenter fra de store konsulenthuse. Jeg ved af erfaring, at dyre offentlig ansatte på de rigtige stole, ville være bedre end de dyre, dyre, dyre indlejede konsulenter.

13
31. oktober 2018 kl. 13:48

?? Måske ??

Jeg har ikke fingrene i klemme mht NetCompany men har den dybeste respekt for det arbejde jeg har set dem udføre - så den del er i så trygge hænder det nu kan være. Arkitektur, teknik, etc. skal NetC få styr på, med mindre nogen ansatte i SKAT insisterer på noget andet. Dette er forhåbentligt afklaret i samarbejdsaftalen.

Selve skattesystemet, modregninger, lovgivningen, etc etc er og forbliver noget skod som et resultat af mange års vaklen frem og tilbage og små og store justeringer og politiske forlig - og den del er givetvis ikke en døjt bedre end det har været hidtil.

Så projektet skal navigere i rørt vande, stadig, og med masser af rimelig og urimelig bevågenhed.... og lur mig om ikke de gode ting der kommer ikke bliver lige så omtalt som de knapt så gode?

12
30. oktober 2018 kl. 23:26

Lidt relateret til ovennævnte har nogle af jer muligvis hørt om E&E: https://www.kombit.dk/nyheder/f%C3%A6rdig-ejendomsskatte-l%C3%B8sning-overtages-af-kombitSystemet som foretager vores allesammens ejendomsskatteberening, altså grundskylden.

Det oprindelige system var fra omkring 1965 og var sikker lavet på hulkort og (20 år?) senere konverteret til et højniveau sprog. Det gamle system blev konkurrenceudsat af Kombit, ikke kun fordi det blev holdt sammen med gaffatape, men også fordi det tog en månedstid at regne skattebilletten for alle kommuner og dertil kostede (vistnok) i omegnen af 150 mio. kr. at trykke på knappen – og det skulle gøres to gange om året. Drift og vedligehold oveni.

Så Det gamle system (fra Datacentralen?) skulle skrives om af CSC, nu DXC, tidligere Datacentralen, for et stort beløb, men dog ikke mere, end det kunne tjene sig ind på et par år. De grinede sikkert hele vejen hen til banken.

Projektet blev forsinket, og kom til at koste mere (spørg Kombit om detaljerne), men det kom dog i mål. Det hjalp nok ikke, at parterne brugte to år på at forsøge at detailspecificere en datamodel uden at skrive kode, mens en kæmpe projektorganisation sad på deres hænder. Først da en ekstern vred arkitekt dikterede ”del og hersk” via en microservice-arkitektur og projektet samtidig gik fra vandfald til agil udvikling, kom der skub i det, så 70 personer kunne fokusere på konkrete, løbende leverancer fremfor daglig frustration.

Nu koster det småpenge at trykke på knappen og tager 5 timer for alle boliger i alle kommuner. Det kunne sikkert gøres hurtigere, men det er i realiteten ligegyldigt.

Så moralen er, at vi bliver nødt til at tage fat i den grød, som politikerne har gået uden om de sidste 20 år, så vi ikke skal bruge alle skattekronerne på MIPS. Monopolerne tjener stadig mange milliarder hvert år på noget gammelt skidt fra da farfar var ung, hvor (en stor del af) pengene i stedet kunne have været brugt på sundhed, skoler, børnehaver etc.

Det er nok mindre vigtigt om det bliver den ene eller anden (moderne) arkitektur, så længe monolitterne bliver brudt ned i nogle afgrænsede komponenter eller services. Men leverancemodellen må og skal være agil for komme i mål. Man kan med al respekt ikke definere alle opgaver som alle deltagere skal løse med acceptkriterier på forhånd for et projekt på 400 mandeår, uanset hvor dygtig en jurist man er. Elefanten skal spises i bidder.

I min bog er det offentligt ombud, så det bør være dygtige folk fra både private og offentlige organisationer, som sammen finder de bedste løsninger.

Til gengæld bliver man nødt til at sætte penge af til at holde systemerne i live, så de ikke sygner hen (igen igen).

11
30. oktober 2018 kl. 16:56

Det meget spændende spørgsmål er hvordan et sådant fornuftigt project er kommet igennem et EU-udbud - uden at have form af en traditionel vandfaldmodel. Hvis Skat.dk kunne få en fornuftig projektmodel gennem et EU udbud - så kan andre vel også?

10
30. oktober 2018 kl. 15:02

Jeg tror vi skal kigge i retningen af EU udbuds processen for at finde den store synder.

9
30. oktober 2018 kl. 13:40

Ikke selve systemet.

har en opgave med at lave integration til et af de nye systemer:

https://info.fordringshaverportal.skat.dk/

(det er ihvertfald også oracle psrm produktet...)

Fin hjemmeside, hvor siderne bliver opdateret hver 1-2 måned så alt ser relativt nyt ud... men ikke er det.

7
30. oktober 2018 kl. 12:12

Jeg håber virkelig at lykkedes at få ryddet op efter den omgang som skattevæsenet er blevet udsat for - vores lands fremtid afhænger af det.

Trenden er negativ for de holdninger som driver "udviklingen" har ikke ändret sig:

Hvis man er den type person som mener at "alt offentligt er dyrt, dumt, udueligt og skadeligt" og man mener at det er meget vigtigere altid at have ret i sine religiöst funderede politiske / ökonomiske påstande end det er at löse problemerne som de er ...

Så "vinder" man ved at fortsätte med grönthöster-besparelser, lov-sjusk og ikke-reformer. Man "vinder mere" ved at klatte noget software oveni et uforståeligt lovgrundlag, uforståeligt fordi alle eksperter i forvejen er sparet väk.

Man er sikker i håbet om at når skandalen omsider igen ruller så er der et "bredt politisk flertal" fedtet ind i den, så det"brede politiske flertal" er helt enige om at den seneste fiasko heller ikke denne gang skal have nogen konsekvenser - ud over en undersögelseskommission som alle naturligvis ignorerer.

I 2019 kommer ejendomskatten. Vil det fungere? Näppe!

6
30. oktober 2018 kl. 11:46

en løbende agil proces

... kan ikke erstatte overblik, omtanke og planlægning. De første par leverancer bliver nemme nok, men så bliver det også spændende.

Jeg håber virkelig at lykkedes at få ryddet op efter den omgang som skattevæsenet er blevet udsat for - vores lands fremtid afhænger af det.

5
30. oktober 2018 kl. 11:32

Det svære er at ende med et sæt af krav der giver mening, at omsætte disse krav til fornuftig forretningslogik, at få teste systemet ordentligt, etc. At lave alle de tradeoffs som er nødvendige. Alle de ting som er specifikke for Skat.

Ja det er jo netop altid et problem, når det hele skal beskrives og udliciteres på en gang. Ofte skrives kravspec af folk der mere kyndige i jura end i udvikling af brugbar IT og reel indsigt i arbejdsgange.

Det som kunne lyde lovende her, er at det er en løbende agil proces og at SKAT selv er med i udviklingen. Det forudsætter netop at kravene kan justeres hen ad vejen. Jeg ved ikke hvilke positioner SKATs medarbejdere har i dette projekt. Men man kan da håbe på at det er i positioner, hvor forretningsviden tilflyder projektet og IT projekt erfaring tilflyder SKAT. (Politisk indblanding har tidligere, nærmest haft den modsatte effekt)

3
30. oktober 2018 kl. 10:19

Mange af disse tiltag lyder jo helt fornuftige - Det kunne jo gå hen og blive en positiv historie!

Det svære er ikke valg af teknologi - der er millioner af IT folk på kloden der kan hjælpe med det. Det svære er at ende med et sæt af krav der giver mening, at omsætte disse krav til fornuftig forretningslogik, at få teste systemet ordentligt, etc. At lave alle de tradeoffs som er nødvendige. Alle de ting som er specifikke for Skat.

Specielt hvis det er SKATs egne medarbejdere, der opsamler erfaringer og har godt fat i styringen af projekterne.

Sandsynligvis vil meget få af dem der deltager i projektet fra Skats side, nogensinde deltage i et projekt af samme størrelse igen. Og sandsynligvis har meget få deltaget i projekter af samme størrelse tidligere - bortset fra EFI. Det er en del af asymmetrien mellem kunde og leverandør i IT projekter.

2
30. oktober 2018 kl. 09:55

Mange af disse tiltag lyder jo helt fornuftige - Det kunne jo gå hen og blive en positiv historie! Specielt hvis det er SKATs egne medarbejdere, der opsamler erfaringer og har godt fat i styringen af projekterne.

Det bliver interessant at følge

1
30. oktober 2018 kl. 09:54

Så fristes man til at overveje, om det er lovgivningen frem for implementeringen, der er noget galt med.