Teknologi vurderingsmodel

Transkript

1 Teknologi vurderingsmodel Version 1.1 Dato 14. januar 2010 Status Færdigvurderet Produkt Borger.dk/Min side Udarbejdet af Kurt Hansen Indhold 1. Forside Dette faneblad 2. Vurderingsguide Kort vejledning i vurdering af produkt 3. Vurderingsopsamling Vurderingsopsamling for produkt for alle vurderingsområder 4. Enterprise arkitektur Kriterier direkte afledt fra Enterprise Arkitektur og IT-strategi 5. Reference arkitektur Kriterier direkte afledt fra Referencearkitekturen 6. Sikkerhed Kriterier afledt af sikkerhedsarkitektur og sikkerhedsmodel 7. Platformskrav Kriterier som er specifikke for det produkt der vurderes 8. Leverandørinformation Kriterier for leverandør

2 Vurderingsguide Hvordan og hvad skal vurderes Alle r skal vurderes og tildeles en score fra 1-5. (5 er det bedste) Hvis et ikke kan vurderes skal det gives scoren 0. Samtidig skal der gives en begrundelse i kommentarfeltet Vigtig information relateret til et specifikt kan skrives i kommentarkolonnen En kort tekstuel opsummering af vurderingen skal skrives i 3. Vurderingsopsamling

3 Giv en kort opsummering af vurdering. F.eks i form af bullet fordele og ulemper ved produktet/platform Produkt vurderet : Borger.dk/Min side Dato : 11. januar 2010 Vurderet af : Kurt Hansen Vurderingsopsummering : Både for arkitekturområderne, sikkerhed og platformsr scorer alternativet pænt i forhold til de opstillede r. På leverandørsiden scorer borger.dk meget lavt, og dette grunder i leverandørens (ITST) manglende erfaring som leverandør og det faktum at ITST ikke har nogen leveranceorganisation opbygget. Dette fremgår også af modenhedsvurderingen samt en lav score på support-struktur som ikke er gearet til at understøtte en stor kommune med en bred vifte af selvbetjeningsløsninger. Det er derfor en forudsætning ved et evt. valg af denne løsningsplatform at der fokuseres på disse områder. På arkitektursiden og de øvrige tekniske områder vil et implementeringsprojekt kunne håndtere de forhold der er bemærket. På sikkerhedsområdet er den tekniske del tilfredsstillende pånær logningskoncept. I forhold til sikkerhedsregulativet skal Systemejer og dennes ansvar præciseres for Min Digitale Borgerservices, herunder om det er en fællesløsning og som afledt heraf med systemejerskab hos KS, eller om det ses som en samling af fagsystemløsninger med "delt" systemejerskab i forvaltningerne Vurderingsscore Område Total antal r Antal vurderet Vurderingsprocent Vægtet score Pct. vægtet Mulig total score score 4. Enterprise arkitektur % % 5. Referencearkitektur % % 6. Sikkerhed % % 7. Platformsr % % 8. Leverandør information % % Total for r % %

