Kommentar: Derfor er en it-havarikommission ikke løsningen

Illustration: REDPIXEL.PL/Bigstock
En it-havarikommission vil få svært ved at forebygge nye it-skandaler, fordi vi allerede kender årsagerne til, at de store projekter går galt.

I efterdønningerne fra CSC-hackersagen og den forestående ballade om Skats EFI-system er det nærliggende at slutte sig til koret af it-folk og politikere, der efterlyser en it-havarikommission. Men en kommission er ikke løsningen på de offentlige it-skandaler.

For det første har vi allerede været der. Bonnerup-udvalget og forskningen fra Bent Flyvbjerg har allerede kortlagt flere af de væsentligste årsager til, at projekterne går galt. Og det er de samme årsager, som vi allerede kendte i 2001 fra Amanda, som går igen i Polsag, Proask og EFI.

Et velkendt kritikpunkt har således været, at de store it-projekter blev sat i gang på baggrund af standardkontrakter, hvis formål ikke var at sikre, at det rigtige it-system blev udviklet på den rigtige måde, men derimod, at begge parter havde deres juridisk på det tørre.

Flere af de velkendte årsager til fejlslagne it-projekter er desuden svære at undgå. Eksempelvis var der i både Proask og Polsag ikke de nødvendige kompetencer internt i henholdsvis Rigspolitiet og Arbejdsskadestyrelsen til at styre projekter af denne størrelse. Derfor måtte de støtte sig til eksterne konsulenter.

Hos Arbejdsskadestyrelsen var Proask-projektet først solgt som et uundgåeligt platformskifte, men blev senere til et redskab, der kunne hjælpe med at gennemføre en besparelse. Det gav problemer, da projektet blev forsinket, men besparelserne blev gennemført helt efter tidsplanen. Nøjagtigt samme billede tegner sig nu hos Skat.

En it-havarikommission vil kunne gå endnu længere end Rigsrevisionen, som allerede har undersøgt flere af it-projekterne. Men det kan vise sig at være særdeles vanskeligt at slå ned på, hvornår bolten knækkede, og motoren faldt af flyvingen, for et it-projekt.

Ofte peger evalueringen af de fejlslagne projekter tilbage på udformningen af kravspecifikationen, som viser sig at være udarbejdet af eksterne konsulenter, der også har prækvalificeret leverandører til at byde på projektet. Det er oldgammel viden inden for faget systemudvikling, at det er i foranalysen og kravspecifikationen, grundlaget for en it-skandale lægges.

Det bedste bud på en løsning er at give mulighed for at tilpasse projektet undervejs i takt med, at man bliver klogere. Det er først for nylig, at det er blevet lettere for offentlige myndigheder at vælge denne udviklingsmodel.

Og det afspejler et andet problem ved at kulegrave de fejlslagne projekter. Skats EFI har rødder tilbage i Skats Systemmodernisering, som blev sat i gang i 2004. Det var før, agil udvikling og virtualisering blev moderne. Proask, som blev skrottet i 2013, blev sat i gang i 2006. Det betyder, at hele måden, vi arbejder med it på, når at gennemgå store forandringer i den tid, der går fra første notat fra en myndighed om et it-projekt, til systemet viser sig at have kostet en kvart milliard og aldrig kommer til at virke.

It-havarikommissionen vil måske kunne placere et ansvar. Hvem burde have sagt fra, da det kunne havde kostet 25 millioner i stedet for 250 millioner? Hvem sagde god for at købe et system, som slet ikke var det, der var brug for, og derfor aldrig ville kunne løse opgaven?

Det kan være en vigtig opgave, men det giver os ingen garanti for, at vi kan lære noget, som forhindrer den næste skandale. For det første fordi projekterne altid er forskellige, om ikke andet som følge af udviklingen inden for it-området. For det andet fordi en it-havarikommission vil have svært ved at reproducere fejl og dokumentere dem så soleklart, at de kan undgås.

Hvordan dokumenterer man eksempelvis, at en projektleder ikke havde de fornødne kompetencer, på en måde, så man i et andet projekt kan vurdere, om den valgte projektleder er klædt på til opgaven?

De store it-projekter er samtidig så sjældne, at det er svært at finde mange projekter, som ligner hinanden tilstrækkeligt til, at specifikke erfaringer kan overføres fra det ene, der er kollapset, til det andet, der stadig er under udvikling.

Dermed ikke sagt, at de dårlige erfaringer ikke skal udnyttes. Men meget af arbejdet er gjort, og det er tvivlsomt, om vi når til en ny erkendelse ved at endevende Skats Systemmodernisering. Eller rettere: Selvfølgelig skal Skats fejlslagne projekt endevendes, men vi skal nok ikke forvente, at konklusionen vil overraske os.

Det må være langt vigtigere at sikre, at den viden, vi allerede har opbygget om gode og dårlige projekter, rent faktisk bliver anvendt. Statens It-projektråd er ét bud. Tiden vil vise, om det er tilstrækkeligt. Et andet bud er muligheden for iterative eller agile udviklingsforløb. Det kender vi heller ikke resultatet af endnu.

Et tredje bud kunne være at gøre det mere legitimt for kontorcheferne, direktørerne i styrelserne eller endda leverandørerne og konsulenterne at sige stop, når der er brugt småpenge på projekterne, og man ud fra vores allerede indsamlede viden kan se, at et projekt er skruet forkert sammen.

Men når det hele skal forbi Folketingets finansudvalg, og den ansvarlige minister skal stå skoleret, så bliver det svært at sige undskyld for at have brugt 25 millioner på ingenting. Også selvom man så fem år senere har brugt 250 millioner på lige så lidt ingenting.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (54)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Michael Erichsen

Bonnerup stillede sig op i Århus og sagde, at hovedproblemet er "nulfejlskulturen" i det offentlige, altså at man ikke vil indrømme fejl.

Jvf. George Santayana: “Those who cannot remember the past are condemned to repeat it.”

Amtsborgmesteren fra Ringkøbing Amt (dengang) sad i panelet og tilføjede med jysk lune: "Ja, det er fuldkommen rigtigt. Men lad det ikke komme ud!"

Niels Flensted-Jensen

Jeg er uenig med konklusionen om at en havarikommision ikke er løsningen.

Når man andre steder har havarikommisioner, er man jo netop ikke på jagt efter en tendens eller en generel observation (som "projektledere skal uddannes til risikostyring"). Man søger de meget specifikke årsager til at det gik galt.

Når man har fundet en specifik fejl (f.eks. dimsen var forkert svejset) går man tilbage vha. noget i stil med "5 whys" og finder ud af hvordan man fixer processen, organisationen, uddannelsen, osv. for at undgå netop dette specifikke problem i fremtiden.

Mere konkret for IT-projekter er der jo den hage, at købere som regel kun kan forholde sig til projektet som en række styringsredskaber rundt om en - ofte meget stor - black box med alt det tekniske inden i. Og den tekniske del interesserer man sig af kompetencemæssige årsager ikke for.

Det har ellers tidligere været dokumenteret af Globeteam at Polsag bl.a. gik galt på grund af ringe teknisk kvalitet. Men så vidt jeg ved har det ikke affødt krav om certificering af softwarearkitekteter, uddannelse i bestemte tekniker, anvendelse af bestemte teknologier eller lign.

Som analogi kan man forestille sig at der døde for mange patienter på hjerteafdelingen på Rigshospitalet i forhold til andre steder, og man derefter alene gav sig til at analysere de administrative processer, lederuddannelse, etc. Og at pressen alene interesserede sig for at høre hvad den administrative ledelse havde at sige. Og man besluttede at lave et "hjerteråd" og så lod det ligge der! Men sådan går det jo ikke. Den første der kommer i fjernsynet er en læge i hvid kittel med operationsmasken trukket ned om halsen for at vi bedre kan forstå ham.

