Konsulenter skyld i problemer med offentlig it, mener CBS-professor og eks-vicedirektør i IBM

Meget oplysende og ærlig artikel, tak for det.

"Problemet består i, at der ikke er nogen, der har en interesse i at rette systemfejlen."

Jo!!!!! Det har vi - borgerne og patienterne og skatteyderne i den grad - selv om vi efterhånden ikke regnes for andet end datamalkekøer, forsøgsdyr og stemmekvæg i disse sammenhænge.

Det gør mig rasende at læse dette interview, som bekræfter de fornemmelser, man hele tiden sidder med, men som man typisk ikke kan dokumentere, fordi alt relevant stort set mørklægges, og kræver journalistisk graverarbejde at få frem i lyset.

Mørklægningsloven har i hvert fald ikke gjort dette problem lettere at løse - lad os få den ud ad vagten hurtigst muligt. Så kan vi borgere lettere holde de ansvarlige i ørerne - når nu de ikke selv er i stand til det - det fremgår jo tydeligt af ovenstående interview.

Jo!!!!! Det har vi - borgerne og patienterne og skatteyderne i den grad - selv om vi efterhånden ikke regnes for andet end datamalkekøer, forsøgsdyr og stemmekvæg i disse sammenhænge.

Men Anne-Marie, det er jo ikke OS som er KUNDEN, vi er bare en den dødvægt som systemerne skal administrere, vi kunne lige så godt være sten eller rødspætter. Politikerne har helt glemt årsagen til deres eksistens, derfor er jeg f.eks. stor fortaler for direkte demokrati som i Schweiz. Vores statsapparat koster for meget og er i princippet bare et talerør for EU.

Tak for svar, Maciej Szeliga

Men Anne-Marie, det er jo ikke OS som er KUNDEN, vi er bare en den dødvægt som systemerne skal administrere, vi kunne lige så godt være sten eller rødspætter.

Hihi - ja, du har ret. Personlig føler jeg mig nu for tiden mest som datamalkeko - hvis vi var rødspætter, gad IBM og Lundbeck og den slags nok ikke sponsorere så mange projekter. Men vi er tydeligvis til for industriens, politikernes og embedsmænds og forskeres skyld.

Jeg kan ikke lige overskue, om direkte demokrati er løsningen. Men jeg kunne godt tænke mig et meget snævert loft over vore politikeres og embedsfolks deltagelse i konferencer, rejser, middage og lobbyistmøder, for jeg tror, at det er der, roden til mange problemer ligger. Man bliver for gode venner med industrien, man får for meget fokus på egen karriere og netværk, man får for mange "gode" og dyre ideer, og man kommer for meget på afstand af dagligdagen og medarbejderne på gulvet, som ellers kunne få en til at holde benene på jorden. Man får oparbejdet det helt forkerte bagland, nemlig internationale kontakter og folk i samme skylag som en selv - uden føling med de borgere, man burde have fokus på og betjene. Og så bliver det alt for let med "kuverter under bordet".

Jeg ville gerne se en ærlig opgørelse over, hvor meget konferencer og rejser middage og den slags fylder i budgettet. Måske ser det ikke ud af så meget - men for den afdeling, som måske beskæres for at få råd til det, kan det være katastrofalt.

Det er jo et kultur problem. Jeg synes ikke man kan bebrejde konsulenterne, igen så udfører de jo generelt kun det de bliver betalt for. Hvis man skubber for meget den anden vej, så er det ud af vagten på alle fire. Og hvis du nu selv går ned i brugsen og køber en indkøbsvogn fuld af chips, slik, øl og vin og personen i kassen begynder, at snakke med dig om kostvaner og alkohol forbrug...... så ja..

Problemet ligger i manglen på respekt for fagligheden i det man beskæftiger sig med og så i manglende konsekvens. Noget vi med al tydelighed ser lige nu i den måde, som 'administrationer' rundt omkring skyder tilbage på f.eks. rigsrevisionen. Og ansvaret ligger altså i 'bestyrelserne' for disse offentlige institutioner. Og det er politikerne.

Problemet er bare, at partierne lever af at lave 'marketing', det er jo det de gør, så de er jo belagt med metervis af teflon.

// Jesper

Han glemmer helt at nævne project creep, som for det meste skyldes at kunden (det offentlige) vil have alt, og helst have nye ting implementeret mens man er ved at implementere det egentlige projekt.

Og hvis konsulenten/projekt manageren siger fra når disse nye ting kommer, så bliver han/hun bedt om at forlade projektet, og så kommer der bare en der siger ja....

Så det offentlige er omtrent lige så meget skyld i problemet som konsulenterne.

Siden nullernes mantra om, vi skal af med ekspertvældet og købe specialviden når det er nødvendigt, er konsulentbistanden til det offentlige eksploderet. Jeg har prøvet et projekt, hvor der til stadighed var ca. 20 konsulenter og vi var 6 fastansatte til at sikre leverancerne. I dag er de nede på 3 fastansatte og lidt flere konsulenter. I dag leverer de tilbageværende fastansatte ydelser til konsulenthuset som sælger ydelserne tilbage til staten som altså betaler så, betaler dobbelt for arbejdet. Jeg og andre smuttede, fordi vi ikke kunne stå inden for konstruktionen, men det har ikke løst problemet.

Denne kommentar tror jeg er humlen i det hele. Det politiske ønske om privatisering og udflytning, fordi man tror eller håber, at det bliver billigere og bedre. Men det bliver det ikke! Det bliver dyrere og dårligere, ligesom det sker ved udlicitering af rengøring på hospitalerne og udflytningen af Skat! Mange af de ansatte eksperter, der forlader det offentlige, bliver jo ansat privat som konsulenter til langt højere løn. Deres kendskab og netværk fra den offentlige ansættelse bliver særlig nyttigt og betyder desuden en form for sammenspisthed, som er uønsket.

Da jeg var ansat i miljøstyrelsen fra 1974-1982 var teknikerne dygtige specialister, og der var stort set ikke brug for eksterne eksperter til andet end personaleudvikling. Nu er teknikerne i højere grad generalister og og er afhængige af input fra eksterne konsulenter til at lave det faglige arbejde, forskning, projekter og rapporter. Samtidigt er medarbejderantallet faldet i forhold til opgavernes stigende omfang, så medarbejderne ikke mere har tid til at læse og implementere rapporternes indhold, og for mange ringe og overlappende projekter sættes i gang uden ordentlig evaluering af de tidligere resultater, og forberedelse af og indholdet i lovgivningen bliver teknisk-fagligt utilfredsstillende. Vi ligger som vi har redt, fordi for mange danske politikere i mange år har været ligeså overfladiske, populistiske, anti-faglige, naive og bedrevidende som Donald Trump, som de ellers kritiserer kraftigt.

Lige i øjet, Allan Astrup Jensen. Og netop bl.a. sundhedsforskningen får man også indtryk af er styret af en sammenspist gruppe, som efterhånden har så tætte bånd til industrien, at de ikke er til at skelne fra denne. Og det ligger jo egentligt i selve udtrykket "offentligt-private partnerskaber", at man er fælles om det hele, også ansvaret, dvs. det ansvar, der forsvandt.

Igen og igen kommer der forskellige, men samstemmende vinkler på det grundlæggende problem ved den nuværende metodik omkring store IT projekter (ofte i det offentlige). Denne her er nok mere solidt funderet på erfaringer end min egen mere teoretiske analyse på https://www.linkedin.com/pulse/public-scandals-founded-during-contract-p...

Jo!!!!! Det har vi - borgerne og patienterne og skatteyderne i den grad - selv om vi efterhånden ikke regnes for andet end datamalkekøer, forsøgsdyr og stemmekvæg i disse sammenhænge.

Vi bliver da troligt spurgt hvert 4. år om vi ønsker at fortsætte med de store linjer med privatisering af overskud, socialisering af omkostninger, og mikromanagement af i vores alle samens institutioner.

Problemet er vel at vi svarer nogenlunde det samme hver gang! for dem der mener noget andet er jo latterlige, urealistiske eller uansvarlige outsidere :)

Vi bliver da troligt spurgt hvert 4. år om vi ønsker at fortsætte med de store linjer med privatisering af overskud, socialisering af omkostninger, og mikromanagement af i vores alle samens institutioner.Problemet er vel at vi svarer nogenlunde det samme hver gang!

Ja, du har ret - som jeg siger, vi har vores berettigelse som datamalkekøer, forsøgsdyr - og ja: Stemmekvæg.

Problemet er jo bare, at det i så høj grad mørklægges og foregår under radaren, den måde denne udvikling luskes igennem på, og de skjulte konsekvenser i form af indspisthed og pengemandsstyre, som udviklingen har. Det har mørklægningsloven været med til at sikre. Og partistøttelovene og VL-klubberne. Og denne mørklægning lykkes desværre alt for godt - det kræver særlig interesse eller "vækkelse" at blive opmærksom på, hvordan det er, vi føres bag lyset. Så ja - udviklingen vedtages demokratisk, men det ændrer ikke ved, at det, der foregå bag kulisserne, efterhånden forekommer i høj grad i strid med demokratiske principper.

Kære Kim

Tak fordi dit indlæg.

Dit centrale spørgsmål er: “hvorfor er der ikke nogen der siger fra”.

Jeg skal, som en af de ‘skyldige’ forsøge at besvare dit spørgsmål efter bedste evne. Jeg sad indtil for et par år siden sammen med Jesper Frimann hos en af de store spillere i markedet, KMD.

Vi er begge enterprise arkitekter og vi har brugt mange timer på at diskutere netop det spørgsmål du fremhæver og vi har også begge forsøgt at ‘råbe op’, dog uden at det gjorde nogen forskel.

Jesper må hellere selv fortælle om egen rolle hvis han har lyst, da jeg ikke har koordineret dette indlæg med ham.

Jeg har blandt andet skrevet væsentlige dele af flere af de tilbud som KMD har vundet nogle af de store ordrer på og har derfor været helt inde i maskinrummet på leverandørsiden.

Min personlige konklusion er, at problemet helt overordnet set er strukturelt og kun i mindre grad personafhængigt.

Der er følgende tre væsentlige strukturelle problemer:

1) Finansieringen.

Som du selv er inde på, så finansieres større anlægsprojekter (som nye it-løsninger er) for det meste via et aktstykke til Finansministeriet. Der får man så penge til at bygge løsning X.

Forud for denne ansøgning er gået et større eller mindre arbejde med at beskrive HVAD det er man tror man vil bygge.

I det arbejde er der ofte ikke tilstrækkelig brugerinddragelse og man har kun sjældent så meget styr på forretningen, at man er i stand til at beskrive de forretningsmæssige processer der indgår, samt de eventuelle ændringer der er behov for.

Når man indgiver sit aktstykke er man derfor allerede dårligt i stand til at regne på hvad det egentlig kommer til at koste for man ved faktisk ikke i detaljer hvad det er man vil lave.

Når først aktstykket er godkendt, så fanger bordet. Nu har man fået penge til præcis det projekt man har ansøgt om og ikke andet. Skulle man blive klogere undervejs, skal pengene som hovedprincip retur til Finansministeriet og så må hele møllen starte forfra.

