Open source-løsning skal spare kommuner for CPR-opslag hos KMD

6. maj 2011 kl. 15:1430
It-udfordringen: En ny, gratis løsning skal gøre det nemmere for kommuner at spare på opslag hos leverandører som KMD. Men konceptet med open source krævede lidt forklaring.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Hvorfor lade mange forskellige it-systemer hente samme oplysninger flere gange, fra forskellige eksterne datakilder, og betale for det hver gang, når man kan samle alle opslag og spare penge?

Det er kort sagt ideen bag den såkaldte CPR Broker, som skal hjælpe kommunerne med at få styr på alle de mange opslag, de kommunale it-systemer hver dag har i registre hos CPR-kontoret, KMD og andre datakilder om borgerne.

Ved at sætte en ekstra database ind mellem kommunernes it-systemer og de eksterne registre, kan man få samlet alle data ét sted, så nogle opslag bliver overflødige og kan klares internt.

Her fortæller Leif Lodahl fra Magenta om projektet, som blev udført for Gentofte Kommune og IT- og Telestyrelsen.

Artiklen fortsætter efter annoncen

Hvad går projektet ud på?

»Kommuner har en hel masse systemer, som henter persondata fra en række forskellige kilder. Vi har identificeret mindst 18 it-systemer hos kommunerne, som henter data med CPR-nummer som nøgle, og hvert af systemerne har en proprietær integration med datakilden. Nogle bruger også flere datakilder samtidigt.

Vi skubber CPR Broker ind imellem datakilderne og it-systemerne, så kommunerne kan få et overblik over, hvilke datakilder de bruger til persondata. Samtidigt bliver alle data så stillet til rådighed på en standardiseret måde, efter IT- og Telestyrelsens standard PART.

De rå persondata kommer fra CPR-kontoret, men så beriger leverandørerne dem med ekstra information, så det passer til deres systemer. Og kommunerne betaler for alle disse opslag.

Først udviklede vi løsningen til Gentofte Kommune, og i version 2 har vi i samarbejde med IT- og Telestyrelsen opgraderet CPR Broker til at følge den nye standard på området, PART, som ikke var klar, da vi udviklede version 1. Nu bliver CPR Broker også testet i Ballerup og Odense.«

Hvad er målet med projektet?

»Ved at samle og flette alle de data, som kommunerne henter, beriger vi dem. Det kunne man ikke før. Det var kun i hvert enkelt it-system, man samlede data, og det sker proprietært.

CPR Broker giver også mere konsistente datakilder, fordi det hele bliver samlet. Der er forskellig opdateringsfrekvens på de forskellige datakilder, og derfor kan man ikke helt stole på, at de er opdaterede, når man får dem enkeltvis.

Mange oplysninger er også de samme, så med tiden kan kommunerne spare penge ved at reducere antallet af datakilder, man skal abonnere på.«

Hvilken teknologi indgår i projektet?

»Vi bruger en Microsoft SQL-database og .Net-programmering. Det ligger på en Microsoft IIS-server. Det var et pragmatisk valg, da Gentofte Kommune, som i første omgang drev projektet, kun bruger Microsoft-servere og ikke har Linux-servere. Og mange kommuner har på samme kun Microsoft-servere i kælderen.

Men vi er i øjeblikket i gang med at gøre det muligt at bruge MySQL eller en anden generisk database, så man selv kan bestemme. Vi forventer, at vi kan gøre det helt uafhængigt, så man ikke er tvunget til at have software fra en bestemt leverandør.«

Hvad var tidsplanen for projektet?

»Vi udviklede version 1 tilbage i 2009, hvor vi var to programmører på opgaven i tre måneder. Dengang var der jo ingen standard for de data, så vi opfandt bare selv et interface.

Så kom PART-standarden for persondata i 2010, og IT- og Telestyrelsen spurgte, om vi ville implementere den i CPR Broker. Det gjorde vi med med version 2, som var klar i februar 2011. Her var vi også to programmører på, siden november, men fik også assistance fra IT- og Telestyrelsen.«

