6 Tekniske krav

Tekniske krav er viktige i en kravspesifikasjon for e-servicetorg. De tekniske løsninger som velges får betydning for:

• kostnadene (mht anskaffelse, drift og videreutvikling)
• systemets mulighet for å overleve og videreutvikles i takt med kommunens og brukernes behov

Tekniske krav til systemet dekker i dette kapittelet:

• Mulighetene for kommunikasjon med og utveksling av data med andre systemer, f eks innenfor kommunene, mellom kommuner og mellom kommune og stat
• Krav til utstyr, operativsystem og annen basisprogramvare som f eks databasesystemer
• Programmeringsspråk og verktøyer som er brukt og brukes i utviklingen av det elektroniske servicetorg.
• Arkitektur og mulige konfigurasjoner. Skal det kjøres på en stor maskin eller kan det fordeles på flere mindre enheter? Kan kapasiteten økes uten at systemet må tas ned?
• Leverandørens servicemodell. Hvilken service tilbyr leverandøren? Hvordan installeres feilrettinger og oppgraderinger.

• Juridisk ramme for de tekniske kravene. Hvordan er kunden sikret et levedyktig system, f eks ved uforutsette hendelser som stopp av videreutvikling fra leverandør, at produktet går ut av leverandørens produktspekter, eller at leverandørens status endres, for eksempel ved konkurs, oppkjøp eller fusjonering.

Andre tema, som sikkerhet mv, kan også grupperes som tekniske krav. I denne kravspesifikasjonen er sikkerhet behandlet i eget kapittel, se også begrepsavklaringen nedenfor.

Tekniske krav omfatter alle tekniske egenskaper ved systemet som danner basis for e-servicetorget. Her har vi behandlet de mest sentrale. Sikkerhet er omtalt i eget kapittel.

Det er ingen lovgivning som regulerer tekniske forhold for IT-systemer.

Når det gjelder standarder innenfor det IT-tekniske området er det spesielt for kommunikasjon det er definert norske standarder.

Både AAD og KS har satt i gang aktiviteter for å få fram standarder som gir bedre systemarkitekturer og dermed letter og øker muligheten for datautveksling mellom forskjellige systemer.

KS prosjektet fokuserer særlig på integrasjon mellom sak/arkivsystemer og fagapplikasjoner. AAD's innsats, hva gjelder arkitektur, tar utgangspunkt i regjeringens moderniseringsprogram om brukerretting, effektivisering og forenkling. For å oppnå dette må digitale systemer samspille enklere og mer sømløst. Særlig legges det vekt på ønsket om minimalisering av risiko i IT-prosjekter, optimalisering av IT-investeringer og et mer konkurransedyktig og fleksibelt IT-marked. Interoperabilitet er et begrep som går igjen. Det omfatter, slik vi forstår det, alle forutsetninger fra de rent tekniske til de organisatoriske, som må være på plass for at ulike systemer skal kunne kommunisere med hverandre.

Et første skritt i arbeidet for interoperabilitet er å å få fram forslag til en policy for datasamordning samt en felles arkitektur for i offentlig sektor .

I påvente av resultater fra disse nylig i gangsatte initiativer, har vi her lagt stor vekt på det danske arbeidet på området, se nedenfor.

Det foregår en rekke aktiviteter internasjonalt, bl a med sikte på å gjøre det enklere å få til bedre systemarkitekturer og integrasjon mellom forskjellige systemer.

En god del av disse aktiviteter dreier seg om å etablere standarder på flere nivåer. I Europa peker bl a arbeidet i UK og Danmark seg ut som interessante.

I Danmark er et av resultatene med arbeidet rundt arkitekturer og interoperabilitet det som kalles en referanseprofil. I referanseprofilen gis en oversikt over standarder, spesifikasjoner og teknologier på en rekke områder som er viktige for hvordan systemer utvikles, med fokus på systemers kommunikasjon med omverdenen, mennesker og andre systemer. De forskjellige standarder, spesifikasjoner og teknologier er kommentert og klassifisert i anbefalt, godkjent, kommende etc.