4 4. Enterprise arkitektur Kriterie ID Kriterie Beskrivelse af Vægtning/Prioritet for [1="nice to have", 2=forventet egenskab, 3="must have"] Vurdering af opfyldelsesgrad af [1=laveste score - 5=højeste score] Vurderingskommentar Kilde 4.1 Arkitektur Principper Optimale og it-understøttede arbejdsprocesser fra start til slut også når disse går igennem flere forskellige forvaltningsområder Data indsamles kun én gang og er tilgængelige for alle relevante parter herunder også borgeren Når den samme opgavetype løftes flere forskellige steder, sker det i samme it-system og med ensartede processer Platform skal understøtte at processer går på tværs af forvaltninger og fagområder Data der opsamles af platformen skal gøres tilgængelig for både forvaltninger til sagsbehandling men også borgeren Platform må ikke kræve introduktion af funktionalitet som allerede er understøttet af andet system i København Kommune It-løsninger til at ressourcestyre, overholde Platformens arkitektur skal kunne indgå i en frister og understøtte de ensartede processer og arkitektur der understøtter ensartede processer forretningsgange Data lagres et sted og har en ejer Der er kun en primær kilde til data og data skal som udgangspunkt gemmes/hentes her. Data har endvidere en og kun en ejer. 3 3 Platform understøtter ikke dette, men forhindrer det heller ikke på nogen måde 3 5 Platformen persisterer ikke nogen data, og de skal lagres af de løsninger der lægges på platformen. Kun personaliseringsdata gemmes på platformen 2 5 Platformen tilbyder ingen forretningsmæssig funktionalitet 2 4 Platformen understøtter ikke processer eller enforcer dette, men er mere glaspladen mod borgeren Morten Winther 3 5 Data kan hentes ved kilden og vil også kunne gemmes her. Dette dog forudsat at der kan blive etableret de fornødne credentials krævet af backendsystem, eks. SAML-2 token Workshop Arkitektur krav Krav om fleksible, standardiserede, serviceorienterede og åbne løsninger Københavns Kommune skal bruge allerede kendte og afprøvede løsninger, hvor det er muligt (genbrug). Når et køb er nødvendigt, købes der standardløsninger, og først når disse muligheder er udtømte, overvejes det at få udviklet særlige løsninger og da helst i samarbejde med andre Nye løsninger baseres som udgangspunkt på købeprodukter eller genbrug og egenudvikling sker kun hvis dette ikke er muligt eller det giver en klar strategisk værdi 3 3 OPIS delen som er adminstrations og personaliseringsdelen af borger.dk har pt. ikke nogen service grænseflade. Men den selvbetjeningsfunktionalitet der skal udstilles kan i høj grad være serviceorienteret og åben. Bliver webpart den foretrukne portal service for Borger.dk, bliver dette også propretiært (Microsoft) 2 5 Basis platform er Microsoft produkter og Borger.dk er en etableret løsning 4.3 Arkitektur begrænsninger Når data skal deles på tværs, er det nødvendigt Platform skal understøtte fælles offentlige med fælles definitioner og ansvar for standarder datakvalitet, samt et afklaret forhold til åbenhed og sikkerhed. 3 5 OIOXML og tilhørende standarder er understøttet fuldt ud

5 5. Referencearkitektur Kriterie ID Kriterie Beskrivelse af Vægtning/Prioritet for [1="nice to have", 2=forventet egenskab, 3="must have"] Vurdering af opfyldelsesgrad af [1=laveste score - 5=højeste score] Vurderingskommentar Kilde 5.1 Arkitektur Service orientering Platformen skal kunne indgå i en service orienteret arkitektur og den skal kunne udstille standard funktionalitet som services Udskiftelige Komponenter Platformen skal understøtte en komponentbaseret arkitektur hvor komponenter kan udskiftes uafhængigt af hinanden 3 4 funktionaliteten til Min Side er ifølge Rasmus Espholm service orienteret og kan tilgås via servicegrænseflade. Service grænseflade udvides i næste version som kommer til marts. Vurderes til 4 da der pt. mangler enkelte services 3 2 Basis komponenter kan udskiftes indenfor Microsoft produktfamilien. Løsningskomponenter til Min Side er programmeret i.net og kan ikke umiddelbart flyttes til andre platforme ESDH ref. Ark Morten Winther Enterprise service Bus Platformen skal kunne udnytte en central ESB i KK til integration mod udstillede services 2 5 Der er ingen begrænsninger i relation til hvordan backend services udstilles i forhold til platformen ESDH ref. Ark Morten Winther 5.2 Grænseflader Platform skal understøtte standardiserede grænseflader De grænseflader som platformen tilbyder og eksponerer skal understøtte standarder på området og må ikke være propretiære Offentlige Integrationsmodel (OIM) Platformen skal understøtte OIM og de specifikationer der er beskrevet/omfattet heri Understøtter ITST standarder, NemID (digital signatur) etc. 2 5 Understøtter fuldt ud OIM ESDH ref. Ark ESDH ref. Ark 5.3 er OIORASP RASP står for Reliable Asynchronous Secure Profile og sikrer, at datakommunikationen imellem to punkter er sikker, pålidelig, uafviselig og med signerede kvitteringer. OIORASP 1.1. skal understøttes. Vil være aktuel mod KK eksterne services SOAP Platformen skal understøtte SOAP (Simple Object Access Protocol) som er de facto standarden ved brug af web services 2 5 Understøtter RASP 2 5 Understøtter SOAP ver. 1.1 og opefter. Er også WS-I compliant ESDH ref. Ark Workshop OIOXML Platformen skal understøtte OIOXML 2 5 Understøttet Workshop