Hvilke udfordringer stødte I på undervejs?

»Rent teknisk er OIOXML-skemaerne ret voldsomme og meget komplekse. Vi vidste, at der var meget høje kvalitetskrav, og at vi måtte være ekstremt præcise i vores implementering af standarderne. Vi udviklede CPR Brokeren parallelt med, at standarden var i høring, så der kom kommentarer og mindre ændringer undervejs. Men det var et vilkår, der var.

Ellers har udfordringen mest været at forklare konceptet ude hos kommunerne. Det er en applikation uden brugergrænseflade, så vi kunne ikke fremvise skærmbilleder. Den udveksler data mellem to andre applikationer, og det er svært at forklare.

Det var også svært at forklare business casen for at lave det som et open source-projekt. Vi ejer ikke koden, og kommuner kan downloade den gratis og installere den. Men det betød, at vi skulle skaffe sponsorer, og der har vi skullet forklare vigtigheden af, at leverandøren ikke ejer koden.

Hvis KMD eller CSC havde lavet den, skulle kommunerne betale et løbende abonnement, når produktet var klar, men her skulle sponsorerne have penge op af lommen på et tidligt tidspunkt, ligesom hvis man køber et hus som et projekt, der ikke er bygget endnu. Den forretningsmodel er forholdsvis ny for kommunerne.

Til gengæld ejer KMD eller CSC ikke koden, og kommunerne kan selv bestemme, hvad der skal ske fremover, og hvem der skal udvikle næste version. Det kan godt være nogle andre end os.«

Hvilke gode råd kan du give videre?

»I sådan et projekt som dette, der er så standardspecifikt, er det vigtigt at få IT- og Telestyrelsen med. Det har været så skønt at have deres arkitekter med, for de har en grundviden, som har sparet os for rigtig meget arbejde.

For open source-modellen gælder det om, at man skal have et community på plads, og man skal aftale hele modellen. Hvem har ansvaret for CPR Broker? Hvem bestemmer hvilke features, der skal med i den næste version? Og hvilken teknologi skal der bruges? Løsningen kan være at stifte en forening for CPR Broker med en bestyrelse, der så bestemmer over udviklingen.

Vi har fået mange gode råd fra IT- og Telestyrelsen om, hvordan man gør det levedygtigt. Der er flere open source-projekter i Danmark, der ikke når længere end version 1.0, fordi man glemmer at sikre sig, at der også i fremtiden er en governance-model for projektet. Man skal sikre sig et community, der forpligter.«

30 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
1
6. maj 2011 kl. 18:07

Som jeg læser artiklen,virker brokeren som en slags proxy,der minimerer opslag i de eksterne databaser.For at det skal kunne spare opslag,må brokeren nødvendigvis gemme data fra disse databaser lokalt. et begynder at minde om registersamkøring,så man kan undre sig over om det er i tråd med gældende lovgivning?

3
8. maj 2011 kl. 04:24

ja og lagring (mængde i periode) kan nok ikke afvises, da de nævnte baser jo er egnet til det formål.

Det der er mere mærkværdigt synes jeg er, at nogen kan finde på at reklamerer åbenlyst med ny angrebsflade på vores CPR, samt at anvende Windows IIS-server.

Vores CPR + tilknyttede data er efterhånden ikke særligt følsomme.. trist at naivitet bliver en generel holdning.

@Morten Du forsimpler brugen af CPR-register, dine antagelser og beregninger holder ikke mere end de første 10-15 sekunder i byretten :)

CPR har en mere kompleks opbygning + anvendelse, end du overhovedet kan forestille dig (udefra).

4
8. maj 2011 kl. 19:58

Hej Finn - du kunne måske komme med et eksempel på noget af det komplekse? Bare en enkelt use-case.

5
9. maj 2011 kl. 04:06

