Standardiseringsrådsmøte # mai 2013

Transkript

1 Standardiseringsrådsmøte # mai 2013

2 Sak 1 godkjenning agenda 10:00-10:10 Godkjenning agenda (beslutningssak) 10:10 11:00 Altinn Strategi (orienteringssak) 11:00 11:45 Revisjon for dokumentstandarder (beslutningssak) 11:45 12:30 Lunsj (fordøyelsessak) 12:30 13:30 Revisjon og utredning av ehandelsstandarder (beslutningssak) 13:30 13:45 Status for arbeidet med standardisering i Difi (orienteringssak) 13:45 14:45 Revisjon av multimediastandarder (beslutningssak) 14:45 15:00 Eventuelt

3 Sak 2 - Ny Altinn strategi Standardiseringsrådet 6/ Bjørn Holstad

4 Bakgrunn Felleskomponentrapporten (DIFI 2010): Manglende organisatorisk kapasitet og manglende teknisk fleksibilitet. En del tekniske og organisatoriske forhold medførte to evalueringer av Altinn DNV: Vurdering av Altinn 2 plattformen, Teknisk rapport Nr Cap Gemini: Altinn en plattform å satse på?

5 DNV Det er begrensninger og flaskehalser i arkitekturen. Risiko for manglende skalerbarhet. Betydelig mange feil og utestående feil. Men positiv trend. Kvaliteten på test har vært for dårlig. For dårlig testregime. Det kan ikke verifiseres at kriseberedskapen fungerer. Ingen planer for hvordan økt volum i datamengd og trafikk skal håndteres. Manglende kompetanse og kapasitet til å forvalte Altinn Manglende langsiktig strategi Dato Direktoratet for forvaltning og IKT

6 Capgemini Gjennomfører kildekode analyse og teknisk analyse funn: Plattformen i Altinn2 er fremstidsrettet og kan satses på. Andre funn: Forretningsmodellen må styrkes Behov for en rekke tiltak for å definere og bedre tjenestekvaliteten Behov for en rekke tiltak for å modne plattformen Behov for en rekke tiltak for å bedre testregimet Ny ansvarsdeling og tilgang på verktøy for tjenesteutvikling M.m. Dato Direktoratet for forvaltning og IKT

7 Capgemini Dato Direktoratet for forvaltning og IKT

8 Komponenter i sluttbrukerløsningen i Altinn Sluttbruker/ Tjenesteeier Virksomhetssertifikat Etatssystem Andre nettsteder Certificate Authority Sluttbrukersystem Autentisering Altinn II - SBL Andre tjenesteleverandører MinID Ny i v2.0 Autoriser ing Min profil Arkiv BuyPass BankID Tjenestemotor Statistikk og analyse (Paradata) Register Forsendelse Offentlige registre Etatssystemer 8

9 Sluttbrukertjeneste i en arkitekt kontekst

10 KOMPONENTER Autentisering Authentication Decision Point (OpenSSO) Federation (OpenSSO) Policy Agent (OpenSSO) User Self Service (OpenSSO) Authentication User Profile (OpenSSO) PIN Code Generation (OpenSSO) Arkiv Autorisering Min profil Tjenestemotor Archive Common Reportee Archi Administration Decision Point User Profile Forms Engine Subscription Context Handler Service Owne Archive Policy Agent Prefill Reportee Element Lists Key Management TTP Archive Register Service Metadata Form Task Common DSF ER Statistikk og analyse Notification Correspondence Paradata Workflow Case Prosessflyt Forsendelse Process Engine Receive Send Receipt Service Metadata Shipment

11 Tjenestetyper Innsendingstjenester Meldingstjenester Innsynstjenester Lenketjenester Formidlingstjenester Samhandlingstjenester Standardtjenester bl.a. nødvendig for å kunne definere tjenestenivå og å standardisere bruken av komponentene.

12 Sluttbrukertjeneste

13 Sluttbrukerprodukt

