Der skal helt sikkert arbejdes hen mod open source til offentlige løsninger. Men i denne sammenhæng er det vel mere et spørgsmål om at finde (eller skabe) mindst en generel Ofiice leverandør som leverer hele pakken (incl. drift) og som man med sikkerhed kan tvinge til at overholde GDPR.
At afvikle sin drift on-premice. Selom den foreliggende skandale har ramt bredt så vil Azure hurtigere og mere sikkert rydde op end de tusindevis af exchange servere som findes on-premice. Episoder som denne - skubber på den store overliggende trend. On-premise drift er langsomt, men sikkert, på vej til at blive et nicheområde for de få.
Er vel at det er teknisk og økonomisk fristende at benytte de US baserede cloudtjenester. Vi er gået lidt i gang (for at høste gevinsten :-)) - og så opdager vi så at det faktisk ikke er i orden, ifølge vores egne regler og principper. Nu går vi så og venter på hvem der skal bøje sig. Garantier fra Amazon m.fl. er i sagens natur ubrugelige. Intet firma kan med troværdigheden i behold, garantere at vinde retssager mod justitsministerier (og lovgivere) i det land hvor hovedkontor og væsentlige dele af forretningen befinder sig i. Længere er den vel ikke....
1: Hvis du benytter en password manager hvor du selv håndterer password database filen - er det så godt som sikkert at det kun dig der kender dine passwords. Eks. Keepass databasefilen kan beskyttes med en nøglefil. Hvis man benytter denne facilitet så er det i praksis 2FA og så kan man efter min vurdering godt gemme databasefilen på nettet - blot man altså husker at holde nøglefilen tæt til kroppen. 2: Behovet for en password manager er i praksis massiv for mange. Jeg har eks. selv mere end 250 passords til alle mulige og umulige tjenester og apps. 3: Man bør benytte 2FA til alt der er vigtigt. Og det åbner behov for at gemme nødudgangsoplysningerne et eller andet sted.
Keepass er også er nævt i den oprindelige artikel fra Mike. Hvis du selv kan håndtere din password database fil og bruger en times tid på at komme i gang med keepass - så er du sandsynligvis godt kørende. Gratis og sikkert meret sikkert end så mange andre. Uanset hvad kan en password Wallet ikke stå alene.https://www.linkedin.com/posts/andersdjursaa_sikkerhed-windows-linux-activity-6767148311301427200-ZCEb
Og tilbydes af https://www.cookiebot.com/da/ som oven i købet er dansk. Det tog et par timer at få vores firma WordPress site til at samarbejde med Cookiebots - og så havde jeg endda også nået at læse en hel del af det med småt.
Hvor 10'erne blev en sejrsgang for agile udviklingsprocesser så gætter jeg på at 20'erne bliver årtiet hvor der kommer mere focus på at kodebasen får forbedret de agile egenskaber. Herunder også øget fokus på kvaliteten af sourcekoden således som den defineres her
Det er naturligvis nødvendigt at tegne de store streger og have overblikket fra helikopterperspektivet. Og der er naturligvis mange årsager til at systemer forældes. En af de væsentlige årsager er at sourcekoden slides ned og sander som konsekvens af "sparsommeligt" vedligehold. Der kan ofte afses midler til de store armbevægelser - men der er langt fra altid hverken anseelse i, eller ressourcer nok til, det løbende vedligehold. Et underkendt nøgleord i denne forbindelse er kodekvalitet - således som det eksemplevis er beskrevet af CodeImprover herSelvom det kan være fristende at forsøge at revolutionere sig ud af problemerne, så er det min opfattelse at man oftest er bedre tjent med en evolution.
Jeg tror der findes eksempler på at udviklere bliver presset til at springe over hvor gærdet er lavest. Hvis en overskrift skal være provokerende - så er det lykkedes :-)
Men et team sammensat af udviklertyper med den rette sammensætning - kan yde mere en summen af enkeltmedlemmerne. Denne "merværdi" kan optimeres ved at teamet kender hinandens styrker og svagheder og supplerer hinanden. Tilsvarende mindskes "merværdien" jo mere hver enkelte skal bruge tid på sine egne svagere sider.
1: Jeg har ikke næstuderet MUMPS (hvilket 99,9999% af udviklerne i denne verden heller ikke har) men ud fra et hurtigt kig på sproget så synes det ikke specielt egnet til noget specifikt domæne. Men det var sikkert ret moderne i 1966.
2: Relationsdataser er meget udbredt og særdeles velegnet til opbevaring af de fleste administrative strukturerede data, herunder også størsteparten af dataentiteter om sundhed. Og selvom relationsdatabaseteknologien i de seneste årtier er blevet supleret med andre lagringsteknologier (typisk til andre formål), så er den stadig state of art på sit område.
3: Oplysningen om sprogversioneringsteknikken stammer fra et foredrag i Ingenørforeningen hvor en daværende projektleder for implementeringen af Sundhedsplatformen nævnte det som et irritationsmoment.
Sundhedsplatformen er rent IT teknologisk så afvigende fra de sidste 30 års "best practice" at den alene ud fra en IT-håndværksmæssig vurdering bør diskvalificeres. Herunder:
- Sundhedsplatformen er kodet i et urgammelt niche programmeringssprog https://en.wikipedia.org/wiki/MUMPS
- Sundhedsplatformen benytter ikke en relationsdatabase.
- Sprogversionering i Sundhedsplatformen foregår med hardkodning i stil med If country = "DK" then Text = "Sygdom" else Text = "Disease"
Især synes jeg at læse at gevistrealisering bedst opstår i det lange stabile samarbejde. Jeg hæfter mig også ved at "fastpris er gift for bevinstrealisering" Jeg kunne ikke være mere enig.
Så hvis kunden ønsker at leverandøren skal tænke business Casen ind i leverancen - så skal det være en af de parametre som leverancen måles på. Herudover så gætter jeg på at mange Business Cases udarbejdes ud fra den antagelse at projektet/leverancen er et Level 1 kaos. Og at det er i mange tilfælde viser sig at være et Level 2 kaos. (Level 1 og 2 kaos - se https://www.linkedin.com/pulse/level-1-2-chaos-anders-djursaa/ ) Hvorfor mange Business Cases ofte får svært ved at stå distancen.
Jeg har netop deltaget i "IDA Ledelse 2018" og hørt en tidligere programchef for Sundhedsplatformen forklare hvorfor det faktisk er en succes. Og det må være klart at implementering af et fælles IT system i en så kompleks verden ikke er nemt - for nu at sige det på jydsk. Og det er sandsynligvis også helt korrekt at mange af de fortrædeligheder som man er blevet hængt ud for, faktisk ikke skyldes selve IT-systemet men beror på uundgåelige problemer der er i sådan en process. Men det står tilbage at man har købt, og under stor udgift, ibrugtaget et system som teknologisk er forældet og meget afvigende fra best practice. Det er slemt at Sundhedsplatformen er skrevet i et (lille) niche programmeringsprog, ikke benytter relationsdatabase og at sprogversioneringen foregår ved at at man hardcoder tekster direkte i programkoden. Men det værste er at Sundhedsplatformen er skrevet i MUMPS https://en.wikipedia.org/wiki/MUMPS som sammen med den øvrige forældede arkitektur udgør en seriøs strategisk risiko.
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å?
Opfattelser i samfundet ændrer sig langsomt. Det er alt, alt for tidligt at drage konklusioner. Der skal meget mere tid, vedholdende viderearbejde og håndhævelse til- før man kan forvente at gode initiativer som GDPR fører til øget tillid. Tillid tager som bekendt lang tid at opbygge.
Kunne det være interessant at få de tekniske rådgivere i udbudssagen til at forsvare eller forklare deres oprindelige anbefaling (af Sundhedsplatformen). For man vægrer sig jo ved at tro at ansvarlige og sikkert begavede konsulenter/eksperter kan have anbefalet noget med så mange åbenlyse og let forudsigelige problemer. PS: 1.400 mandeår kan vel oversættes til mellem ½ og 1 milliard kroner. Det er ufatteligt at man kan vinde et udbud med en sådan ekstraudgift.
Som jeg forfattede for nogen tid sidenhttps://www.linkedin.com/pulse/analog-information-technology-needed-democratic-election-djursaa/
Så er konklusionen at et valg bedst afvikles med lidt analog teknologi. Nærmere (eller snarere resumeret) argumentation findes på https://www.linkedin.com/pulse/analog-information-technology-needed-democratic-election-djursaa/
Anders Djursaa