De ‘inkompetente ledere’ som mange af kommentarerne kredser om, ja de administrerer blot efter reglerne for de er nødt til at holde sig indenfor lovens rammer.

2) Udbudsreglerne

Når man har fået tilsagn om pengene i Finansministeriet så rammes projektet af endnu et strukturproblem nemlig udbudslovgivningen.

I denne fase indfinder angsten for fodfejl sig - både hos leverandør og kunde. Selv banale fejl, som et kryds i en forkert rubrik, kan ende med at man mister muligheden for at byde. Eller udbuddet skal gå om fordi kunden er kommet til at lave en fejl i processen.

Da ALT væsentligt skal være aftalt i udbudsfasen så handler 85% af udbudsmaterialet om at kunden forsøger at dække sig ind i og kun meget lidt handler om det der egentlig skal leveres (... og som fortsat ikke er ordentligt beskrevet, så leverandøren ved ikke præcis hvad han skal levere i sit tilbud).

For at føje spot til skade, så blander Kammeradvokaten sig hyppigt på kundens side og mantratet har i flere år været at 2/3 af udbudsmaterialet skal være mindstekrav. Mindstekrav vil sige krav, hvor leverandøren ikke må kommentere eller beskrive sin leverance i forhold til kravet, men blot skal acceptere det kunden har forlangt - også selvom det kan forekomme tosset eller fordyrende eller modsiger et andet krav.

Så nu er vi derhenne, hvor kunden altså ikke tilstrækkeligt har beskrevet sine forretnings behov og -processer i detaljer, og leverandøren i væsentligt omfang ikke har mulighed for at beskrive hvad han har tænkt sig at levere, fordi han er afskåret pga mindstekrav.

Leverandøren er også helt og aldeles afskåret fra at komme med et bud på noget der er smartere eller bedre, end det kunden har beskrevet.

Og så er der jo lige prismodellen. Som en del af udbuddet indgår der som regel et regneark hvori leverandøren skal angive sine priser i nogle scenarier kunden har udtænkt og da prisen de fakto betyder mest i et tilbud, så er det her man vinder eller taber.

Det vil sige, at man som leverandør leder efter smuthuller i modellen og det giver nogle gange nogle fuldstændigt vanvittige priser på de enkelte dele, men i kundens prismodel er det det der giver den mest fordelagtige pris ...og det er jo den der vinder ... også selvom det bliver megadyrt for kunden når virkeligheden indfinder sig. Prismodellen og tidsplanen er kongerne i ethvert udbud.

3) Leverancen og tiden

Når der er fundet en vinder af udbuddet, så er vi typisk 1-2 år fra de første tanker blev tænkt. Kundens forretning (som aldrig blev ordentligt beskrevet i detaljer) har muligvis ændret sig men nu skal der leveres på det der er beskrevet - på den udbudte genstand, som det hedder hos juristerne.

Leverandøren får ofte point for den mest optimistiske tidsplan, så sådan en har han skruet sammen, velvidende at erfaring fortæller at der altid er tilbageløb, men skriver man den realistiske tidsplan, så vinder man bare ikke.

Leverandøren var jo i praksis nødt til at byde med den billigste pris og til nogle skrappe krav blandt andet på deadlines. Så hans mulighed for at tjene noget på ordren ligger i ændringsønskerne som kunden er nødt til at fremsætte hvis han ønsker noget som ikke står i kontrakter, for eksempel fordi hans forretning har ændret sig eller fordi han endelig er ved at kende sine processer i detaljer og opdager, at de ikke passer med det han har bedt leverandøren om at lave.

Her sætter leverandøren så tommelskruerne på og kræver noget der ligner ublu priser for banale ændringer og frem for alt kræver han, at kunden tager ansvaret for de forsinkelser ændringerne medfører. Det er jo ikke leverandørens skyld at kunden ikke havde beskrevet sine behov detaljeret nok og enhver forsinkelse medfører bod i sidste ende så det gælder om at det er kunden der er årsag til forsinkelsen, ikke af ond vilje men blot fordi gamet strukturelt er skruet sådan sammen.

En forsinket tidsplan er IKKE karrierefremmende for en embedsmand på samme måde som budgetoverskridelser heller ikke er det.

... så resultatet bliver at leverandøren nu leverer et system sådan som han tror det skal være, på baggrund af den mangelfulde forretnings- og procesbeskrivelse som kunden leverede og de få ændringsønsker som de i fællesskab kan blive enige om, så tidsplanen bliver overholdt.

Det er således et under og resultatet af indsatsen fra meget kompetente ledere, arkitekter, udvikler m.fl. både hos kunden og leverandøren, når det ind i mellem lykkes at levere et brugbart resultat, for de underliggende strukturelle forudsætninger tilsiger at projektet SKAL fejle.

Beklager det meget lange indlæg.

Eller skiftet du job, lige så snart du fandt ud af, at dit arbejde bestod i, samt uden mulighed for at ændre system det - (som du beskriver det),

Ved at mange andre, som gerne har ville bevare deres personlig integritet har fundet nyt job hurtigst muligt. Så mange af dem, der er tilbage, ved mange leverandører til det offentlig. Enten er nyuddannet som skal have erfaring, eller mennesker uden personlig stolthed over deres arbejde og bare skal have løn til terminen. Eller i sidste ende personer, som er lige så dygtigt som det system de administrere og laver programmer til.

Hvis du har fortsat med dit arbejde efter denne erkendelse, så har du også selv, solgt ud af dig selv for ussel mammon. Og selv om dit indlæg er ærligt og redeligt, og du nået udgangen med en god smag i munden. Så mener du at dine gamle kollegaer, er (noget som nok alligevel vil blive slettet, uden forklaring af V2) :-)

PS.. Ikke et for langt indlæg.. Læste det gerne. Du har på mange måder sikkert, slået hovedet mere på sømmet, end PHK har med sin kommission. Tak for langt og ærligt indlæg, selv om jeg langer ud efter dig,,,

Tak for interessant, ærligt og lærerigt indblik i processen, Henrik Sørensen. Der er godt nok mange snublesten, og ingen nærliggende løsninger.

så finansieres større anlægsprojekter (som nye it-løsninger er) for det meste via et aktstykke til Finansministeriet.

