Även om vi i redaktionen strävar efter att täcka in alla perspektiv så blir det ofta mer arkiv och mindre teknik i tidningen. För att råda bot på detta satte vi oss ner med några av utvecklarna på ArkivIT för att få deras perspektiv på e-arkivprojekt, både vad gäller själva det tekniska genomförandet men också tips för ett gott samarbete inom projektgruppen. 

Att arbeta på som utvecklare på ett företag där arkivfrågor står i fokus är inte alltid tacksamt då teknikfrågorna lätt hamnar i skymundan. Men i ärlighetens namn, teknikfrågan är central och utan våra utvecklare skulle det inte ens bli några leveransprojekt. Trots att arkivarier och utvecklare arbetar nära i projekten så är det ibland som skilda världar med ibland helt olika språk. Men som Magnus Raask tar upp i sin artikel börjar vi närma oss varandra och han betonar även vikten av att vi delar samma begrepp och att vi kan kommunicera med varandra. 

På ArkivIT arbetar våra utvecklare med flera olika typer av uppdrag och projekt. Dock är det vanligt att flertalet uppdrag hos oss innefattar dataextraktion som “innebär uttag av data från en datakälla”. Utvecklarens uppgift är enkelt uttryckt att hitta rätt teknik för detta samt att därefter genomföra uttag av data. Den data som tas ut (extraheras) ska bearbetas och levereras till en utpekad lagringsplats. Vad som ska bearbetas och vad som ska nyttjas som lagringsplats varierar från uppdrag till uppdrag. Om det är filer med i uttaget måste även dessa kontrolleras och i många fall konverteras till arkivbeständiga format. Varje uppdrag ser väldigt olika ut, både vad gäller det programmeringsspråk som används men även om uttag ska göras återkommande eller enbart en gång. Ofta är det sistnämnda det vanligaste i samband med att system läggs ner. Det är när det ska beslutas om vad som ska bevaras och gallras kopplas arkivarien in då denna har koll på informationens gallringsfrist. 

”Att vara systemutvecklare handlar om så mycket mer än att endast jobba med teknik.”

Ett begrepp som återkommer i ett leveransprojekt är ETL som står för Extract (extrahera), Transform (transformera), Load (ladda in). Våra utvecklare förklarar att det “är en process med delmoment för att i turordning hämta, bearbeta och till sist ladda data från en eller flera källor till ett eller flera mål.”  De fortsätter: “ett lyckat ETL-flöde till ett e-arkiv ger en tydlig känsla av kvalitet och noggrannhet i varje del från uttag till inleverans. Det ska finnas spårbarhet, dataintegritet och långsiktig läsbarhet vilket innebär att information går att härleda till sin ursprungskälla, att data har validerats och transformerats korrekt enligt arkivets regelverk och att format och metadata uppfyller krav på långtidsbevarande. Nyckeln till framgång i ett ETL-projekt är samma som i många andra av våra projekt, ett nära samarbete mellan verksamhet, IT och arkivfunktion.” 

Har du som utvecklare tur finns en systemdokumentation som du överskådligt kan läsa igenom vid projektstart. Systemdokumentationen används därefter under projektets gång i de fall du behöver svar på mer detaljerade frågor. En extra bonus är om systemet har en ”super user” hos kunden, det vill säga en användare på expertnivå som kan visa hur systemet används. Genom att sitta tillsammans med användaren ges en inblick i vilken information systemet hanterar och på vilka delar av det som fokus ska läggas. Ibland uppstår dock situationer där systemdokumentation saknas och/eller att det endast finns ovana systemanvändare kvar i organisationen. Det går fortfarande att komma framåt men i de fallen upplever våra utvecklare att det tar det avsevärt mycket mer tid att få ut rätt data och det blir en stor osäkerhet kring informationens betydelse. Eller som de själva uttrycker det; “Det blir mer gissningar men de kan göras någorlunda kvalificerade genom att reda ut hur information hänger ihop och om det finns mönster i hur information sparas i systemet. Går det att få ut databasrelationerna genom reverse engineering så är det ett bra stöd.” 