Kan man forestille sig chefarkitekten bag Polsag blive trukket en tur gennem mediemøllen? Og som sagde på direkte TV at der var for stor cykolmatisk kompleksitet i et bestemt modul? Eller at kvaliteten af et bestemt standardssystem var for lav?

Så hvor ville det være skønt hvis fejlslagne projekter faktisk førte til at vi lærte noget specifikt og ikke blot fik domænebestyrelser, projektråd, osv. Tænk hvis dem der var skyld i at flyet styrtede faktisk blev stillet til ansvar?

Julian Hollingbery

Hvordan kan "vi allerede kender årsagerne til, at de store projekter går galt" når det samtidigt kan "være særdeles vanskeligt at slå ned på, hvornår bolten knækkede, og motoren faldt af flyvingen, for et it-projekt", for ikke at tale om at "De store it-projekter er samtidig så sjældne, at det er svært at finde mange projekter, som ligner hinanden"? For mig at se argumenteres der her ret godt for en IT-havarikommission, som kan opsamle erfaringer over en længere årrække end et midlertidigt udvalg. Og jeg tror at nulfejlskulturen modarbejdes bedst ved at få indarbejdet reel risiko for de ansvarlige: Små fejl medfører lille eller ingen straf, store fejl medfører stor straf.

Poul-Henning Kamp Blogger

Jesper tager ikke engang fejl i sin kritik af den foreslåede ITHK, hvilket han selv afslører i sætningen: "It-havarikommissionen vil måske kunne placere et ansvar."

ITHK skal overhovedet ikke placere noget ansvar.

Det har vi Sø og Handelsretten, Rigsrevisionen, politikere og i sidste ende vælgerne til.

ITHK's opgave er at afdække hvad der gik galt, med det ene formål at vi ikke skal begå den samme fejl igen.

I det omfang ITHK's redegørelse kan indgå i en placering af ansvaret er det naturligvis en fin "synergieffekt", men det er ikke deres opgave og det er ikke noget de skal spilde tid på.

Var kravspecifikationen forkert ?

Fint, lad ITHK afdække hvorledes den var forkert, således at den næste offentlige kravspecifikation ikke indeholder samme fejl/misforståelser/udelaldelser/tåbeligheder.

Hvem der er skyld i at den var forkert kan andre tage sig af, det er ikke ITHK's resort.

Tag POLSAG som eksempel.

Det var utvivlsomt et juridisk roderi og alt muligt andet og det har Rigsrevisionen og andre haft fingrene dybt nede i.

Men POLSAG var også IT for en halv millard kroner der ikke performede godt nok til Bornholms politikreds.

Hvorfor performede det ikke ?

Var det fejldesign af databasen ?

Var det forkert hardware ?

Var det uforudsete brugsmønstre ?

Præcis hvad var det der gjorde POLSAG så langsomt ?

Det har vi aldrig fået at vide og vi får det formodentlig heller aldrig.

De næste der skal prøve kræfter med opgaven starter derfor på bar bund igen.

Det er simpelthen for tåbeligt!

Hvis vi nogensinde skal blive bedre til IT, kræver det at vi lærer af vores fejltagelser.

Og fejltagelser er der nok af, også mange der intet har at gøre med om der blev brugt "Agile" eller standardkontrakter eller ej.

Hvorfor opdagede hverken IBM eller Nets at en medarbejder solgte personfølsomme oplysninger fra kreditkortsystemet til Se og Hor ?

Var der ingen logfiler ?

Blev logfilerne ikke skrevet ?

Var der ingen der kiggede i logfilerne ?

Hvorfor endte alle mulige offentlige instansers personfølsomme registre sammenblandet på fire LPAR på CSC's IBM mainframe ?

Hvordan kunne DSB sende reklameemails med personfølsomme oplysninger til 10.500 forkerte addresser ?

Hvorfor styrtede Danske Banks systemer i grus på grund af "en opdatering" ?

Hvorfor opdagede Seruminstituttet ikke at de havde et ulovligt register ?

Det rager mig en pap-and hvem der er skyld alt dette rod, men jeg vil have en ITHK der kan fastlægge hvorfor det skete og anbefale hvorledes vi forhindrer gentagelser.

Og lur mig om ikke den forbedrede juridiske/organisatoriske ansvarsfordeling som Jesper væver lidt om til sidst også kunne gøre god brug af ITHK's rapporter.

F.eks ved at indføre en standard paragraf der siger:

"Alle ITHK's anvisninger og anbefalinger skal følges."

Per Erik Rønne

Måske skulle man også se på om projektledelsen har den rigtige uddannelsesbaggrund.

Mange hævder at man i her fortrinsvist bruger jurister og andre djøf'ere. I stedet for folk der rent faktisk ved noget om hvad det hele drejer sig om.

Som dataloger og operationsanalytikere.

Kan der være noget om at jurister med deres vægt på detaljerede kravspecifikationer fortrinsvist beskytter deres egen posterior?

Claus Juul

Prince2 har en rolle/koncept der hedder "Project assurance role", hvis rolle det er at holde øje med om projektet er på sporet og forhold der kan ændre projektets berettigelse.

Hvis man nu forstiller sig en lille gruppe på ca. 2-3 personer der varetager denne rolle.
Rollen skal besættes af personer som ikke har aktier i projektet eller den organisation der har projektet (får løn fra en seperat institution) og de skal på samme måde som Rigsrevisionen have adgang til alt materiale.

Sådan en gruppe vil kunne fungere som gardering for at projekter ikke går over tid, koster mere end hvad der kan forsvares og levere et relevant resultat.

Claus Juul

Prince2 har en rolle/koncept der hedder "Project assurance role", hvis rolle det er at holde øje med om projektet er på sporet og forhold der kan ændre projektets berettigelse.

Hvis man nu forstiller sig en lille gruppe på ca. 2-3 personer der varetager denne rolle.
Rollen skal besættes af personer som ikke har aktier i projektet eller den organisation der har projektet (får løn fra en seperat institution) og de skal på samme måde som Rigsrevisionen have adgang til alt materiale.

Sådan en gruppe vil kunne fungere som gardering for at projekter ikke går over tid, koster mere end hvad der kan forsvares og levere et relevant resultat.

Poul-Henning Kamp Blogger

Måske skulle man også se på om projektledelsen har den rigtige uddannelsesbaggrund.

Hvor er uddannelsen i at lede store IT projekter ?

Hvor er uddannelsen i at designe store IT-systemer ?

Hvor er uddannelsen i at gøre store IT-systemer praktisk drift-bare ?

Hvor er uddannelsen til Persondataansvarlig ?

Der er rigtig meget at tage fat på i denne ende, men det har intet at gøre med om vi skal have en ITHK eller ej...

Jesper Stein Sandal Blogger

Præcis hvad var det der gjorde POLSAG så langsomt ?

Men hvad kan vi lære af svaret til fremtidige projekter? POLSAG var et ret unikt system, hvor det, der gav problemer, blandt andet var, at det skulle trække data ud af et endnu mere unikt mainframe-system.

Min pointe er, at når det gælder de fejlslagne it-projekter, så er det langt fra givet, at yderligere to års kulegravning med afhøringer af udviklere og projektledere vil give os viden, der kan forhindre gentagelser.

I POLSAG var problemet - efter min mening - ikke de lange svartider. Problemet var, at de lange svartider var blevet ignoreret helt frem til pilottesten - og selv med brugernes sønderlemmende kritik var det ikke en selvfølge, at projektet skulle skrottes, når det efter mange års udvikling ikke havde løst problemerne.

Dernæst peger du på CSC-hackersagen, Nets-sagen og andre tilfælde af virkelig skidt omgang med it. Der kan vi godt blive enige om, at der kunne være brug for at få meget konkrete anbefalinger til teknikerne, end dem Rigsrevisionen og Datatilsynet leverer i dag. Men det ser jeg som en anden opgave end at kulegrave de store it-projekter (hvor mit indtryk efter at have beskæftiget mig med flere af skandalerne er, at fejlene ligger på Powerpoint-niveau og ikke i koden).