Her er det, jeg tænker, at det måske allerede er gået galt inden da. For er de større anlægsprojekter faktisk udtryk for ægte samfundsmæssige behov, eller er de mest udtryk for personlige prestigeprojekter (såsom et aktuelt eksempel, som ikke er nået at blive til underskud på samfundskontoen endnu - men det 'bliver* det garanteret, nemlig Formel1-projektet. Jeg undskylder med det samme til alle jer, som synes, at det er et fantastisk projekt. Jeg ser det ikke som noget, samfundet har brug for, Og jeg er klar over, at det ikke er et IT-projekt - men mekanismerne er de samme)?

Eller er det kunstige behov, fremkaldt af for megen færden i lederklubber (jeg har en aktindsigt fra sundhedsministeriet, hvor der bl.a. figurer et medlemsgebyr på 25000 kr. for én person årligt til en sådan klub, som jeg andetsteds på nettet har set beskrevet som mest et mødested for udveksling af vinsnobberi og gourmetsladder), hyppige besøg på konferencer, som dybest set er salgsmesser, hvor lobbyister i luksuøse omgivelser har frit spil til både at love guld og grønne skove mht. besparelser og fantastiske resultater, og til at love beslutningstagere gode karrierer, når de engang er smidt ud af det offentlige pga. kuldsejlede projekter? Eller projekter som er resultat af "relationsplejende" rejser og middage, som i Atea-sagen, hvor man sikkert også har fået mange gode ideer, som skulle gå ud over den sagesløse befolkning?

Som jeg ser det, er situationen i det offentlige på IT-fronten for tiden så kriminelt elendig, at det eneste virkeligt påtrængende behov lige nu er at få ryddet op og få styr på de projekter og systemer, som vi allerede har. Få sikret infrastruktur og datasikkerhed i eksisterende systemer og få oparbejdet en stab af virkeligt dygtige medarbejdere, som kan hamle op med lobbyister, fordi det værdsættes mere at gøre det end at stile efter krydser i rubrikker og overfladiske resultatkontrakter. Så må nye, fantastiske projekter vente, til vi har fast grund under fødderne, og har fundet bedre måder at sætte projekter i gang på, og bedre måder at styre den på, end det, du beskrive så levende ovenfor.

Men hvad sker i stedet? Det vælter fortsat frem med nye prestigeprojekter, som vore politikere hellere vil fremvise, end de vil stå på mål for SundhedsSplatforme, Skattesystemer, og hvad der ellers er i pipelinen. "Nå, det gik ikke så godt - hurtigt videre til det næste projekt, det går måske bedre".

Hvor mange af disse projekter har faktisk haft afgørende positiv betydning for samfundet og borgerne? I mine øjne de færreste - de har mest effekt på virksomheders og beslutningstageres bundlinjer.

@Hans

Tak for din kommentar og tak, fordi du havde tålmodighed til at læse det hele. Du må gerne ‘lange ud efter mig’ - debat er ofte kvalificerende, hvis vi formår, at holde os til emnet, der debatteres.

Som jeg skrev, er problemet strukturelt og ikke personafhængigt. Jeg langer derfor ikke ud efter tidligere kollegaer eller efter dem der sidder der nu i stedet for mig.

Om jeg fik en dårlig smag i munden? ... nej, sådan vil jeg ikke udtrykke det, men jeg var fagligt udfordret, ja.

Det underlige er, at det enkelte udbud er en superspændende intellektuel udfordring. Du skal forstå et nyt domæneområde, en masse jura, en masse teknik, en masse processer og du skal, under enormt tidspres, finde og beskrive en løsning der kan bygges og leveres og samtidig overholde +1500 krav.

Det bliver man fagligt høj af, når man som jeg (tillad lidt praleri) nok er blandt de bedste til den slags. Bedste forstået som: indenfor de givne strukturelle (håbløse) rammer.

Den reelle udfordring er så, om det giver mening i et større samfundsperspektiv - løste vi opgaven eller løste vi problemet?

... og der støder jeg mig så på den anden del af min faglighed, for det er min helt klare overbevisning, at vi (alle involverede) primært løste opgaven og kun i mindre grad problemet.

Vi vil kunne opnå markant bedre resultater og undgå mange af de ulykkelige ‘skandaler’ vi har set, men det vil kræve at vi først og fremmest involverer brugerne hele vejen igennem; at vi sætter faglighed over struktur og at vi sætter ambitionerne til et niveau, hvor vi faktisk kan levere succesfuldt, jf. Kim Østrups pointe om at vi gør projekterne så store, at de ikke kan leveres succesfuldt.

Men det vil kræve væsentlige strukturelle ændringer og dem kan jeg ikke rigtig trylle op af den sorte muld, hvor end jeg gerne vil.

Vi ser de samme problemer alle mulige andre steder uden for it-branchen - peg på IC4 eller nogle af de mange andre projekter, hvor man undrer sig.

Selvom vi sikkert, hver især, kan udpege en eller flere ‘inkompetente ledere’ så er der simpelthen ikke nok af dem til at vi kan forklare alle de fejlslagne projekter med dårlig ledelse.

Strukturen nedenunder må ændres, men jeg ved simpelthen ikke hvordan. Gode bud er velkomne.

@Anne-Marie

Jeg glemte et punkt 4, men jeg kom i tanke om det, da jeg læste din seneste kommentar.

Kim Østrup peger på et behov for mere ekspertise i den offentlige sektor og jeg giver ham fuldstændig ret.

... men hvorfor skulle eksperterne (og andre) søge ansættelse i det offentlige, når lønnen ofte er 20-30% dårligere og man samtidig skal udsættes for en nedladende mistænkeliggørelse, smålighed og navlepillende misundelseskultur, som den du giver udtryk for, når du sætter spørgsmålstegn, ved offentligt ansattes deltagelse på konferencer mv.

Den der konspiratoriske tankegang er i dén grad skadelig. Skulle vi ikke i stedet gøre den offentlige sektor til et attraktivt sted at være.

Skal vi ikke begynde at tro på, at de ansatte faktisk møder op for at gøre deres bedste og ikke som onde zombier, der bare vil suge blod.

De offentligt ansatte bør få en konkurrencedygtig løn, frugtordning og sundhedsforsikring og hvad der ellers følger med på en moderne it-arbejdsplads i den private sektor, bare vi ser bedre resultater end i dag.

Men det vil kræve væsentlige strukturelle ændringer og dem kan jeg ikke rigtig trylle op af den sorte muld, hvor end jeg gerne vil.

Det er jo ikke fordi det er specielt svært at løse. Statskundskab er bare et andet fagområde. Uden at forklejne en stor kompleksitet, handler det kort sagt om:

• At stoppe det store samfundseksperiment med at privatiser alting af ideologiske grunde.
• At stoppe med mikromanagement fra regeringers side.
• At genindfører anerkendelse af reel kompetence hos embedsmænd og uddelegere beslutninger til de mennesker ved mere om emnerne, end de fleste politikere gider at vide
• At genindfører retten til at blive klogere af erfaring, selvom man er offentligt ansat.
• At have gennemsigtighed i processerne allerede fra ide-fasen.

Hvis der igen kommer fornuftige politiske rammer for det offentliges virke, kan embedsværket begynde at træffe fornuftige beslutninger. Det vil sikkert medføre noget i retning af:

• At projekterne trækkes hjem til det offentlige igen, således at projektstyringen og erfaringsopsamlingen sikres over tid og projekter.
• At der kommer en god adskillelse mellem drift, data og bruger applikationer.
• At brugerapplikationer kan sendes i udbud i små portioner, der løbende kan udbygges og tilpasses forretningen.
• At data konsolideres og driftes trygt. ... og alle de andre fornuftige metoder og forslag, der ofte omtales her på sitet.

Det er absolut ikke en umulig opgave at opbygge en effektiv struktur. Der er masser af kompetencer at trække på. Det er derimod vanskeligt at se hvordan det skal kunne gennemføres i det nuværende politiske klima.

Henrik Sørensen: Tak for svar.

Jeg ser gerne, at man giver en ordentlig løn, uden en masse bonusser, gyldne håndtryk osv. - men det er min helt ærlige overbevisning, at det er skadeligt for den offentlige sektor, at rejsen rundt til konferencer og lobbyistarrangementer er blevet så stor en del af beslutningstageres arbejde. De bør have deres bagland og deres identifikationer herhjemme - ikke hos en international lederklasse, som lever i et helt andet luftlag end resten af befolkningen.

Mere, Henrik Sørensen:

Skal vi ikke begynde at tro på, at de ansatte faktisk møder op for at gøre deres bedste og ikke som onde zombier, der bare vil suge blod.

Jo, det gælder for rigtigt mange - men de ledertyper, man fremelsker, belønnes jo netop for at kigge opad, ikke nedad, og for at gå efter egen karriere, ikke efter det fælles bedste. Selvfølgelig er der undtagelser, men pga. mørklægningsloven er det ikke til at vide, hvem der er skurke, og hvem der faktisk af et ærligt hjerte gør deres bedste. Og da det oftest er resultatet af skurkenes arbejde, vi ser, er det svært ikke at skælde ud på "toppen" som sådan. Hvad skal vi ellers gøre - for skurkene findes jo, og er langt hen ad vejen toneangivende - se bare Atea-sagen?

At anklager om korruption og fiflen også rammer de gode medarbejdere, og er med til at gøre det offentlige mindre attraktivt , kan ikke bruges som begrundelse for ikke at forsøge at pege på de årsager til problemerne, som findes, heriblandt korruption og smøring. Måske kan det vække nogen potentielle whistleblowere til handling.

De offentligt ansatte bør få en konkurrencedygtig løn, frugtordning og sundhedsforsikring og hvad der ellers følger med på en moderne it-arbejdsplads i den private sektor, bare vi ser bedre resultater end i dag.

Helt enig - jeg har intet sted gjort mig til talsmand for, at det ikke skal være tilfældet. Jeg holder af det offentlige - det er netop derfor, jeg er så vred over, at det bliver ødelagt af pengemænd og deres tankegang om, at love og regler ikke gælder for dem, "because we're worth it". Og der er jeg sikker på, at politikeres og topembedsfolks alt for tætte omgang med lobbyister er med til at korrumpere det offentlige system.

...som også Anne-Marie og Hans er inde på, byder for mig på et par gedine etiske spørgsmål:

Er der noget I vejen med at man udfylder sin plads, og hjælper til med at udfører demokratiske beslutninger i samfundet efter bedste evne? Og gør det en forskel om man er privat eller offentligt tilknyttet?

Der skal nogle gange store evner og rå intelligens til at gennemfører politikernes beslutninger, på en måde er ikke afslører hvor elendig betingelser de byder offentligt ansatte (ledere) til at gøre det rigtige for samfundet. Når begavede mennesker som Henrik og andre, gør deres yderste for at få enderne til at mødes alligevel, på trods at tilsyneladende umulige krav, sløres konsekvenserne for beslutningstagerne. Det forpester tusindvis af offentligt ansattes hverdag og arbejdsglæde at skulle arbejde med elendige systemer. Det kan ikke undgå at forringe den offentlige service for millioner af mennesker og det er en byrde for den generelle vækst og ligheden i samfundet.

Har mennesker med store evner en etisk forpligtelse til at bruge disse evner konstruktivt eller i det mindste på en måde der ikke til skade for samfundet?

Historisk set og uden sammenligning i øvrigt, blev det slået fast ved Nürnbergprocessen, at man pådrager sig et moralsk ansvar, også selvom det er en demokratisk valgt regering, der pålægger en at gøre noget, der er uetisk. Specielt hvis man gør det godt!

For mig er det afgørende spørgsmål her, om det er et spektrum der også har gyldighed i mindre grelle spørgsmål? Og ikke mindst om der er noget der har ændret sig i løbet af de sidste 70 år, som retfærdiggøre at den historiske tolkning ikke længere er gyldig?

Min personlige holdning er et betinget ja til alle forhold. Og tak Henrik for at udvise noget ansvar, ved at fremlægge dine oplevelser her.

Henrik Sørensens indlæg er godt. Rart at få noget indsigt i den del af offentlige IT projekter.

Hvis man i dag køber en bil vil man sjældent opleve at den ikke kan starte om vinteren. Det er ikke mere end 30 år siden at det ofte var et problem. De sidste 30 år har leveret utroligt meget udvikling til biler. De er meget mere sikre, ruster meget mindre, er langt mere pålidelige og langt bedre for miljøet. Havde man haft ambitionen om nutidens bilers i 1988 og prøvede man at definere et projekt som Henrik beskriver det, ville det garanteret fejle. Det folk glemmer er at de første biler i princippet var hestevogne med en motor monteret. De biler vi har i dag er i princippet blot resultatet af små forbedringer der kontinuerligt er implementeret.

Problemet med den form for ideologiske tilgang til produkt udvikling, som Henrik beskriver, er at man skal være usandsynligt heldig for at nå målet. Ideen lader til at være, at kan vi blot definere det vi vil have, så kan vi bygge det. Det er IKKE rigtigt. Gode produkter udvikles normalt med små kontinuerlige forbedringer. Nogle gange bringer det man troede var en forbedring endda nogle utilsigtede ulemper med sig.

I det offentlige har man valgt ikke at følge denne process. Det lader til at man blot vil købe et færdigt produkt sætte det i stik kontakten. Hvis man blot kunne gøre det ville det være en udmærket tilgang. Men det er ikke det man faktisk gør. Man vil i stedet købe nogle "hylde vare" løsninger og tilpasse dem til det danske system. Det er egentlig her det går galt. For dermed vil man gerne blæse og have mel i munden. Produkt udvikling er en iterativ process. Når man så har den tilgang til problemet som Henrik beskriver, hvor man med ren ønske tænkning opfinder det man vil have og endda forventer at få det til en fast pris, så er det dømt til at gå galt.

Hvis vi i Danmark gerne vil have en unik dansk infrastruktur kan vi ikke undgå at skulle udvikle nye IT løsninger. Det kan simpelthen ikke undgås. Så problemet er i virkeligheden at vi dermed ikke kan købe hyldevare løsninger som blot kan stikkes i kontakten. Vi er nødt til at have en vedblivende og løbende udvikling af den software som implementere denne danske unikke infrastruktur. Dette produkt kan så have interface til disse hyldevare løsninger, så vi ikke behøver at opfinde den dybe tallerken, hver gang vi har brug for nye IT løsninger.

Hvis jeg som IT udvikler skulle komme med mit bud på hvordan dette bedst gøres, så ville det være at definere det som en åben standard. Softwaren kan være både open source og proprietær. Definer denne standard som en decentral løsning således at flere udbydere kan levere løsningen til de forskellige kunder, således at vi kan få noget konkurrence og valgfrihed. Denne standard skal indeholde en obligatorisk protokol der gør det muligt for alle services at snakke sammen.

Jeg har en lidt bedre definition:

Navn: Dansk IT infrastruktur standard (DITIS) o Standarden skal varetages af et almennyttig selskab, hvis eneste formål er at varetage standarden. o Standarden skal være obligatorisk for al offentlig it infrastruktur. o Standarden har til formål at garantere at enhver leverandør kan tilbyde en løsning og på samme tid garantere at disse løsninger er kompatible med hinanden. Interaktion imellem de forskellige services skal defineres med en åbent defineret protokol. o Standarden må ikke stille krav til en enkelt leverandør eller teknologi der kan udelukke andre leverandører. o Standarden skal være decentral og modulær i det omfang det er muligt, således at flere udbydere kan levere løsninger, og dermed give kunderne en valgfrihed der gør dem i stand til at vælge den bedste løsning til deres problem. o Standarden skal have en reference implementering der er open source, således at funktionalitet kan bevises. Derudover skal reference implementeringen danne grobund for udviklingen af standarden. Reference implementeringen skal ikke nødvændigvis implementere den bagved liggende infrastrukturen. Reference implenteringen bør kunne forkes til en integration med f.eks. EPIC og SP. etc. Reference implementeringen skal bruge en licens der gør det muligt at forke til closed source (BSD, MIT)

o Selskabets bestyrelse skal bestå af politikere og interessenter fra industrien samt et minimum af 40% teknisk kvalificerede IT udviklere og IT administratorer, ligeligt fordelt.

De 40% er vigtigt og fordelingen er også vigtig.

Det kunne godt tænkes at de 40 % både er udviklere og administratore, men det er ikke særligt sandsynligt. Der vil muligvis være nogle få med overlap. Specielt hvis der er tale om ældre IT folk.

grunden til at begge dele er vigtigt er de inbyrdes modsætningsforhold.

Administratore er oftest interesseret i stabilitet og kvalitet, hvor udviklere oftest er interesseret i forandring og nyskabelse. Man kan dermed sige at administratore er konservative (højre orienterede) og udviklere er progressive (venstre orienterede). Folk har det med at blivere mere konservative med alderen, så hvis man er heldig nok til at få noget af det grå guld med i bestyrelsen kan man muligvis få begge discipliner.

politikere og interessenter fra industrien

Der er meget, jeg godt kan lide i dit forslag, Magnus Jørgensen, og det er svært at finde perfekte løsninger. Ovennævnte citat giver dog lige et lille gib af bekymring for, at det kunne risikere blot at blive endnu et af de mange fora, hvor det er industrien, som indirekte ender med at diktere udviklingen, og hvor indspistheden mellem beslutningstagere og industri blot bliver endnu større. Jeg har ikke nogen umiddelbar løsning, for selvfølgelig er man nødt til at have industrien med også (er man?) - men i mine øjne vil det være en forudsætning for, at man kommer ud af den udemokratiske og småkorrupte udvikling, at det transparente følges op med nedlæggelse af Mørklægningsloven, så offentligheden i det mindste har mulighed for at følge ordentligt med i, hvad man sidder i sådanne organer og foretager sig. I disse tider, hvor de tekniske løsninger til den slags findes i massevis, kunne man måske ligefrem transmittere møder/lægge videoer fra møderne ud på nettet, sådan som man f.eks. gør med regionsrådsmøderne i Region H og i folketinget? Det er faktisk et teknisk fremskridt, jeg sætter pris på, denne mulighed for at se med egne øjne, hvad der foregår - uanset hvor deprimerende det ofte er. Og lukketheden er et af de allerstørste demokratiske problemer i denne udvikling, efter min opfattelse.

Ovennævnte citat giver dog lige et lille gib af bekymring

Jeg er enig. Det er en balancegang. Jeg nævnte bevidst ikke noget om hvor stor en andel af bestyrelsen der er politikere og interessenter fra industrien. Hvilken deling ville du mene var bedst?

Og lukketheden er et af de allerstørste demokratiske problemer i denne udvikling, efter min opfattelse.

Jeg er enig i udgangs punktet at der skal være fuld transparens. Men det behøver ikke at være live, således at vi montere et webcam på hovedet af alle de mennesker der er involveret i offentlig drift og udvikling. Der bør i efter min holdning være krav om fuld dokumentation og en dato for offentliggørelse, således at folk har et rum at bevæge sig i, men samtidig foranstaltning imod korruption ved at det hele bliver offentliggjort på et tidspunkt.

Hvilken deling ville du mene var bedst?

Uha, her giver jeg op, Magnus. Jeg ved det ikke - måske skulle udviklerne være i overtal, da det vel ville mindske risikoen for indspisthed, da de i dagligdagen vel færdes i andre kredse end politikere, administratorer og industri? Bare et gæt - jeg har ikke insiderviden på det felt. Dilemmaet er, at administratorer vel ikke altid har samme interesser, men administrerer hver sit område. Så er der brug for, at mange af dem er repræsenterede, og det bliver et kæmpe organ. Måske skulle administratorer simpelthen ud? De kan sende deres input til rådet, som så må afveje interesserne på bedst mulige måde?

Men for mig er det allervigtigste, at mulighederne for anvendelse af mørklægninglov, og for korridoraftaler (som jeg har nævnt det før: konferencer, middage, rejser) begrænses meget. Det skal ikke være et organ, der giver undskyldning for at rejse rundt i verden og mødes uofficielt uden for det egentlige forum. I mine øjne er det et kæmpe problem, at "magteliten" på denne måde mødes langt uden for de demokratiske organers rækkevidde. Bilderbergmøder i mindre målestok.

det behøver ikke at være live, således at vi montere et webcam på hovedet af alle de mennesker der er involveret i offentlig drift og udvikling

Helt enig - live er godt, men ikke et nødvendigt krav. Det vigtigste er åbenheden, gennemsigtigheden, og bullitproof dokumentation for, hvad der foregår.

Men for mig er det allervigtigste, at mulighederne for anvendelse af mørklægninglov, og for korridoraftaler (som jeg har nævnt det før: konferencer, middage, rejser) begrænses meget.

Hvis standarden ellers overholdes tror jeg at dette kan modvirkes. Men problemet er i virkeligheden at du gerne vil have en verden uden korruption. Det ville jeg også mægtigt gerne... Hvis du har opskriften på den verden er jeg villig til at lytte, men jeg tror bare ikke at den findes.

Gode tanker Magnus. Nogle af dine ideer burde implementeres under alle omstændigheder. Men jeg tror desværre at ville være endnu en lap på en ubrugelig systemisk fejltænkning.

Hvis det skal komme til at virke, er det nødvendigt at det er brugene der igen bliver kunden og at ekspertisen og erfaringsopbygningen forbliver i organisationen.

Uanset hvor mange gode ideer og tanker man har, kommer det ikke til at virke med topstyring og mikromanagement, sålænge beslutningstagerne er hævet over enhver kompetence og reelt ansvar. Det er et ideologisk problem, der ikke kan løses med flere regler og mere politisk styring. Vi må lade dem der sidder med aben, passe den. Hvis de ikke duer til deres job, skal ledelsen ligesom andre steder, selvfølgeligt kunne skifte dem ud. Men vi kan ikke bare presse en privatiseringsmodel ned over et problem det ikke passer til.

Hvis det skal komme til at virke, er det nødvendigt at det er brugene der igen bliver kunden og at ekspertisen og erfaringsopbygningen forbliver i organisationen.

Min standard nævner netop at kunden skal kunne vælge den løsning der passer bedst til deres problem.

Uanset hvor mange gode ideer og tanker man har, kommer det ikke til at virke med topstyring og mikromanagement, sålænge beslutningstagerne er hævet over enhver kompetence og reelt ansvar. Det er et ideologisk problem, der ikke kan løses med flere regler og mere politisk styring.

Nej, men det er også derfor at standarden definerer en overordnet struktur og lader detaljerne være op til den enkelte udbyder. I øvrigt behøver udbyderen ikke at være privat. Det kan være en offentlig instans.

Men problemet er i virkeligheden at du gerne vil have en verden uden korruption

Ja :-)

