Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed

Der var ingen Plan B. Alle Skats it-systemer blev udviklet efter vandfaldsmodellen, så der var ingen vej tilbage, selvom den underliggende infrastruktur blev et problem.

Skats EFI-system til at inddrive danskernes gæld til det offentlige blev planlagt som en del af en enorm modernisering af de grundlæggende it-platforme hos Skat. Men Skat arbejdede ud fra vandfaldsmodellen, der ikke gav plads til at stoppe op og lave store ændringer, da kritiske dele voldte problemer for EFI-projektet.

Kristian Mandrup er ét af de øjenvidner til projektforløbet, som nu står frem og fortæller, hvordan han oplevede projektet løbe af sporet.

Version2 bringer her første uddrag af Kristian Mandrups kritik, som ifølge hans opfattelse hænger tæt sammen med en blind tro på vandfaldsmodellen og store leverandører:

Jeg var i sin tid IT-arkitekt hos SKAT på EFI projektet i en kort periode, indtil det kuldsejlede første gang. SKAT var igang med en større omstilling, vi internt kaldte 'Big Bang' modellen. Idéen var at gå væk fra legacy systemer, vendor lock-in og point to point integration. SKAT havde over 100 forskellige systemer der var forbundet på kryds og tværs, en stor rodebutik.

Målsætningen var, at gå over til en Web Service arkitektur, hvor en given service let kan erstattes uanset det underliggende system. Idéen var god nok! Kommunikation mellem systemerne skulle opbygges på en Web service grænseflade (API) og beskeder (data) sendes rundt via en Enterprise Service Bus (ESB). Fordelen herved er bl.a., at man dermed kan udskifte services og desuden centralt monitorere beskeder på bussen. Dvs. man undgår 'point to point' integration, bussen fungerer som en mediator.

En komplet SOA-platform som fremtidige systemer kunne bygges på og dermed spare tid, kræfter og penge. Genbrug af infrastruktur giver altid god mening!

Staten bruger stadig typisk Vandfaldsmodellen for store IT-projekter i stil med store anlægsprojekter i byggebranchen. IT-projekter har langt flere ubekendte, langt mindre transparente og derfor langt større risici. I starten af 00'erne var mange (specielt indenfor Open Source) gået over til Agile Development, hvor et projekt planlægges og udvikles langt mere 'flydende'.

Læs også: Skat-direktør: Vandfaldsmodellen er ikke måden at lave it-systemer på

Jeg prøvede selv at få min chef til at forstå at Vandfaldsmodellen var passé, men fik at vide, at der ikke var alternative muligheder, da et projekt skulle forhåndsbudgeteres. Der var en illusion af, at et projekt udbudt til fastpris og specificeret i detaljer, ville skabe trygge rammer.

SKAT satte nu Titanic projekter i søen, med blind forventning om at et underliggende system ville være klar og parat når det næste blev sat i søen. Imidlertid blev infrastruktur platformen stærkt forsinket og de efterfølgende projekter gik derfor ned med flaget, herunder EFI. Der var ingen plan B.

Læs også: It-professor Søren Lauesen: EFI hang alt for dårligt teknisk sammen med tilknyttede it-systemer (podcast)

Når man som erfaren systemarkitekt/udvikler betragter denne udviklingsmodel, er der en række ting der står i øjnene. For det første bør man aldrig udbyde og bygge et IT system op som en monolit. Argumentet for denne model var, at det var billigere. For alle typer systemer stiger kompleksiteten eksponentielt, systemet bliver uigennemskueligt og det kollapser let.

Specifikationerne på Skats systemer var typisk på mindst 30.000 sider, med hundredvis af Web Service specs, flow diagrammer osv.

Læs også: Derfor gik det galt for EFI-systemet

Infrastrukturen bliver typisk bygget på dyrt indkøbt Enterprise software, fra Oracle, BEA, IBM og Microsoft, hvilket uundgåeligt giver vendor lock-in. Der findes altid Open Source alternativer der er langt mere fleksible og overskuelige. Ofte er der kun behov for en brøkdel af funktionaliteten i et dyrt indkøb Enterprise system.

