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

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

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. 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-spesifikkemetadata (RM-relatertemetadata) • 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. http://www.aiim.org/

19. Hvilken sky?

20. ID-Portalen Sikret sone (SN 3-4) SvarUt Offentlig Journal Henvendelses- modul Fagmodul Fagmodul Fagmodul Generell fagmodul 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 N5 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. Annen Arkivskaper? IKS? Oppsett i N5 kjerne (lokalt) Arkivskaper TK Sikkerhetsnivå? Trondheim Kommune Klassifikasjonssystem? Virksomhets-spesifikkemetadata? Arkivdel - Eiendom Skjerming? Sløyfes? Mappenivå I Journal Mappenivå II (Saksmappe?) Registrering Basisregistrering? Registrering? Journalføring? Dokument-beskrivelse Dokumentlager Dokument objekt

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? 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?