14 Felleskomponenter skal fungere sammen i tjenesteutviklingen Felles byggeklosser for å kunne utvikle elektroniske tjenester. For selvangivelse fungerte dette fint! Folkeregisteret Dato Direktoratet for forvaltning og IKT

15 Utfordringer Utbredelse Organisatorisk kapasitet Stabilisering og konsolidering Kompleksitet Ulike mål

16 STRATEGI KORT SIKT (1-2 år): Strategi 1: Robusthet - stabilitet 1. Tiltak gjennomføres slik at uplanlagte driftsproblemer unngås og de verdiene som er skapt og som representerer Altinn i dag, sikres og utnyttes. Dette er nødvendig for at dagens tjenesteeiere får dekket sine behov. Det er også nødvendig før vesentlige ytterligere utviklinger i Altinn gjennomføres.

17 Strategi 2: Volum - stabilitet Volumet av transaksjoner må kunne skaleres etter behov slik at ytelsen ikke påvirkes i høyvolumperioder, og slik at Altinn kan benyttes selv om det er problemer med enkelttjenester. Profesjonelle brukere Redusere risikoen for svikt i sluttbrukertjenestene.

18 Strategi 3: Test Tiden fra et behov er identifisert til tjenesten er satt i drift skal reduseres vesentlig. Dette er nødvendig for å sikre at tjenesteeiernes behov blir dekket innenfor rimelig tid og for å sikre tiltro og tillit hos tjenesteeiere i Altinn.

19 Strategi 4: Altinns organisasjon Altinns organisasjon styrkes og tydeliggjøres slik at den blir mer profesjonell og konkurransedyktig og har riktig kompetanse til å løse sitt oppdrag.

20 Strategi 5: Modne tjenester De tjenestene som både er testet og tatt i bruk uten problemer (modne tjenester) skal kunne brukes av alle offentlige virksomheter som kan benytte dem uten vesentlig tilpasning, etter sommeren En forutsetning for kommunal deltagelse er samordning fra kommunenes side. Modne tjenester: Innsending og melding

21 Strategi 6: Ikke modne tjenester kort sikt For tjenester som vurderes som mindre modne, eller der det er et vesentlig behov for særskilte tilpasninger, begrenses inntaket til et håndterbart antall per år. Tjenesteeiere som ikke kan få dekket sine behov i Altinn på kort sikt, kan benytte løsninger i markedet eller utvikle løsningene selv.

22 Strategi 7: Effektivisere arbeidsdeling Den interne styringsstrukturen mellom Altinns organisasjon og de etatene som er ansvarlige for de enkelte sluttbrukertjenestene, effektiviseres. Formål: Rolledeling og gjensidige forventninger blir tydeligere og beslutninger tas til riktig tid. Virksomhetene må i større grad selv sørge for tjenesteutvikling

23 Langsiktig strategi Altinn videreutvikles som et viktig bidrag til digitaliseringen av offentlig sektor. Kommunene Hvorvidt nye tjenestetyper skal utvikles i Altinn, vurderes når behovene er identifisert. Teknisk videreutvikling: uavhengige tjenester som deler maskin- og programvareressurser, men som ikke påvirker hverandres ytelse (tjenestehotell).

24 Strategiske valg Det er behov for en ny og klarere Altinn strategi Hva skal altinn være for hvem på lenger sikt? Et enda tydeligere prioriteringsregime Se Altinn i sammenheng med øvrig felles infrastruktur Et langsiktig målbilde Ny felles styringsstruktur med et fokusert SKATE

25 En annen vei til digitalisering? En offentlig virksomhet jobber rett på andre virksomheters rådata. Gjennom åpne data Lenkede åpne data tilgjengelig i en metadatakatalog Kanskje er Seres framtiden? Dato Direktoratet for forvaltning og IKT

26 Sak 3 - Revisjon av dokumentstandarder Kristian Bergem 3 møter i arbeidsgruppen 1 møte med leverandører Det foreligger en revisjonsrapport Det foreligger en innstilling fra arbeidsgruppen Det har ikke kommet inn noen merknader i høringen i forkant av rådsmøte