Devisen lyder: "er det dyrt må det være godt!". Grundet beslutningstagernes manglende viden, er det sikre valg altid den dyreste løsning (og anbefalinger fra Gartner rapporter o.lign). Samme model gælder i øvrigt for drift, hvor indkøbes dyre high-end servere i stedet for at bruge en langt billigere, distribueret Cloud løsning. Ja, der er sikkerhedsaspekter, men alligevel.

Web services kostede typisk mindst 100.000 stykket, også selvom der var tale om en one liner: "Hent Person med et givent personnummer data fra Person tabellen".

En sådan Web service burde typisk kun koste en brøkdel, men beslutningstagerne er lette at narre med smarte fagtermer der får det til at lyde dyrt. Desuden står de ofte i en monopolsituation med en enkelt systemudbyder.

Den skitserede model er langt fra enestående. Samme udviklingsmodel bliver benyttet overalt i det offentlige. Polsag og lignende IT fiaskoer var bygget på samme model og resultatet er derfor ofte fiasko. Problemerne er dybt strukturelle og grunder ikke i manglende specifikationer, planlægning eller styring men i for meget bureaukrati, kompleksitet og deraf manglende fleksibilitet, transparens og IT forståelse.

Version2 bringer senere Kristian Mandrups forslag til bedre løsninger for offentlige it-projekter. Send også gerne konkrete spørgsmål om EFI-projektet på mail eller i debatten.

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

Er det mon fordi det ikke endnu er 110% klart, at komplekse it-projekter ikke kan håndteres som anlægsprojekter eller er der nogen der insisterer mod bedre vidende?