Jeg opfatter, at du fortrinsvis tænker CPR som et online-register Morten, der servicerer forespørgsler udefra, men CPR anvendes også ifm. interne produktioner..

Prøv at lave en liste over alle du mener anvender/trækker på CPR-data - intern/ekstern Opdel dem i krav til tidstro eller batch Opdel dem i krav til at benytte subsæt af data .... ....

6
9. maj 2011 kl. 13:14

Nu skal man måske lige passe på at opdele et system i hvad der er egentlige krav til det, og hvad der er gået hen og blevet dets udformning fordi det er udviklet over en lang periode ("accidental complexity", om man vil).

CPR systemet var helt sikkert en bemærkelsesmæssig teknisk, politisk og organisatorisk bedrift da det blev stablet på benene i 1968, hvor et helt lands personstamdata blev gjort tilgængelig og der blev etableret integration på kryds og tværs. Men i år 2011 er datamængden ikke skræmmende, og det er kompleksiteten sådan set heller ikke -- redskaberne til at opbygge systemer, der kan håndtere begge områder er usammenligneligt meget bedre i dag.

Uha, ja, der er måske 15-20 entiteter i systemet -- man skal foruden personer og adresser jo lige huske værgemål, familierelationer, forældremyndighed, civilstand, og lad os bare tage distrikter, myndigheder og vejregisteret med selvom det helt afgjort er "accidental complexity" (disse data findes autoritativt andetstads og giver integrationsbøvl med inkonsistente data). Datamodellen skal have selvfølgelig have register- og virkelighedshistorik, inkl. sporbarhed på hver enkelt ændring, og til dels også søgning (iht. Persondataloven).

På servicesiden er der både ajourføring og opslag (herunder eksterne), registerindsigt (den borgerrettede side), diverse "semantiske" system-til-system integrationer, f.eks. personstatusændring (f.eks. fødsel og død) og endelig abonnementsordning/dataeksport til administrativt og statistisk brug.

Ikke trivielt, men det er ikke rocket science.

Dér hvor det bliver grimt er nok snarere at alle nuværende krav og integrationspunkter som er opsamlet over så lang tid over i et nyt system, hvis altså alle snitflader skal bibeholdes, og der ikke kan ryddes op i f.eks. knopskudte forretningsregler, som kunne formuleres mere tydeligt ved et redesign, ja, så er det helt sikkert en ordentlig mundfuld...

Man kan læse en masse om CPR systemet, inklusiv de hjemmestrikkede kommunikationsprotokoller, dataformater, m.v., på http://cpr.dk

7
9. maj 2011 kl. 14:14

Ikke trivielt, men det <em>er</em> ikke rocket science.

Du nævner ikke noget som er ikke-trivielt. Med mindre de nedre dele af dit indlæg skal tillægges (hjemmebixede protokoller mm.).

8
9. maj 2011 kl. 14:30

YMMV, men det er trods alt ikke uden udfordringer, hvis det skal blive godt. Det er i min erfaring aldrig hverdagsagtigt eller banalt at få f.eks. en brugergrænseflade med både virksomhedshistorik og registerhistorik til at virke overskuelig for brugeren. Men jeg er selvfølgelig begrænset af egne evner.

9
9. maj 2011 kl. 22:52

Jeg tror ikke vi er så uenige. Min første pointe er/var, at det er urimeligt at tage så store beløb for opslag i et så simpelt register (som det må være tilfældet når det ligefrem kan betale sig at lave nye systemer for at nedbringe antal opslag!). Den kompleksitet der ligger i at håndtere en Google søgning er størrelsesordener større end hvad CPR-systemet tilbyder, og er endda ganske gratis (pånær man skal se på en reklame, men det er ikke mange basseører Google får for det).