Aktivitetene i Norge i regi av KS, AAD og andre vil sannsynligvis fører til resultater som er egnet å bruke i en kravspesifikasjon som denne. Inntil disse foreligger bør man søke veiledning i den danske referanseprofilen. Den gir, som vi har vist ovenfor, oversikt over standarder, spesifikasjoner og teknologier av betydning for tekniske krav.

Som nevnt i innledningen vil de tekniske løsninger som velges for e-servicetorget være viktige for kostnadene både for anskaffelse, drift og videreutvikling samt for totalløsningens muligheter for å overleve og videreutvikles i takt med endringer i kommunenes behov og endringer i e-servicetorgets omgivelser.

Videre er det viktig at e-servicetorget fungerer på det utstyr og basis programvare som den enkelte kommune har valgt som plattform for sine IKT-løsninger, og at det kan integreres med andre systemer som det skal ha samspill med.

Tekniske krav skal sikre at det er klart for kommunen og leverandøren hvilke tekniske egenskaper e-servicetorgløsningen skal ha for at kravene i de to foregående avsnitt skal være oppfylt.

Leverandører skal levere en beskrivelse av:

Systemets mekanismer for automatisert datautveksling og samspill med andre systemer (slik de nå fungerer eller er planlagt å fungere i nær framtid og på noe lengre sikt).

Datautveksling og samspill med andre systemer og verktøy er et viktig i vurdering av e-servicetorgets tekniske egenskaper totalt sett. Årsakene er bl a:

• E- servicetorget vil være avhengig av å importere eller vise frem informasjon som produseres og vedlikeholdes i andre (fag)systemer og av andre verktøy. Av effektiviseringshensyn er det viktig at dette kan skje mest mulig automatisk.
• E-servicetorget kan også være primærsystemet for enkelte typer av informasjon og det kan også være aktuelt å eksportere eller gjøre denne informasjonen tilgjengelig for andre systemer.
• Det kan være aktuelt både å utveksle data og informasjon med forskjellige fagsystemer samt med verktøy for produksjon av tekst, grafikk, bilder mm.

For å få til dette samspillet behøves:

• Bruk av standarder og de facto standarder for dokument- og dataformater.
• Webbaserte tjenester for at systemer kan "snakke" med hverandre selv om de er bygd opp på forskjellig måte .
• Dataintegrasjon for å sikre at innholdet på karakter- og datafeltnivå kan overføres og forstås mellom systemer (her må det et eksempel til: menes det behov for interoperabilitet).
• Interkonnektivitet for å sikre at systemer og prosesser kan kommunisere og informasjon kan transporteres mellom systemer ved hjelp av definerte standardprotokoller (som f eks HTTP, SMTP/MIME, CORBA m fl).

Hvilke konkrete mekanismer og standarder innenfor hver av de fire ovennevnte kategorier som stilles tilgjengelig for datautveksling og interoperabilitet bestemmes av leverandørene gjennom deres tilbud. Det er sterkt ønsket at leverandørene følger veldefinerte, åpne standarder og at de tekniske løsningene ikke er bundet til et eller få operativsystemer.

Det er ønskelig at leverandøren redegjør for tilgjengelighet av de forskjellige standarder, spesifikasjoner og teknologier som er listet opp i følgende tabell.

Tilbyder skal levere en beskrivelse av hvilke valgmuligheter man har for å velge konfigurasjoner for e-servicetorget.

Konfigurasjonenes fleksibilitet vil påvirke mulighetene til å bestemme :

• Generell lastfordeling. Dette inkluderer linjekapasitet, regnekraft, belastning på primærminne, sekundærminne (datalagring) og tertiærminne (ved backup), samt andre relevante ressurser.
• Konfigurering for å redusere uønskede virkninger mht oppetid ved pilotinstallasjoner, oppgraderinger, utprøving av ny funksjonalitet osv.
• Eventuell tilpasning til eksisterende systemer i drift hos kunden.
• Totalkostnader til maskin- og programvare, ved oppstart og i vanlig drift.