Hos Digitaliseringsstyrelsen fremgår det af at det er et lovkrav at Den fællesstatslige it-projektmodel benyttes til at gennemfører it-projekter (se: http://www.digst.dk/Styring/Projektmodel/Lovkrav-til-it-projekter). Denne medfører så bla. brug af standard kontrakterne (K01, K02, K03)

Hvorfor er det et lovkrav og hvorfor bliver det ikke lavet om?

  • 12
  • 0
Morten Toudahl

Hvornår kommer folk i fængsel for at skade Danmark?

Der har været statistisk evidens for at vandfaldsmodellen ikke virker for software i en hel del år efterhånden.

Hvorfor kan statsansatte så trumfe igennem at det skal foregå på den måde, uden at det har konsekvenser

  • 13
  • 1
Allan S. Hansen

I bund og grund er jeg sådan set lige glad med hvilke modeller og mønstre der benyttes - hvad jeg ser som problemet her er ikke vandfaldsmodellen. Ja ja - jeg ved godt - vi udviklere har vores religioner og ting vi kan lide og ikke lide....
Men det reelle problem her er et system der forsætter på trods af advarsler igen og igen i det offentlige; projekt efter projekt.
(Og ja, der er sikkert mange private virksomheder der fejler, men der er det ikke skattekroner, der er virksomheden kun ansvarlig overfor deres interessenter)

Hvis ikke der lyttes og reageres på input fra dem der ved noget og sidder med fingrene i maskinrummet; så kunne hvilken som helst udviklingsmodel - også de agile - blive benyttet mens resultatet sandsynligvis ville være det samme.

Og at det så sættes i drift på trods af tilsyneladende massive advarsler, understreger blot at på toppen ledes der med skyklapper på.

  • 13
  • 1
Bjarne Nielsen

Der har været statistisk evidens for at vandfaldsmodellen ikke virker for software i en hel del år efterhånden.

At blive ved med at gøre det samme og forvente at resultatet af sig selv bliver bedre, er i bedste fald fra stædighed. Til gengæld kan man ikke bruge det, at en metode fejler, til at mene, at en anden vil være bedre (uden at pege på, hvor den vil gøre en forskel).

Og præcis her er jeg bange for, at der ikke er tale om, at opgaven bliver løst på den forkerte måde, men at der er tale om den forkerte opgave til at starte med. Selv den bedste metode i universet må give fortabt overfor den forkerte opgave.

  • 8
  • 0
Henrik Mikael Kristensen

Man må starte med et meget beskedent sæt features, som f.eks. det 3 mand kan udvikle på en måned, hvor der er relativt stor sikkerhed for, at man får de one-liners, man skal have.

Desuden må man så fortælle politikerne, at nu er vi blevet godt våde af at stå i den her vandfaldsmodel. Artiklen kunne være skrevet for 15 år siden uden ret mange ændringer.

  • 3
  • 0
Anne-Marie Krogsbøll

Fokus er tit - forståeligt - på de mislykkede projekter - skandalerne. Det er nærliggende at ønske disse dissekerede, og det synes jeg da også er en god ide.

Men måske skal man oprette en "evalueringsinstitution", som analyserer både de kuldsejlede projekter og de succesfulde, som ifølge tidligere kommentarer i andre tråde også findes i det offentlige?

På hvilke måde ligner de succesfulde og de mislykkede projekter hinanden?
På hvilke områder adskiller de sig?
Er der særlige træk ved de succesfulde projekter, som kunne overføres til de mislykkede, så disse kunne være blevet vellykkede?
Er det størrelsen, der adskiller dem?
Måden, projektet er organiseret på?
Styresystemet?
Ressourcerne/økonomien?
Politisk indblanding?
Ledelsesstil?
Projektkultur (agil eller kravspecifik eller kollison mellem disse)?

Kan vi ikke lære en masse af de vellykkede projekter, som kan genbruges i andre store projekter, og som det derfor også er vigtigt at få indkredset, i stedet for kun at analysere de mislykkede projekter?

  • 6
  • 0
Chresten Christensen

Problemerne er dybt strukturelle og grunder ikke i manglende specifikationer, planlægning eller styring men i for meget bureaukrati, kompleksitet og deraf manglende fleksibilitet, transparens og IT forståelse.
Ok lad os tage udgangs punk i at det er nogenlunde rigtigt.
Man forstår godt at folk løber skrigende bort fra det offentlige, men man må arbejde, med hvad man har. Og der er absolut muligheder her, som ikke findes i det private.
1) Muligheder for samarbejde på tværs af flere offentlige instanser; hvis vi under en størrer it-projekt, skal bruge eksempelvis; en sikker og simple tilgang til CPR registeret for at checke dit eller dat. Kan det måske være en god ide at snakke med andre afdelinger som måske kan tænkes at skal bruge en ækvivalent løsning på dette problem, kan et samarbejde her måske vær en ide, da det giver mulighed for at lave en fælles indkøb, eller et fælles mini projekt(billiger)
2) Korrekt opdeling af projektet; vi ser af 1) at den rigtige opdeling af projektet er yders vigtig. Og brugen af standardiseret produkter fra leverandør også kan have en indflydelse på snit fladerne i projektet. Brugen af OpenSource løsninger her ligger lige for, og er absolut en god løsning der kan intrigeres i projektet , og kan bruges som API snit flade.
3) Legasy kobling; hvis det er muligt at tilgå et eksisterende system eller dele af dette. Kan det også være en fordel, da det give mulighed for en gradvis udrulning af projektet.
4) Gradvis implementering; hvis man har opdelt projektet, som 1) 2) 3), behøver man ikke en store kontrakt, men en masse små, som give mulighed for at bremse et projekt før det bliver at for dyrt. Og penge er ikke spildt hvis man har samarbejdet med andre, offentlige instanser.
OSV...

  • 0
  • 0
Lars Jensen

Når man læser alle ovenstående indlæg om hvordan det kunne have været gjort, så er det imponerende at staten gang på gang laver kontrakter med nogen der tilsyneladende intet fatter mht. styring af projekt, tid eller økonomi.

Der må sidde 500 IT-konsulenter derude et sted og føle sig nedgjort. Hvornår tager de til genmæle?

  • 3
  • 0
Anne-Marie Krogsbøll

Det kan være, at det er mig, der misforstår diverse indlæg, i så fald beklager jeg, men jeg opfatter dem mere som rettet mod lagene over IT-konsulenterne, de lag (helt op på ministerniveau?), som tilsyneladende ofte vælger at overhøre IT-konsulenternes gode råd og advarsler.

