Informationsmøde vedrørende Proof of concept for en integrationsplatform

Informationsmøde vedrørende Proof of concept for en integrationsplatform

Dagsorden 1. Velkomst 2. Selve Løsningen 3. Visionen 4. Datamodel 5. Milepæle og prøver 6. Open source 7. Praktisk information

Selve Løsningen

Proof-of-Concept 2011 Etablere platform i testmiljø Basal integrationsplatform Modtage CPR udtræk og opdateringer Levere CPR data til IT System hos Kunden 31.01.2011 KOMBIT / Dataadgang 4

Rammer for teknisk platform Anvende afprøvede teknologikomponenter Anvende open source baseret software Service-baseret, modulariseret løsning Fokus på aggregering og integration af data Understøtte relevante standarder Best-practice lagdelt arkitektur Robust og skalerbar løsning

Løsningskoncept og omfang for POC

Arkitekturkomponenter for POC

Løsningsdrift for POC

Leverancer Kode & licenser Dokumentation Drift i driftsperioden Ingen hardware eller netværksudstyr

Visionen

Formål med præsentation af visionen Understrege formålet med POC Guide leverandørerne i løsningsarkitektur og design Sætte POC i muligt fremtidigt perspektiv

Proof-of-Concept Erfaringsdannelse Udstille fælles data på standardiseret form Afprøvning af arkitekturprincipper Etablering af infrastruktur Brug af open source i løsning Afgrænsninger Midlertidig løsning med (meget) begrænset drift Kun et dataområde til én anvender

Efter gennemført POC Erfaringerne fra POC giver Grundlag for videre forløb Input til arkitektur for fremtidig infrastruktur KOMBIT kan definere næste skridt i forhold til Dataadgangsprojektet Fælles infrastruktur for projekter

Dataadgangsprojektet Giver anvendere adgang til fælles, standardiserede data Fælles it-platform samt værdiskabende data. Nem, billig og hurtig adgang til relevante data Øget konkurrence mellem it-leverandører på kommunale marked Mulighed for bedre sammenhæng mellem kommunale fagsystemer Omkostningseffektiv og hurtig time-to-market med nye kommunale løsninger vha. fælles KOMBIT infrastruktur

Adgang til data Identificerede arketyper Gennemstilling af opslag (og evt. opdatering) Datarepository til opslag Datagrundlag for datawarehouse Fælleskommunalt register IT understøttelse Infrastruktur til integration Fokus på aggregering og udstilling af data

Skitse over arkitektur i fremtidig løsning

Mulige arkitekturkomponenter

Datamodel

Datamodel I kontrakten står: Leverandøren skal senest 5 uger før Overtagelsesdagen, levere dokumentation for den anvendte datamodel, inklusiv databeskrivelse, for distribution af CPR-data fra Løsningen til Kunden Formålet med denne formulering er, at vi så tidligt som muligt kan få tilstrækkelig information til, at vi kan forberede det it-system, der skal trække data fra Løsningen (Anvendersystemet)

Datamodel Det vil sige, at vi har behov for: En beskrivelse af den logiske datamodel i Løsningen En beskrivelse af den fysiske datamodel i Løsningen En beskrivelse af de operationer, der udstilles i snitfladen (fx handlinger og afhængigheder) En beskrivelse af samtlige data (fx hvilke data transmitteres, obligatoriske vs. valgfrie felter og datasemantik)

Datamodel I bilag 2, Kravspecifikationen står: Løsningen skal anvende relevante fællesoffentlige standarder. Særligt relevant er, at CPR-data i videst muligt omfang stilles til rådighed for Anvendersystemet som OIOXML. Der er to årsager til den formulering: Som offentligt ejet virksomhed ønsker vi i videst mulig udstrækning at anvende fællesoffentlige standarder. Konkret i forhold til datamodellen ønsker vi at anvende OIOXML, i det omfang det er muligt

Datamodel Vi ønsker, at det bestræbes, at datamodellen overholder OIOs navngivnings- og designregler. Med mindre, der er saglige grunde til at lade være, forventes, at datamodellen anvender skemaer i: 1. Kerneklassen 2. Domæneklasse for OIB 3. Andre relevante skemaer fra OIO

Milepæle og prøver

Generelt om prøver (1) Der er fire prøver Leverandøren udarbejder som del af sit tilbud en prøveplan for gennemførelse af hver af de fire prøver En prøve gennemføres ved at udføre prøveplanen for den konkrete prøve Efter gennemførelse af en prøve udarbejder Leverandøren en rapport over prøveforløbet med opførelse af eventuelle konstaterede fejl og mangler