Poul-Henning Kamp Blogger

Min pointe er, at når det gælder de fejlslagne it-projekter, så er det langt fra givet, at yderligere to års kulegravning med afhøringer af udviklere og projektledere vil give os viden, der kan forhindre gentagelser.

Min pointe er at uden nogen form for teknisk kulegravning bliver vi aldrig klogere.

Dernæst peger du på CSC-hackersagen, Nets-sagen og andre tilfælde af virkelig skidt omgang med it. Der kan vi godt blive enige om, at der kunne være brug for at få meget konkrete anbefalinger til teknikerne, end dem Rigsrevisionen og Datatilsynet leverer i dag. [...]

Bingo: Det er det vi skal bruge ITHK.

Men ITHK skal ikke stilles udenfor døren bare fordi du eller andre mener der er sprøjtet for lidt "Agile" perfume ud over kontrakten.

For selvom POLSAG organisationen ikke reagerede som de burde på de dårlige svartider, mangler vi stadig at finde ud af hvorfor det var dårlige svartider til at begynde med, hvorfor dette ikke blev opdaget som en risiko meget tidligere i forløbet osv. osv.

Jesper Stein Sandal Blogger

For selvom POLSAG organisationen ikke reagerede som de burde på de dårlige svartider, mangler vi stadig at finde ud af hvorfor det var dårlige svartider til at begynde med, hvorfor dette ikke blev opdaget som en risiko meget tidligere i forløbet osv. osv.

Det er to meget forskellige spørgsmål.

Ja, vi kan måske lære, at det ikke går (i et tænkt eksempel) at kombinere Scanjours ESDH med en Microsoft Biztalk Server 2006 og Oracle DB 9, hvis man vil have lave svartider.

Men der er en pointe: Det offentlige har haft en tendens til at være first mover - ikke bare på at digitalisere, men også på at vælge nye teknologier. Det blev eksempelvis skrevet ind i kravspecifikationen for ESDH-systemer i 2006, at de skulle bygges på SOA. I dag kender vi langt flere af problemerne ved SOA og vil næppe sige, at man altid skal bruge SOA. Men nogle af de lærepenge kommer fra offentlige it-projekter.

Og det er det andet spørgsmål i POLSAG - hvorfor opdagede man ikke risikoen tidligere i forløbet?

Hvis du går tilbage til de aktstykker, som Folketingets Finansudvalg har behandlet om de store it-skandaler, da de skulle godkende det første budget, så indeholder de en risikovurdering. Det er absurd - i bagklogskabens lys - at risikoen ved eksempelvis at være first mover på en ny teknologi sjældent bliver vurderet til mere end 3 på en skala fra 1-5.

Jeg vil holde fast i, at problemerne er opstået allerede i udformningen af kravspecifikationerne og ikke i den konkrete implementering - bortset fra, at en leverandør meget vel kan have overdrevet sine kompetencer inden for en bestemt teknologi for at vinde udbuddet.

Før vi begynder at endevende kildekoden til POLSAG, så mener jeg, at vi skal overveje, hvad vi får ud af det i forhold til at fokusere på de rammer, der gjorde det muligt for eventuel klytkode at slippe med i det færdige system.

Det er trods alt de færreste programmører, der skriver dårlig kode ene og alene på grund af manglende talent (derimod kan adgang til erfaren rådgivning, uddannelse, tid eller fleksibilitet i forhold til konkrete krav spille en rolle).

Jesper Frimann

Jeg er sådan set enig med Jesper S, om at en IT havari kommission ikke vil kunne løse det generelle problem vi har med offentlige IT-projekter har det med at Foobar'e.

Når det så er sagt, så er der da brug for en centraliseret IT-havari kommission like konstruktion, som vi også kan se på datatilsynets udtalelse, som jo er sådan lidt vag rent teknisk.
Og en IT-havari kommission ville kunne give værdifuld input til en forståelse af, Hva' er det der går galt , både rent teknisk men også arkitektur mæssigt og projekt mæssigt. Og sørge for at denne viden blev opsamlet og 'gemt'.

Problemet er bare .. at de spg. som PHK stiller og gerne vil have besvaret i sin post oven for, er besvarede.

De svar der skal til for, at vi kan få offentlige IT-projekter til at have en høj success rate er jo svarene på de spørgsmål, som man stiller 2..3 .. 4 eller flere trin efter at have besvaret PHK's spg.

Og det vil IMHO være out of scope for en IT-havari kommission. For de svar man ville få der, er svar der har med politik at gøre, organisering af ministerier.. og andre ja...

Så ... ja vi har brug for en IT-havari kommission.. men det er ikke nok.

Personlig er mit take, er at IT er så stor en del af 'core business' for det offentlige at det skal have sit eget ministerium eller en rigtig selvstændig myndighed.

// Jesper

Poul-Henning Kamp Blogger

Så ... ja vi har brug for en IT-havari kommission.. men det er ikke nok.

Jeg håber sandelig ikke at jeg nogensinde har givet udtryk for at ITHK ville løse alle problemer, langt fra.

Men den kan og skal løse det problem at vi ikke lærer af vores fejltagelser i IT branchen - præcis som Havarikommisioner har løst det problem i luftfart og jernbanesammenhæng.

Thomas Søndergaard

Ideen om en IT-haverikommission kommer formodentlig fra luftfarten. Her er det værd at bemærke at et top-moderne passagerfly ikke er til at skelne fra et fra halvtredserne. Min pointe er at det er sandsynligt at en IT-haverikommision vil kunne øge stabiliteten og sikkerheden i IT-systemer, men man er nødt til at overveje hvordan det påvirker udviklingen.

Jeg er ikke afklaret ved en IT-havarikommision, men det er da en interessant tanke.

Flemming Nielsen

Prince2 har en rolle/koncept der hedder "Project assurance role", hvis rolle det er at holde øje med om projektet er på sporet og forhold der kan ændre projektets berettigelse.

Hvis man nu forstiller sig en lille gruppe på ca. 2-3 personer der varetager denne rolle.
Rollen skal besættes af personer som ikke har aktier i projektet eller den organisation der har projektet (får løn fra en seperat institution) og de skal på samme måde som Rigsrevisionen have adgang til alt materiale.

Sådan en gruppe vil kunne fungere som gardering for at projekter ikke går over tid, koster mere end hvad der kan forsvares og levere et relevant resultat.

@Claus, hvis det skal være brugbart, så hviler det på en række forudsætninger, som langt fra altid er til stede i et projekt:

  • at det Prince2 styrede projekt samtidig også har fået lavet et realistisk "produktnedbrydningshierarki" fra starten af projektet (hvilket ikke ret mange store, komplekse it projekter reelt har, målt op mod den samlede projektleverance, der kan konstateres ved afslutningen af et succesfuldt projekt), og
  • fået produktnedbrydningshierarkiet til en udspecificeret detail projektplan (hvilket også sjældent gøres ... i stedet arbejdes der med hovedplaner og roadmaps, der kun forholder sig til hovedmilepæle og større blokke af projektleverancer)
  • at der undervejs i projektforløbet ikke sker "scope creep" eller godkendes markante, større change requests, der ændrer markant på hvad der rent teknisk skal leveres fra projektet, inkl. alle de potentielle knock-on effekter på øvrige dele af projektet ... (det er et klassisk projekt dilemma: de arkitektur- og løsningsmæssige beslutninger der træffes i begyndelsen af et projekt, har størst impact på slutløsningen, men den nødvendige viden og information er lavest i begyndelsen af et projekt, og stiger gradvist og rykvist undervejs i projektet; se evt. grafik nedenfor, planket fra Mikkelsens & Riis, "Grundbog i projektledelse")

http://www.myllerup.dk/images/SenesteAnsvarligeTidspunkt.jpg