27 Følgende 5 spm med spesielt diskutert Er HTML 5 moden? Behøver vi å peke på en rekke versjoner av PDF-standarden? Er PDF det eneste formatet som ivaretar formattering? Er det alternative formater for dokumenter beregnet for lesing? Bør det være krav til bruk av åpne standarder for kontorstøtteprogramvare?

28 Konklusjoner HTML 4.01 (W3C 1999), XHTML 1 (W3C 2000), XHTML 1.1 (W3C 2001) eller HTML 5, skal være primærformatet for publisering av tekstdokumenter på offentlige nettsider. Siden HTML5 ikke er vedtatt enda, skal standarden implementeres slik at den kan leses av en HTML 4.01 nettleser, og det må gjøres grundige brukertesting for å sikre tilfredsstillende støtte også i eldre nettlesere.

29 Konklusjoner forts. Når det av spesielle grunner må publiseres dokumenter på andre format enn spesifisert over, skal følgende format benyttes: For publisering av ferdigstilte dokumenter med behov for å ivareta formattering, skal PDF/A-1 benyttes (Fortrinnsvis PDF/A-1a, hvis programvaren støtter det). Har virksomheten behov for å benytte funksjonalitet utover PDF/A-1 kan PDF , PDF 1.7 (ISO :2008), PDF/A-2(ISO :2011) eller PDF/A-3 (ISO :2012) benyttes i stedet. Ved publisering av et dokument for videre bearbeiding, anbefales det å basere seg på en åpen standard.

30 Konklusjoner forts. Det er anledning til å publisere et dokument i andre formater i tillegg til formatene som er spesifisert ovenfor. Blant annet har PDF og ODF per dags dato begrenset støtte i enkelte løsninger for svaksynte som gjør at en slik parallellpublisering er å anbefale. Ved produksjon av PDF dokumenter anbefales det at fonter innkapsles (embed) i PDF dokumentene. Dette for i større grad å sikre at dokumentet blir gjengitt korrekt, uavhengig av plattform som benyttes, ved visning av dokumentet. Dokumenter som følger PDF/A (ISO :2005) standarden har alltid fontene innkapslet i dokumentet. Tegnsettstandarden ISO/IEC representert ved UTF-8, er anbefalt for publisering av HTML/XHTML-dokumenter på offentlige nettsider.

31 Konklusjoner forts. ISO 639 anbefales for deklarering av språkkoder for offentlige nettsider i HTML. For de språkene som har språkkoder i ISO (to bokstavers kode) skal denne brukes. Om ikke må en se videre til ISO og ISO (tre bokstavers koder). Entydige koder skal brukes fremfor språkgruppekoder. Herav følger at det må skilles mellom ulike samiske språk samt mellom bokmål og nynorsk. Anbefalingen gjelder alle språk. Se veiledning på Standardiseringsportalen for entydige koder for alle offisielle språk i Norge

32 Konklusjoner Ved behov for å formattere HTMLdokumenter, anbefales det å benytte CSS 2.0 eller CSS 3.0. Velges 3.0 kreves ekstra testing for å sikre at sidene kan vises på eldre nettlesere. Ved behov for å benytte script i HTML-sidene, anbefales det å basere seg på W3C sin versjon av DOM.

33 Behov for samfunnsøkonomisk konsekvensanalyse Det ble ikke identifisert noen nevnbare kostnader knyttet til de anbefalinger som gis på området, og man finner derfor ikke noe behov for å gjennomføre en samfunnsøkonomisk konsekvensanalyse, utover de vurderinger som allerede er gjort.

34 Sak 4: Elektronisk faktura ordre og katalog Direktoratet for forvaltning og IKT Avd. for offentlige anskaffelser Jens Aabol

35 Purring Direktoratet for forvaltning og IKT