Mht. implementeringen af et komplet system er der selvfølgelig noget mere i det (og jeg siger ikke dette kan/skal gøres for 100.000), men som Nikolaj er inde på, skal man heller ikke overdrive hvor meget det er. CPR-systemet er ikke mere kompliceret end systemer som mange har implementeret i deres fritid 'for sjov', og til hobbybrug osv. Der er selvfølgelig nogle specielle krav ang. logning/sporbarhed/registrering osv. men disse ting er også trivielle sammenlignet med så meget andet. Og ofte har jeg endda gennem mine mange år set megen sjusk og "hurtige løsninger" netop på de punkter, selv i de 'dyre' systemer.

Sandheden er (og lad det blive mellem os, Version2-læserne!), at langt de fleste ting jo er lette at implementere... men at dette ingen hindring er for at det kan koste 3-cifrede millionbeløb, især i offentlige projekter. Problemet er, at de eneste der har en interesse i at holde prisen nede er skatteborgerne, og de har næsten ingen indflydelse. Politikerne tør sjældent blande sig, for hvis de sparer og lortet ikke virker, så vil de få skylden. Desuden aner de ikke et klap om hvad systemer skal koste. Leverandører, konsulentfirmaer, projektledere, usability eksperter, tester, programmører m.m. har en stor interesse i at blæse det hele en størrelsesorden eller to op... både hvad angår krav, specifikationer, implementering osv. Så snart de ser et stort opslået offentligt system, så er det med at hæfte sig på, og suge så længe man kan.

Al den megen tilsyneladende 'grundighed' fører kun til et dårligere og dyrere system, som med garanti bliver forsinket, hvis det overhovedet kommer. Og i så fald vil det med usvigelighed sikkerhed, på trods af den megen "grundighed" og fine udviklingsmetodikker, være ustabilt og have masser af mangler. Alt det megen "udenoms" fjerner fokus fra at implementere kernefunktionaliteten, som sikkert var ganske triviel.

Men hvor er det godt for IT-folkene - hvad skulle de dog lave hvis systemerne blev lavet effektivt?!

12
10. maj 2011 kl. 07:36

Hej Morten,

Sandheden er (og lad det blive mellem os, Version2-læserne!), at langt de fleste ting jo er lette at implementere

Jeg var engang på et IT-projekt her i hovedstaden, er nok den dag i dag er den største skandale, der har været. På et tidspunkt var vi nok 100 personer på opgaven fra både indland og udland incl. organisationens egen medarbejdere.

På det tidspunkt snakkede min kone med en kollega, der var IT-supporter i deres organisation. Han konstaterede overfor hende over frokostbordet, at "det kan sgu da ikke være så svært. Jeg er sikker på, at hvis jeg og 5-6 af mine venner fik mulighed for det, så kunne vi lave systemet på tre måneder".

Med andre ord: dine ytringer er det mest uigennemtænkte jeg længe har hørt. Jeg læste selv udbuddet igennem fra ITST med henblik på et muligt bud på opgaven, men af forskellige årsager vurderede vi ikke, at det var noget for os. Men mit indtryk dengang var helt klart, at den udbudte pris for CPRBroker bestemt ikke var himmelhøj - snarere tværtimod. Alene "PART"-implementeringen var en udfordring - som Leif kommer ind på, så var den ikke færdiggjort da opgaven røg i udbud.

Du skriver, at det er absurd, at det kan betale sig med sådan en løsning - men er du overhovedet klar over, hvad CPRBroker kostede?

Find udbuddet frem og kom igen, når du har læst og forstået opgaven.

14
10. maj 2011 kl. 08:40

Hej Jesper,

Jeg var engang på et IT-projekt her i hovedstaden, er nok den dag i dag er den største skandale, der har været.

Hvis vi snakker største skandale, er der jo rigtigt mange andre grunde til at dette gik i vasken (bla. OS/2 som platform mm.).