Bo Victor Thomsen

Ja, vi kan måske lære, at det ikke går (i et tænkt eksempel) at kombinere Scanjours ESDH med en Microsoft Biztalk Server 2006 og Oracle DB 9, hvis man vil have lave svartider.

Hvis den ovenstående kombination rent faktisk var årsag til lange svartider og et IT-havari er det da en vigtig oplysning at få ud af en "havari-kommisions-analyse". Det er jo ikke alle kombinationer, som er så usædvanlige som den valgte strå-mand.

Hen af vejen vil det sandsynligsvis være muligt at finde en række specifikke årsagssammenhænge til IT-havarier. Det er vel basalt set den egentlige årsag til at nedsætte kommisionen ...

Poul-Henning Kamp Blogger

Her er det værd at bemærke at et top-moderne passagerfly ikke er til at skelne fra et fra halvtredserne

Du mener "cockpit ude foran, to vinger og nogle motorer" ?

I så fald har du ret.

Der er nu heller ikke meget forskel på et computer system fra 1950erne og idag: De består begge af "Noget software og nogle computere med I/O enheder".

Men hvis man faktisk har forstand på fly, vil man se at moderne fly er meget bedre gennemtænkt end dem fra 1950, f.eks indenfor sådanne områder som brandsikring, metaltræthed, nødudgange, redundans osv. osv.

Omvendt, selv hvis man har forstand på computere kan det faktisk godt være svært at finde tilsvarende forskelle på IT systemer fra 1950erne og idag.

Hvor man finder sådanne forskelle er falder de ofte ikke ud til de nutidiges systems fordel.

Dem der i sin tid skrev det første kildeskattesystem og det første CPR register havde tydeligvis en noget mere ærbødig tilgang til opgaven en nutidens "Det gør vi lige agilt med noget objekt-orienteret cloud-scrum UX devops mashup".

Mikkel Lauritsen

Jeg vil holde fast i, at problemerne er opstået allerede i udformningen af kravspecifikationerne og ikke i den konkrete implementering - bortset fra, at en leverandør meget vel kan have overdrevet sine kompetencer inden for en bestemt teknologi for at vinde udbuddet.

Hvis en kravspecifikation skal give mening, så skal den være mindre detaljeret end koden - ellers er den koden - og det efterlader plads til, at den kan omsættes til kode på mere eller mindre hensigtsmæssig måde.

Jeg har set masser af eksempler på, at specifikationen er blevet omsat til dårlig kode, og at det i øvrigt først er blevet opdaget, når koden går i produktion. Det klassiske eksempel er det med at lave et roundtrip mellem servere pr. element i en collection, hvilket går fint, så længe det er udviklerens håndlavede testdata, men kører som en gigtramt snegl indefrosset i en gletcher, så snart datavolumen vokser med en faktor 1.000 eller mere i produktion.

Så med forbehold for, at det kan ende med en meget detaljeret redegørelse, så synes jeg også, at det giver fin mening at undersøge, om der kan være andre forklaringer på fejlslagne projekter end bare "dårlig kravspecifikation".

Jesper Stein Sandal Blogger

Hen af vejen vil det sandsynligsvis være muligt at finde en række specifikke årsagssammenhænge til IT-havarier. Det er vel basalt set den egentlige årsag til at nedsætte kommisionen ...

Men når det gælder de tekniske bidrag til problemerne, så får vi ikke ret meget ud af at kende dem. Fra et projekt får en kravspecifikation til det endegyldigt viser sig at være gået, og it-havarikommissionen har en rapport klar, så er afstanden i tid for lang. Polsag var 8 år undervejs - der når simpelthen at ske for meget, selv med de involverede teknologier, i mellemtiden til, at vi kan bruge erfaringer som mit tænkte eksempel til ret meget.

Og så er det de tekniske problemer, der bliver stråmanden. Årsagen til de tekniske problemer er mere interessant:

http://www.version2.dk/artikel/breaking-hemmelig-rapport-afsloerer-cscs-...

http://www.version2.dk/artikel/derfor-kiksede-polsag-kraevede-100000-sql...

http://www.version2.dk/artikel/afsloering-daarlig-kodekvalitet-lagde-gru...

Der var mange tekniske problemer med Polsag. Men det var ikke problemer, der opstod ud af det blå, når en udvikler havde siddet til klokken lidt for sent. Og jeg er ikke sikker på, at vi kan lære mere af de konkrete tekniske fejl, end vi kan af de strukturelle fejl, der tillod de tekniske fejl.

Poul-Henning Kamp Blogger

Men når det gælder de tekniske bidrag til problemerne, så får vi ikke ret meget ud af at kende dem.

Forklar mig lige hvordan din kravspecifikation/kontrakt tilgang forhindrer endnu en IBM/Nets/Se&Hor sag ?

Eller endnu en Rigspolitet/IM/Moderniseringsstyrelsen/CSC sag ?

Eller endnu en "Dankortet/NemID var nede hele dagen" sag ?

At påstå at vi ikke har brug for en ITHK barefordi den ikke løser det der lige er din hjertesag er i bedste fald uinformeret og i værste fald bevist FUD...

Gert Madsen

Og jeg er ikke sikker på, at vi kan lære mere af de konkrete tekniske fejl, end vi kan af de strukturelle fejl, der tillod de tekniske fejl.


Så fordi en IT-havarikommision ikke kan garantere at løse alle problemer, så skal vi istedet gøre som vi plejer ?
Svaghederne til trods, støtter jeg en IT-havarikommision. Alene synliggørelsen af fejlene/problemerne vil medføre en bedring af kvaliteten.
Hvis vi ikke gør noget, så ved vi jo hvad der sker.

Mikkel Lauritsen

Der var mange tekniske problemer med Polsag. Men det var ikke problemer, der opstod ud af det blå, når en udvikler havde siddet til klokken lidt for sent. Og jeg er ikke sikker på, at vi kan lære mere af de konkrete tekniske fejl, end vi kan af de strukturelle fejl, der tillod de tekniske fejl.

Nu har jeg ikke set kravspecifikationen, så jeg kan ikke fuldstændigt udelukke, at der står i den, at systemet skal lave 100.000 databasekald i sekundet, men det er forhåbentlig ikke tilfældet. Det lugter derimod langt væk af en strukturel fejl, nemlig at projektet ikke har haft en deltager med overblik over den samlede løsning, så han/hun kan sikre, at den slags problemer ikke opstår - eller alternativt at det overblik ikke er blevet formidlet til de enkelte udviklere. Det er nok nærmest mangel på det, som go'e, gamle Brooks for 40 år siden betegnede som konceptuel integritet, så det er bestemt ikke noget nyt.

Men før man kan drage den konklusion, så er det nødvendigt at vide, hvori problemerne helt præcist har bestået. Oplevet dårlig performance er ikke nok til at kunne udpege årsagen.

For den sags skyld kan problemet teoretisk set ligge i en kravspecifikation, som ikke nøjes med at beskrive hvad man vil opnå (løs kobling, udskiftelige komponenter etc.), men også specificerer en uhensigtsmæssig måde at gøre det på (SOA, hrm-hrm). Hvordan den slags nonfunktionelle ting skal håndteres bør man nok lade være op til nogen med større teknisk indsigt at finde ud af.

Jesper Stein Sandal Blogger

At påstå at vi ikke har brug for en ITHK barefordi den ikke løser det der lige er din hjertesag er i bedste fald uinformeret og i værste fald bevist FUD...

Poul-Henning, jeg argumenterer imod en ITHK som en generel løsning på it-skandaler. En ITHK, som har autoritet til at skaffe svaret på det, Rigspolitiet indtil videre ikke har kunnet oplyse mig om (hvem fandt på, at Schengen-systemet skulle køre på samme LPAR som en webserver fra en anden myndighed?), er en god idé.

Men man skal ikke forvente, at den kan hjælpe os med at undgå en ny Polsag ved at granske Polsag.