Og derudover som en faglig diskussion om, hvad der er bedste måde at gribe denne slags projekter an på. Det er vel helt legalt at have divergerende meninger om, især når der er tale om groft kuldsejlede projekter.

  • 2
  • 0
Henrik Sørensen

Infrastrukturen bliver typisk bygget på dyrt indkøbt Enterprise software, fra Oracle, BEA, IBM og Microsoft, hvilket uundgåeligt giver vendor lock-in. Der findes altid Open Source alternativer der er langt mere fleksible og overskuelige. Ofte er der kun behov for en brøkdel af funktionaliteten i et dyrt indkøb Enterprise system.

Jeg kan ikke rigtig se, at det har nogen relevans om softwarestakken er proprietær eller Open Source. Der er lavet - og bliver fortsat lavet - fantastiske løsninger på software under begge forretningsmodeller.

Der er vel ikke mange, der vil påstå, at Open Source er en særlig slags woodoo software, som får alle projekter til at lykkes eller at brug af Microsofts eller IBMs software er lig med at dødsdømme et projekt fra fødslen...??

På samme måde er der næppe tale om et større eller mindre vendor lock-in ... er løsningen baseret på PostgresSQL (Open Source) med en stribe add-ins fra forskellige udviklere, så sidder man lige så meget i saksen, som hvis man havde valgt Oracle eller noget andet købe-software.

Der findes dygtige folk i alle lejrene, som hver især kan få deres foretrukne platform til at yde max. og som er i stand til at løse de mest komplekse tekniske udfordringer.

Jeg tænker, at svaret derfor næppe findes i valget mellem den ene eller den anden platform eller i brugen af Open Source eller ej.

Jeg noterer til gengæld, at anvenderne (brugerne), forretningen og rammebetingelserne (fx kompleks lovgivning) kun i begrænset omfang bringes ind i debatten.

Kigger man mod England og Estland, som har gjort noget væsentligt anderledes end os mht. offentlig it, så er det netop disse forhold de har haft fokus på og som de tilsyneladende har succes med at sætte i centrum.

UK har lavet en offentlig projektmodel med brugeraccept som det centrale omdrejningspunkt i de forskellige projektfaser og betinget, at anvenderne siger god for resultatet af en fase, før man kan fortsætte (og få penge) til den næste fase.

I begge lande (med Estland som nok er længst fremme) har man taget skridt til at tilpasse, forenkle og modernisere lovgivningen, hvilket bl.a. har medført stærkt reduceret snyd med bl.a. moms.

Herhjemme er der dog også gode initiativer i gang. Justitsministeriets chefjurist har sammen med Digitaliseringsstyrelsen sat fokus på, at der fremover skal jurister med i hele forløbet omkring nye løsninger - fra idé til færdig kørende løsning.

Formålet er, at juristerne skal være med til at sikre at løsningen ikke bare er teknisk fungerende, men at de processer den understøtter også er lovmedholdelige. Netop den manglende lovmedholdelighed var det som væltede EFI i sidste instans.

Jeg er helt overbevist om, at vi kan gøre mange ting bedre og fx Henrik Mikael Kristensens indspark om at starte småt (least viable product tankegangen) er givetvis et skridt i den rigtige retning.

Måske vi kunne forsøge at pege på og debattere de gode løsningsdele?

Hvilke andre tiltag har du oplevet som værende succesfulde i de projekter du har deltaget i, og hvilken værdi skabte de?

/Henrik

Disclaimer: Jeg er ansat som Enterprise Arkitekt hos KMD, men skriver i egenskab af privatperson. Alle kommentarer og holdninger jeg giver udtryk for, er derfor mine egne og er således ikke et udtryk for KMDs holdning til - eller opfattelse af - et givent emne.

  • 9
  • 3
Lars Jensen

men jeg opfatter dem mere som rettet mod lagene over IT-konsulenterne, de lag (helt op på ministerniveau?), som tilsyneladende ofte vælger at overhøre IT-konsulenternes gode råd og advarsler.