For alle de ovennevnte aspekter av driftsmodellen kreves det utfyllende beskrivelse fra leverandøren av tilgjengelige konfigurasjonsmuligheter, samt også en eksplisitt beskrivelse av hvilke spesifikke begrensninger man må føye seg etter ved installasjon og drift av e-servicetorget.

Tilbyder skal levere en beskrivelse av servicemodell for e-servicetorgets tekniske aspekter gjennom dets levetid.

Det er en forutsetning for velykket drift at systemleverandørens servicemodell er av høy kvalitet. Generelt er det ønskelig at leverandøren har en servicemodell som minsker unyttig belastning på driftspersonell, tilbyr innsyn for kunden i hvilke støttemekanismer som finnes, samt sørger for meget høy oppetid.

Motivasjonen for å gjøre en detaljert vurdering av de støttemekanismer som tilbys i systemets totale livsløp etter utplassering, er hovedsakelig som følger:

• At man enten selv eller via tredjepart skal kunne gjøre kvalitetssikring av alle prosesser i leverandørens service ved vilkårlig tidspunkt etter utplassering. (Erfaring fra drift av større systemer viser at hvis leverandørens servicemodell er svak, kan dette føre til store belastninger med tilhørende effektivitetstap for kundens personell. Dette er noe man meget sterkt ønsker å unngå ved innføring av e-servicetorget.)
• Man ønsker en viss grad av innflytelse på prioriteringer som gjøres hos leverandør, for eksempel i forhold til feilhåndtering eller mangler i systemet.
• Driftspersonell ønsker muligheten for til enhver tid å ha full kontroll over endringer som skjer med systemet.

Det er et viktig kriterium ved vurdering av de tilbudte systemer at potensielle leverandører kan vise til en god servicemodell også etter utplassering og drift av e-servicetorget.

Spesifikke områder som er særlig viktige i vurderingen av de tekniske kvaliteter inkluderer følgende (i ikke-rangert rekkefølge):

Leverandørens strategi for overvåkning av systemet for å kunne oppdage mulige feil- og/eller faresituasjoner som skyldes eksterne forhold. Eksempler på slike er:

• For stor ressursbelastning som overforbruk av kapasitet på prosessorer, nært forestående utilstrekkelig tilgjengelighet av primærlager (RAM), ditto for sekundærlager (disk), benyttelse av databaseressurser (tabellstørrelser og lignende) og andre relevante kapasitetsbegrensninger.
• Forsøk på ikke-autorisert tilgang, hacking mv.

Hvis slike mekanismer for overvåkning er en integrert del av tilbyders system, vil det også være naturlig at tilbyder beskriver hvilket grensesnitt funksjonaliteten har i forhold til driftspersonell, for eksempel i forbindelse med loggføring og automatisk alarmfunksjon.

Som vi har påpekt ovenfor må leverandøren gi en beskrivelse av kundens innsynsrett i systemets spesifikasjoner, oppbygning, komponenter og støttemekanismer. Det ønskes også en forpliktende beskrivelse av hvordan kunden sikres at systemet skal være levedyktig. Dette gjelder også ved uforutsette hendelser som for eksempel stopp av videreutvikling fra leverandør, at produktet går ut av leverandørens produktspekter, eller at leverandørens status endres, for eksempel ved konkurs, oppkjøp eller fusjonering.

Det juridiske rammeverket skal kort sagt gi høyest mulig sikkerhet og forutsigbarhet for kunden. E-servicetorget bør ha en relativt lang levetid, anslagsvis fra 10 til 15 år. Service og effektivitet vil påvirkes negativt dersom systemet må skiftes raskt.

