Bilag 3 Teknisk løsningsbeskrivelse Side 1 af 14
Indholdsfortegnelse 3 TEKNISK LØSNINGSBESKRIVELSE...3 3.1 Vejledning til udfyldelse af bilag...3 3.2 Vision for IT-arkitekturen...4 3.3 Generel arkitektur...5 3.4 Trelags model...7 3.5 Datamodel...10 3.6 Præsentationslaget...11 3.7 Forretningslaget...11 3.8 Datalaget...12 3.9 Moduler...12 3.10 Platformskrav...14 Side 2 af 14
3 Teknisk løsningsbeskrivelse 3.1 Vejledning til udfyldelse af bilag Dette bilag indgår som et element i den samlede besvarelse. Det skal understreges, at kravspecifikationen og de øvrige bilag i materialet er fuldstændig ligestillede. Hvert kapitel i bilaget omhandler et givent afgrænset emneområde. Indenfor hvert kapitel er anført de tilhørende krav med tilhørende tekstafsnit. Disse er nummereret med et kapitel nummer og et fortløbende nummer indenfor kapitlet. Således vil kapitel 7 s krav være nummereret således: 7.1, 7.2, 7.3 etc. De opstillede krav er prioriteret i en tredeling, der er som følger: Krav, anført ved et. Dette er krav, der prioriteres højest. Tilbudsgiver skal for hvert angive om og hvorledes kravet opfyldes. Krav, anført ved et K2. Disse er krav, der prioriteres næsthøjest. Det skal ligeledes angives om og hvorledes, kravet opfyldes af tilbudsgiver. Krav, anført ved et K3. Disse prioriteres lavest. Det skal igen angives om og hvorledes, ønsket bliver opfyldt af tilbudsgiver. Desuden kan der være tale om informationspunkter, markeret ved et I, der skal besvares som led i tilbudsbesvarelsen. Besvarelsen af disse informationspunkter vil indgå i den samlede vurdering af tilbudsgivers besvarelse. Det skal bemærkes, at hvert krav også skal indeholde en tekstlig beskrivelse, således at hvert krav består af hhv. en tekstlig beskrivelse og et decideret krav. Besvarelsen af hvert krav skal forholde sig både til selve punktet og til den tilhørende beskrivelse. Hvis en af de to dele giver anledning til forbehold for opfyldelse af kravet, skal dette fremgå af feltet Bemærkninger. Side 3 af 14
Hvert krav er angivet i en tabel struktur. Denne indeholder en række felter, der for hvert krav skal udfyldes. Tabellen vil se således ud: Punkt: Vil være en angivelse af kravets nummerering. Denne skal overholdes og må ikke ændres. Type: Det vil her være angivet, hvilken type krav, der er tale om. Kravene er prioriteret i forhold til den ovenfor omtalte opdeling af prioriteringerne. Der vil af opdragsgiver være angivet et, et K2 et K3. Der kan tillige være angivet et I for informationspunkter, der ikke er deciderede krav. Opfyldelse: Her skal angives, hvorledes kravet er opfyldt. Dette skal angives med STD for standard funktionalitet, med OPS for parameteropsætning, med UDV for angivelse af, hvorvidt kravet kræver nyudvikling, og endelig NOT for angivelse af, at kravet ikke kan opfyldes. Bemærkning. Feltet anvendes til at angive udførlige redegørelser for besvarelsen, uanset hvilken markering, der er angivet i Opfyldelsesfeltet. Der henvises i øvrigt til de offentliggjorte kontrakter. 3.2 Vision for IT-arkitekturen Et vigtigt, men bagvedliggende, element i at forbedre og effektivisere den offentlige forvaltning, er en fælles, fleksibel IT-arkitektur. FESD-projektet lægger med dette udbud en række vigtige grundsten i en fælles IT-arkitektur på ESDH området, men det er også klart at det er en længerevarende proces, der både involvere det offentlige og de leverandører, der leverer løsninger på området. Den overordnede arkitekturproces er beskrevet i Hvidbog om IT-arkitektur fra IT og Telestyrelsen (Kan rekvireres på Videnskabsministeriets hjemmeside). FESD projektets mål er at medvirke til skabe første skridt i en fælles IT-arkitektur, hvor de offentlige organisationer, der bruger de tilbudte systemer, får en fleksibel løsning, der sikrer interoperabilitet og gør det muligt at integrere med fagsystemer, tilpasse arbejdsgange, udveksle elektronisk oplysninger med andre myndigheder m.v. Formålet er også at sikre den enkelte organisation en lagdelt og modulopbygget IT-arkitektur, der på sigt muliggør at enkeltmoduler kan udskiftes med tredjepartsmoduler, og hermed en teknik der underbygge en langsom udvikling af fælles forvaltningspraksis og ensartede arbejdsgang på tværs af den offentlige forvaltning. Alt dette er elementer der har en lang modnings tid, og som forudsætter et væsentligt standardiseringsarbejde. Det forventes at konkurrencedeltageren i deres oplæg udarbejder et grundigt visionspapir, der sigter på at understøtte denne proces og at de nødvendige tekniske og organisatoriske løsninger både på kort og langt sigt og kan indgå i forhandlingsforløbet. I arkitekturprocessen og forhandlingsforløbet er det væsentligt at tilbudsgiveren både forholder sig til deres egen løsning, men også til, hvad der er nødvendigt for at de leverede løsninger kan spille sammen om at understøtte den overordnede målsætning. For at sikre interoperabiliteten, både til andre systemer, men også så tredjepart kan udvikle moduler til systemet, er det afgørende, at der udvikles en fælles offentlig datamodel. De indholdsmæssige rammer for en sådan datamodel findes delvist i Dokform arbejdets Side 4 af 14
strukturering af data, men det er vigtigt, at dette arbejde videreudvikles til en egentlig konkret model. FESD-projektet vil i samarbejde med tilbudsgiverne udforme en fælles datamodel, herefter kaldet "FESD datamodel", som er en del af "FESD standarden". "FESD standarden" vil som første skridt bestå af FESD datamodel" samt beskrivelsen af en række fælles moduler kaldet "FESD moduler". FESD standarden vil blive udviklet i samarbejde mellem de tre leverandører og FESD. Arbejdet vil tage sit udgangspunkt i Noark 4 s datamodel og databeskrivelser og leverandørenes løsninger og med denne baggrund skabe den størst mulige fællesmængde. Standarden kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor leverandørene kan opnå enighed om en afvigelse. Arbejdet sigtes tilrettelagt sådan at leverandørerne udarbejder standarden i samarbejde med FESD, med det mål at understøtte de arkitekturmæssige visioner og den forretningsarkitektur, der er beskrevet i dette bilag. Med hensyn til plan for udviklingsarbejdet og status henvises til www.oio.dk Der skal samtidig udarbejdes generiske integrationsmodeller og gennemføres standardisering af nogle konkrete integrationsgrænseflader (CVR, BBR, KMD, Navision etc.), og der skal endvidere tages stilling til beskrivelsen af andre grænsesnit til forskellige fagsystemer. I dette bilag er opstillet de 4(5) arkitekturdokumenter fra Hvidbog om IT-arkitektur og de konkrete krav som systemet og leverandøren forventes at leve op til. 3.3 Generel arkitektur I det efterfølgende er beskrevet de krav og forventninger, der er til det tilbudte systems ITarkitektur. Det er væsentligt, at indkøb af ESDH systemer til den offentlige sektor ikke stiller uhensigtsmæssige krav til den købende organisations øvrige IT-arkitektur. Derfor forventes der i løsningen en generel funktionalitet, som giver mulighed for integration via applikation, så brugeren ikke oplever at arbejde i flere systemer. Kommunikationen mellem f.eks. et GISsystem og ESDH-systemet skal dermed kunne ske på en standardiseret måde med klare snitflader mellem de to systemer. Det er et krav, at den tilbudte løsning understøtter interoperabilitet og fleksibilitet, som beskrevet i Hvidbogen om IT-arkitektur. Beskrivelsen skal forholde sig konkret til modulopbygning, lagdeling, standardisering og kommunikation. 3.3.1 Det er et krav at de XML skemaer der udvikles lever op til beskrivelsen fra XML Komiteen om udvikling af XML skemaer. 3.3.2 Det er et krav at den leverede løsning integrerer til andre systemer ved brug af WEB services som beskrevet af XML komiteen Side 5 af 14
3.3.3 Det er et krav at den leverede løsning kan udveksle data ved brug af Dok- Formgruppens metadata. 3.3.4 Det er et krav at den leverede løsning integrere til CPR, CVR, BBR ved brug af Nøgledatagruppens beskrivelser. 3.3.5 Det er et krav at de skemaer der udvikles, offentliggøres på inforstrukturdatabasen. 3.3.6 Det er et krav, at den leverede løsning skal leve op til principperne om god IT-arkitektur og at leverandøren skal indgår i den standardiseringsproces, der tilrettelægges i fællesoffentligt regi af eksempelvis XML komiteen, OIO arbejdet, IT og Telestyrelsen etc. 3.3.7.a De organisatoriske, indholdsmæssige og tekniske standarder, der udvikles for dataudveksling, som et led i standardiseringsprocessen skal løbende implementeres i løsningen. IT-arkitekturen skal understøtte, at systemet - uden at der er tale om væsentlige forøgelser i svartider etc. - kan skaleres i forhold til de tre arketyper, så det er effektivt og økonomisk relevant for både store og små organisationer. 3.3.7 Det er et krav, at systemet kan skaleres. Det skal beskrives hvilke tekniske grænser der er for kapaciteten af den tilbudte løsning, eller elementer af den. Hvor skalerbarheden kun kan opnås ved at tilbyde en anden teknologi, skal dette specificeres: Tilbydes der eksempelvis flere forskellige databaser skal det beskrives, hvilke kapacitetsmæssige og økonomiske fordele der er ved de forskellige og hvilke tekniske tiltag der er nødvendige for at skifte database. Side 6 af 14
3.4 Trelags model Systemet skal være opdelt i en flerlags arkitektur. Denne opdeling i forskellige lag skal sikre, at man kan skifte moduler ud i et af lagene med tredjepartprodukter, uden at det medfører forandringer i de øvrige lag, og hvert lag skal have sin egen struktur og logik, der kan arbejdes med uafhængigt af de øvrige lag. Eksempel på en simpel trelagsdeling: Præsentationslag Forretningslogik Datalag En modulopdeling af trelagsmodellen kan opbygges efter nedenstående model. 3.4.1 Løsningen skal som minimum være delt i et præsentationslag, et forretningslag og et datalag. Side 7 af 14
Præsentationslag FESD systemet Andre systemer og moduler Forretningslag CPR Datalag Kommunikation på baggrund af generel datamodel Kommunikation baseret på konkret specifikation af data, baseret på generel model 3.4.2 Det er et krav, at grænserne mellem præsentationslaget, forretningslaget og datalaget skal være klart definerede, og at der må ikke ligge forretningsfunktioner i præsentationslaget og datalaget. Hvis forretningsfunktioner er placeret i præsentations eller datalaget, skal det specificeres i tilbuddet. 3.4.3 Det er et krav, at grænserne mellem de tre lag skal kunne baseres på FESDstandarden, for at understøtte interoperabilitet. En vigtig komponent i systemet er anvendelse af XML baseret kommunikation. 3.4.4 Det er et krav at systemet skal kunne kommunikere med eksterne systemer ved brug af XML udformet efter XML komiteens anvisninger (kaldet OIOXML), og der skal derfor beskrives niveauet for brugen af XML skemaer til udveksling af informationer. 3.4.5 Det et krav, at den tilbudte løsning kan importere og eksportere data ved brug af Dokform gruppens skema, Noark 4 og Moreg og ISO 15489. Der skal være en konkret stillingtagen til de enkelte dataelementer og deres definitioner. Er import/eksport funktionen ikke implementeret på leverancetidspunktet, skal det fremgå af udviklingsplanen, hvornår dette vil foregå. Side 8 af 14
XML kommunikationen skal understøttes af en række kommunikationsprotokoller, der skal sikre interoperabiliteten og fleksibiliteten i systemet. Protokollerne skal være bredt anvendte og baseret på åbne standarder, som eksempelvis CORBA eller SOAP. I vurderingen af systemet vil der blive lagt vægt på det antal kommunikationsprotokoller, som systemet understøtter. 3.4.6 Tilbudsgiveren skal dokumentere hvilke standardiserede kommunikationsprotokoller der kan anvendes til at understøtte kommunikationen med XML 3.4.7 Tilbudsgiveren skal dokumentere, hvilke protokoller der anvendes til kommunikation mellem systemets moduler og mellem lagene i trelagsmodellen. 3.4.8 Hvis der anvendes proprietære standarder skal tilbudsgiveren dokumentere, hvor og hvordan standarderne anvendes, hvilke fordele der er ved at anvende disse, og hvilke muligheder der er for at erstatte dem med åbne standarder. Punktet forventes behandlet i IT-arkitektur dokument 1: Vision og pejlemærker og ITarkitekturdokument 4: Teknisk arkitektur. Med åbne standarder menes standarder, der er anerkendt af et internationalt eller nationalt standardiseringsorgan som ISO (International Standard Organization) og DS (Dansk Standard), eller som minimum sammenslutninger af normsættende karakter som W3C eller WfMC (Workflow Management Coalition). At standarden er åben betyder også, at dens anvendelse i systemet er veldokumenteret, at dokumentationen er almindeligt tilgængelig, og at brugen ikke er forbundet med afgifter eller licenser. 3.4.9 Tilbudsgiveren skal sikre at dokumentationen for de standarder der anvendes er almindeligt tilgængelig. Tilbudsgiveren skal redegøre for hvor dokumentationen kan anskaffes og under hvilke betingelser. Side 9 af 14
3.5 Datamodel For at sikre interoperabiliteten, både til andre systemer, men også så tredjepart kan udvikle moduler til systemet, er det afgørende, at der udvikles en fælles offentlig datamodel. De indholdsmæssige rammer for en sådan datamodel findes delvist i Dokform arbejdets strukturering af data, men det er vigtigt, at dette arbejde videreudvikles til en egentlig konkret model. FESD-projektet vil i samarbejde med tilbudsgiverne udforme en fælles datamodel. 3.5.1 Som en del af forhandlingsforløbet skal tilbudsgiveren indgå i udarbejdelsen af en "FESD standard". Standarden skal indeholde en fælles datamodel, baseret på NOARK 4 og NOARK 4.1, og beskrivelse af en række fælles moduler. 3.5.2 Datamodellen og de nødvendige databeskrivelser, som leverandøren lader indgå i FESD standarden, samt løsningens øvrige eksterne interfaces skal være almindeligt tilgængelige, og anvendelsen må ikke være belagt med særlige rettigheder eller omkostninger. 3.5.3 Det er et krav at tilbudsgiveren sikrer at tredjepartsleverandører får informationer om leverandørens implementering af FESD standarden i sine produkter og løsningens øvrige eksterne interfaces, så tredjepartsleverandører kan nå lave tilpasninger, samtidigt med at ændringerne i datamodellen træder i kraft. 3.5.4 Som led i udarbejdelsen af FESD standarden skal tilbudsgiveren dokumentere den i løsningen anvendte datamodel i form af Diagrammer og tabel og feltbeskrivelser, som beskrevet nedenfor. Der skal leveres en systematisk beskrivelse af hvilke data elementer fra Noark 4.1, systemet indeholder. Det skal beskrives hvilke dataelementer som er defineret i henhold til Noark 4,1 og hvilke dataelementer, der ikke overholder standarden. For de elementer der ikke overholder standarden, gemmeomgås, hvilke dataelementer der træder istedet, og hvordan de er defineret. (I Noark 4.1 bilag 14 bruges en skematisk notation for elementbeskrivelse der indeholder: Betegnelse, K, O, Format, Kortnavn, beskrivelse. Definitionen forefindes i Noark 4 Bilag 14 side 8. Der ønskes en lignende skematisk besvarelse der tilkendegiver Noark betegnelse, Format, leverandørens egen betegnelse* og Beskrivelse. For dataelementer der ikke overholder Noark 4.1 standarden ønskes en beskrivelse af Leverandørbetegnelse, format og beskrivelse.) Punktet forventes behandlet i IT-arkitektur dokument 3: Informationsarkitektur. Side 10 af 14
3.6 Præsentationslaget 3.6.1 Præsentationslagets brugergrænseflade skal være browserbaseret og skal kunne afvikles i et vindue af variabel størrelse, eksempelvis til brug for portaler, WAP eller lign. 3.6.2 Præsentationslaget skal sikre muligheden for at understøtte andre kanaler som for eksempel PDA eller lign. 3.6.3 Det tilbudte system må kun i begrænset omfang indeholde moduler, eksempelvis scanning eller brugeradministration, der skal afvikles på en tung klient. Tilbudsgiver bedes redegøre for dette. 3.6.4 Den tilbudte løsning skal give mulighed for, at den enkelte organisation selv kan tilpasse præsentationsslagets bruger grænseflade. 3.7 Forretningslaget 3.7.1 Forretningslaget skal være opdelt i funktionsmoduler, der implementerer FESD standardens generiske moduler og kommunikerer ved brug af veldefinerede grænseflader og ved brug af FESD standardens datamodel. 3.7.2 Som en del af FESD standardens skal forretningslaget indeholde et eller flere moduler, der kan styre og fordele in- og output til eksterne systemer.(se Hvidbogen figur 6). Side 11 af 14
3.8 Datalaget 3.8.1 Datalaget skal kunne fungere på flere almindeligt, udbredte databaser. Som for eksempel SQL server og Oracle. 3.8.2 Knytter der sig specielle konditioner til brug af de enkelte database typer, skal det fremgå hvilke konditioner. Med konditioner menes enhver form for praktisk, juridisk eller kommerciel betingelse, som fx licensbetaling eller overholdelse af tredjeparts regler vedrørende brug eller videreudvikling en af software, templates, procedurer, etc. 3.8.3 Datalaget skal, under iagttagelse af de nødvendige sikkerheds-foranstaltninger, kunne udgøres af en ekstern service, eksempelvis som ASP-løsning. Tilbuddet skal beskrive mulighederne herfor, inklusive de nødvendige forudsætninger som fx netværkskapacitet, hjælpeprogrammel, etc. 3.9 Moduler 3.9.1 Systemet skal i videst muligt omfang være selvstændige moduler med åbne grænseflader, der er baseret på de ovenfor nævnte åbne standarder. Det vil blive vægtet, at de i dette afsnit opstillede moduler er tilstede i systemet, og i forhandlingsprocessen vil det kunne komme på tale, at der skal ske en tilpasning af de enkelte leverandørers moduler til den modulære opbygning, der vises i nedenstående figur. 3.9.2 Hvis de i dette afsnit nævnte moduler ikke er selvstændige moduler på leveringstidspunktet, skal tilbudsgiveren beskrive om og hvordan de enkelte moduler kan skabes med udgangspunkt i systemets nuværende opbygning og det skal fremgå af udviklingsplanen, hvilke moduler der påtænkes udviklet og hvornår de vil være det. Side 12 af 14
Modulerne i forretningslaget kan illustreres med følgende model. Som det fremgår af modellen, kan der være flere moduler end i nedenstående liste. Præsentationslaget Forretningslaget Sikkerhed Workflow n1 Advis Sagsstyring Dagsorden Ledelsesinformation n2 Integration Datalaget Registrering Journalisering Skanning Scanning Brugeradm. n3 Dokumenthåndtering Versionsstyring Check in/out Metadata Søgning Arkivering Det er et krav, at systemet på én gang tilsikrer en fleksibel modulær opbygning, sikrer interoperabilitet, og at systemet fremstår som en effektiv og økonomisk favorabel løsning. Kontorpakker 3.9.3 Systemet skal indeholde funktioner, der sikrer integration til de to nyeste versioner af de mest udbredte kontorpakker og mailsystemer. Tilbudsgiver bedes udfærdige en liste over de kontorpakker og mail systemer, der integreres til, en generisk beskrivelse af integrationens art, og hvordan integrationen er implementeret. 3.9.4 Hvis systemet på tidspunktet for kontrakternes underskrivelse ikke indeholde integration til alle disse produkter, skal integrationen til de pågældende kontorpakker og mailsystemer være implementeret inden ibrugtagningstidspunktet. Punktet forventes behandlet i IT-arkitekturdokument 1: Vision og pejlemærker. 3.9.5 Tilbudsgiver skal beskrive de procedure og foranstaltninger, der er for at sikre at den leverede løsning sikkerhedsmæssigt lever op til de stillede krav. Side 13 af 14
3.10 Platformskrav 3.10.1 Det er et krav at leverandøren opstiller et skema, der beskriver alle løsningens krav til organisationens IT-infrastruktur. Herunder styresystem og andre software krav på server/klient, Skærmstørrelse, maskinkapacitet (ram, cpu, disk etc.), netværkstopologi, båndbredde mv. Side 14 af 14