Det ville jeg også mægtigt gerne... Hvis du har opskriften på den verden er jeg villig til at lytte, men jeg tror bare ikke at den findes.

Nej, det tror jeg heller ikke - magt korrumperer, det er meget menneskeligt, og ikke engang nødvendigvis onde mennesker. De færreste kan nok holde stand, når først de er steget i graderne, og vurderingernes referencepunkter ændre sig.

Men korruption har konsekvenser for samfundet og for andre mennesker, hvis liv kan blive ødelagt af det. Derfor er vi nødt til at blive ved med at bekæmpe det - velvidende, at vi aldrig når i mål. Alternativet er jo et samfund, der ender med at være gennemkorrupt. Jeg må igen henvise til de i mine ører rystende udtalelser af Jens Brøndberg, som higlighter, hvor langt normerne er skredet i de lag af det offentlige system. https://www.computerworld.dk/art/238753/tidligere-indkoebschef-i-dsb-om-...

For mig, som tidligere offentligt ansat, er det ufatteligt, at man for alvor kan være i tvivl om, at grænserne er langt overskredet i de eksempler han nævner som åbenbart hverdagshændelser. Så noget må gøres, og ingen løsninger på kuldsejlede (og overflødige?) projekter vil virke, hvis ikke vi finder løsninger på det problem.

Måske skulle administratorer simpelthen ud? De kan sende deres input til rådet, som så må afveje interesserne på bedst mulige måde?

Der er egentlig ikke tale om et råd, men en bestyrelse. Bestyrelsen arbejde består i at sætte grundlaget for at ansætte folk med de rette kompetencer til at beskrive standarden. Administratorer er vigtige, da det er dem der ender med at drifte løsningen. At sætte dem ud på et sidespor ville skærme standarden fra vigtige input.

Ok, tak for uddybning, Magnus Jørgensen.

Men korruption har konsekvenser for samfundet og for andre mennesker, hvis liv kan blive ødelagt af det. Derfor er vi nødt til at blive ved med at bekæmpe det - velvidende, at vi aldrig når i mål.

Nemlig. Her er jeg helt enig. Vores samfund er bygget op omkring erkendelsen af menneskets begrænsninger. Magtens tredeling og alle de balancer der er skabt i vores regerings type har til formål at hindre korruption og fejltagelser. Det er egentlig det jeg prøver med min DITIS standard. :) Sætte rammen for hvordan vi pragmatisk set kan løse problemet omkring IT udvikling i det offentlige.

Vi er nok ikke særligt uenige, Magnus Jørgensen. Og du har nok mere insiderviden end mig, så jeg bøjer mig for din vurdering.

@Magnus

Mange gode tanker Magnus. Briterne var for 7-10 år siden igennem en omfattende ændring af måden de laver it-projekter på.

De var drevet af en økonomi, der tvang dem til at tænke nyt og de stod på ryggen af en stribe it-skandaler med blandt andet CSC Healthcare til +1 mia £ (hvis jeg husker ret).

Faktum er, at man mere eller mindre tog skeen ud af hånden på de traditionelle mega-leverandører og lavede et fuldstændigt paradigmeskifte. Så vidt jeg er orienteret opnåede man væsentlige resultater på ganske få år ved at skifte til en projektmodel hvor penge og brugeraccept følges ad fra start til slut kombineret med en ændret adfærd som tillod også mindre og mellemstore virksomheder at komme i betragtning.

Der er sikkert nogen der kender endnu mere til hvad de gjorde om OM de fortsat er succesfulde???

@Magnus du skriver:

“Interaktion imellem de forskellige services skal defineres med en åbent defineret protokol.”

Hvis jeg forstår dig ret, så findes det du efterlyser faktisk allerede i form af OIOXML ... en dansk standard for netop interaktion mellem services ...

Udfordringen har vist været at det var en ... dansk standard ... dermed ingen ingen industristandard og ingen native understøttelse i hverken udviklingsmiljøer eller standardprodukter ... jeg har på fornemmelsen at arbejdet med OIOXML er gået i stå for længe siden men må indrømme at jeg ikke har fulgt op på det for nylig

Hvis jeg forstår dig ret, så findes det du efterlyser faktisk allerede i form af OIOXML ... en dansk standard for netop interaktion mellem services ...

Du er nødt til at tage alle punkterne med:

o Standarden har til formål at garantere at enhver leverandør kan tilbyde en løsning og på samme tid garantere at disse løsninger er kompatible med hinanden. Interaktion imellem de forskellige services skal defineres med en åbent defineret protokol. o Standarden må ikke stille krav til en enkelt leverandør eller teknologi der kan udelukke andre leverandører. o Standarden skal være decentral og modulær i det omfang det er muligt, således at flere udbydere kan levere løsninger, og dermed give kunderne en valgfrihed der gør dem i stand til at vælge den bedste løsning til deres problem.

Personligt er jeg mere tilhænger af REST/json.

Mange gode tanker Magnus. Briterne var for 7-10 år siden igennem en omfattende ændring af måden de laver it-projekter på.

Jeg husker fjernt at have hørt om det.... Hvad er deres erfaringer med denne nye tilgang? Kan vi lære noget af den?

Personligt er jeg mere tilhænger af REST/json.

JSON er i min optik ikke svaret. Tag ikke fejl, jeg elsker JSON, men JSON er fortsat skemaløs, selvom der er flere initiativer igang med at ændre på dette.

Et skemaløst dataformat er en mindre optimal løsning, da det flytter definitionen over til den, der implementerer interfacet og dermed kommer du længere væk fra dit ønske om frigørelse fra leverandørerne.

JSON alene mangler også flere andre elementer der konstituerer et domænespecifikt format. Forestil dig, at du gemmer data i json format uden skema i en MongoDB og over årene opdager man at dato formatet bidragsyderne har brugt er forskelligt. Nogen har brugt DDMMYY og andre MMDDY og nogle har brugt GMT, nogle UTC og nogen bare serverens tidsstempel som du ikke kan redegøre for.

Hver af systemerne har haft egen input validering og hvad der ellers skal til, så set lokal er alt i skønneste orden.

Det er først da man udveksler data og lægger dem i en fælles database at problemet opstår ... til gengæld er det pludselig blevet et svært løseligt problem

Man kan også kigge mod Estland, hvor man har en national CIO (i tråd med Kim Østerbyes tanke om at staten i højere grad skal kunne selv) og i lovgivningen har implementeret regler for hvor gamle legacy systemer må blive; at staten ikke må bede borgerne om data den besidder i forvejen og en lang række andre tiltag.

JSON er i min optik ikke svaret. Tag ikke fejl, jeg elsker JSON, men JSON er fortsat skemaløs, selvom der er flere initiativer igang med at ændre på dette.

Læs gerne wikipedia's artikkel om REST: https://en.wikipedia.org/wiki/Representational_state_transfer

Individual resources are identified in requests, for example using URIs in Web-based REST systems. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server may send data from its database as HTML, XML or JSON, none of which is the server's internal representation.

på den måde er hverken OIOXML eller REST i sig selv standarden. Standarden skal selvfølgelig specifikt definere hvordan data representationen er udformet. Jeg er ikke selv bekendt med OIOXML, så denne standard er muligvis helt udemærket til formålet.

Mere specifikt skal standarden overordnet definere hvordan den offentlige danske IT infrastruktur skal se ud. Så det handler ikke kun om data representation, men også design af services.

Her er denne post vigtig: o Standarden skal være decentral og modulær i det omfang det er muligt, således at flere udbydere kan levere løsninger, og dermed give kunderne en valgfrihed der gør dem i stand til at vælge den bedste løsning til deres problem.

@Magnus Jørensen Rigtig Rigtig meget af det du efterlyser eksistere faktisk i dag. Både i form af standard arkitektur, standard løsningsblokke, protokol standarder m.m.

Vi kan diskutere om, det er der hvor det burde være.. om der er tilstrækkelig 'buyin' fra alle interessenter, ikke mindst industrien.

Problemet er bare at man f.eks. startede forfra kommunalt da man solgte KMD. Det efterlod et HUL af dimensioner i den offentlige IT, hvor man først nu så småt ... 10 ÅR EFTER og mange milliarder kroner.. er ved at være der, hvor man kan se enden på 'monopolbrudet'. Altså man har haft 10 år, hvor hovedfokus på det kommunale område (Som er det største offentlige IT område) har været at komme sig over salget af KMD.

Og i den sammenhæng så husk på at 'De gamle Grønne systemer', som Sundhedsplatformen erstatter også er de gamle KMD udviklede 'sygehus systemer'.

Og så kan vi snakke om salget af statens datacentralen til CSC bagefter.

Så en politisk beslutning om at nedlægge relativt velfungerede 'stærke faglige' organisationer har defacto på mange områder bremset den offentlige IT udvikling. Og fjernet koncentrationer af offentlige IT viden, som man så har måtte opbygge igen både centralt og decentralt.

IMHO så er rootcause (og min ærede kollega Rasmus synes jeg strækker den lige hårdt nok, ved at bruge ordet rootcause, for han siger, at det er der ikke evidens for at bruge den term. Og han har en pointe, men jeg gør det nu alligevel) at man tager politiske beslutninger, der ikke er funderet i virkelighedens verden, fordi man ikke forstår fagligheden. Beslutninger som så et 'vi gør hvad der bliver sagt' embedsværk (med kulturelle rødder i enevælden), der heller ikke forstår fagligheden, forsøger at føre ud i livet, efter bedste formåen.

Og det er ikke kun på IT området vi ser det her... se f.eks. IC4 skandalen, eller indkøb af militær isenkram.

// Jesper

Man kan også kigge mod Estland, hvor man har en national CIO (i tråd med Kim Østerbyes tanke om at staten i højere grad skal kunne selv) og i lovgivningen har implementeret regler for hvor gamle legacy systemer må blive; at staten ikke må bede borgerne om data den besidder i forvejen og en lang række andre tiltag.

Der findes masser af eksempler på BDFL (Benevolent Dictator For Life) strukture, i IT verdenen, hvor en enkelt person holder alle trådene. Linux og Python er gode eksempler hvor det virker. Men det man skal huske på er hvor sjældne de er, og hvor mange "failed regimes" der er. At have et centralt overhovede kan virke, men man skal huske på at folk har tilvalgt Linus og Guido. Begge projekter er open source projekter hvor folk altid har kunne forke hvis diktatoren blev sindsyg og begyndte en masse udrydelse. Dette er grunden til at min DITIS standard er styret af en blanding af folkevalgte, industrien og håndværkerene.

Man kan med fordel læse kapitlerne om Government as a Platform i O'Reilly bogen om Open Government. (http://shop.oreilly.com/product/9780596804367.do) Det er bla. der tankerne bag de ting man har lavet i UK og formodentlig også i Estland, har sine rødder. @Magnus Jørgensen

Mere specifikt skal standarden overordnet definere hvordan den offentlige danske IT infrastruktur skal se ud. Så det handler ikke kun om data representation, men også design af services.

Igen så arbejdes der på disse ting, vi kan snakke om det gøres rigtigt.. om det er sker de rigtige steder.. om kvaliteten.. om om om om .. men det kræver at man deltager. Hvis du har input så er det bare at gå i gang, man plejer at tager imod review og konstruktiv input. Og jeg skal ikke kaste med sten i den forbindelse, for jeg har en trackrecord af at bo i glashus :)

// Jesper

Rigtig Rigtig meget af det du efterlyser eksistere faktisk i dag. Både i form af standard arkitektur, standard løsningsblokke, protokol standarder m.m.

Er du så enig i min DITIS standard? Hvis ikke... Har du så nogle bud på forbedringer?

Problemet er bare at man f.eks. startede forfra kommunalt da man solgte KMD. Det efterlod et HUL af dimensioner i den offentlige IT, hvor man først nu så småt ... 10 ÅR EFTER og mange milliarder kroner.. er ved at være der, hvor man kan se enden på 'monopolbrudet'. Altså man har haft 10 år, hvor hovedfokus på det kommunale område (Som er det største offentlige IT område) har været at komme sig over salget af KMD.

Og i den sammenhæng så husk på at 'De gamle Grønne systemer', som Sundhedsplatformen erstatter også er de gamle KMD udviklede 'sygehus systemer'.

Mht. at rive gamle systemer ned, så er jeg klog af skade. Der er lagt mange flere tanker i de gamle "legacy" systemer, som man ikke er klar over, hvis man starter forfra. Hvilket er grunden til at jeg understreger det med at produkt udvikling er en iterativ process der bygger på det eksisterende. Vi står på skuldrene af kæmper.

Vores moderne computere bygger på principper fra 70'erne og meget af den 'kode' er ikke blevet gammel. Noget er skiftet ud, men det meste er tilbygning.

IMHO så er rootcause (...) at man tager politiske beslutninger, der ikke er funderet i virkelighedens verden, fordi man ikke forstår fagligheden.

Jamen, der er vi helt enige. Politikere bør endda være et groft udsnit af befolkningen, selvom der desværre er meget få IT folk i folketinget, regionerne og kommunerne. Der skal også være plads til at de tager fejl og gør noget dumt...... Det vigtige er bare at fejltagelserne bliver anerkendt, således at de kan omgøres. Her er problemet at der ikke rigtigt er en opposition, for IT folk vælger normalt ikke at blive politikere. På den måde kan man jo sige at pilen også peger på os.

Det var nemt at blive forarget over Trine Bramsens indlæg, men der er muligvis en pointe i noget af det hun sagde. Der er ikke ret mange af os der stiller op til valg og taler et sprog som alle kan forstå. Hvis bare nogle få af os deltog i folkestyret kunne nogle af disse ting muligvis undgås?

Personligt er jeg mere tilhænger af REST/json.

En typisk kommentar fra folk, der ikke ved, hvad de snakker om. Den fornødne sikkerhed kan aldrig indopereres i en REST/json struktur, og det er også årsagen til, at man ikke anvender denne. Du kommer ikke udenom SOAP, hvis du vil lave systemer, hvor sikkerheden har et højt nok niveau.

Hvis man ønsker, at sikkerheden skal være i bund, så er REST/json vejen frem. Der kan man lave man-in-the-middle attacks og gud ved ikke hvad. Rent slaraffenland for ondsindede hackere.

Er du så enig i min DITIS standard? Hvis ikke... Har du så nogle bud på forbedringer?

Ja og Nej. Igen så eksisterer mange af tingene jo i dag. Vi kan så diskutere, hvor godt det er implementeret, og hvem der er repræsenteret i de eksisterende 'organer' etc. etc. Du skal huske på, at der er rigtig mange aktører og interessenter i det her. På mange forskellige niveauer. Vi har .. Alle øvrige ministerier, Kommunernes landsforening, regionerne, kommunerne, KOMBIT, Digitaliserings styrelsen, Statens IT, EU, FN, NGO'er og så de private og semiprivate aktører.

Det der mangler er en klar entydig offentlige Enterprise Arkitektur, der giver plads og indflydelse for relevante interessenter og aktører på de dele af den offentlige EA, hvor det er relevant. Og en organisatorisk del af EA'en, der er afkoblet fra politisk fnidder fnadder, og med kompetent ledelse der forstår/respekterer IT nok til, at den organisatoriske del faktisk har midler og ikke mindstmandat til at rykke noget.

Problemet er, at der går politik (både politisk politik, og office politics i tingene), og sådan noget resulterer i flere organer der har samme funktion, magtkampe og kompromiser med super laveste fællesnævner, når der så endelig vedtages noget.