Generelt om prøver (2) En prøve godkendes, når prøveplanen for den konkrete prøve er gennemført, og det er dokumenteret, at resultatet er som aftalt Alle prøver, undtagen driftsprøven, kan godkendes med mindre betydende fejl og mangler. Alle mindre betydende fejl og mangler skal være rettet inden driftsprøven kan godkendes Prøver, der involverer data, udføres med CPR-data. Kunden foretager de nødvendige aftaler vedr. adgang til CPR-data

Prøver Prøve Formål Særlige krav til inddragelse af Kunden Funktionel overtagelsesprøve Sikre, at Kundens funktionelle behov til Løsningen imødekommes i det aftalte omfang Nej Non-funktionel overtagelsesprøve Sikre, at Kundens nonfunktionelle krav til Løsningen imødekommes i det aftalte omfang Nej Dokumentationsprøve Sikre, at Kundens krav til dokumentation imødekommes i det aftalte omfang Kunden skal have 5 arbejdsdage til review af materialet

Prøver Prøve Formål Særlige krav til inddragelse af Kunden Driftsprøve Sikre, at Kunden kan hente et totaludtræk og ændringsudtræk fra Løsningen og på den baggrund kan generere et nyt totaludtræk, samt at sikre, at data overholder den valgte datamodel Kunden skal bruge: 10 arbejdsdage til at verificere totaludtrækket 10 arbejdsdage til at verificere ændringsudtrækket. Ændringsudtrækket kan først foretages efter verificering af totaludtrækket Sikre, at Løsningen imødekommer Kundens servicemål i minimum 10 sammenhængende dage Nej Sikre, at alle fundne fejl og mangler er afhjulpet Nej

Milepæle og deres sammenhæng Milepæl Deadline Forudgående milepæl Beskrivelse af datamodel indleveret Funktionel overtagelsesprøve gennemført Non-funktionel overtagelsesprøve gennemført Dokumentationsprøve gennemført Driftsprøve gennemført 5 uger før funktionel overtagelsesprøve 10. Maj 2011 Beskrivelse af datamodel 10. Maj 2011 Funktionel overtagelsesprøve 10. Juni 2011 Funktionel og nonfunktionel overtagelsesprøve 10. Juni 2011 Funktionel og nonfunktionel overtagelsesprøve Foretages senest samtidigt med Driftsprøven

Open Source

Krav om Open Source? Ikke et mindstekrav men et vurderingsparameter Løsningen kan derfor baseres på en kombination af standardprogrammel og Open Source Anvendelse af Open Source i Løsningen vil dog blive tillagt værdi i tilbudsvurderingen (Løsningens kvalitet)

Kontraktens definition af Open Source Open Source Programmel: Programmel, hvis licensbetingelser giver Kunden ret til og mulighed for at foretage ændringer i programmet på grundlag af kildekode, der er stillet til rådighed af licensgiveren for Kunden, andre kunder og offentligheden, (kontraktens 2.9)

Rettigheder Kunden erhverver alle rettigheder til programmer, interfaces og specifikationer, der er Kundespecifikt Programmel, samt den tilhørende Dokumentation, herunder retten til at ændre og videreoverdrage sådant programmel. (kontraktens 14.1) Kunden skal kunne stille Løsningen til rådighed for danske kommuner samt andre offentlige eller private kunder i Danmark mod betaling eller vederlagsfrit efter eget valg. (kontraktens 14.4.1)

Praktisk information

Proces for udbud Annoncering Kunden forventer ikke, at de samlede udgifter til Leverandøren i forbindelse med projektet vil overstige 1 mio. kr. eksklusive moms. Leverandøren ikke udelukket fra at byde næste gang

Tidsplan -24. januar kl. 15.00-16:30 Spørge- og informationsmøde i KOMBIT. -10. februar 2011, kl. 15.00: Frist for modtagelse af leverandørernes tilbud. -28. februar 2011: De 3 økonomisk mest fordelagtige tilbud i henhold til kriterierne udvælges til forhandling -2. marts 2011: Forhandlingsrunde med leverandørerne af de 3 økonomisk mest fordelagtige tilbud. - 9. marts 2011, kl. 11.00: Frist for modtagelse af reviderede tilbud. - 14. marts 2011: Leverandørerne vil blive underrettet om Kundens valg - 15. marts 2011: Kontraktunderskrift.