Jean-Philippe André Caquet eKommune

Presentasjon om: "Jean-Philippe André Caquet eKommune"— Utskrift av presentasjonen:

1 Jean-Philippe André Caquet eKommune 16.09.2014
Arkiv og Arkitektur (Eller Arkivtektur) Jean-Philippe André Caquet eKommune

2 Visjon Temaplan IKT, Digitalisering og Velferdsteknologi 2015-2018
Effektivisering av tjenesteproduksjon ved standardisering og automatisering Legge til rette for selvbetjening og digital kommunikasjon som førstevalg Teknologi bidrar til innovasjon i tjenesteproduksjonen Gode verktøy gir et bedre arbeidsmiljø for den enkelte

3 Nasjonale arkitekturprinsipper (DIFI)
Tjenesteorientering Interoperabilitet Tilgjengelighet Sikkerhet Åpenhet Fleksibilitet Skalerbarhet

4 Tjenesteorientert arkitektur?
ESB ”Tjenestebuss” All customer services communicate in the same way with the ESB: the ESB translates a message to the correct message type and sends the message to the correct producer service.

5 Også kalt tre-lags arkitektur
Presentasjonslag Applikasjonslag Databaselag

6 ”Arkivet” som en tjeneste.
”Kan vi ikke bare integrere fagsystemet med arkivet?” Men hva ER ”Arkivet”, er det bare EN tjeneste? Arkiv i tradisjonell forstand hører i utgangspunktet hjemme kun på databaselaget, men i det man kaller ”arkiv” i dag, er egentlig mye mer

7 Før Nå

8 Dette ”arkivet” I dag heter arkivet ePhorte, ESA, Acos eller P360, mao = Sakarkivsystemet Men det er ikke bare en plass hvor dokumenter går for å dø. Sakarkivsystemet skal oppfylle en rekke forskjellige oppgaver og lovkrav… … mer eller mindre bra

9 Informasjons-forvaltning
Saksoppfølging Saksbehandling SAKARKIVSYSTEM Postjournal Samarbeids-rom Informasjons-forvaltning Transaksjonslogg Dokument-håndtering Offentlig Innsyn Kommunikasjon Record Management Arkiv

10 Hvordan klarer det disse oppgavene?
Sakarkivsystemer har ofte et eller et par GUI, hvorfra man skal gjøre følgende Saksbehandling? Så lenge du følger malen Saksoppfølging? Så lenge alle og spesielt lederne bruker systemet. I dag er dette en rolle dumpet på ”arkivarene” Journal? For det som kommer inn gjennom postmottaket (og for det man selv husker å legge inn) Transaksjonslogg? Samme som forrige Dokumenthåndtering? Informasjonsforvaltning? En liten brøkdel Offentlig innsyn? Svært tungvint Samarbeidsrom? Det meste foregår utenfor Arkiv? Så lenge folk bruker det Record Management? HÆ???

11 Record Management Ta vare på og sikre all informasjon på en enhetlig, valid og kontekstuelt riktig måte gjennom hele dens ”livssyklus” fra den oppstår til den faller ut av daglig bruk, uten å skyve eventuelle utgifter foran oss i forbindelse med avslutning og deponering av utgåtte systemer som fortsatt inneholder nødvendig informasjon.

12 Når vi avbryter noen vi er uenige med med ”For the record vil jeg si…”…”
Sier vi egentlig: Her og nå, i denne sammenhengen og i min funksjon har jeg, sagt til dere. ”Recorden” er med andre ord ikke bare det du sier, men også kontekstopplysningene (metadataene), som også må registreres, signeres og bekreftes, kun da kan dette kalles en”Record” Så er det også med all annen informasjon, både dokumenter og data. Uten kontekst er de verdiløse Og dette var bare 7 metadata. Som oftest trenges langt flere…

13 NOARK 5 UTTREKK – OBLIGATORISK FOR SAKARKIV
INNEHOLDER ”TIMESTAMPS” OG ”SIGNATURER” SAMT ENKELTE ANDRE KONTEKSTOPPLYSNINGER SOM GARANTERER FOR DELER AV KONTEKST

14 Metadata og datakvalitet
Metadata – data om data Det finnes en del NOARK-spesifikke metadata (RM-relaterte metadata) I tillegg genererer saksbehandling andre arkivverdige metadata (f. eks. klientinformasjon, eiendomsdata, statistikk osv). Det må på forhånd vurderes hvilke som skal bevares. Når en ”Record” er avsluttet er det for sent For en del metadata må endringer over tid logges fordi tidligere versjoner av dataene ligger som grunnlag for saksbehandling (t. eks. i klientarkiv) Manuelle registreringer bør unngås fordi: Manuell registrering er tungvint Manuell registrering er en hyppig feilkilde Manuelle registreringer er en sikkerhetsrisiko

15 Innsyn Datakvalitet og innsyn. Dårlig datakvalitet, problematisk gjenfinning Datakvalitet og sikkerhet. Dårlig datakvalitet, sikkerhetsrisiko ved digital tilgjengeliggjøring ”Datatilten” Prosess vs gjenfinning Prosessorientert vs objektsorientert Finn fisken… Jeg fisker…