För en arkivarie låter det ibland lite som att utvecklaren tittar på en skärm, skriver in lite tecken och sen är det klart. Men verkligheten är mer komplex och det är inte alltid en strömlinjeformad process. En av våra utvecklare berättar om en av de största utmaningarna hen stött på. Detta var “i ett projekt där vi skulle hämta data från ett äldre skräddarsytt verksamhetssystem. Dokumentationen var i stort obefintlig och ingen av utvecklarna som byggt systemet fanns kvar i organisationen. Vi försökte använda reverse engineering genom verktyg för att skapa ER-diagram¹ över informationsstrukturen i databasen – detta ger inblick i databastabeller, fält, nyckelvärden och relationer. Diskussion med användare skapade ytterligare förståelse för samband mellan data och datans betydelse.” Ofta går det att lösa, men vägen dit är inte alltid enkel. 

Under projektets gång är det speciellt en fas i ETL- processen som utmanar mest- extract- och transform. När vi frågar varför får vi svaret att “det är så många aspekter som påverkar hur jobbet ska göras. Du måste kunna genomföra analys av komplex informationsstruktur i databaser såväl som ostrukturerad data (filer i mappar med mera) samt förstå verksamhetslogik och betydelsen av källdata för att kunna omvandla den korrekt. Det kräver ofta programmering av regler, script för konvertering² och hantering av felaktiga eller saknade värden.” Hur hanterar man då detta? Vi får svaret att vid hantering av datakvalitet ligger fokus på att identifiera, flagga och rätta fel i flera steg. Data analyseras för att hitta tomma fält, felaktiga värden, dubbletter, logiska fel med mera. I diskussion med verksamheten beslutas därefter hur felen ska rättas. Ibland sker rättningen redan i källdatan medan i andra fall sker detta längre fram i ETL-processen. 

Även om det finns applikationer och system som har egna uttags- och importfunktioner eller en sedan tidigare färdig lösning, så menar våra utvecklare att det fortfarande är allra vanligast att bygga en extraktionslösning från grunden. Och även om grunden i arbetet är densamma, det vill säga, du hämtar (extraherar) data, bearbetar (transformerar) den och slutligen så laddas den in i ett målsystem. Vägen till målet varierar dock beroende på typ av databas och vilket programmeringsspråk du som utvecklare föredrar att arbeta med. Om du som utvecklare kan arbeta direkt mot databasen, och den aktuella applikationen har en SQL-databas, så är SQL ett alternativ för att ta ut data ur systemet. Ibland finns det en databas som går att nå med SQL, men det räcker inte – du behöver även själva applikationen för att förstå vad datan betyder och hur den hänger ihop. Och den applikationen har du inte tillgång till. I sådana fall används något som kallas RPA (Robotic Process Automation). Det innebär att du som utvecklare programmerar en mjukvarurobot som klickar sig runt i applikationens användargränssnitt och hämtar ut data, precis som en vanlig användare skulle göra. Ett exempel på ett sådant verktyg är Microsoft Power Automate som ingår i Microsoft M365-portföljen. 

Idag har flertalet moderna program något som kallas ett API.³ Det är en typ av tekniskt gränssnitt som gör att man kan hämta ut data direkt från databasen i mer strukturerade format, som JSON eller XML, utan att behöva gå via själva användargränssnittet. Vilket språk som används vid programmeringen är helt upp till utvecklarens egna preferenser och vad som fungerar bäst för det aktuella projektet, vi utvecklare rör oss bekvämt mellan Python, PHP, C#, Java. Men det finns alternativ till den kanske mer traditionella programmeringen, berättar våra utvecklare, “där det finns verktyg i vilka det skapas modeller för ETL-processen. Dessa verktyg ansluter till datakällan och via modellen definieras det hur data ska transformeras och färdigställas för att levereras till lagringsplatsen. Utöver det har vi även en mängd andra tekniker och metoder som vi utvecklare hittar och tipsar varandra om vartefter vi utför våra ETL-uppdrag.” 

