CSC ville få 33 millioner om året for at drive Polsag – og måtte være nede i dagevis

Var det kuldsejlede Polsag-system kommet i luften, havde det kostet politiet 33 millioner om året i drift og vedligehold til CSC. Den lovede oppetid var på 99,0 procent, svarende til flere dages nedetid om året.

Politiet fik aldrig et nyt, centralt it-system til sagsbehandlingen, for Polsag-projektet endte med at køre af sporet og blev stoppet endegyldigt i begyndelsen af februar af Justitsministeriet.

Men havde CSC fået leveret et produkt, der virkede godt nok, kunne politiet se frem til en årlig regning på drift og vedligehold på 33 millioner kroner.

Læs også: Konklusion af Polsag-review fra 2009: Elendig kode hånd i hånd med elendig kontrakt

Det viser den evaluering af Polsag-projektet, som blev gennemført af Boston Consulting Group i 2009. Konsulentrapporten er blevet mørklagt af Justitsministeriet, men det er lykkedes Version2 at skaffe et eksemplar.

Læs også: Så oldnordisk er politiets it-miljø: Nostalgisk gensyn med 1980’erne

Mens det gamle Polsas - som politiet nu altså må fortsætte med at bruge i lang tid endnu - koster 17,9 millioner kroner om året at få CSC til at drive, var prisen for driften og vedligehold af Polsag sat til at være næsten dobbelt så høj.

33,3 millioner kroner lød kontrakten med CSC på i årlige driftsudgifter, delt op i 1,5 millioner til licenser, 16,8 millioner til drift, og 15 millioner om året til vedligehold og opgradering.

En del af forklaringen på den højere pris er ifølge Rigspolitiet, at den garanterede oppetid for Polsas er på 98,0 procent, mens det nye Polsag skulle være tilgængeligt mindst 99,0 procent af tiden, dog 99,5 procent i dagtimerne.

Det svarer til, at politiets nuværende, helt centrale it-system kan være offline samlet set seks dage om året, uden at leverandøren CSC bryder kontrakten.

For Polsag svarer den garanterede oppetid til, at systemet måtte være offline i 54 timer om året, mere end to døgn i alt.

I timerne 7-24, hvor der er mest brug for systemerne, er kravet et halvt procentpoint højere for begge systemer, altså 98,5 procent for Polsas og 99,5 procent for Polsag.

Polsag-projektet, der nu er stoppet efter en regning på en halv milliard kroner, kom hurtigt i problemer, og forløbet og det foreløbige produkt fra CSC blev derfor underkastet et eksternt review både i 2009 og i 2011.

Læs også: Grotesk jobinterview i 2007: »Tag ikke jobbet, vi får alligevel aldrig Polsag til at virke«

Den seneste rapport, der blev afleveret i begyndelsen af januar 2012, efter ni måneders arbejde, var baggrunden for, at Justitsministeriet trak stikket ud for Polsag. Men rapporten bliver holdt hemmelig af staten. Rapporten fra 2009 er heller ikke offentligt tilgængelig.

I artiklen blev det tidligere antaget, at den laveste oppetid - henholdsvis 98,0 % og 99,0 % for Polsas og Polsag - gjaldt som minimum generelt. Tallet for samlet tilladt nedetid er nu ændret, så det afspejler kravet om højere oppetid i timerne 7-24. Version2 beklager fejlen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (17)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 Michael Lykke

Hvad skal der til før vi kan forhindre at CSC bliver involveret i flere offentlige projekter... De er jo en fiasko af format, men vi hælder milliarder af kroner i lommen på den ene leverandør som år efter år røvrender den danske befolkning! Vi hælder skattekroner i det ene projekt efter det andet som de ikke formår at levere og selv de projekter de formår at levere 25% af ender med fuldstændig sindssyge driftsomkostninger!

Er vi virkelig så dumme at vi ikke kan se at de er fuldstændig ligeglade - De score jo 400 millioner på et projekt der fejler!

  • 7
  • 3
