Peter Nørregaard

Eksperterne er enige: Ny fransk afgørelse klemmer livet ud af Analytics i Danmark

"Må offentlige websites bruge Google Analytics?", spurgte jeg før GDPR i 2011. Svaret dengang var, mente jeg, nej. Det lader til at svaret stadigt er nej, men nu også for alle andre EU-baserede hjemmesider.

16. februar kl. 14:33
Skal De også have en SAFe? Fortidens skygger truer

Torben, er det etproblem med metoden eller med implementeringen, i din optik? Det kunne være spændende at høre om

31. januar kl. 15:30
Skyen ændrer it-arkitektens rolle: »Hvis man ikke har fulgt med i ti år, så har man et stort problem«

Meget enig. Hvis man er interesseret i at læse mere om de to ben, John taler om, så læs om operational backbone og digital platform i Designed for Digital (bl.a. af Jeanne Ross, MIT)

6. januar kl. 22:54
Microsoft dropper blockchain-tjeneste i egen sky

Gartner blev for nogle år siden citeret for at de "ikke har set et blockchain-projekt som kunne gøres bedre uden block-chain".

Efter min vurdering det stadigt: https://www.version2.dk/blog/hvem-finder-blockchains-missing-link-1077677

3. juni 2021 kl. 17:31
Offentlige midler, offentlig kode!

Som Lise Gerd skrev i sin afskeds-blog er statens behov tit ret unikke.

Der er lang vej fra Henriks gode eksempler på vellykket open source et stykke nede i stakken og til at kunne opfylde behovet for tæt it-understøttelse i det offentlige.

Man kan sige meget rigtigt om det overdrevne i "vi-er-åh-så-unikke" effekten, men se lige på statens opgaver og så på, om der findes mange organisationer som løser lige akkurat de opgaver under de samme regler og omstændigheder. Der er ikke så mange.

Et open source ejendomsvurderingssystem vil ikke være særligt nyttigt. For statens fagsystemer taler situationen derfor ikke åbenlyst til fordel for open source. Selvfølgelig kan der indgå open source komponenter i sådan et, men det er en anden sag.

Men det er nok heller ikke nødvendigt med en open scource model her, mindre kan gøre det.

Det ville være nyttigt, hvis ingen leverandør kunne bruge systemet som malkeko. Og det ville være nyttigt ikke at skulle i genudbud med systemet hvert 4-8 år. Begge dele kunne opnås uden open source, men ved at indkøber fik de nødvendige rettigheder til at kunne få videre-udviklet koden hos hvem, de ville.

14. maj 2021 kl. 15:35
Hvad skal staten stille op med sine gamle IT-systemer?

Principielt er jeg enig, Mads.

I praksis kan det være en anden sag:

  • Fx når der sker et paradigmeskift. En proceduralt sprog (fx COBOL) konverteret til et objektorienteret sprog (fx Java) bliver aldrig godt.
  • Også når forretningsdomænet flytter sig (gradvist eller i større ryk) og dermed skurrer mod løsningsdomænet og dets implementering, vil vedligehold ikke være nok.

Er der også andre tilfælde, jeg ikke har fået øje på?

12. maj 2021 kl. 10:58
Hvad skal staten stille op med sine gamle IT-systemer?

Gode pointer, Lise.

Kravene til systemerne har uafladeligt udviklet sig i 20-30 år. Ingen ændringer er lavet for sjov, alle har et ophæng i nye regler som alle vil have påvirket menneskeskæbner (og måske gør det stadigt) hvis de blev saneret. Kan vi håbe på mere simple forretningskrav fremadrettet? Ikke uden at klippe en hæl og hugge en tå og det er nok svært at se (eller at ønske) ske.

Gamle systemer bliver tynget af teknisk gæld, både fordi de er gamle, men også fordi udviklerne har glemt hvad de tidligere (selv eller andre) har tænkt eller vidst, da de skrev koden. Værktøjsunderstøttelsen er sikkert heller ikke fulgt med tiden. Over tid sander systemerne til.

Som en it-chef i et ministerium sagde til mig engang: "Vi har gået og omhyggeligt spændt snubletråde ud over de sidste 10 år - dem bruger vi nu tiden på at falde over"

Men der er også meget godt:

  • Indkøbte standard-systemer er lykkes på flere områder, fx inden for ESDH og økonomi. Forestil jer hvis hvert fagsystem skulle styre sagsgange, dokumenter, debit og kredit.
  • De fælles registre har også været en god hjælp. Forestil jer det offentliges it-situation uden fx registre for CPR, CVR eller BPR.
  • Staten har også løftet godt mht fællesoffentlige løsninger. Igen, forestil jer statens it-situation UDEN NemID, digital post, NemKonto osv. ov.
  • FDA har løftet meget og vil også fremover løfte kvaliteten.

Vejen frem? Der er ingen nemme løsninger.