Så IMHO er din model alt alt for forsimplet, tingene er rigtig meget mere komplekse, og vil derfor kræve en mere kompleks løsning for at virke. Igen IMHO.

// Jesper // Jesper

En typisk kommentar fra folk, der ikke ved, hvad de snakker om. Den fornødne sikkerhed kan aldrig indopereres i en REST/json struktur, og det er også årsagen til, at man ikke anvender denne. Du kommer ikke udenom SOAP, hvis du vil lave systemer, hvor sikkerheden har et højt nok niveau.

Denne påstand bliver du simpelthen nødt til at dokumentere.

Hvis man ønsker, at sikkerheden skal være i bund, så er REST/json vejen frem. Der kan man lave man-in-the-middle attacks og gud ved ikke hvad. Rent slaraffenland for ondsindede hackere.

Denne påstand er du simpelthen også nødt til at dokumentere.

Så IMHO er din model alt alt for forsimplet, tingene er rigtig meget mere komplekse, og vil derfor kræve en mere kompleks løsning for at virke. Igen IMHO.

// Jesper

Grundloven er også meget simpel, men det betyder jo ikke at vi ikke kan bygge et komplekst system oven på den. Simple fundamenter er tit en fordel. Kan du ikke nævne en specifik ting ved min DITIS standard du er uenig i?

Hvis bare nogle få af os deltog i folkestyret kunne nogle af disse ting muligvis undgås?

Politik er (heldigvis) meget andet end IT.

Men desværre er synspunktet et eksempel på hovedreglen om, at folk som har dyb viden indenfor deres område, som oftest tager selvtilliden med sig over på andre områder, hvorefter det udarter sig til dum-stædig bodegasnak.

Det gælder både for ingeniører, jurister, læger, økonomer og IT-folk (herunder enterprise-arkitekter) - humanister, samfundsfaglige, ufaglærte, faglærte og naturvidenskabelige - selvstændige, lønmodtagere, offentlige, private - alle har en rem af huden.

Misforstå mig ikke, jeg har stor respekt for alle, når de bruger deres faglighed, og mange af nyere tids ulykker kan føres tilbage til at man ikke bare vil have lov til at have egne synspunkter, men også til have egne fakta ved at selv at vælge "eksperter" - man spørger simpelthen til man får det svar, som passer en. Folk med relevante og velunderbyggede indvendinger afvises som brokkehoveder, nej-sigere, reaktionære, romantikere, sølvpapirshatte eller bare "fake news".

Og ja, der er brug for mere IT-viden. Men der er også brug for så megen anden viden fra mange andre fagområder, for i dagens politiske virkelighed trumfer tro altid viden, og inhabilitet virker til at være selvstændigt kvalificerende ('jeg satser hele mit liv og udkomme på det, så derfor må jeg være særdeles kvalificeret!').

Og IT folk er flest, som folk er flest. De er derfor i almindelighed ikke særligt kvalificerede til politik, og vil som udgangspunkt ikke være særskilt kvalificerede som politikere.

Der vil selvfølgelig være undtagelser, og vi skal i almindelighed endelig ikke sidde på vores viden eller indsigt, hvor den er relevant.

Men bare at mene af 'verden ville være meget bedre, hvis bare der var flere fra mit fagområde i politik' er meget udbredt, og generelt forkert. Også for IT-folk.

Men desværre er synspunktet et eksempel på hovedreglen om, at folk som har dyb viden indenfor deres område, som oftest tager selvtilliden med sig over på andre områder, hvorefter det udarter sig til dum-stædig bodegasnak.

mjaaaa. Vores folketing er f.eks. domineret af Lærere, Journalister, jurister og folk med kandidat i statskundskab og administration. Så vidt jeg kan se af https://www.altinget.dk/artikel/her-er-de-179-medlemmer-af-det-nye-folke... er der ikke en eneste person der har uddannelse i eller arbejdet med IT udvikling eller drift. Jens Henrik Thulesen Dahl har arbejdet som ingeniør, men det er vist det tætteste vi kommer.

Hvor mange af dem roder sig ud i bodegasnak og hvorfor skulle de være bedre kvalificerede?

Hvor mange af dem roder sig ud i bodegasnak og hvorfor skulle de være bedre kvalificerede?

Nu er jeg meget lidt imponeret af vores nuværende nationale politikere (og i særdeleshed med dem, som selvdeklarerer som 'regeringsbærende'), men det mener jeg har mindre med deres uddannelse (eller mangel på samme!) at gøre, og langt mere mere med overdreven tillid til egne evner og deraf følgende forkærlighed for at mene fremfor at lytte - og en tilsvarende tendens til at lytte til dem, som bekræfter førnævnte mening, fremfor til dem som udfordrer den.

Derfor mener jeg ikke, at det giver mening at forlange flere af egen faglighed på tinge - problemerne starter IMHO et helt andet sted: vi har brug for folk, som er bedre til at lytte end til at mene.

vi har brug for folk, som er bedre til at lytte end til at mene.

Det vil jeg give dig ret i. Det er altid godt at lytte. Det kunne muligvis også gøre at flere politikere oftere er tilstede i folketingssalen.

vi har brug for folk, som er bedre til at lytte end til at mene.

Lige præcis. Egentlig er politikere jo til for at mene noget, hvilket kan være ganske relevant. Men at mene har sine begrænsninger. Noget kan/skal måles og evt. beregnes. Og hvis et beregningsgrundlag hænger på noget, der "menes", så skal det være fremhævet med store typer, så man ikke forveksler en mening, med fakta.

@Gert @Magnus ... fine synspunkter I giver udtryk for.

Kan I mon lokkes til at fokusere debatten på det oprindelige tema i Kim Østerbys artikel?

Kan I mon lokkes til at fokusere debatten på det oprindelige tema i Kim Østerbys artikel?

Mit bidrag til debatten er min DITIS standard som fremgangsmåde til at udvikle IT i det offentlige. Med denne standard mener jeg at vi har større mulighed for at ramme rigtigt.

Iterativ IT-udvikling i små trin er vejen frem. Og brugerne godkender hvert trin. Sådan forstår jeg Magnus Jørgensen's og briternes nye måde at udvikle offentlig It. Det betyder, at problemet er i fokus. Desværre er det de færreste ledere såvel offetnlig som private, der har forstået at IT-udvikling ikke er at bygge en bro. Fundamentet for IT er kompetent forståelse af forretningsprocesserne. Processer og arbejdsgange der netop forandres ved IT-løsningen og med tiden og politikernes nye love. Så små trin der giver besparelser, når de lykkes, og koster minimalt, når de fejler.

jeg har fulgt debatten om emnet i længere tid og jeg ser at flere er inde på de områderjeg også ser som problem-skabere.

offentlig licitation: reglerne gør det umuligt for små og mellemstore udviklere at byde ind. der kan vi miste nytænkning da det er de færreste små startups der har en økonomi ogorganisation der gør det muligt at byde ind.

store komplekse projekter: som det offentlige ikke selv har overblik over (var det 400 forskellige typer gæld der er i EFI?). det skal brydes ned.

standard virker: det er også tit man ser det offentlige vælge et standard system der så skal tilpasses. tit vælges bare standarder der bygger på lovgivning fra USA som ikke helt passer ind her. Sundhedsplatformen virker mere som et system der skal dokumentere hospitalers fakturaer til forsikringsselskaber og ikke understøtte sygehuspersonale og få patienter hurtigere igennem.

jeg har skrevet lidt mere om det her (det er mit bud på en statslig IT strategi) https://helenepigen.blogspot.com/2017/06/debatten-om-borgernes-data-cens...

Det er nok værd at flytte fokus fra konkret problemløsning og diverse gode modeller, til at undersøge hvad de virkelige problemer er.

Det er spild af tid at løse problemer, hvis det ikke er de rigtige problemer man løser. Jeg overbevist om at der er dygtige embedsmænd der har ekspertisen og brugernærheden, til at løse praktiske problemer. Ellers kan de nok ansættes.

Dette er et strukturelt og politisk problem, der ikke løses med mere eller bedre kode :)

Denne påstand bliver du simpelthen nødt til at dokumentere.

Du vil have mig til at dokumentere noget, som er en de facto standard indenfor alle større enterprise projekter?

Du får ganske enkelt mere sikkerhed givet gennem SOAP, fx via WS-Security - https://en.wikipedia.org/wiki/WS-Security . Det er det man har i OIOSAML og som du aldrig ville kunne implementere på en lignende måde i REST/json.

Du vil have mig til at dokumentere noget, som er en de facto standard indenfor alle større enterprise projekter?

Du får ganske enkelt mere sikkerhed givet gennem SOAP, fx via WS-Security - https://en.wikipedia.org/wiki/WS-Security . Det er det man har i OIOSAML og som du aldrig ville kunne implementere på en lignende måde i REST/json.

Kan du forklare mig hvorfor man ikke kan implementere en hvilken som helst Autentifikation mekanisme over TLS til en REST service?

Det ville jeg nemlig mene at man skulle kunne. I princippet burde du kunne implementere kerberos eller NTLM til en REST service, hvis du altså virkelig vil gå the Enterprise way. Det mener jeg faktisk at Sharepoint supporter out of the box. Hvis du så ikke har fået nok Enterprise Buzzzz så ville jeg mene at Apache har en java implementering... http://cxf.apache.org/docs/jaxrs-kerberos.html

Så skulle du nærmest ikke kunne gøre det mere Enterprisy sikkert.

Kan du forklare mig hvorfor man ikke kan implementere en hvilken som helst Autentifikation mekanisme over TLS til en REST service?

Det kan man sikkert også, men autentifikation er blot en af de ting, som er vigtige i end-to-end security. Hvis dit setup involverer proxies - og det gør det tit i en enterprise situation - så har du behov for sikre dig, at sikkerheden er intakt på den proxy, som beskeden transporteres igennem. Hvordan vil du gøre det, med TLS og REST?

Hvordan sikrer du dig, at en patientjournal besked fra A til B, via proxy C ikke kan aflæses på proxy C ved brug af TLS og REST? Hvordan ville du, som en ondsindet bruger med fuld kontrol over proxy C kunne tænke dig, at afkode beskederne fra A til B? Det er ikke svært hvis det kun er TLS der er i brug, fordi du kan ret hurtigt deducere dig frem til formater på beskederne ved at sende fup-beskeder fra proxy C til B.

Derfor bruger man SOAP. REST og TLS er fint til en webshop der sælger gøgl og pis. Det duer ikke til enterpriseløsninger. Sådan lidt firkantet sat op ...

Hvordan sikrer du dig, at en patientjournal besked fra A til B, via proxy C ikke kan aflæses på proxy C ved brug af TLS og REST? Hvordan ville du, som en ondsindet bruger med fuld kontrol over proxy C kunne tænke dig, at afkode beskederne fra A til B? Det er ikke svært hvis det kun er TLS der er i brug, fordi du kan ret hurtigt deducere dig frem til formater på beskederne ved at sende fup-beskeder fra proxy C til B.