Der er dog ét punkt, hvor en ITHK kunne give os ny indsigt i, hvorfor de store offentlige it-projekter går galt. Men det er ikke i teknikken. Det kunne være rigtig fantastisk, hvis en ITHK havde autoriteten til at se på nogle af de leverandører og konsulentfirmaer, der har ageret centrale rådgivere i det ene projekt efter det andet, der er gået galt. Det er ingen hemmelighed, at der er et par gengangere, som burde have vidst bedre - i hvert fald i forhold til den betaling, de har modtaget gennem årene (ét firma på mit whiteboard har været rådgiver eller endda projektleder på mindst seks store off. it-projekter, der er gået galt eller har været i store vanskeligheder siden 1990'erne - og i visse tilfælde søsat projekter med næsten enslydende kravspec. efter et parallelt projekt er kommet i problemer - men den historie får I, om aktindsigterne vil det, en anden dag).

Poul-Henning Kamp Blogger

hvis en ITHK havde autoriteten til at se på nogle af de leverandører og konsulentfirmaer, der har ageret centrale rådgivere i det ene projekt efter det andet, der er gået galt

Kig på hvordan havarikommissioner er strikket sammen: De har adgang til alt relevant materiale, uanset hvor det befinder sig.

Selvfølgelig skal udspekulerede klaphatte ikke kunne gemme sig bag "forretningshemmeligheder" overfor en ITHK.

Niels Henrik Sodemann

@Jesper, du argumenterer jo i høj grad for at der er behov for ITHK. Hvis den læring som du mener findes (fra Bonnerup-udvalget og forskningen fra Bent Flyvbjerg) ikke er benyttet, hvad er så den præcise forklaring herpå?
En lang rækker projekter, inkl. de rygter der er om et nyt PROASK udbud, må da gøre det krystalklart at de læringer du påpeger ikke er: 1) forstået 2) bevist bliver tilsidesat af involverede parter.
Uanset om det er det første, det sidste eller noget herimellem, må det da efterhånden være klokkeklart at der er behov for et uvildig / uafhængigt organ til at sikre at det ikke bare bliver gentaget i en uendelighed.

Jn Madsen

Ingen er vel i tvivl om, at den største årsag til de fejlslagne projekter er, at tingene er lavet uden de rette faglige kompetencer har været ind over?

Der skal de rette (teknisk kompetente) øjne til at kigge på tingene inden man starter.
De skal være med under design og implementering.
De skal være med til aflevering,- og løbende opgraderinger.

Problemet er, at staten ikke har folk der har de rette kompetencer. Der er masser af ledere der mener, de skal have afgørende indflydelse. Der køres pallevis af projektledere ind på sagen,- som mener de er mere kompetente end fagfolk. Derefter søler man det hele ind i juristeri.

Alt i alt er man helt i leverandørenes vold,- og de er der for at tjene penge, men desværre heller ikke altid fuldt kompetente.

Staten skal have et kontor/ministerium/haverikommision - kald det hvad i vil. Der skal sidde nogle meget dygtige folk. De skal være højeste autoritet. Mere end kontorchefer, projektledere og jurister.

Bo Victor Thomsen

Men når det gælder de tekniske bidrag til problemerne, så får vi ikke ret meget ud af at kende dem. Fra et projekt får en kravspecifikation til det endegyldigt viser sig at være gået, og it-havarikommissionen har en rapport klar, så er afstanden i tid for lang. Polsag var 8 år undervejs - der når simpelthen at ske for meget, selv med de involverede teknologier, i mellemtiden til, at vi kan bruge erfaringer som mit tænkte eksempel til ret meget.

Du har ret mht. til det valgte (teknik) eksempel: At dims A ver. x spillede dårligt sammen med dims B ver. Y for 10 år siden vil i mange tilfælde være urelevant. Men der er så mange andre (og vigtigere) årsager til et havari: Som f.eks. den valgte udviklingsmetode, projektstyringen vedr. udvikling, opsplitning af gigant projekter i overskuelige, mindre bidder, iterativ kontrol af del-leverancer, brugerinddragelse (eller mangel på samme) osv. osv. - aspekter, som ikke ændrer sig synderligt over lange perioder. Disse problemer ville en havari kommision kunne belyse og i sidste ende afhjælpe.

René Nielsen

Hvis vi skruer tiden tilbage til den gang Fru Thatcher var PM i Storbritanien, så var der seriøst rod i økonomien i offentlige projekter. Det var ikke kun hendes skyld, for sådan var den offentlige kultur som hun overtog, at der var omvendt Darwinisme i offentlige projekter, idet man groft underdrev omkostningerne og groft overdrev indtægterne.

De projekter som burde dø allerede i fødslen blev gennemført og især var der to projekter som lagde det offentlige ned i Storbritanien i et årti - et tog projekt og tunnelen under kanalen.

Så var det hendes afløser en vis Tony Blair gennemførte en revision af dette område. Et af resultaterne var at der var brug for en projektlederuddannelse - med senere opdateringer kendes den i dag som Prince2 og styres stadig at det engelske indenrigsministerium.

Et andet tiltag var et belønningssystem. Som offentlig projektleder starter man med det ene ben i fængslet og det andet ben i kongehuset. Der er selvfølgelig en masse trin ind imellem med tilhørende objektive målepunkter, men afhængig af hvordan du performer som projektleder så du kan blive alt fra Lord til indsat i et tugthus.

Målt på denne måde (så vidt jeg husker) så ville en EFI projektleder afgjort få et "berus verbot", altså et lovfæst forbud imod nogen sinde igen at arbejde med projektledelse. Muligvis endda en straffesag på halsen - men så godt husker jeg det heller ikke.

Anyway enhver som har arbejdet med offentlige udbud, sidder og tænker at der mangler centrale dele i udbuddet. Som en anden læser så smukt har udtrykt, så bestiller udbuddet en bil men beder om at få pillet motoren ud.

Hvad gør man som leverandør her? Prisen er jo altid den vigtigste parameter i offentligt udbud. Man afgiver tilbuddet uden motoren, vel vidende at kunden på et tidspunkt spørger efter motoren. Og nu er det jo ekstra arbejder, så nu er timesatsen anderledes.

Nu er det jo ikke altid sådan, jeg husker et udbud, hvor udbudsmaterialet bestod af 8 meget store flyttekasser fyldt med fyldte A4 ringbind leveret af en fragtmand. Her blev der meget detaljeret redegjort for hvordan systemet skulle virke. I dette eksempel kunne der jo godt være en motor "i en anden kasse", for alle mand sidder ikke og læser alle mapper. Det bliver delt op indenfor fagområder.

Glem alt om standardsystemer her - for der er nultolerance i forhold til krav/specs.

Det kan vel for pokker ikke undre hvis der er costoverrun i et sådan projekt, når en offentlig myndighed er bedrevidende og selvhøjtidelig.

Og her tror jeg nu godt at vi kunne lære noget af en kommission!

Jakub Nielsen

Et projekt består af myriader af beslutningsprocesser der er bestemt af kultur, økonomi, politik, egne overbevisninger, psykologiske processer som ønske om konformitet mv. En del af disse beslutninger handler om de tekniske valg, en anden del omkring leverandørstyring, en anden del omkring kundestyring som er kendetegnende for det offentlige og så videre. De er forbundet som indmaden i en levende organisme - en klassisk metafor for organisationsanalyser. At lade en ITHK fokusere på de tekniske valg er som, at en skrivebordsgeneral efter et par år ser tilbage på de operationelle beslutninger i operationer, hvor han samtidig ignorere konteksten for disse valg. Det vil ikke stoppe den næste skandale. Sandsynligvis vil det ende med halv-religøse konklusioner om at man skal anvende agile/små størrelser på projekter/open source/... eller det omvendte, afhængig af hvem man sætter til at deltage. Hvis en ITHK skal kikke på de organisatoriske aspekter, så bevæger vi os over i det humaniske fagområde, hvor svar er subjektive og dermed politiske. Det vil blive et mange-hovedet svar, som skal sættes i kontekst af den nye organisation for det nye store offentlige projekt før de fornødne foranstaltninger til at undgå en katastrofe kan identificeres og effektueres. At lade en ITHK kikke på det hele og virkelig komme ind til den ægte rod af problemstillingen, samt at undervise/evagalisere i resultater herfra således fremtidige it-projekter får kompetencerne til at sætte det i deres kontekst vil være enormt komplekst og hertil har det offentlige, min vurdering, ikke evner endnu. Det vil kræve, at der gennemføres en kulturændring således det ikke blot er det operationelle paradigme der hersker, men også det strategiske således en læringseffekt (med input fra en ITHK) kan tage effekt

