"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.
Torben, er det etproblem med metoden eller med implementeringen, i din optik? Det kunne være spændende at høre om
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)
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
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.
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å?
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.
How, sorry, Lise, jeg lægger lige denne over på dit forrige indlæg. God pension og tak for indsatsen herinde
Mvh Peter
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"
... 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.
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.
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.
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.
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?
Har du gode, gerne konkrete forslag til hvordan du/brugerne/forsyningsselskaberne kan få gode oplevelser med det?
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.
Off topic, dejligt at starte fredagen med en HHGTTG-reference, tak :-)
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.
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.
Peter Nørregaard