36 Hva trenger det offentlige? Hele handelsprosessen Katalog, ordre, ordrebekreftelse, pakkseddel, faktura, kreditnota, purring. En standard Mindre vedlikehold på mapping av forskjellige formater Mindre feil, færre misforståelser Sikrer et minimum av innhold for å sikre kjøpsbeslutningen Effektivisering Enklere sporbarhet Enklere for leverandørene og kjøperne å forholde seg til et format. Kompatibel med EU Forenkler samhandelen med EU Felles forståelse uavhengig av språk

37 3 standarder ønskes 1. Versjonsoppgradering av EHF fra 1.6 til EHF for katalog. 3. EHF for ordre og ordrebekreftelse. Direktoratet for forvaltning og IKT

38 Standard EHF for hele handelsprosessen. Katalog Ordre Ordrebekreftelse Pakkseddel Faktura Kreditnota Purring EHF obligatorisk for offentlige virksomheter. Direktoratet for forvaltning og IKT

39 Elektronisk handelsformat (EHF) Direktoratet for forvaltning og IKT

40 Eksempel på en faktura med XML tag. Direktoratet for forvaltning og IKT

41 Faktura og kreditnota Formater i Norge: e2b Edifact EHF Produkt relaterte formater (SAP, ERP systemer, m.fl.)

42 Ordre, ordrebekreftelse, katalog Formater i Norge: xcbl EDI EHF

43 Arbeidsgruppen består av: Kristian Bergem Difi Jens Aabol Difi Marianne Knutsen Almas DFØ Terje Olsen Norstella Anne Salvesen Norstella Inger Anne Nilsen Oslo kommune Leif Bårnås Skatteetaten Annette Bech Skatteetaten Direktoratet for forvaltning og IKT

44 Arbeidsgruppen er enige om: Arbeidsgruppen er enig i at elektronisk utveksling av handelsdokumenter er riktig. Arbeidsgruppen er enig i at ett standard obligatorisk format gir best gevinster for offentlige virksomheter. Arbeidsgruppen er enig i at EHF har mange fordeler for å bli obligatorisk standard for offentlige virksomheter. Direktoratet for forvaltning og IKT

45 Arbeidsgruppens anbefaling Standardisere EHF for faktura versjon 2: Arbeidsgruppen er enig at EHF er i dag det beste formatet og at en utvidelse fra versjon 1 til 2 er tilrådelig. Standard for katalog: Arbeidsgruppen er enig at EHF er i dag det beste formatet og er tilrådelig som en obligatorisk standard. Standard for ordre og ordrebekreftelse: Arbeidsgruppen er enig at EHF er i dag det beste formatet og er tilrådelig som en obligatorisk standard. Direktoratet for forvaltning og IKT

46 Spørsmål

47 Regional myndighet (Difi) ansvarsområde Aksesspunkt 1 Utsteder 1 Mottaker 1 VAN SML SMP (ELMA) Utsteder 2 Aksesspunkt 2 Mottaker 2

48 Endringer 1.6 til 2.0 Identifikasjon av underversjon i ELMA. Endring av CustomizationID til urn: Dette gjøres fordi nytt EHF versjonsnummer må inn for gjenkjenning av riktig versjon som benyttes. Standardisert angivelse av EndpointID Fra <cbc:endpointid> 9908: </cbc:EndpointID> Til <cbc:endpointid schemeid= NO:ORGNR > </cbc:EndpointID> Dette gjøres fordi det reduserer misforståelser om bruken av feltet. Fullt samsvar med Bokføringsforskriften Navn på «juridisk enhet» er påkrevet Dette gjøres fordi det er et krav i Bokføringsforskriften. Fjerne inkonsistens mellom faktura og kreditnota. Dette gjøres fordi det forenkler EHF faktura og kreditnota da disse blir tilnærmet like. Det medfører mindre arbeid hos aktørene. Direktoratet for forvaltning og IKT

49 Endringer 1.6 til 2.0 Støtte for fakturering av privatpersoner (B2C) Dette gjøres fordi formatet da kan tilbys for forsendelser til privatpersoner. Oppgradering til BII2 og «PEPPOL BIS 2.0» Vil også innebære oppgradering til UBL 2.1 Dette gjøres fordi EHF må være kompatibelt med EU formatene. Direktoratet for forvaltning og IKT