Simon Rigét

er at der begås ufattelig mange og dyre fejl ved den måde store projekter skrues sammen på.
Hovedårsagen er at udviklingsprocessen fra design til det færdige produkt er totalt gennemsyret af jura og privatiseringsideologi. Der fantes agil udvikling længe før det blev et buzz word. Dengang hvor egne IT afdelinger udviklede softwaren. Hele misæren opstod (for det meste) da alting skulle privatiseres for enhver pris.

Selv de privatiseringsglade briter har indset at den metode ikke duer. De er med succes begyndt at trække projekterne hjem til IT afdelingerne igen. Man omdeler opgaverne og indhyrer eksterne til at løse små delopgaver. På den måde kommer man også uden om de tåbelige licitationsregler.

En IT havarikommission gør nok ingen skade. Hvis den arbejder hurtigt nok, kan den endda være til nytte for beslutningstagerene. Mange af de skandaler der opstår, skyldes ikke at der ikke var nogen der viste at det var noget skidt der blev lavet, men at systemet forhindrede disse i at komme til orde. Sagsbehandlerkulturen har overtaget.

Før vi gør noget ved det betændte kultur for offentlig IT udvikling, fjerne vi ikke årsagen til rækken af IT skandaler.

Jn Madsen

Jo. Det vil jeg da mene der er tvivl om. F.eks. kunne det jo vaere at de fejlslagne projekter er mere givtige for leverandoerene end successfulde projekter. Men det finder vi jo nok aldrig ud af.

Så er vi jo enige :-)
Jeg snakker jo netop om, at staten skal møde op med EGNE kvalificerede mennesker.
De forstår hvad "kunden" ønsker, de forstår teknikken og de kan skille en plattenslager af en leverandørs tilbud af.

De skal også kunne slå i bordet i egne rækker. Chefer der blander sig i ting de ikke har forstand på, jurister der vil køre den forkerte vej og projektledere, hvis fødder der ikke kan nå jorden.

Så har jeg hørt denne: "Jammen, teknikere forstår jo slet ikke alle de komplicerede sider af en ordre".

Jo, de gør .. hvis man snakker med de rigtige folk. Jeg kan f.eks. nævne et par stykker der har sin gang her på Version2, der forstår temmeligt meget af mange ting.

Bjarne Nielsen

Jeg tror at det ville være gunstigt for debatten, hvis vi fik en større grad af konsensus omkring definitionen af et IT-havari.

Jeg kan ikke lade være med at sammenligne med IC4: at det i et konkret tilfælde udviser så ringe bremseevne at det er ved at påkøre det godstog, som søger for ølforsyningen i en betydende del af riget, gav anledning til grundige undersøgelser. At hjulophæng sprækker og flækker ditto. Men at leverancerne er forsinkede og at rettidigheden er udfordret, kalder vel næppe på en havarimæssig undersøgelse, og det gør det faktum, at der ofte kaldes på ekstra bevillinger heller ikke.

På samme vis ville lignende hændelser med andet materiel kunne påkalde sig granskning; det er ikke isoleret til nyudvikling, men sandelig også vedligehold og drift.

Hvordan relaterer det sig til IT? Et kriterie kunne være at der har været en hændelse med skadeligt indhold (eller potentialet herfor). Hacker-sagen og tys-tys kilden ligger lige for, men gør POLSAG? Nets/NemId stiller tjenester til rådighed, som på godt og ondt er gået hen og blevet samfundskritiske, så problemer med oppetiden bør også kunne granskes. Men er DAMD et teknisk uheld?

Jeg så meget gerne en IT-havarikommission, for der er et stort behov for at få sat lys på det tekniske aspekt, men jeg har meget svært se, at det skulle gøre Datatilsynet eller Rigsrevisionen overflødig.

Jn Madsen

Hvis du køber en bil, så forventer du:

At den leveres til aftalt tidspunkt.
At alting virker som aftalt.
At prisen er den i aftalte.
At leverandøren overholder garantier.

At andet er uacceptabelt,- både med biler og IT-systemer.

Hvis du så finder ud af, at du kører hjem i en traktor,- men havde behov for en stationcar,- så kan du med en vis rimelighed påpege dårlig rådgivning fra leverandøren,- men du har også selv undladt at udvise rettidig omhu. Du kunne have forhørt dig hos en kompetent person = statens eksperter (som de ikke har, og derfor alle de bommerter).

Eksperten kunne have spurgt leverandøren: "Hvad hulen er det i er ved at prakke ham på, stop øjeblikkeligt".

Thomas Søndergaard

Men hvis man faktisk har forstand på fly, vil man se at moderne fly er meget bedre gennemtænkt end dem fra 1950, f.eks indenfor sådanne områder som brandsikring, metaltræthed, nødudgange, redundans osv. osv.

Bevidst misforstået, så du kan fortsætte med at snakke om dine egne pointer. Du har en politiker i maven, tror jeg :-)

Moderne passagerfly er skåret over den samme læst som passagerjetfly fra halvtredserne. Selvfølgelig er der lavet forbedringer, men det er forholdsvis små inkrementelle justeringer.

Martin Bøgelund

Men man skal ikke forvente, at den kan hjælpe os med at undgå en ny Polsag ved at granske Polsag.

Det mener jeg faktisk godt man kan forvente.

For eksempel, noget så brugernært som dårlige svartider var med til at skyde Polsag i sænk - og svartider vil i ethvert projekt være et kritisk successkriterie.

Der skal ikke andet til end at ITHK ser på hvad der skød svartiderne i sænk, og hvilke forberedelser (f.eks. i krav-spec) der var gjort forlods, for at sikre at svartiderne lå under en given maks. Forskellen mellem disse 2 lister vil kunne bruges i næste projekt.

Selvom vi med Polsag måske er ude i specialtilfælde, så vil vi over tid og via forskellige specialtilfælde kunne akkumulere en tjekliste, som viser hvilke ting vi skal få styr over før første kodelinje skrives.

Risikostyring bliver nemlig så meget nemmere, hvis man har en idé om hvilke ricisi der rent faktisk eksisterer. Og til udpegning af ricisi er der nok ikke noget bedre end en undersøgelse af hvad der konkret kan gå galt.

Summa summarum: ITHK.

Poul-Henning Kamp Blogger

Jeg forsøger blot at bringe lidt nuance ind i debatten ved at fremhæve at en ITHK ikke er en magisk sølvkugle, og at en mulig omkostning vil være innovationshastighed.

Jeg har absolut intet problem med at reducere det du kalder "innovationshastighed" hvis det betyder at vi slipper for at man hænger kritisk national infrastruktur som NemID op på ufærdige og usikre "innovationer" som Java...

Ulrik Suhr

Alene det man ikke kan snakke teknisk hvorfor det er gået galt beviser jo manglen på en ITHK.

  • Hvorfor i alverden kan der ikke foretager små ændringer i arbejdsprocesser/kultur/udviklings trin etc. Så tingene fungere?
  • Hvilke tiltag skal der tages generelt så det næste projekt ikke fejler?
  • Hvor er skrivet som JEG kan læse online hvad der er gået galt med projekt X. Ikke hvad journalister skriver/forstår af en udtagelse.