Jeg tror ikke vi kommer uden om flere men mindre løsninger med gode afgrænsninger / bounded context, hvor vi hiver funktionalitet ud af de gamle kasser lidt efter lidt.

Der er heller ikke nogen vej uden om i fremtiden at højne arkitekt- og udvikler-håndværket, den gode faglighed, den gode kode, udviklet efter solide principper med god værktøjsunderstøttelse.

Og der er helle ikke nogen vej uden om at være bedre til at opdele designet, så standard-opgaver løftes af solide, gennemtestede og stabile standardprodukter med lang levetid, og at vi så fokuserer udviklingen på resten.

11. maj 2021 kl. 17:08
Tak for samarbejdet

How, sorry, Lise, jeg lægger lige denne over på dit forrige indlæg. God pension og tak for indsatsen herinde

Mvh Peter

11. maj 2021 kl. 17:06
Sådan flyttede BBC sit website til serverless

Med serverless forholder man sig ikke til hvilken server, funktionen skal deployes på. Så lige som at cloud er på "somebody elses computer" er serverless vel bare på "a server somewhere, I don't care"

18. februar 2021 kl. 15:53
Er vi på vej mod en "EU-cloud"?

... det var bare hvad jeg ville sige

27. november 2020 kl. 11:18
Mandagsgnavpotten vil omkalfatre det danske sprog

... men det er stadigt samme skib på alle måder, bare mere tæt. Vi ville ikke kunne se forskel på før-og-efter billederne.

12. oktober 2020 kl. 23:42
Mandagsgnavpotten vil omkalfatre det danske sprog

He, gode kommentarer (og tak for bajmanden, sorry, begmanden). Det er rettet, kursen er lagt om.

Kom i øvrigt i tanke om den gamle børnesang hvor nogen var sort i hovedet som en tjærespand. Tror ikke nogen børn har set en tjærespand mere, så analogien er agterudsejlet.

12. oktober 2020 kl. 22:31
Trods international løsning: Danmark holder fast i national corona-app

Problemet er (som altid) at få brugerne til at skifter over til en ny app. Det er svært nok at få dem til at downloade en smitte-stop app i det hele taget.

25. september 2020 kl. 10:08
Usmarte elmålere

Ok, nu fandt jeg “ alle danske elmålere via det optiske øje skal svare på IEC1107 med aktuel spænding, strøm med fortegn og effekt med fortegn samlet og for hver fase for sig, samt akkumleret kWh ind og ud og frekvensen, i alt 15 variabler.”, sorry.

31. august 2020 kl. 09:03
Usmarte elmålere

Læs sidste del af blogindlægget ?

Jeg læser at forsyningsselskaberne skal stille krav jf en lov som ikke blev skrevet. Og en kravspecifikation med krav om at holde det simpelt giver nok ikke gode tilbud.

Så helt konkret, har nogen herinde bud på hvordan det gøres bedre? Vil Open Metering System være nyttig og kan man holde leverandørerne op mod sådan et krav?

31. august 2020 kl. 08:55
Usmarte elmålere

Har du gode, gerne konkrete forslag til hvordan du/brugerne/forsyningsselskaberne kan få gode oplevelser med det?

30. august 2020 kl. 20:38
Usmarte elmålere

Godt at få sat ord på hvor det går galt (og læse gode hypoteser om hvorfor), men sæt gerne nogle ord på hvordan det fixes.

Hvad skal det forsyningsselskab som står foran udbud af nye el- eller fjernvarme målere gøre, hvilke krav skal de stille?

For det er fra dem at ændringer skal komme fra hvis det skal ske noget konkret.

30. august 2020 kl. 13:22
Er der styr på software-komponenterne?

En ny-klassikker er vel også Heartbleed-sårbarheden i OpenSSL som bliver brugt mange steder. Gad vide hvor mange installationer har huller, som står åbne endnu.

19. august 2020 kl. 15:32
Er der styr på software-komponenterne?

Jeg vil gerne lægge ud: En organisation havde kildekoden og rettighederne til sit efterhånden +20 år gamle skræddersyede system.

Alt var godt, dog ikke helt godt, da den slags jo er tungt at vedligeholde. De havde nu fundet en ny leverandør til at vedligeholde koden for de næste 5-7 år, som derfor foretog et kode-review. Der blev opdaget en komponent, XXXbuf. Det hed den selvfølgelig ikke, men XXX var forbogstaverne for en bestemt leverandør, som oprindeligt lavede systemet i gamle dage og siden er blevet opkøbet et par gange. Ingen hos leverandøren kender i dag noget til komponenten.

Problem nr 1: Komponenten var en ORM med databaseadgang, brugt af centrale dele af systemet, og ikke opdateret eller patchet i mindst 15 år.

Problem nr. 2: Organisationen havde ikke rettighederne til lige dén del af kildekoden og burde derfor ikke længere bruge den.

19. august 2020 kl. 10:53