Arkitekt på Skats EFI-system: Vandfaldsmodel skabte falsk tryghed
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'.
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.
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.
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.