6

7 6. Sikkerhed Kriterie ID Kriterie Beskrivelse af Vægtning/Prioritet for [1="nice to have", 2=forventet egenskab, 3="must have"] Vurdering af opfyldelsesgrad af [1=laveste score - 5=højeste score] Vurderingskommentar Kilde 6.1 Sikkerhedsstrategi og politik Sikkerhedspolitik Produktet skal overholde Københavns Kommunes sikkerhedspolitik Sikkerhedsregulativ Produktet skal overholde Københavns Kommunes sikkerhedsregulativ 6.2 Sikkerhedsarkitektur Sikkerhedsarkitektur Produktet må ikke enforce egen sikkerhedsmodel, men skal kunne indpasses i Københavns Kommunes sikkerhedsarkitektur 3 5 Der er ikke noget i løsningsplatformen som bevirker at sikkerhedspolitikken ikke kan overholdes 3 5 Der er ikke noget i løsningsplatformen som er i konflikt med sikkerhedsregulativet. Sikkerhedsregulativet er gennemgået og vil kunne overholdes. Dog skal der gøres opmærkom på at præsentationsdelen af selvbetjeningsløsninger evt. har en anden systemejer end fagsystemet. Dette har påvirkning på det organisatoriske setup 1 3 OPIS har egen sikkerhedsmodel. For tilgang til selvbetjeningsløsninger sker dette via digital signatur 6.3 Teknologi Digital Signatur Platform skal understøtte Digital Signatur 3 5 Understøttet ESDH ref. Ark NemID/nemlogin Platform skal understøtte NemID 3 5 Understøttet ESDH ref. Ark OIOSAML Platform skal understøtte OIOSAML 3 5 Understøttet ESDH ref. Ark 6.4 Driftstilgængelig Driftstilgængelig(åbningstid) for brugere, borgere og virksomheder, når de har behov for det 6.5 Fortrolighed Fortrolig behandling, herunder transmission og opbevaring af person- og værdioplysninger Borgere og virksomheder skal kunne tilgå services på Min Digitale Borgerservice indenfor de tidsrum hvor de har behov for det. Det betyder at platformen skal understøtte en driftstilgængelighed på 24x7 Udveksling af information og data skal kunne krypteres. Persondata skal kunne opbevares og tilgås på fortrolig vis 3 5 Driftstilgængelighed er 24x7, men der er kun support indenfor almindelig kontortid hos ITST 3 5 kryptering, herunder https, SSL etc er standard funktionalitet i Microsoft platform Sikkerhedspolitik Sikkerhedspolitik

8 6.5.2 Kun autoriserede og autentificerede brugere har adgang, og brugernes og borgernes adgang er begrænset til det nødvendige Al tilgang til information og funktionalitet skal kunne logges Al tilgang til platformen skal kunne beskyttes så kun autoriserede brugere har adgang. Det skal være muligt at definere hvem der har adgang til information og funktionalitet. Platformen skal understøtte en diffentieret adgang til data, således at man kun kan se det nødvendige Logning skal være en integreret del af platformen og kunne tilgås med standard værktøjer 3 4 Via personalisering ser borgere kun relevant data og funktioner. Hvilke data der vises i de respektive selvbetjeningsløsninger afgøres af bagvedliggende fagsystem. Platform leverer SAML- 2 token til fagssystem der så kan filtrere data der vises. 3 2 Dette er ikke fuldt implementeret i nuværende version, og platformen som helhed har ikke et logningskoncept til brug for udvikling af selvbetjeningsløsninger Sikkerhedspolitik ESDH ref. Ark