#2 Henrik Sørensen

Det kniber helt og aldeles med regnestokken og dermed er jeres konklusioner

Der er vist stadig 24 x 365 = 8760 timer om året.

Oppetid på 99,5% (07-24) => 17 x 365 = 6205 timer om året 0,5% af 6205 = 31,025 hvilket giver en max. nedetid på 31,025 timer

Oppetid på 99,0% (00-07) => 7 x 365 = 2555 timer om året 1% af 2555 = 25,55 hvilket giver en max. nedetid på 25,55 timer om året

Samlet maksimal nedetid om året = 56,575 timer.

I skriver:

For Polsag svarer den garanterede oppetid til, at systemet måtte være offline i 87 timer om året, mere end tre et halvt døgn.

Det er således forkert at regne med 87 timer som opstår hvis man regner med 99% hele døgnet rundt. Dermed er det en helt forkert slutning I drager.

Kontrakten er sandsynligvis indgået på SKI 2.22 vilkår hvor ovenstående oppetider er helt normale. Faktisk er det bedre end standard SKI vilkår.

Artiklen bærer desuden præg af at forfatteren nok har lidt at lære om driftskontrakter. Normalt vil oppetidsgarantien blive målt på uge- eller månedsbasis, samt på årsbasis og det vil derfor ikke være muligt at være nede i 56,575 timer i streg uden bod men derimod højst ca. 4,7 timer om måneden hvor der altså også skal gennemføres patchninger og andet planlagt vedligehold + være tid til retablering hvis det skulle vise sig at noget går galt under vedligeholdet.

Man kan altid diskutere pris, men inden man falder ned af stolen over de nævnte priser så skal man huske at indregne omkostningerne til døgnovervågning, dublerede datacentre, ekstremt hurtige backupsystemer, redundant diskplads, redundant køling, redundant strøm, redundant hardware og alle de teknikere der er involveret i at etablere og vedligeholde løsningen, samt andre omkostninger der ligger ud over det 'bare' at drifte serverene.

En kunde som Politiet køber den SERVICE at deres SYSTEM er kørende og skal normalt ikke forholde sig til antallet af servere, priser på HW, mængder af RAM eller andet - det er leverandørens opgave.

Kunden skal i øvrigt altid afveje hvordan han ønsker at bruge de midler han har til rådighed ... han kan bede om at få en oppetidsgaranti på 99,8 eller 99,9 og betale meget mere for den fordi den er svær at overholde i praksis eller han kan vælge at bruge den merpris på fortsat udvikling i stedet. Umiddelbart ser det ud som om Politiet har valgt fornuftigt her.

  • 8
  • 0
#3 Nils Bøjden

Der er mere og mere der taler for at staten skal anskaffe/drive cloud service for stort set alle statslige institutioner. Dette ville endvidere sikre os mod alle disse idiotiske diskussioner og usikkerheder angående "Patriot Act".

Hos Amazon kan man købe drift af server 10x Ekstra large = 18000 US$/år

(extra large = 8 cpu/15GB RAM/1.6 TB harddisk), Gang selv med 10.

Jeg vil tro at det ville kunne drive et system som Polsas

  • 1
  • 7
#4 Michael Christoffersen

Jeg ved nu ærlig talt ikke om jeg synes godt om at politiets databaser kommer ud i skyen, og gemt på en server i USA. I øvrigt garanterer Amazon jo kun en oppetid på selve hardware/styresystemet. Af gode grunde kan de jo ikke garantere en oppetid på en specifik applikation.

Hvor mange brugere skulle der være på systemet? Prisen er vel ikke særlig høj hvis man dividerer med antal brugere... At systemet så ikke kunne håndtere sagen er jo en helt anden sag.

Kan bare ikke rigtig se nogen historie her.

  • 6
  • 1
#5 Nils Bøjden

Jeg ved nu ærlig talt ikke om jeg synes godt om at politiets databaser kommer ud i skyen, og gemt på en server i USA.