Men det aner vi vel dybest set ikke noget om?
Det kunne være udulige konsulenter der bare har haft snablen nede i statskassen. Lad os kalde det byggesjusk eller ikke håndværksmæssigt korrekt udført.
Det nemmeste er at skylde skylden på politikkere - og helst dem fra en tidligere regering. Jeg mener at skylden i høj grad skyldes dårligt udført arbejde.

  • 0
  • 0
Anne-Marie Krogsbøll
  • 3
  • 0
Niels Henrik Sodemann

England og Estland, som har gjort noget væsentligt anderledes end os mht. offentlig it

Begge lande er medlem af EU (lidt endnu...). De er derfor underlagt samme EU lovgivning omkring udbud som Danmark. Hvis EU lovgivning praktiseres væsentlig anderledes tyder det jo på at vores Danske fortolkning ikke er helt så fastlåst som man ofte får indtryk af.

Vi bliver nød til at een gang for alle at få konstateret at big-bang vandfaldsprojekter ikke nytter på de store komplekse statslige it-projekter.

Det har være kendt / dokumenteret minimum siden Bonnerup rapporten som må antages at have været kendt i minimum 10 år.

At blive ved at fastholde den eksisterende måde at udføre projekterne på, kan alene begrundes i dyb inkompetence / manglende lytten til branche / eksperter eller imod bedrevidende. Jeg har aldrig hørt en leverandør eller en leder i en statslig it-indkøber udtrykke andet end at anlægsparadigmet er dybt godnat.

Da der er en lov, der foreskriver at it-projekterne skal ske som et anlægsprojekt. Step 1A, være at de ansvarlige til at forstå problemstilling / acceptere at få lavet den lov om!

Herefter kan man så, f.eks. ved at lytte til gode erfaringer fra udlandet, få tilpasset vores lovgivning til den virkelighed som er forbundet med it-projekter.

  • 2
  • 1
Kristian Mandrup

@Henrik Der er flere måder at benytte Open Source. Det kan give stærkt øget transparens, hvor hele IT danmark løbende kan følge med, f.eks hvis det offentlige vælger at offentligøre de enkelte moduler/systemer der udvikles i offentlig tilgængelige repositories. En anden model er bare at benytte visse Open Source løsninger i en ellers lukket udviklingsmodel. Det sparer kun lidt penge til licenser og evt. udviklingsomkostninger.

PS: Senest har Bulgarien meldt ud at de vil kræve at offentlig IT bliver open source:

http://www.techweekeurope.co.uk/projects/public-sector/bulgaria-open-sou...

@Henrik Helt enig. Vi bør klart se på hvordan de gør i Estland og England og lære af deres erfaringer.

@Henrik Jeg har svært ved at se at flere Jurister skulle hjælpe. Vi var også i tæt kontakt med SKATs Jurister under hele EFI forløbet. Det gik helt galt på et tidspunkt, hvor Juristerne (uden at rådføre sig med IT afdelingen), skrev under på, at vi ikke fik koden som en del af løsningen. Juristerne kunne ikke se hvad vi dog skulle bruge koden til. Denne beslutning betød endnu en gang et "black box" system med vendor lock-in.

  • 3
  • 0
Rolf Kristensen

Det er ganske irriterende at man bare ved at næsten alt erfaring er væk. Det sker at prototyper ender i havet, selvom nogen kan være dyrt købte. Desværre med udbud, så er værdien af prototypen også forsvundet, da det næste udbud igen starter forfra med nye eksterne konsulenter.

  • 0
  • 0
Kristian Mandrup

Generelt er det et stort problem, at Staten alt for ofte bruger (store og dyre) konsulentfirmaer og leverandører, der har en interesse i at gøre projekterne så dyre som mulige i (blind?) tro på at de vil hjælpe dem sikkert i mål!

Samme strukturelle problem har jeg set i bl.a Council of Europe, som teknisk projektleder "indefra". Der er en kraftig tendens til "kammerateri" i forholdet mellem kunde og leverandør og deraf "vennetjenester". Det er helt almindeligt at man spiser frokost sammen, eller andre sociale arrangementer...