9 7. Platformsr Kriterie ID Kriterie Beskrivelse af Vægtning/Prioritet for [1="nice to have", 2=forventet egenskab, 3="must have"] Vurdering af opfyldelsesgrad af [1=laveste score - 5=højeste score] Vurderingskommentar Kilde 7.1 Målgrupper Borgervendt Platformen skal understøtte borgervendt selvbetjening Tilgængelighed Understøtte ITST standarder for tilgængelighed. Web Content Accessibility Guideline Sagsbehandler "Genvej cookpit" lignende funktionalitet hvor sagsbehandler/supporter kan hjælpe borgere og se/gøre det samme som dem 7.2 Basis funktionalitet Personalisering Min Digitale Borgerservice skal tilbyde mulighed for at personalisere indhold i forhold til den enkelte borger. Dels hvad borgeren kan bruge af løsninger dels hvad borgeren selv ønsker at fremhæve Integration til borgerrettede web systemer 7.3 Dialog og præsentation Det skal være nemt for borgere og virksomheder at skrive til kommunen og at opbevare korrespondancen Materiale skal så vidt muligt samles og præsenteres på tværs af it-systemer, forvaltninger og offentlige myndigheder, således at det for borgeren og sagsbehandleren fremstår som en helhed Borgerrettede web-systemer skal kunne integreres på lige fod med nye selvbetjeningsløsninger på platformen Det skal være muligt at integrere Dokumentboks i platformen Platformen skal indeholde mulighed for at indsamle data på tværs af it-systemer og have funktionalitet til at samle data i visningen. Skal dette også gælde for sagsbehandleren som beskrevet i IT-strategi Vi skal benytte os af de fællesoffentlige tiltag Platformen skal understøtte/benytte nyeste og teknologiske trends, der understøtter brugen teknologiske tiltag og være forberedt på af digitale selvbetjeningsløsninger kommende fælles offentlige tiltag Vi skal være teknologisk fremme, dvs. bruge ny teknologi Københavns Kommune skal selv kunne vedligholde tekster og anden information der vises på Min Dgitale Borgerservice Vedligeholdelse og publicering af tekster på Min Digitale Borgerservice skal kunne udføres og styres af Københavns Kommune uden assistance fra leverandør 3 5 Borger.dk er bygget til dette 3 5 Platform og standard selvbetjeningsløsninger overholder denne standard 2 1 Er ikke en del af platformen i nuværende version 3 5 Er understøttet som standard i Borger.dk 3 5 Der er ikke seamless integration, men via OIM kan de fleste web-løsninger integreres med den ene eller anden teknologi 3 4 Dokumentboks indlægges som en standard selvbetjeningsløsning. Findes ikke i dag, men skal udvikles 2 3 Der er ikke nogen standardfunktionalitet til dette, men selvbetjeningsløsninger kan gøre dette. Skal platformen tilbyde dette skal der suppleres med f.eks. en ESB der kan orkestrere backend-services 1 4 Borger.dk er baseret på de nyeste produktmodne værktøjer fra Microsoft. Teknologi er ikke bleedingedge men må betragtes som forholdvis ny teknologi 3 5 Løsningsplatformen omfatter visning af tekster og lign og har egen CMS funktionalitet.tekster og lign. kan gøres tilgængelig for andre platforme og hjemmesider. KK information kan vises via link/webpart og lign, som trækker data og information fra andre kilder f.eks. Et CMS system, hvor KK har fuld opdatering/vedlighold adgang Julie Workshop Julie Julie Workshop Skalerbarhed