Og derfor foreslog jeg at staten skulle drive sin egen sky/cloud/mainframe/ (eller hvad en sådan dims kaldes nu om stunder). Jeg synes også at brug af USA baserede systemer er en uheldig situation for danske statslige virksomheder.

Amazon var med for at give et pris eksempel på server kapacitet i en sky

  • 2
  • 1
#7 Henrik Sørensen

Hej Nils

Den grundlæggende forskel på cloud og traditionelt virtualiserede miljøer er at kunden i cloud miljøerne selv kan provisionere sine servere og vælger mellem en række forud-definerede standardtilbud. Dermed kan kunden løbende tilpasse kapacitet til behov uden at skulle indblande leverandøren i nævneværdig grad.

Dermed egner cloud sig i høj grad til hyldevarer, men knap så godt til komplicerede systemer som PolSag med mange afhængigheder til andre systemer.

Og lige netop hvor meget leverandøren skal indblandet gør den helt store forskel. Det er relativt overkommelige for alle større leverandører at levere rå serverkapacitet med høj oppetid til en billig penge ... det svære er at få at det der skal ligge ovenpå til at spille sammen og at tage ansvaret for det. Det er det som i realiteten koster alle pengene.

Teknisk set er det de samme virtualiseringsservere der står bagved og der er ingen tvivl om at du vil se Cloud som et tilbud fra alle de store leverandører både udenlandske og danske - KMD var for eksempel allerede i oktober sidste år ude og fortælle om lanceringen af en dansk cloud til det offentlige; men cloud er desværre ikke svaret på de centrale behov i denne slags systemer.

Når du sammenligner Amazons cloud priser med CSCs priser så er det en fin provokation - som da absolut skal få leverandørerne op på mærkerne - men du skal også være opmærksom på at du forsøger at sammenligne to ting der grundlæggende er vidt forskellige og derfor er sammenligningen sjov men også lidt meningsløs.

/Henrik

  • 6
  • 0
#8 Nils Bøjden

Den grundlæggende forskel på cloud og traditionelt virtualiserede miljøer

Jeg ser egentlig cloud services som en smidiggørelse af de virtualiserede miljøer. Og cloud er heller ikke andet en virtualiserede servere tilføjet den service at brugerne selv kan provisionere op/nedgraderinger af deres systemet.

De operativ systemer en fleksibel løsning som Amazon er baseret på ville formodentlig dække de behov som et statsligt cloud center også skulle tilbyde.

Så at sige at cloud er noget andet end det politiet har behov for er jeg ikke enig med dig i. Jeg er så overbevist at jeg tør vædde en flaske Amarone på at Polsag (Scanjour/Captia) med dens platform i diverse MS og Oracle teknologier uden problemer kunne køre på en Amazon Cloud.

  • 0
  • 0
#9 Henrik Sørensen

Hej Nils

Tak for udfordringen men jeg tror desværre at du kommer til at tabe din Amarone.

Til drift af Captia og de tilhørende Oracle databaserne som ligger bagved kræves langt langt mere kraft end det du kan få ud af en Amazon server, hvis svartiderne skal være bare nogenlunde humane.

Til en installation som PolSag med mange tusinde brugere har du brug for at køre Oracle på noget meget stort isenkram, som fx under AIX på IBMs Power 700 platform for at få tilstrækkelig med rå performance og her er en Amazon server med sine 15Gb ram og virtualiserede cores en dværg ved siden af. En anden sag er omkostningerne til licenser til Oracle som gør det helt håbløst dyrt at drive et setup i den nødvendige størrelse på servere i Amazon klassen ... men det er en helt anden snak.

Jeg vil derfor opfordre dig til at tjekke de faktuelle krav til løsningen hvorefter du blot kan sende mig Amaronen i en velemballeret pakke.

Selvom det er hyggeligt at diskutere drift og dimensionering så var mit første indlæg i debatten dog rettet mod de faktuelle fejl i artiklen hvor jeg synes at Version2 skylder at have grundlaget i orden inden man skriver en så farvet artikel som det aktuelt er tilfældet.