Jeg har desuden selv arbejdet for (dyre) konsulentbureauer som pre-sales/teknisk konsulent. I den rolle er der selvklart en personlig (bonus) interesse i at sælge mest muligt til kunden. Derfor sælges de de dyre Enterprise pakkeløsninger uanset om det reelt er det kunden har brug for. Kunderne (herunder offentlige organisationer) forstår sjældent hvad de har brug for og køber derfor oftest hele "katten i sækken" for at være på den sikre side.

  • 5
  • 0
Kristian Mandrup

@Rolf Præcis! Problematikken omkring prototyper angriber jeg som et punkt i næste artikel der giver bud på bedre løsningsmodeller ;)

I øvrigt er det offentlige igang med en omstilling over til Agile Development og mere agile projektmodeller generelt. Denne artikel beskrev forholdene i ca. 2008.

  • 0
  • 0
Henrik Lauridsen

Generelt er det et stort problem, at Staten alt for ofte bruger (store og dyre) konsulentfirmaer og leverandører, der har en interesse i at gøre projekterne så dyre som mulige i (blind?) tro på at de vil hjælpe dem sikkert i mål!

Min erfaring i forbindelse med tilbudsarbejde er nu ellers det modsatte. Som leverandør er der et konstant fokus på at få kompleksitet og pris ned, så man har en chance for at vinde opgaven. Det er rigtigt at kundens rådgivere nogle gange går skævt af opgaven og stiller krav til en løsning, som er for høje i forhold til behovet. Den slags kan godt være svært at adressere ved offentlige udbud, da kravene som regel er mindstekrav. Jeg har været ude for at vi via spørgsmål/svar har fået en kunde til at tilpasse kravene (dette gælder så naturligvis for alle som byder), men det er sjældent.

  • 1
  • 0
Rolf Kristensen

Hvis man har brug for en acceptance-test, så vil man automatisk køre vandfald. Der vil være sat en deadline for hvornår udviklerne leverer et skrabet system til accept-test (og data-import-test). Man kan kalde det små vandfald, men man slipper ikke for en godkendt aflevering.

Hvad udviklerne så vælger at gøre for at nå denne deadline kan de selv bestemme, om det er pisk, gulerod eller SCRUM.

Det er jo kun ved inhouse systemer at man måske kan regne med at udviklerne kan finde ud af at gennemføre continous integration, og vedligeholde regression tests. Ved udbud kan man kun stole på sin egen accept-test, specielt fordi man vælger det billigste tilbud.

For mig tager implementering af fejl-håndtering, unit-test, integration-test normalt tager længere tid end den egentlig forretnings logik. Hvorefter værdien af udbud pludselig udvandes hvis det er nyudvikling af et komplekst system.

  • 0
  • 0
Bent Jensen

Juristerne kunne ikke se hvad vi dog skulle bruge koden til.


Så er det da allerede nu nogen som man kunne fyre, som ikke har været deres arbejde og ansvar voksen.

Men måske er løsningen, bare at fyre og lukket hele SKAT.
Det kan sagtes lade sig gøre, der går jo ikke år imellem at hele styrelser eller ministerierne bliver flyttet, sparet væk, omrokeret eller lagt sammen.

Også starte med TOPPEN, med ny ledelse og struktur, alle medarbejder under et hvis level kan selvfølgeligt, søge arbejde i det nye styrelse. Men ingen som har haft deres hænder i denne sag, heller ikke firmaer eller leverandør må være genganger.

Det er bare så synd hvordan topstyringen fra politiker, med en ledelse som har slikket dem i r.... (men for gode penge) har ødelagt SKAT. De var på forkant med EDB løsninger man skiftet til frivilligt, fordi det var nemmere, og hurtigere.
Men succes steg nok ledelsen til over hovedet, og da de lavest hængene frugter var plukket, så fældet man træet for at komme til resten.

  • 0
  • 0
Log ind eller Opret konto for at kommentere