De rigtigt store projekter der bliver til skandaler (og jeg har været involveret i en del opretninger af sådan nogle), sker af mange årsager. Men fælles for dem er (som jeg ser det):

  • Overallokering af medarbejdere (det skal godtgøres at det er så dyrt).
  • Vild overallokering af ledelse.
  • Ledelse der ikke arbejder i samme retning (flere leverandører på det samme projekt går oftest helt i hegnet).
  • Kompetencemangel (diverse SI'er hælder bare folk ud af skuffen ind i projektet).
  • Mangel på folk med erfaring ud i at realisere systemer (både ledelsesmæssigt og udviklingsmæssigt).
  • Kommunikationsvanskeligheder.

Ovenstående har ikke noget med teknikken bag ved at gøre, for selv de mest såre simple systemer kan bringes i knæ, når først der går over-management og inkompentece, samt bureaukrati i den.

jeg acceptere at det er et hårdt slag for nogen der har arbejdet r.... ud af bukserne og ikke lykkedes, når nogen så siger at de med 5-6 mand kan løse opgaven på utrolig kort tid. Men nogen gange er det sandheden. mindre teams arbejde ofte meget mere effektivt, specielt hvis deres kompetencesæt komplimenterer hinanden.

Det er ikke så forkert hvad Morten siger, selvom jeg læser det som værende ret langt ude på skalaen (måske for at få luft for frustrationer, måske for at understrege pointen).

...dine ytringer er det mest uigennemtænkte jeg længe har hørt.

Det tror jeg ikke på. Jeg tror simpelthen ikke at Mortens ytringer er det mest uigennemtænkte du længe har hørt :-)

13
10. maj 2011 kl. 08:28

Jesper,

Jeg var engang på et IT-projekt her i hovedstaden, er nok den dag i dag er den største skandale, der har været. På et tidspunkt var vi nok 100 personer på opgaven fra både indland og udland incl. organisationens egen medarbejdere.</p>
<p>På det tidspunkt snakkede min kone med en kollega, der var IT-supporter i deres organisation. Han konstaterede overfor hende over frokostbordet, at "det kan sgu da ikke være så svært. Jeg er sikker på, at hvis jeg og 5-6 af mine venner fik mulighed for det, så kunne vi lave systemet på tre måneder".</p>
<p>Med andre ord: dine ytringer er det mest uigennemtænkte jeg længe har hørt.

Jeg forstår ikke dit argument? Du har ikke godtgjort, at IT-supporten ikke kunne have ret. Tværtimod har du indrømmet at projektet endte i en kæmpeskandale, på trods af de >100 medarbejdere -- så den model var åbenbart heller ikke svaret? Men du mener måske det er åbenlyst, at når 100+ eksperter ikke kunne løse det, så kan 5-6 venner absolut heller ikke? For mig er dette bestemt ikke en åbenlys slutning.

Og hvis du læser mine indlæg igen, vil du se at jeg ikke kritisere prisen på CPR broker, som jeg ikke ved hvad har kostet. Jeg kritiserer, at det alm. CPR er så dyrt, at kommunerne skal bruge tid og penge på at udvikle og installere et system som CPR broker (som hver kommune iøvrigt selv skal sætte op). CPR burde være enten flat rate for det offentlige, som i forvejen har bekostet enorme summer herpå, eller også burde det koste mindre end en Google-søgning.

17
10. maj 2011 kl. 08:58

Hej Morten,

Du har ikke godtgjort, at IT-supporten ikke kunne have ret. Tværtimod har du indrømmet at projektet endte i en kæmpeskandale, på trods af de >100 medarbejdere -- så den model var åbenbart heller ikke svaret? Men du mener måske det er åbenlyst, at når 100+ eksperter ikke kunne løse det, så kan 5-6 venner absolut heller ikke? For mig er dette bestemt ikke en åbenlys slutning.

Det er for mig en åbenlys konklusion, at man skal afholde sig fra at udtale sig kategorisk om noget, hvis man ikke kender en sag nok/indefra.

Hej Nikolaj,

Hvis vi snakker største skandale, er der jo rigtigt mange andre grunde til at dette gik i vasken (bla. OS/2 som platform mm.).

Vi taler nok om forskellige projekter. Nøgletal for mit:

55000 arbejdere i organisationen (40% fuldtid, tjenstemænd) 200 overenskomster 1800 underoverenskomster Ny backend Ny frontend Nye organisationsprocesser Forandringsledelse Nye ansvarsområder Central -> decentral styring

Det drejer sig ikke om, at jeg føler min ære trådt under fode af hans kommentar - den er så langt ude, at den mister al værdi. Men kommentaren er karakterisk for debatter også herinde - man tager en sag, river én sætning ud af den og konkluderer på baggrund af denne ene sætning.

Der er nøjagtig lige så meget kød på Mortens kommentar som kommentarer som "Jeg bruger MacOSX og er glad for det, så jeg ville ønske at politikerne havde nosser nok til at kræve, at hele staten og alle kommuner gik over til MacOSX.

Det tror jeg ikke på. Jeg tror simpelthen ikke at Mortens ytringer er det mest uigennemtænkte du længe har hørt :-)

Du har ret :o)

10
9. maj 2011 kl. 23:10

mig i de har krisetider :)

11
9. maj 2011 kl. 23:42

Hej Morten,

Der er et ord for det du beskriver: Agile softwareudvikling. Med mantraer som The Simplest Thing That Can Possibly Work og YAGNI (You Ain't Gonna Need It). Eller mere almindeligt KISS.

Det er sjældent at disse bliver brugt i moderne IT systemimplementering. At diverse store leverandører af teknologi samtidigt får solgt kunderne en hær af ubrugbare produkter som de bare skal have (og som ikke fungere sammen, så en hel anden hær af konsulenter får fast arbejde med at forsøge at integrere dem), hjælper ikke på pris og situation.

Det ville være rart om der snart kunne komme andre boller på suppen. Til gengæld kender jeg nogle enkelte kunder som har set værdien i at starte med kernefunktionalitet, og ikke er bange for ikke at benytte vandfaldsmodeller mm.

2
6. maj 2011 kl. 22:20

Det er absurd at kommunerne betaler så store summer til CSC/KMD, at det kan betale sig med en sådan løsning. Et opslag i et CPR-register er IKKE rocket science og kræver ikke et enormt maskineri.

Tænk på hvor simpelt CPR-registret er. Alle kan gå ind og se deres personlige oplysninger. Jeg vil tro der er ca. 5 kilobyte oplysninger i gennemsnit, når man medtager adresseændringer osv. som sikkert er relativt sjældent forespurgte oplysninger. Kerne oplysningerne er under 1 K. Men lad os bare sige 5K. Med 6 millioner borgere bliver det altså 30 GB. Disse kan med lethed ligge i RAM på en ganske billig maskine - en commodity maskine med 4 kerne og den mængde RAM kan vel erhverves for en 10.000. Maskinen udstyres med noget så simpelt som en hashtabel* og vil kunne håndtere et enormt antal forespørgsler, da alt kører via RAM og med meget simple algoritmer. Det er ikke maskinen men højst netværket der er problemet. Men ikke desto mindre er jeg overbevist om at 4-5 af den slags maskiner kan klare hele landets behov, og der vil sikkert endda være stor overkapacitet. Et sådant system (inkl. opdatering af oplysninger, backup m.m.) vil inkl. lønninger til 2 personer (som får en del fritid) drives for 1,1 mio. kr. om året, en brøkdel af hvad KMG og CSC tjener - det dækker ikke engang blot en enkelt projektleder eller tilbudsarbejdet. Sørgeligt er det, men økonomisk tænkning har aldrig været det offentliges stærke side.

Jeg har ikke regnet på en cloud løsning (via f.eks. Amazon's cloud) men der er tilgengæld privacy problemer at tænke på.

  • Hvis man er rigtig smart, så udnytter man det virtuelle adresserum således at man kan bruge dette som en slag hashtabel - man omdanner simpelthen CPR-nummeret til adresse på hukommelsessiden/rne der indeholder oplysningerne. Opslagstiden er derved reduceret til en transaktion på hukommelsesbussen, d.s. nogle ns.