Den eneste måde du kan lave et man in the middle angreb på TLS er hvis du installerer CA certificater fra proxy C serveren på din client A. Hvis du her rettigheder til at installere CA certificater på client maskinen, så kan du jo installere hvad som helst. En keylogger og en screen caster osv.... Så er din Sikre SOAP service jo ikke meget bevendt.

Derfor bruger man SOAP. REST og TLS er fint til en webshop der sælger gøgl og pis. Det duer ikke til enterpriseløsninger. Sådan lidt firkantet sat op ...

Det er det værste BS jeg længe har læst på V2

Jeg havde et møde for godt 1 mnd siden med en meget stor US baseret IT leverandør. På et tidspunkt var der en af mine kollegaer der nævnte Web Services (som i SOAP) , hvorefter leverandørens folk blev underlig stille og sendte vilde blikke rundt i rummet - SOAP, det var ikke noget man rigtig brugte mere - idag er alle API'er REST/JSON baseret.

Sikkerhedsargumenterne du fremfører er ren vrøvl - både SOAP og REST er baseret på HTTP(S) protokollen og angrebsmetoder og forsvarsmekanismerne er ret ens f.eks. ved forsvar mod MIM angreb.

Den store forskel, jeg har oplevet i praksis er, at SOAP endpoints er pænt besværlige at integrerer mod - arbejdet kan tit måles i uger, medens REST endpoints normalt kan konsumeres på timer eller mindre.

Moderne API baserede letvægts arkitekturer f.eks. Microservice Arkitekturer er ofte baseret på REST. De fleste Cloud Services kan nås gennem et REST API etc. - AWS udfasede deres EC2 SOAP tilbage i '15.

At påstå at SOAP er mere enterprisevenlig er noget vrøvl, med mindre timeantallet pr. integrationspunkt er en målestok for om noget er enterprisevenlig.

ikke noget med at låse sig til bestemte teknologier. det sikreste i dag er helt sikkert ikke lige så sikkert i morgen og i overmorgen er det usikkert.

alle sprog er heller ikke lige velegnede til alt.

og med containere og virtualisering burde det faktisk være muligt at komme ud over at der skal bruges et bestemt OS til alt. vælg den hurtigste database (hvis det er parametret) eller den der håndterer den største mængde data eller den billigste i drift. det dårligste argument er da "at sådan har vi altid gjort og det har vi altid brugt".

Jeg havde et møde for godt 1 mnd siden med en meget stor US baseret IT leverandør. På et tidspunkt var der en af mine kollegaer der nævnte Web Services (som i SOAP) , hvorefter leverandørens folk blev underlig stille og sendte vilde blikke rundt i rummet - SOAP, det var ikke noget man rigtig brugte mere - idag er alle API'er REST/JSON baseret.

Jamen, glimrende! Kan du så ikke bare give ET enkelt eksempel på en enterprise arkitektur, som bygger på REST/JSON? Kun ét enkelt eksempel er nok.

Kan du så ikke bare give ET enkelt eksempel på en enterprise arkitektur, som bygger på REST/JSON? Kun ét enkelt eksempel er nok.

Jeg synes desværre, at debatten på det seneste har fået en lidt kedelig klang af mundhuggeri og det synes jeg er trist.

Microsoft og flere andre udstiller mange af deres services via REST endpoints og udveksler data i enten JSON eller XML (se eks.: https://docs.microsoft.com/da-dk/rest/api/) og jeg tænker, at de har nogenlunde styr på sikkerheden i den forbindelse.

Min egen anke mod JSON er alene det manglende skema, der kan gøre det udfordrede (men ikke umuligt) at samarbejde på tværs af systemer med forskellige repræsentationer af datatyper. Særligt over tid og/eller med begrænset central governance.

JSON tilbyder en enkelhed, som er betagende. Det er, som skrevet i et indlæg fra en anden, lynhurtigt og nemt at arbejde med. I en del situationer kommer denne lethed og forenkling så med en pris på den lange bane. En pris, der ofte langt overstiger den initiale besparelse. Ikke blot i penge, men i særdeleshed i robusthed og governance.

Derfor foretrækker jeg oftest dataformater, der kan tilbyde følgende:

1) Data om data, altså metadata 2) Styring af datatyper 3) Mulighed for at definere et domænespecifikt format, fx entiteter, relationer imellem entiteter, antal repræsentationer af en given entitet mv.

Dermed bliver dataformatet styrende og ikke endpointet, hvilket øger robustheden, særligt over tid og over sprog/landegrænser.

JSON ser pt. ud til at udvikle sig i den retning. Tidligt med AVICII schema og nu med http://json-schema.org/specification.html

Min egen anke mod JSON er alene det manglende skema, der kan gøre det udfordrede (men ikke umuligt) at samarbejde på tværs af systemer med forskellige repræsentationer af datatyper. Særligt over tid og/eller med begrænset central governance.

Har du nogle eksempler på hvor et skema løst data format har skabt problemer for en REST service?

Jeg vil da give dig ret i at det lægger et større pres på udvikleren fordi vedkommende skal lave data validering.

Jamen, glimrende! Kan du så ikke bare give ET enkelt eksempel på en enterprise arkitektur, som bygger på REST/JSON? Kun ét enkelt eksempel er nok.

Microsoft Sharepoint.

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/complete-basi...

Så små trin der giver besparelser, når de lykkes, og koster minimalt, når de fejler.

Hej Jan,

Det er jo svært at være uenig i. :) Problemet er hvordan vi reformerer systemet. Vi skal have overtalt nogle djøffer og nogle politikere. Vi kunne muligvis lave en Video der forklarer det.

Min egen anke mod JSON er alene det manglende skema, der kan gøre det udfordrede (men ikke umuligt) at samarbejde på tværs af systemer med forskellige repræsentationer af datatyper. Særligt over tid og/eller med begrænset central governance.

Tjo.

Det kan bruges til at beskrive en syntaks, men det er langt fra altid, at semantikken kommer med.

Jeg har set mere end et schema, hvor datatypen var "any", da det begyndte at være andet end ceremoni. Som hovedregel er felter af typen "string" uden at der er taget stilling til længde (hvad er en pest, hvis data skal i en relationel database), og samlinger er ofte uden øvre kardinalitet.

Et af de mere spøjse eksempler, som jeg har set, var en besked om at slette, som krævede en "reason", som skulle være en string. Nærmere var det ikke beskrevet. Det viste sig så, at der var tale om en streng-repræsentation af cifrene i et tal fra 0 til 10 (inklusive), dog ikke 7, og at der findes en fin standard, som beskriver dette.

Som hovedregel har schema-validering været slået fra i produktion af "performance-hensyn" og fordi "systemer er testet" - i udvikling fordi valideringsfejl opfattes som uforståelige, eller slet ikke logges.

Der kan så også være andre grunde til at validering er slået fra: i en integration, hvor skemaet sagde kaldet A gav et svar af typen b. Det skulle så bruges i kaldet B, som så ville svare c. Det var der gode, teoretisk funderede grunde til. Problemet var bare, at i produktion fik vi af og til schemavalideringsfejl om, at svaret på A ikke var en b. Punktum. Kunden var ikke til at hverken hugge eller stikke i, det måtte være en fejl hos os, for det andet system havde kørt i årevis uden fejl, og det havde også andre integrationer, og de virkede jo fint. Så opdager vi, at det altid er en valid c, og ikke en b, som vi får, når vi fejler. Det viste sig at være en 'optimering' foretaget for mange år siden, som ikke var dokumenteret, men som vi selvfølgelig skulle understøtte. Og man kunne ikke se nogen grund til at opdatere schemaet, for så skulle legacy enterprise mainframe systemet jo også opdateres, og det er dyrt! Og i øvrigt havde det kørt i mange år uden fejl og uden at skulle opdateres.

Så jo, schema kan bruges, og jeg har da også selv skrevet nogle stykker, men i praksis holder de sjældent helt, hvad der loves i teorien. De er et godt udgangspunkt for den videre diskussion, men de ender tit med at beskrive, hvordan tingene var engang, og der efterlades ofte vigtige detaljer ubeskrevet. Hvis noget kan forstås på flere måder, så bliver det forstået på flere måder, og så vil alle henvise til at deres særlige forståelse er 'schema-valid'.

Derimod har jeg med stor fornøjelse brugt swagger/openapi beskrivelser af REST/JSON APIer. Det er fantastisk, når dokumentationen er levende - senest udforskede jeg APIet på en kørende Nexus server uden at skulle skrive så meget som en linjes kode, og det gav en indsigt, som formelt set fremgik af den statiske dokumentation, men i hvertfald ikke var indlysende.

Så jo, aftaler og gensidig forståelse er vigtig, og schema er et nyttigt værktøj at have. Men i praksis står og falder verden ikke med det.

PS: ...og der bør reserveres en særlig plads i helvede til alle dem, som laver schemaer uden at tænke på versionering!

Et af de mere spøjse eksempler, som jeg har set, var en besked om at slette, som krævede en "reason", som skulle være en string. Nærmere var det ikke beskrevet. Det viste sig så, at der var tale om en streng-repræsentation af cifrene i et tal fra 0 til 10 (inklusive), dog ikke 7, og at der findes en fin standard, som beskriver dette.

Det er en rigtig god pointe. Sagt lidt groft så leverer det ikke nødvendigvis det lovede, derudover vil jeg pointere at man blot flytter data valideringen fra koden til datastrukturen. Så egentlig synes jeg ikke du har vundet så meget.

@Magnus @Joakim ... i jeres diskussionen om REST vs. SOAP (ws*security) tror jeg, at I snakkede lidt forbi hinanden.

Når man benytter HTTPS/TLS så sørger protokollen for at etablere en sikker tunnel som payload (data) kan flyde igennem. Hvad der flyder igennem og hvordan det er struktureret, blander protokollen sig ikke i.

Man kan derfor gennem tunnellen kalde et REST endpoint eller et HTML endpoint eller for den sags skyld et SOAP endpoint ... uanset hvad, så antager vi, at det, der flyder gennem tunnellen, er sikkert.

HTTPS/TLS kan vi derfor definere som ‘en sikker tunnel’ som noget (data) kan flyde gennem.

REST standarden tilbyder ikke yderligere sikkerhedsfeatures, men det gør SOAP i kombination med ws*security. Sidstnævnte tilbyder blandt andet, at du kan kryptere din payload, uden at du behøver kryptere dine metadata.

I billedsprog så svarer det til, at du med REST sender et postkort. Du stoler på, at postvæsenet sikrer, at ingen uden for etaten kan se, hvad der er i postsækken, som du derfor betragter som en sikker kanal. Men postbudet kan faktisk læse med på kortet undervejs og det nytter ikke at skrive “Du må ikke læse det” på kortet.

Med SOAP/WS* putter du dit postkort ned i en kuvert, som du lukker, og udenpå kuverten skriver du hvem, der skal modtage kortet og hvem der var afsender og du kan ovenikøbet også skrive din Public key.

Du sender det med det samme postvæsen (HTTPS), men nu kan postbudet ikke længere læse dit postkort.

Der hvor postbudet smider kuverten og postkort ind gennem din brevsprække (der hvor din HTTPS tunnel slutter), der ligger postkortet nu og kan læses af alle der kommer forbi, mens indholdet i kuverten fortsat er skjult, indtil ham med private key’en kommer forbi og læser brevet, der var addresseret til ham.