50 Faktura og kreditnota e2b e2b har en god utbredelse blant aktører i det norske markedet innenfor elektronisk faktura. e2b er ikke kompatibel med resten av EU. e2b er et format som kun har med faktura og ingen av de øvrige handelsdokumentene. e2b kommer ikke til å bli vedlikeholdt etter 2013 da aktørene heller velger å benytte EHF. e2b er vedlikeholdt av private aktører. Nesten alle ERP leverandører har tilpasset seg formatet. Mange offentlige virksomheter og private leverandører har tilpasset seg formatet. Konklusjon: e2b er ikke egnet som forvaltningsstandard da den mangler flere av handelsprosess formatene. For kun faktura vil den kunne være egnet som forvaltningsstandard.

51 Faktura og kreditnota Edifact Edifact er en standard som mest er brukt mellom private aktører dagligvarehandelen. Edifact benyttes lite utenfor dette området da formatet er stort/tungt og krever god dialog mellom leverandør og kjøper. Edifact er et gammelt system som krever mye av de som skal drifte og vedlikeholde formatet. Edifact har god utbredelse i EU. Edifact er ikke kompatibelt med andre standarder i EU. Edifact er vedlikeholdt av private aktører. Få ERP leverandører har tilpasset seg formatet. Konklusjon: Edifact er ikke egnet som forvaltningsstandard da den er komplisert å vedlikeholde og krever mye arbeid før den kan formidles mellom aktørene. Edifact er mest knyttet til aktører i dagligvarebransjen.

52 Faktura og kreditnota EHF EHF er valgt som standard for elektronisk faktura for statlige virksomheter. EHF er det formatet som er i sterkest vekst i Norge. EHF er kompatibelt med formater i EU. EHF har alle dokumentene i handelsprosessen. EHF er vedlikeholdt av en offentlig instans. Nesten alle ERP leverandører har tilpasset seg formatet. De fleste statlige virksomheter og mange private leverandører har tilpasset seg formatet. Konklusjon: EHF er best egnet som forvaltningsstandard da den inneholder handelsdokument formatene. EHF vedlikeholdes av det offentlige.

53 Ordre, ordrebekreftelse, katalog xcbl xcbl har alle dokumentene i handelsprosessen. xcbl er et kjent format i EU men er ikke direkte kompatibelt med andre formater. xcbl er vedlikeholdt av private aktører. Noen offentlige virksomheter har tilpasset seg formatet. Formatet er i liten vekst i Norge. Konklusjon: xcbl egnet som forvaltningsstandard men den vedlikeholdes av private aktører. Formatet er ikke i vekst i Norge tiltros for at det kan migreres med EDI og UBL.

54 Ordre, ordrebekreftelse, katalog EDI EDI har alle dokumentene i handelsprosessen. EDI er et kjent format i EU men er ikke direkte kompatibelt med andre formater. EDI er vedlikeholdt av private aktører. Noen offentlige virksomheter har tilpasset seg formatet. Konklusjon: EDI er lite egnet som forvaltningsstandard da den er komplisert å vedlikeholde og krever mye arbeid før den kan formidles mellom aktørene.

55 Ordre, ordrebekreftelse, katalog EHF EHF har alle dokumentene i handelsprosessen. EHF er valgt som standard for elektronisk faktura for statlige virksomheter. EHF er det formatet som er i sterkest vekst i Norge. EHF er kompatibelt med formater i EU. EHF er vedlikeholdt av en offentlig instans. Noen offentlige virksomheter har tilpasset seg formatet. Konklusjon: EHF er best egnet som forvaltningsstandard da den inneholder handelsdokument formatene. EHF vedlikeholdes av det offentlige.

56 Lenker Direktoratet for forvaltning og IKT