Der er ingen tvivl om at PolSag er godnat (i flere betydninger), men når man kritiserer skal man have et ordentligt fundament at stå på og det kniber her. Det fremgår for eksempel af artiklen, at driften af det gamle system kostede 17,9 mio. kr. mens det nye koster 33,3 mio. kr. men det er ikke korrekt ... som det faktisk fremgår så koster DRIFT af PolSag (nye) 16,8 mio. mod 17,9 mio.for PolSas (Gammelt). Så i realiteten er overskriften for artiklen helt i skoven og er med til at forvanske billedet og det er der ingen af os der er tjent med.

/Henrik

PS: Hiv bare proppen af Amaronen i aften og send mig en hyggelig tanke når du drikker min vin.

  • 2
  • 0
#10 Nils Bøjden

Hej Henrik

Tak for de uddybende svar.

Mener du virkelig at PolSag ikke ville kunne køre på 40/80/120/160 virtual Amazon cpu (det dobbelte i EC2 Cpu units) maskine med 150/300/450/600 GB RAM?

  • 0
  • 0
#12 Henrik Sørensen

Hej Nils

Jeg kender ikke de nøjagtige database størrelser på PolSag men så vidt jeg lige kan se (gør mig bare klogere) så er max hos Amazon en "Cluster Compute Eight Extra Large Instance" og den svarer vist til en middelstor almindelig 2-vejs XEON slæde med 8 cores og ca. 60 GB RAM (korriger mig hvis jeg tager fejl) og det er altså ikke nok til at trække Oracle til Captia i den størrelsesorden som PolSag skal bruge. Der skal angiveligt nogle stykker af den slags til og så bliver alene prisen på Oracle så eksorbitant at løsningen ikke er relevant.

Jeg erkender meget gerne at jeg ikke kender alle Amazons muligheder men umiddelbart kan jeg ikke se at jeg kan få noget der er større end dual ZEON

Det vil sikkert kunne lade sig gøre rent teknisk at køre det hos Amazon men det vil næppe være økonomisk forsvarligt og alene linjekapaciteten og pålideligheden vil være en udfordring oveni alle de andre ting som man vil skulle forholde sig til.

/Henrik

  • 1
  • 0
#13 Nils Bøjden

Jeg erkender meget gerne at jeg ikke kender alle Amazons muligheder men umiddelbart kan jeg ikke se at jeg kan få noget der er større end dual ZEON

Der er konsulentvirksomheder som er ved at specialisere sig i at hjælpe med at generere disse multicpu instances hos amazon.

arstechnica.com/business/news/2011/09/30000-core-cluster-built-on-amazon-ec2-cloud.ars

Så der er vist frit slag i bolledejen.

Den slags hjælpemidler kommer vel til alle cloud service udbyderne.

Det er ikke ment som en reklame, tværtimod som en opfordring til at staten starter på en lignende opsætning til at hjælpe alle de styrelser, direktorater, ministerier, sygehuse, kommuner og regioner som uvægerligt vil komme i karambolage med persondataloven hvis de skal billiggøre deres IT drift.

  • 1
  • 0
#14 Morten Andersen

Når nu det i flere indlæg anføres at Polsag ville kræve enorme mængder af regnekraft og RAM, er det da ud fra en abstrakt betragtning om hvad et sådant system kræver eller er det ud fra den konkrete CSC/Scanjour implementering?

For når jeg tænker på selve kravene til systemet har jeg svært ved at forstå de massive krav. For at få tal på, vil jeg skønne systemet totalt vil have 10.000 brugere (ikke samtidige) og (skønsmæssigt) 10.000.000 sager totalt.