Det er også muligt, at sende kuverten uåbnet videre til et andet land og dermed med et andet postvæsen (en anden HTTPS tunnel) og igen gælder, at kun den rette modtager kan læse indholdet.

SOAP/WS* tilbyder derfor et ekstra lag af sikkerhed som ikke er bundet til transportkanalen, noget som REST ikke gør.

SOAP og REST er, groft forenklet, på samme niveau og det er derfor /WS* man skal bide mærke i, det er dér forskellen ligger, når vi snakker sikkerhed.

I mange anvendelsessituationer er der ikke behov for /WS* og så er REST ofte hurtigere og nemmere at arbejde med end SOAP/WSDL (når man ikke har brug for et skema).

Jeg håber, at ovenstående forklaring kaster lidt lys over land og måske kan være med til at rette et par misforståelser ud.

God søndag

Har du nogle eksempler på hvor et skema løst data format har skabt problemer for en REST service?

REST er en interface standard, altså en måde at etablere kommunikation mellem to eller flere endpoints.

Standarden definerer ikke formatet af payload. Det afgøres i http headeren, fx application/json. Altså af en anden standard.

Retorisk må jeg derfor svare nej til dit spørgsmål eftersom de to ting strengt taget ikke har noget med hinanden at gøre.

Retorisk må jeg derfor svare nej til dit spørgsmål eftersom de to ting strengt taget ikke har noget med hinanden at gøre.

Udmærket. Jeg ænser en form for klandring af Min og Joakims debat hvilken jeg medgiver er åbentlyst irrelevant for emnet. Så jeg vil gerne pointere at du selv har startet præcist den samme form for debat om OIOXML og JSON uden at kigge på min oprindelige pointe (som netop er i fokus på det oprindelige emne). Så jeg vil spørge lidt direkte.. Er der noget i mit DITIS standard oplæg du er uenig i?

REST standarden tilbyder ikke yderligere sikkerhedsfeatures

REST er ikke en standard men en række de-facto konventioner, som muliggør en ret genial og meget letvægts måde at udveksle data, kalde funktioner osv. gennem HTPP protokollen. Konventionelt udveksles data som XML eller JSON men JSON foretrækkes normalt af en række praktiske grunde.

Nogle REST services anvender OAuth2. Se f.eks. https://www.rfc-editor.org/rfc/rfc7519.txt eller en forklaring her https://medium.com/scalable/an-oauth2-grant-selection-decision-tree-for-....

En del gider ikke bøvle med OAuth2 eller kræve at deres kunder gør det, så et typisk pattern for REST services er at bruge en https tunnel kombineret med en unik API token enten i header eller som en del af kaldet: https://my_super_api_endpoint/orders/?api_token=42.

Swagger, som er nævnt tidligere, anvendes af flere og flere til at dokumenterer deres REST endpoints, men fantasien er stor og jeg medgiver at man godt kan finde kommercielle REST endpoints med en endog meget vanskelig tilgængelig dokumentation men reglen er at dokumentationen er god og at der bl.a. tilbydes mulighed for at mappe egne callbacks.

Nå - ud af male kvistvinduer ...

Go søndag osse herfra

Er du så enig i min DITIS standard? Hvis ikke... Har du så nogle bud på forbedringer?

Det problem du prøver at løse er organisatorisk ekstremt komplekst, der er enormt mange interessenter og stakeholders.

Det problem der (igen IMHO) skal løses er, at der er brug for en definition beskrivelse og styring af Enterprise Arkitektur'en for det 'offentlige'. Og det er en ekstrem kompleks opgave, som ikke kan løses af et uafhængigt organ med lidt politikere, erhvervsfolk og lidt 'teknikere'. Det kræver, at man fra central side tager problematikken.. eller kald det fagligheden alvorligt. Man skal indse, at man ikke kan løse 'det offentliges' IT-projekt problemet med en AC værktøjskasse. Det kræver, at man lytter til fagligheden og acceptere, at løsningerne skal kommer derfra. Altså man må uddelegere, det at komme med løsningerne til folk der har forstand på det.

Og det er der jo ikke rigtig en kultur for i toppen, hvor politikere rutinemæssigt benægter videnskabelig fakta, fordi de tror de kan score stemmer på dette.

// Jesper

Det problem du prøver at løse er organisatorisk ekstremt komplekst, der er enormt mange interessenter og stakeholders.

Det problem der (igen IMHO) skal løses er, at der er brug for en definition beskrivelse og styring af Enterprise Arkitektur'en for det 'offentlige'. Og det er en ekstrem kompleks opgave, som ikke kan løses af et uafhængigt organ med lidt politikere, erhvervsfolk og lidt 'teknikere'.

Hvis du nu havde læst min oplæg ordentligt ville du måske have bemærket at disse folk du referere til er bestyrelsen, og ikke selve den arbejdsgruppe der skal definere standarden.

Jeg er ikke helt enig med dig i at det ikke skulle kunne lade sig gøre. Du siger at mit koncept er for simpelt til en alt for kompleks opgave. Nuvel, hvordan ville du mene at det bedst løses? Kan vi gøre mit koncept mere avanceret således at de kompleksiteter du refererer til kunne imødegås? Mit spørgsmål er måske mere... Kan du være lidt mere konkret?

Er der noget i mit DITIS standard oplæg du er uenig i?

Ja, stort set det hele. Jeg er langt hen ad vejen enig Jesper.

Udfordringen er i mine øjne ikke den tekniske infrastruktur men primært forretningens evne til at forstå, beskrive og overholde egne processer i kombination med en for ringe brugerinddragelse.

Udfordringen er i mine øjne ikke den tekniske infrastruktur men primært forretningens evne til at forstå, beskrive og overholde egne processer i kombination med en for ringe brugerinddragelse.

Mit oplæg havde til formål at løse den problem stilling uden at have et monopol. På den måde ville jeg have en infrastruktur med et minimum af fællesnævner der gør det muligt at flere kan byde på opgaven, uden at vi ville få den fragmentering der historisk har gjort det svært for de enkelte IT løsninger at snakke sammen. Dermed kan hospitaler og lægehuse vælge den bedste løsning, eller den løsning der passer dem bedst.

Jeg har ingen problemer med kritik af min ide. Men bare at afvise den fordi den er for simpel, det er jo ikke særligt produktivt. Fair nok. Jeg har givet mit besyv.

Hvis du nu havde læst min oplæg ordentligt ville du måske have bemærket at disse folk du referere til er bestyrelsen, og ikke selve den arbejdsgruppe der skal definere standarden.

Det læste jeg godt. Måske udtrykte jeg mig ikke klart nok. Jeg tror ikke på din konstruktion. Du løser ikke problemet beskrevet i artiklen, ved at lave et uafhængigt organ, der skal lave en 'teknisk løsning' i form af en standard platform, med standard integration.

Igen så eksisterer nogle af disse standarder og platforme til dels i dag. På Integrations området f.eks. OIOXML som Henrik nævnte eller OIOSAML, men der er også integrationer på et højere plan (forretningsmæssigt) som f.eks. OIOUBL (faktura). Ud over det er der offentlige standard platforme, der stille services tilrådighed for 'det offentlige'. Se f.eks. serviceplatformen og støttesystemerne (på kommunalt niveau). https://www.kombit.dk/mere-om-sts https://www.kombit.dk/serviceplatform

Desuden er forretningen 'det offentlige' nok den videste 'forretning' der fås. Den strækker sig fra vugge til grav. Omhandler alt fra Krig til Fred. Desuden består det offentlige af mange lag. FN,EU,Staten,Regionerne og det kommunale. Og at lave en standard.. en platform der dækker det hele i et organ..er ja........

Jeg er ikke helt enig med dig i at det ikke skulle kunne lade sig gøre. Du siger at mit koncept er for simpelt til en alt for kompleks opgave. Nuvel, hvordan ville du mene at det bedst løses? Kan vi gøre mit koncept mere avanceret således at de kompleksiteter du refererer til kunne imødegås? Mit spørgsmål er måske mere... Kan du være lidt mere konkret?

Igen hvis vi ser på nogle af de projekter, som der er lidt konsensus her på v2, er knap så vellykkede, så er det jo ikke 'teknik', der er skyld i at projekterne er blevet knap så vellykkede.

Rejsekortet virker jo, problemet er bare at 'kunden' ikke var 'kunden', det problem man prøvede at løse (og for den sags skyld også løste), var bare ikke vores ejerne/kunderne/borgernes problem. Det var de offentlige trafikselskabers problem med intern fakturering man løste.

EFI der forstod SKAT ikke ordentligt det problem, der skulle løses, selv om de kommunale pantefoder råbe op.

Igen så kommer vi tilbage til respekten for den faglighed, der er i det problem man skal IT-ficere. Man skal inddrage de faktiske brugere og personer der forstår forretningen. Man skal have beskrevet processerne, identificeret relevant data etc etc. Altså respektere IT-fagligheden også.

Nogen gange løses IT problemer bedst ved at bruge andre værktøjer end 'kodestokken'. // Jesper

Det læste jeg godt. Måske udtrykte jeg mig ikke klart nok. Jeg tror ikke på din konstruktion. Du løser ikke problemet beskrevet i artiklen, ved at lave et uafhængigt organ, der skal lave en 'teknisk løsning' i form af en standard platform, med standard integration.

Min forige kommentar beskriver det overordnede formål. Ikke som sådan at lave en 'teknisk løsning', mere blot at definere mindste fællesnævner således at vi kan undgå et monopol.

gen så eksisterer nogle af disse standarder og platforme til dels i dag. På Integrations området f.eks. OIOXML som Henrik nævnte eller OIOSAML, men der er også integrationer på et højere plan (forretningsmæssigt) som f.eks. OIOUBL (faktura). Ud over det er der offentlige standard platforme, der stille services tilrådighed for 'det offentlige'. Se f.eks. serviceplatformen og støttesystemerne (på kommunalt niveau). https://www.kombit.dk/mere-om-sts https://www.kombit.dk/serviceplatform

Jamen er det ikke en god ting da? Vil du afskaffe de standarder? Jeg synes da det er fint... Godt at vi har noget vi kan blive enige om. Jeg ville egentlig blot udvide det lidt.

Igen så kommer vi tilbage til respekten for den faglighed, der er i det problem man skal IT-ficere. Man skal inddrage de faktiske brugere og personer der forstår forretningen. Man skal have beskrevet processerne, identificeret relevant data etc etc. Altså respektere IT-fagligheden også.

Det er jeg slet ikke uenig i. Faktisk ville jeg frigøre IT leverandørene til at finde den bedste måde at gøre det på...

Nogen gange løses IT problemer bedst ved at bruge andre værktøjer end 'kodestokken'.

Smukt sagt Jesper. Jeg er enig.

Tak for debatten, jeg stopper i denne tråd, da der er andre ting der også kræver opmærksomhed. Det har været interessant at følge og heldigvis er der jo ikke noget krav til at vi partout skal blive enige.

God sommer til jer alle

God sommer til jer alle

Ja, tak for debatten Henrik, og god sommer til dig også.