Ønsket om innsynsrett i programvaren og de omkringliggende prosesser for kunden er å øke tryggheten ved ordinær drift. Skal kunden kunne gi kvalifisert kritikk av tekniske sider ved systemet, er det ofte nødvendig at man har innsyn i systemets oppbygning, bestanddeler og løpende utviklingsprosess. Ved innsyn får man blant annet muligheten til uavhengig kvalitetssikring av systemet (enten ved å benytte interne ressurser, eller ved å trekke inn en kompetent tredjepart). Dette ansees som spesielt viktig i forhold til sikkerheten i systemet.

Dersom kunden kjenner systemet fra innsiden har han/hun også større muligheter til å bidra konstruktivt med ekstra ressurser. Slik "egenservice" av systemet kan for eksempel resultere i raskere feilfinning og reparasjon. Høy egenkompetanse vil generelt gjøre systemet mer robust. for eksempel mht hvordan man klarer å kompensere for svakheter i systemet inntil ny versjon foreligger, og hvordan bruken av systemet kan optimaliseres.

Generelt betyr en bred innsynsrett i programvaren man investerer i at man unngår å bli avhengig av leverandøren, med den trygghet dette gir. Kunder som har eller skal kjøpe en e-servicetorgløsning må også ha en avtale som sikrer innsynsrett i tekniske løsninger. Innsynsretten bør inkludere (men ikke nødvendigvis være begrenset til):

• Tekniske spesifikasjoner, som for eksempel konstruksjonsspesifikasjon, dokumenter som omhandler implementeringsmetodikk, og andre relevante høynivå beskrivelser av systemet som er benyttet i konstruksjon og implementasjon.
• Detaljert innsyn i støttemekanismer etter utplassering og aktivering av systemet, som for eksempel hvordan leverandør håndterer feilrapporter ("bugtracking"), feilfiksing ("patching") og oppgraderinger.
• Kildekode for det komplette sett av systemets komponenter.
• Datamodellen

En slik innsynsrett vil kunne kreve en form for juridisk bindende avtale som forhindrer kunder, eller driftspersonell som representerer kunder, videreformidling av informasjon. For å hindre at uforutsette hendelser hos eller med leverandør medfører en uønsket avvikling av e-servicetorget er det også sterkt ønskelig at man har et juridisk rammeverk som sikrer muligheten for videreføring uansett eksterne faktorer.

I denne forbindelse virker det naturlig at man kontinuerlig deponerer all teknisk dokumentasjon og kildekode for alle systemets bestanddeler under en felles avtale (i såkalt "escrow"). Man avklarer hvilke omstendigheter (som for eksempel utviklingsstopp eller avvikling av leverandør) som gir kunden tilgang til deponert materiale og visse rettigheter for videreføring av systemet gjennom egne ressurser eller tredjepart.

Det er ønskelig for kunden å få innsyn i språk og verktøy mm som er benyttet for utvikling og forvaltning av systemet. Det vil bli lagt vekt på at løsningen er basert på verktøy og teknologier som har stor utbredelse både i Norge og internasjonalt. Dette bl a for å sikre at det er god tilgang på kvalifiserte ressurser.

Det er ønskelig at leverandøren kan tilby muligheter for testing av svartider ved forskjellige typer og mengder av informasjon i e-servicetorget samt forskjellige bruksmønstre og antall brukere.

Det finnes mange forskjellige modeller for prising av programvare: basert på hvor store deler av funksjonaliteten som utnyttes, antall brukere av forskjellige kategorier, antall samtidige brukere.

Leverandøren må beskrive sine lisensmodeller slik at det er mulig for kunden å beregne kostnadene ikke bare for den startinstallasjonen, men også for systemet etterhvert som det tas mere funksjonalitet i bruk og antall brukere øker.

Det finnes prismodeller som består av en engangsavgift pluss en årlig avgift, og det finnes modeller som bare har en årlig avgift.

For prismodeller som består av en engangslisens og en årlig avgift er det viktig å være oppmerksom på at det er den årlige avgiften som blir den dominerende kostnad når man beregner kostnadene for en periode lengre enn 3-6 år. Denne årlige avgiften ligger vanligvis på 15-30 % av engangslisensen.