Jeg kan for det første ikke forstå at DB'en kunne være et problem! Hvor komplicerede forespørgsler er der tale om? Langt de fleste forespørgsler er sikkert direkte på sagsnummer. De forespørgsler kan konceptuelt klares med en hashtabel d.s. næsten gratis, i hvert fald i CPU termer. Jeg kan forestille mig der er behov for et par andre indexes f.eks. personer (d.s. yderligere et par hashtabeller). Dertil kommer lidt mere sjældne typer af opslag f.eks. fritekst søgning. Det kræver tekstindeksering af databasen hvilket er en meget velkendt problemstilling med særdeles effektive algoritmer til såvel opdatering og søgning af databasen. De vil være i logaritmisk tid i.f.t. databasen. D.s. ikke helt så billige som hasherne men der vil givet være væsentligt færre af dem, så jeg tvivler på det er et problem.

Jeg kan simpelthen ikke se at en database af den karakter kan kræve de enorme AIX-maskiner der nævnes. I så fald burde man droppe databasen fuldstændigt og sætte sig ned og kode en simpel og light-weight selv til netop dette system. Det ville skønsmæssigt tage en dygtig datalog maximalt et par uger. Så sparer man også for Oracle's enorme licensomkostninger.

Er der nogen af jer der har set Scanjour i funktion? Det er reelt bare et system med nogle tekstfelter med vedhæftede dokumenter. Ikke det store datalogiske ridt. Det største performancemæssige problem er formentlig diskadgang og netværk. Netværk er et nødvendigt onde (men en "fed" klient, og dette kan godt være AJAX, kan naturligvis hjælpe en hel del). For diskadgang købes SSD'er. Ikke hele DB'en behøves være dækket af SSD'er. Jeg forestiller mig at SSD'erne fungerer som en slags cache for den rigtige database (men databasen skal naturligvis være fuldt søgbar ud fra infoen i SSD'erne). Det er fuldt acceptabelt at det tager nogle sekunder at hive en "gammel" sag frem, hvis de efterfølgende forespørgsler tilgengæld er hurtige indtil sagen swappes ud igen. Med maximalt 100.000 aktive samtidige sager og med 10MB per sag så taler vi ca. 1TB der skal backes af en SSD, d.s. omkostningerne er peanuts.

Hvordan forestiller folk sig at systemer som Facebook og Google fungerer? De har immervæk en 5-6 størrelsesordener flere brugere og ditto data (mindst) og det skalerer fint til cloud. Disse systemer fungerer fordi skaberne har tænkt over hvad der konkret skal udføres af beregninger for at udføre systemets opgaver og har designet derefter. Fremfor at "shoe-horne" en masse overkomplicerede standardprodukter ind som typisk ikke skalere eller passer 100% til kravene. Standardprodukterne kan forsvares i nogle situationer hvis udviklingen skal gå hurtigt og en evt. benefit ved selv at skrive det er minimal. Dog er der ingen garanti for at brug af standardprodukter forkorter udviklingstiden, det kan tværtom gå stik modsat. Se bare hvor mange år PolSag tog at implementere - på basis af standardprodukter!

Jeg tror dog slet ikke cloud tankerne er nødvendige. Hvis vi forudsæter en semi-fed/rich klient applikation (evt. AJAX applikation) vil jeg blive forbavset (efter lidt back-of-an-envelope-math og estimater af antal forespørgsler per bruger per dag) hvis ikke hele systemet kunne afvikles på en enkelt commodity maskine med 2 high end CPU'er, til en skønsmæssig pris på under 15.000 kr. ekskl. diske.

  • 4
  • 2
#15 Michael Olesen

Jeg tænkte noget af det samme da jeg læste

...16,8 millioner til drift...

Årligt! Med døgnbemanding af 2 personer udelukkende til denne applikaton/servere, og på 2 forskellige (redundante) lokationer, bliver det til 6 mio. pr år i drift (med en årsløn på 500.000 kr pr medarbejder). Dertil kommer lokalerne til serverne (læs "husleje", køling, brandslukning, m.m.). Når jeg tænker på hvad man kan få sin egen server i lignende lokaler, så lyder det som en meget god forretning for CSC (læs penge ud af borgernes lommer). Hvorfor bliver alle "statens" IT-systemer ikke samlet i 2-3 stats-ejede datacentre?

Men værre bliver det...

...og 15 millioner om året til vedligehold og opgradering

15 mio for et år? 1 mio. til 2 udvilkerere året rundt , som skal vedligeholde softwaren + Et gæt på 2 mio. til ny hardware hvert år(!) - så er der 12 mio. om året til opgradering!!! - helt ærligt - det må fa**** være nogle vilde "opgraderinger" som er planlagt (eller måske dækker det over de funktioner som egentligt skulle have været implementeret i den oprindelige levering, men ikke blev lavet til afleveringstiden).

Men tilbage til det som jeg egentligt ville frem til, så lyder det skrevne forlag næsten for godt til at være sandt, og jeg kunne egentligt godt tænke mig at høre om er der nogle "big-system"-eksperter, som kan finde en udlempe ved dette? - "we alle learn something new every day ;)". PS Var det ikke CSC der gik fra 7000 kald til 700 efter en "optimering" i Polsag ?

  • 1
  • 1
#16 Finn Christensen

Der tegner sig efterhånden et billede af, at CSC er lykkedes med at forandre Datacentralen til it-verdenens svar på AnsaldoBreda. Hurtige penge i kassen og skidt med om det virker - advokaterne rydder op.

Tror nu ikke CSC eller fordums Datacentralen er hovedskurken.. måske skulle staten have overvejet mulige fremtidige konsekvenser, før man solgte alle aktierne. (Til de historieløse, var der dengang noget med både privatisering, (EU) samt at få stoppet et gabende hul i finanskassen.)

Hvis en prof IT-udviklingsorganisation/-leverandør skal udvikle sammen med en ikke IT-vant organisation, så koster det - xx% til kontraktsummen samt x mdr. til udviklingstiden.

Men perioden 2011-2012 har været et blåt øje på den gamle central.. men så må de jo tage sig sammen, på samme måde må staten finde en anden model end nuværende 'jeg tror og håber'.

Når administrative eller andre faglige organisationer (ikke IT-faglige) skal have nye systemer, så er det jo ikke de skarpeste knive i skuffen til udvikling - prøv at anskue deres daglige verden......

Se betjente med deres biler, blå blink, våben og alskens udstyr. Hovedparten er en praktisk og juridisk verden langt langt fra IT. Det samme var tilfældet i sin tid med tinglysningsfolkene, der har deres force i matrikler, jura og dokumentation mm.

Hvorfor i alverden lader man disse typer organisationer have ansvar ifm. med systemudvikling - det dur de ikke til! De skal jo passe deres faglige arbejde hver dag, og har hverken tid eller tilstrækkelig indsigt til at ramme et ukendt mål.

Mange statslige (også kommunale mfl.) burde ikke have egentlig IT-ansvar ifm. udvikling. Det er mere hensigtsmæssigt at have rejsende IT-projektgrupper, trænede og faglige kompetente, der rykker ud og indlogerer sig hos kunden. Det vil have koster 1/10 af de xxx mio->mia. der er smidt ud af vinduet gennem de sidste 10-15 år. Samt ikke mindst var hovedparten af skandalerne kvalt i fødslen og ikke en daglig underholdning for en undrende befolkning, der heller ikke har det fjerneste begreb om udvikling af IT-systemer.

  • 1
  • 0
#17 Nils Bøjden

Det vil have koster 1/10 af de xxx mio->mia.

Det største problem en statslig udrykningsstyrke ville stå over for ville være at kunder alle som en ville insistere på at 100% af deres krav i kravspec'en skulle udfyldes til en faktor 10 af prisen hvis 99% af kravene skulle udfyldes.

Da kunden endvidere har et pengetræ i baghaven, ville de bare rejse det finansielle krav mod skatteyderne.

Så en statslig task force skulle både have som opgave at hjælpe de forskellige statslige myndigheder samt at reducere så mange systemer som muligt til hyldevare.

Ellers ville politiet i det pågældende projekt (PolSag) have insisteret på at de absolut have unikke behov således at alt skulle laves fra bunden.

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