At blande Prince2 eller andet projekt form ind i debatten hjælper heller ikke. Opfindere af Prince2 har netop indført projekt godkendelses procedurer før de overhoved kan gå i gang!
Det alene fortæller mig at ophavsmændende til Prince2 sætter opgaverne under analyse før de overhoved ser på kravspecifikationerne!
De mener kort og godt at selv om projektet gennemføres og laves som det er tiltænkt så skal det også dække et behov!

Jeg kan stadig ikke forstå hvordan befolkningen kan spises af med de udtagelser og manglende handling fra politisk hold.
Alene det at offentlige myndigheder IKKE er sidestillet med firmaer når de omgås borgernes data er stadig en gåde?

En ITHK vil ikke være magi og gøre alt godt, men det er første skridt så man overhoved kan enes om hvilken vej vi skal gå.

Jn Madsen

Alene det man ikke kan snakke teknisk hvorfor det er gået galt beviser jo manglen på en ITHK.

Jeg tror,- er dog ikke helt sikker på, at du tænker som mig.

Svenskerne indførte med stor succes, på samme tid som os, et system svarende til Polsag.
Til den halve pris som vores mislykkede system.

Såvidt jeg forstår, så satte svenskerne en lille hundfuld garvede brugere sammen med nogle interne systemkyndige folk. De måtte til nogle komplicerede ting købe konsulenthjælp udefra.

Bimbambum ... færdig!!!

Når jeg læser om Polsag (og andre danske katastrofer), bl.a. her i tråden, så læser jeg "Prince2", "bedre analyser", "flere projektledere", "ledelse" .... og når årsagen til fiaskoen skal findes, så er det noget med de samme mennesker skal analysere noget mere.

Det er altså folk der kan og ved, der kan skabe ting der virker. Derfor har svenskerne firmaer som Tetra Pak, de kan lave avancerede jagerfly og meget andet, de kan sågar ryste et "Polsag" system ud af venstre ærme uden problemer ... de sætter bare brugere og systemfolk rundt om et bord, så finder de ud af det.

Jeg krummer tæer ..

Peter Møller

Ideen med ITHK er super forudsat vi bliver ved med, i offentligt regi, at lave disse kæmpe systemer og rewrites gang på gang.

Problemet(det grundlæggende) er IMO udbudsreglerne, nulfejlskulturen og tendensen til ansvarsfraskrivelse i mange off. institutioner.
Kravsspecs er jo i sig selv udgjort af en ikke uvæsentlig portion ansvarsfraskrivelse

Systemet er efterhånden skruet sammen på en måde der fordrer eksistensen af CSC, CGI, KMD, Systematic og ja, the usual suspects.

Hvis man satte det offentlige fri og lod dem vælge IT efter behov(og ikke efter pris) så kom vi et stykke af vejen.
Næste skridt ville være fuld(!) gennemsigtighed overfor hvem der har købt hvad (og hvorfor!) og en annullering af udbudsreglerne!
Lad embedsmænd/afdelinger/chefer/indkøbsafdelinger stå til ansvar for deres IT-indkøb og projekter.
Lad os tilskynde til at off. institutioner i højere grad starter ud med hyldevarer(og evt. tilpasser senere) eller udvikler mindre systemer med åbne snitflader. Eller endnu bedre, starter med interne proof-of-concepts.
Det sidste kan måske sløve udviklingen en anelse, men om et projekt bremses i starten eller slutningen kan vel være lige fedt :)

I særlige tilfælde kan store omskrivninger og leviathanske systemer nok ikke undgåes.
Men det må være muligt at vende tilgangen lidt på hovedet og starte mere i det små.
Så er uheldene, når de indtræffer, i det mindste ikke så omkostningsfulde.

Benjamin Bach

Jeg vil gerne foreslå en it-havarikommission bestående af Jesper Stein Sandal, der på den måde kan lære om arbejdets vigtighed.

Kommissionen skal afdække:

  • Hvordan er det nye version2.dk blevet så ringe udført, at man tolker en tæt på 100% utilfredshed i kommentarsporet?
  • Hvorfor lyttede man ikke til advarslerne?
  • Hvad brugte man så egentlig bruger-testen til?
  • Blev tidsrammerne overholdt?
  • Hvorfor er der stadig ikke SSL?

Etc. Føj selv til listen :)

Beklager spydigheden, men trods alt tak for den ellers gode Version2-journalistik... men den her "Derfor er en it-havarikommission ikke løsningen"-kommentar er sådan lidt fjollet og skulle nok ikke være skrevet... og jeg har det lidt på samme måde med redesignet.

Lars Duelund

Som person der ikke arbejder med IT til daglig (men med glæde brokker mig over alle IT systemer og IT afdelelingen) sidder jeg tænker at sådan en ITHK jo kan koste alverden så hvorfor ikke bare prøve det af? Lad en ITHK se på 2-3 seneste sager og så ved vi om vi lære noget af det. Og hvis sammenligner med fx luftfartern så lære man altid noget vigtig og det er ofte noget men ikke kunne forudse.
Så lad os dog bare afprøve det, hvis vi ikke lære noget så lærte vi det og kan lukke den igen.

Magnus Jørgensen

Jeg har nu arbejdet professionelt med IT i snart 10 år, men jeg er egentlig uddannet Maskine ingeniør. Jeg har derfor en bagage som kan bidrage til debatten om en IT havari kommission og dens arbejde. Resultatet af det arbejde som en ITHK laver, kunne udmærket være en ækvivalent til det som ASTM og ASME laver for mekanisk design. ASME har eksisteret siden 1880 og har siden samlet en masse viden om bedste praksis for mekanisk design i industrien. Mange af det regler er dannet på grundlag af keddel eksplosioner i den tidlige industrialisering hvor dampmaskiner hyppigt blev brugt. Standarderne er meget konservative og sikrer at tiden imellem store havarier er meget lang. Dette betyder dog ikke at der lægges grænser for innovation. Det der gør sig gældende for regel sættet i ASME er at de alle er relateret til faktiske problem stillinger. Hvis man føler sig begrænset af disse regler er det blot fordi man ikke i tilstrækkelig grad tænker ud af boksen.
Industrien har fundet ud af at definere regelsættet i ASME og ASTM således at det er så tilstrækkeligt generisk at man kan konstruere hvad som helst inden for nogle sikre rammer.
Derudover har ASME også udviklet et certificerings system der hedder Boiler and Pressure Vessel Code (BPVC) Sections I, IV, VIII, X, and/or XII. Reglerne for certificering er forskellige fra land til land, men i reglen minder de meget om hinanden.
Pointen er at Tekniske regler og systemer for ingeniører ikke behøver at være en praktisk hæmsko. Tit og ofte er disse regler faktisk en stor hjælp til konstruktører og designere. Det arbejde en ITHK ville lave kunne også gå hen og vise sig at være den samme hjælp.

Magnus Jørgensen

Som eksempler på hvordan et standardiserings arbejde som det ASME og ASTM har udviklet ikke er en hæmsko for udvikling.

  • Du kan designe dit mekaniske apparat i det CAD, CAM system du måtte have preference for. Reglerne vælger ikke platform for dig. Reglerne siger intet om hvilke produkter du må bruge eller ikke bruge. Du kan i princippet tegne i hånden, hvis du er god nok til det.
  • Du kan implementere reglerne for dette design helt manuelt, eller du kan bruge 3. parts produkter som PVElite, VVD eller lignenden, efter eget ønske. Det vigtigste er blot at du kan dokumentere disse implementeringer. Denne dokumentation kan du også helt selv vælge om du laver i et Word dokument, et Latex script, et LibreOffice dokuement eller i ASCII tekst.
    Certificering af den hardware du måtte producere bliver nøje fulgt med stempler og cetificerede inspektører. Hvis der er tale om trykbærende udstyr har man før certificering en tryk test af apparatet.
    Dette er måske ikke helt så relevant for software udvikling, men der kunne sagtens laves nogle ækvivalenter, hvor man tidligt i system design processen har review, senere i processen har inspektion og til sidst en stress test af enkelte komponenter før idriftsættelse.