10 7.4.1 Platformen skal kunne skalere Platformen skal kunne skalere både horisontal og vertikal Platformens enkelt komponenter skal kunne skaleres individuelt Enkelt komponenter i platformen skal kunne skalere uafhængigt af hinanden, således at evt. flaskehalse fjernes 2 5 Løsningsplatformen er baseret på et Microsoft Sharepoint cluster og ved hjælp af standard Microsoft teknologi kan platformen skaleres både horisontalt og vertikalt. Dette gælder også den underliggende database. Ifølge Rasmus (ITST) kan OPIS skalere på samme måde. I næste version vil det også være muligt at lægge OPIS ud i skyen Workshop De enkelte komponenter herunder OPIS kan skaleres uafhængig af de øvrige komponenter Workshop

11 8. Leverandør information Kriterie ID Kriterie Beskrivelse af Vægtning/Prioritet for [1="nice to have", 2=forventet egenskab, 3="must have"] Vurdering af opfyldelsesgrad af [1=laveste score - 5=højeste score] Vurderingskommentar Kilde 8.1 Leverandør information Support struktur Leverandøren skal kunne tilbyde en support struktur/organisation der understøtter 24*7, med en reaktionstid på x timer Konsulentbistand Har leverandøren mulighed for at tilbyde ekspertbistand og/eller kvalificeret konsulent bistand ved implementering Involvering i standardisering/ standardiseringsorganisationer Leverandøren er involveret i standardisering, følger standardisering på nært hold eller er medlem af standardiseringsorganisation indenfor det område som funktionaliteten i leverandørens produkt dækker Involvering i sektor og markeds organisationer Leverandøren bør være involveret i sektor/markeds organisationer som er med til at drive udviklingen indenfor det område som funktionaliteten i leverandørens produkt dækker Reference kunder Leverandøren skal have referencekunder i Danmark på platform og teknologi Ansvar for løsning som helhed Hvis leverandørens løsning/produkt er baseret på et eller flere partner produkter, skal leverandøren være villig til at tage ansvaret for den fulde løsning 2 2 ITST kan kun tilbyde support indenfor almindelig kontortid (9-16) 3 3 ITST er afhængig af underleverandør 1 5 ITST er drivende aktør indenfor standardisering 1 5 ITST har mange af statens aktiviteter indenfor selvbetjening og relaterede områder 2 2 Det er meget begrænset hvad der er udstillet på Borger.dk i dag 3 5 ITST tager det fulde ansvar

12 8.1.7 Leverandørmodenhed Leverandøren skal have god modenhed ved måling med ITST light modenhedsmodel beskrevet i "Modenhed i it-baserede forretningsprojekter" Leverandørens ressourcer Leverandøren skal have tilstrækkelig med ressourcer til at service flere kunder og det skal være ressource med relevant kompetence på platform og teknologi. Der skal være andre leverandører på markedet der kan levere de samme kompetencer 2 3 Modenhedsmodellens sigte er et specifikt udbud hvor leverandøren skal besvare de 30 spørgsmål i modenhedsmodellen og levere eksempler på bla. styringsleverancer. Da nærværende analyse ikke er et udbud er der en række områder i modenhedsmodellen der ikke kan evalueres og det vurderes derfor at en delvis udfyldt modenhedsmodel ikke kan give et korrekt billede af leverandøren. Gennem interview med ITST (dokumenteret i spørgeguide med svar) er det blevet klart at ITST som leverandør ikke har en høj grad af modenhed. Det skal bemærkes at ITST har NNIT som underleverandør på systemsiden og de derfor bør indgå ved komplet udfyldning af modenhedsmodellen. Derfor gives vurdering 3 Workshop ITST bemanding/ressourcer pt. tillader ikke flere kunder som skal serviceres samtidig. Så en opmanding hos ITST vil være en forudsætning for valg af dette alternativ Workshop