57 Sak 5 Status for standardiseringsarbeidet i Difi Kristian Bergem Vi har gjennomført utredninger på ehandel, revisjon av dokumentstandarder og multimediastandarder. Snart vil 4.0 versjonen av referansekatalogen legges ut. Det jobbes med en 4.1 versjon av referansekatalogen Det jobbet med revidert forskrift

58 Status forts. Videre vil det gjennomføres konsekvensanalyser innen ehandelsområdene Prioriteringen for i år er ikke ferdig besluttet, men følgende ligger godt an til å bli prioritert: Sikkerhet (avventer trolig neste år) Tilgjengeliggjøring av åpne data (avventer???) Tilgjengeliggjøring av definisjoner (avventer???) Standard for plattform (avventer???) Norsk profil for web services (har ikke kapasitet stor jobb) Integrasjonsstandarder (for-prosjekt med næringslivet) Standarder for virksomhetsoversikt (påbegynne i år) Sorteringsstandard (nedprioritert ikke viktig nok) Transkriberingsstandard (prioritert i år) Standard utvekslingsavtale (nedprioritert ikke viktig nok) Teksting av video (nedprioritert ikke viktig nok) Saml-profil (nedprioritert ikke viktig nok)

59 Status forts. Det er ønskelig å få til en revisjon av arbeidsmetodikken I tillegg jobbes det med informasjon, særlig ut mot de som bryter dagens retningslinjer Det jobbet også aktivt med oppfølging av styringssystem for informasjonssikkerhet Det jobbes aktivt med oppfølging av arbeidet med innføring av felles tegnsett, men noe forsinkelse pga. skader

60 På arkitektursiden Det jobbes med arkitektur for meldingsboksarbeidet. Dette vil bli presentert på neste møte i Standardiseringsrådet. Det jobbes også med prosjekt rundt meldingshåndtering i offentlig sektor. Det kan gi spinn og i forhold til både arkitektur og standardiseringsbehov.

61 Sak 6 revisjon av multimediastandarder Kristian Bergem 4 møter i arbeidsgruppen 1 leverandørworkshop Revisjonsnotatet foreligger Innstilling fra arbeidsgruppen foreligger Det har ikke kommet inn noen merknader i forbindelse med høringen før rådsmøte. I denne gjennomgangen ble det spesielt stilt spørsmålstegn ved behovet for å opprettholde obligatoriske krav på områdene. Det ble også stilt spørsmålstegn rundt behovet for å utvide anvendelsesområdet til å inkludere utveksling.

62 Konklusjoner multimediastandarder Punktgrafikk For publisering av bilder på offentlige nettsteder er det anbefalt å benytte følgende standarder: JPEG for bilde med tapsbasert komprimering PNG for bilde med tapsfri komprimering. Det anbefales ikke å benytte GIF ved eventuell parallellpublisering Skalerbar grafikk Ved publisering av skalerbar grafikk på offentlige nettsider er det anbefalt for offentlig sektor å benytte: SVG 1.1

63 Konklusjoner forts. Lyd Ved publisering av tapsbasert lyd er det obligatorisk å benytte minst en av følgende standarder: Vorbis 1 (Xiph.org 2004) innkapslet i Ogg (RFC 3533, IETF 2003) MP3 (ISO ), uten innkapsling (elementærstrøm) Ved publisering av tapsfri lyd er det anbefalt å benytte: FLAC (Xiph.org 2007), kapslet inn i enten FLAC s eget innkapslingsformat eller Ogg (RFC 3533, IETF 2003). Det anbefales å parallell-publisere på ALAC ved behov.

64 Konklusjoner forts. Video For publisering av video på offentlige nettsteder er det obligatorisk å benytte minst en av følgende standarder: Videosporet kodet i Theora 1.0 (Xiph.org 2008) og lydsporet i Vorbis 1 (Xiph.org 2004) innkapslet i Ogg (RFC 3533, IETF 2003) Videosporet kodet i H.264 (ISO/IEC :2009) og lydsporet i AAC (ISO/IEC :2006) innkapslet i MP4 (ISO/IEC :2003) (NB: WebM med VP8 ble vurdert)

65 Sak 7 Eventuelt