”En annan effekt de ser är att vissa roller, om det fortsätter i riktning mot det digitala, måste ta till sig den kunskap som krävs för att jobba med e-arkiv.”

Ett projekt är inte bara metodik och processer utan en stor del består av att samarbeta och kunna kommunicera med olika roller, som ibland inte har insyn i det arbetet du själv utför. Undertecknad har erfarenhet av att stå på arkivsidan men hur upplever våra utvecklare att samarbetet fungerar i ett projekt? “Samarbetet fungerar oftast som ett nära samspel där varje roll bidrar med sin expertis. Med arkivarier diskuteras sådant som informationsstruktur, begrepp, metadata och vad som ska gallras respektive vad som ska sparas och tas med i leverans för vidare lagring. Till projektledare rapporteras status, risker och framsteg. Projektledaren prioriterar uppgifter och kommunicerar med andra delar av projektet. Behörigheter och tekniska detaljer stäms av med systemägare och drifttekniker. De är viktiga för att förstå hur systemet fungerar i praktiken och hjälper till vid viss typ av felsökning. Sammantaget handlar det om att vara kommunikativ, lyhörd och tydlig – så att alla parter jobbar mot samma mål.” 

Ibland kan det dock uppstå missförstånd kring utvecklarens roll som ofta upplevs “som en ganska ”teknisk” uppgift det vill säga att bara flytta data från punkt A till punkt B. I själva verket handlar det mycket om att förstå både verksamhetsprocesser och datakällornas struktur och begränsningar. För att klara detta krävs både teknisk kompetens och förmåga att sätta sig in i och förstå verksamheten. Att vara systemutvecklare handlar om så mycket mer än att endast jobba med teknik. Tekniken ska vara ett stöd för verksamheten och till nytta för användarna!” 

Våra utvecklare har de senaste åren sett en ny trend kring utvecklingen i e-arkivbranschen där de ser en framväxt av samarbeten kring e-arkiv, exempelvis kommuner emellan. Här menar de att det “ökar standardisering i ETL-jobbet och möjlighet att hjälpa varandra genom kompetensdelning. En annan effekt de ser är att vissa roller, om det fortsätter i riktning mot det digitala, måste ta till sig den kunskap som krävs för att jobba med e-arkiv. ”Detta kommer ställa krav särskilt på arkivarierollen så den successivt utvecklas till att inkludera mycket mer kunskap om e-arkivering.” 

Slutligen, har ni några tips ni vill skicka med på vägen för att få till ett lyckat e-arkivprojekt? “Absolut, några medskick har vi: 

• Klargör vad det är för information som ska e-arkiveras och hur den ska göras tillgänglig. Hanteringen ska uppfylla flera olika krav gällande juridik, informationssäkerhet med mera. 

• Ta med arkivarier, tekniker och eventuellt andra experter tidigt i diskussionen så att ni får vägledning kring standarder, format, metadatakrav, teknikplattformar och metoder. 

• E-arkivering är en del av verksamhetens informationsförvaltning. IT-systemen som kallas e-arkiv löser inte ensamt hela e-arkiveringen, det behövs en förvaltningsorganisation som hanterar verksamhetens e-arkivfunktion.” 

 Med de slutorden tackar vi för intervjun och hoppas på än fler lyckade arkiveringsprojekt i framtiden! 

---

Namn: System Utvecklare 

Roll: Systemutvecklare 

Arbetsplats: ArkivIT 

Jag är en samling av alla utvecklare som arbetar på ArkivIT och mina svar speglar erfarenheter som hänt i teamet. 

Namn: Alexandra Meija

Roll och arbetsplats: Tidigare projektledare och chefredaktör AIT på ArkivIT nu arkivarie på Förvaltning för utbyggd Tunnelbana, Region Stockholm samt chefredaktör för världens bästa tidning AIT

Alexandras yrkesbana har varit rätt brokig. Från läraryrke till registrator, till arkivarie till projektledare och nu senast webutveckling. Det finns alltid en strävan att lära sig nytt och utveckla sig som ligger bakom. När hon inte arbetar med denna eminenta tidning så är det troligt att hon sitter och bygger databaser i C#.