Claus Jepsen

Når den eneste mulighed for at få finansieret det nye sagssystem er at vælge blandt få godkendte standard FESD systemer, skal det gå galt.

Bevillingen går igennem men kravene fordrer at standard løsningen bøjes og bukkes og voldtages, hvorefter bunkevis af fejl introduceres, performance daler og de fleste arbejdsgange kun understøttes delvist, hvis ikke ligefrem dårligere end før. Men betingelserne for bevillingen er opfyldt uanset om. Det patienten døde.

Niels Henrik Sodemann

Ja, vi kan måske lære, at det ikke går (i et tænkt eksempel) at kombinere Scanjours ESDH med en Microsoft Biztalk Server 2006 og Oracle DB 9, hvis man vil have lave svartider.

Det kunne også være at vi kunne lære at man kunne få lave svartider ifm. ovennævnte (i et tænkt eksempel), hvis man fraveg et ”ufravigeligt” krav en ekstern konsulent havde copy/pastet ind i kravspecifikationen om at transporter til/fra brugergrænseflade, skulle ske asynkront gennem de angivne komponenter.

Tænk nu hvis der faktisk var et projekt, der tidsmæssigt forud for PROASK (i et tænkt eksempel), havde opnået denne læring og at læringen havde været offentlig tilgængelig.

Uden nogen form for teknisk kulegravning bliver vi aldrig klogere.

Finn Christensen

Staten skal have et kontor/ministerium/haverikommision - kald det hvad i vil. Der skal sidde nogle meget dygtige folk. De skal være højeste autoritet. Mere end kontorchefer, projektledere og jurister.

..."For vækst og jobskabelse er de to helt centrale temaer, når man kigger på stærre nationale programmer og projekter. Vurderingskriterierne for at opnå vækst, forandring, forskning og udvikling er i stadig stigende grad, at teknologierne kan bringes til et niveau, hvor de kan skabe effekt på den offentlige sektors bundlinje - og på samfundets, ikke mindst.

Det er helt korrekt at spænde it-teknologi og viden for den vogn. For det er anvendelsen af ny teknologi og viden, som kan give Danmark den fordel, der gør os i stand til at være med globalt.

It-teknologisk Institut (ItI) er en helt central drivkraft for innovationen og teknologianvendelsen i Danmark. Vi har også det nødvendige samarbejde med erhvervslivet."

Ovennævnte (skånsomt tilrettet) stammer fra en nuværende seriøs organisation, der kender og kan sit job. Så det er uendeligt let at skabe det samme for it-sektoren, så sektoren løftes op og så vi slipper for fortsat vi-prøver-lige + rod-og-raven nivau = alle løber derfor helt forventeligt fra ansvaret.

Men der er ikke set en eneste M/K'er på tinge i denne omgang, der har interessen samt de nødvendig hår på brystet, til at løfte opgaven.

Michael Cederberg

Som jeg ser der har vi to kategorier af problemer i denne diskussion:

  • Projektfejl
  • Sikkerhedsfejl

En ITHK vil sikkert være strålende til at belyse de fejl der opstår i projekter. Om ikke andet vil rapporter kunne bruges som autoritativ begrundelse af offentlige beslutningstagere når de vælger hvordan deres projekter skal udbydes og gennemføres. Jeg har selv mine ideer til hvad der går galt med offentlige projekter, men det må vente til en anden gang.

Sikkerhedsproblemer er af en anden kaliber. Jeg mener ikke at en ITHK er den rigtige løsning her af to grunde.

  1. Vi kender allerede til hvordan man laver sikre IT systemer (køberen må så se hvad han har råd til).
  2. En ITHK vil kun slå ned på de problemer der rent faktisk bliver udnyttet negativt.

Istedet bør man have en uafhængig revision af IT sikkerhed. Ikke noget med folk der kommer ind og prøver at lave SQL injection e.lign., men at system ejeren hvert år skal have revideret sin IT sikkerhed, på sammen måde som regnskabet skal revideres. Revisionen skal foregå af en uafhængig instans.

Herudover kan vi så snakke om at drage folk til ansvar hvis der sker noget. For eksempel kan man kræve at en ansat øjeblikkeligt rapporterer et nyopdaget sikkerhedsproblem til sin chef. Og at ledelsen i en virksomhed eller offentlig myndighed kan straffes såfremt de ikke har taget nødvendige skridt til at afdække sikkerhedsproblemer samt fikse kendte sikkerhedsproblemer.

Sidst kan man snakke om at borgere skal kunne anlægge erstatningssag mod virksomheder og offentlige myndigheder såfremt disse har behandlet borgerens data uforsvarligt. Dette gælder også hvis de har udleveret disse til 3. part uden hjemmel.

Dette vil forhåbentligt føre til en kultur hvor man sikrer sine systemer, men måske vigtigere - overvejer hvilke data man har brug for at have gemt. Det ville være rart med en kultur hvor man forsøgte at gemme så lidt som muligt istedet for at gemme alt hvad man kan få fat på.

For eksempel kunne man forestille sig at hospitaler ikke gemte patienters navn, adresse og CPR nummer. At disse istedet lå i nogle få supersikrede systemer. På den måde kunne hospitalernes systemer måske nedgraderes en tand på sikkerhedsskalaen.

Finn Aarup Nielsen

Jeg er ikke overbevist af Sandals argumentation.

Information om at et system bukkede under pga af for mange SQL-kald er relevant at have for en udvikler. Man kunne ligefrem forstille sig et statisk analyseværktøj der talte antallet af SQL-kald og rapporterede det. Eller at det var essentielt fra starten at teste med simulerede data der var af tilpas størrelse som 'real life'.

Påstanden om at agilt eller PRINCE2 udvikling (nævnt i kommentarsporet) skulle føre til bedre software er ikke kvantitativt underbygget. Jeg har for nyligt læst et kapitel i den britiske bog "The Blunders of our Government", hvor de opregner mange it-skandaler fra UK. Jeg formoder deres it-udvikling var styret af PRINCE2 og således er PRINCE2 ikke et gyldent værktøj.

Ud over haverier vil det være relevant at kvantificere succesfulde projekter. Digital tinglysning er mig bekendt et succesfuldt system (hvis man ser bort fra overgangsproblemet med digital signatur). Det har med ført til betydlig effektivisering i tinglysningen, digital adgang for borgerne (og muligvis eksport?). Hvorfor? Hvad adskiller POLSAG og digital tinglysning? Langt færre database-skrivninger? Mindre kompleksitet?

Jeg selv har den uunderbyggede formodning at et it-system succes i høj grad beror på de tekniske kompetencer på begge sider af bordet. Hvis det virkeligt er tilfældet kunne man før man overhovedet går i gang evaluere kundskaberne hos de involverede, f.eks tælle LoC, eksaminere, sørge for certificeringer, undersøge og score tidligere skreven kode.

Log ind eller Opret konto for at kommentere
Pressemeddelelser

Welcome to the Cloud Integration Enablement Day (Bring your own laptop)

On this track, we will give you the chance to become a "Cloud First" data integration specialist.
15. nov 2017

Silicom i Søborg har fået stærk vind i sejlene…

Silicom Denmark arbejder med cutting-edge teknologier og er helt fremme hvad angår FPGA teknologien, som har eksisteret i over 20 år.
22. sep 2017

Conference: How AI and Machine Learning can accelerate your business growth

Can Artificial Intelligence (AI) and Machine Learning bring actual value to your business? Will it supercharge growth? How do other businesses leverage AI and Machine Learning?
13. sep 2017
Jobfinder Logo
Job fra Jobfinder