16 Innsyn og skjerming Datatilsynet har fire sikkerhetsnivå: 1, 2, 3 eller 4… Kommunene bruker, eller skal bruke, alle Offentleglova, Forvaltningsloven på den ene siden personopplysningslova, Helseregisterloven, Sikkerhetsloven osv. på den andre Prinsipp om meroffentlighet Skal systemet inneholde personregistre må det meldes inn til Datatilsynet. Det kan også være nødvendig å søke konsesjon Hva med ”Mappa mi”? Ønsker vi ikke å gi innbyggerne fullt innsyn i ”sine” saker?

17 Kommunenes totale utfordringer
Systemene føles tungvinte og blir lite brukt. Informasjonsrevolusjonen Systemene dør og og dataene blir ikke trukket ut eller trukket ut feil Kommunene forholder seg til hundrevis av lovverk. Mye saksbehandling foregår av nødvendighet utenfor systemene

18

19 Hvilken sky?

20 Dokumentlager sensitivt
ID-Portalen Sikret sone (SN 3-4) SvarUt Offentlig Journal Fagmodul Fagmodul Fagmodul Generell fagmodul Henvendelses- modul Generell fagmodul Fagmodul Fagmodul Journal/Logg NOARK-5 kjerne SN 1-2 NOARK-5 kjerne SN 1-2 NOARK-5 kjerne ”Blandet” NOARK-5 kjerne ”Blandet” NOARK-5 kjerne SN 3-4 Kunderegister Dokumentlager Dokumentlager sensitivt N5 webservices LDAP Brukerhenvendelser, innsyn Sikre innsyn, henvendelser

21 Prosjekter NOARK 5 åpen og konfigurerbar kjerne. Prosjekt igangsatt
Felles Henvendelsesmodul. Prosjekt igangsatt Sentral Kommunikasjonslogg/Postjournal. Tar over for registrerings- og journalføringsoppgavene som tidligere var en del av arkivet. Del av prosjekt for Felles Henvendelsesmodul Webservices: Generisk NOARK 5 og GeoIntegrasjon (SOA?) Ny Forenklet Saksbehandlerløsning (Forprosjekt ut 2015) Annet: Webservices for integrasjon mot sentrale registre, som f. eks Folkeregister (gjennom eget Kunderegister), Brønnøysund og matrikkel (GEO-integrasjon) Felles Saksbehandlerregister (For tilgangsstyring, PKI og SSO) PKI og Sentrale sikkerhetsløsninger Eget kunderegister? Igangsatt foranalyse

22 Informasjonspakker/Dokumentuveksling
ID N5 N5 Signering Nøkkel N5 N5 Bruker

23 NOARK 5 kjerne må ha: Grensesnitt mot fagsystemer [N5 WS].
grensesnittmot Sentral Kommunikasjonslogg [N5 WS]. Verktøy for måling av datakvalitet i N5-basen (overvåke datakvalitet under danning) Forenklet GUI for avansert kjerneoppsett Innsyns-GUI for kjernen for historiske uttrekk Støtte for kjerner på begge sider av intern/sikret sone (SN 1-2, SN 3-4) Støtte for konvertering til alle lovlige arkivformater (Lyd, bilde, tekst, xml osv) Verktøy for massearkivering av filområder (gjerne med automatisk forslag til strukturoppsett) Mappingverktøy for migrering av databaser fra eldre (ikke N5) fagsystemer Videreutvikling av uttrekksmodul for å støtte uttrekk av ”dokument/informasjonspakker”, er fremtidens arkivformat RTF (UTF-8)?

24 Overordnet oppsett i arkivkjernen
Arkivet gjenspeiler tradisjonelt sett organisasjons- og fagområdestrukturene, men for å gjøre arkivet mer robust for endringer trengs et mer funksjonsbasert bilde. Definer arkivstruktur (arkiver, underarkiver, mapper, mapper-i-mapper, klassifikasjonssystemer o.l)

25 Virksomhets-spesifikke metadata?
Oppsett i N5 kjerne (lokalt) Annen Arkivskaper? IKS? Arkivskaper TK Sikkerhetsnivå? Trondheim Kommune Klassifikasjonssystem? Virksomhets-spesifikke metadata? Arkivdel - Eiendom Skjerming? Sløyfes? Mappenivå I Journal Mappenivå II (Saksmappe?) Registrering Basisregistrering? Registrering? Journalføring? Dokument-beskrivelse Dokument objekt Dokumentlager

26 NOARK 5 Journal/Logg må ha
Grensesnitt mot fagsystemer [N5 WS]. Grensesnitt mot Arkivkjerner [N5 WS]. Grensesnitt mot Henvendelsesmodul Tildeling av saksnummer Skjermingsfunksjonalitet Ferdige GUI for ”embedding” i fagsystemer Støtte for kjerner , fagsystemer og journaler på begge sider av intern/sikret sone (SN 1-2, SN 3-4)

27 For fagsystemer Krav til nyanskaffelser skal anpasses etter ny
arkitektur ”Naturlig avgang” av gamle systemer Systemanskaffelsene vil fokusere på arbeidsprosesser med arkiv/record keeping, journalføring og utsendelser tatt hånd om Kan fagsystemer bli apper?

28 # * FAG- OG SAKSBEHANDLINGSMODULER Men hva skal de kunne i morgen?
En grunnmodul med tilpasninger? Men hva skal de kunne i morgen? Dagens saksbehandlere bør kunne sitte her * Journal/Logg Arkivkjerne # Dokumentlager Webtjenester * Eksterne registre (hentes utenfra, matrikkel, folkeregister o.l) # Interne databaser (kommunens ansvar å vedlikeholde, kunderegister, AD)

29 SPØRSMÅL?