Grundläggande förståelse

Transkript

1 Syftet Syftet med denna text är att vara inspiration och tankeväckare runt arkitektur och integrationer. Målgrupp för texten är intresserade främst inom kommunal verksamhet. Texten har inte för avsikt att ge detaljerade svar på detaljerade frågor. Istället ger texten inspiration och inspel som förhoppningsvis i nästa steg ger de svar som efterfrågas. Inledning Ett modernt samhälle med digitaliserade medborgare ställer krav på varje offentlig organisation. Krav på snabb, billig och personlig service. Krav att kunna utföra sina vardagliga måsten digitalt via tjänster tillgängliga oavsett tid och plats. Medborgaren vill kunna fråga, ansöka och anmäla och snabbt få svar. Givetvis ska varje ärende kunna följas digitalt i realtid. Medborgaren uppträder i olika roller beroende på sammanhang. Det kan t.ex. vara: som privatperson som förälder som målsman som förmyndare/god man som företagare som företrädare för en förening som anhörig som kommuninvånare som besökare Oavsett vilken roll medborgaren för stunden upprätthåller förväntar sig även medborgaren att ses som en individ av sin kommun. Dvs om jag söker bidrag vill jag också att kommunen ska veta vilka bidrag jag tidigare sökt, vilka insatser jag tagit del av, om jag fått vård och om jag har barn i skola eller omsorg. Jag vill inte behöva svara på samma frågor flera gånger eller lämna samma information upprepade gånger exempelvis om jag har tre barn att placera i skola så vill jag att kommunen har reda på att just jag har tre barn och att just jag är deras förälder. Inte alltför sällan vet medborgaren kanske inte ens om det är kommunen eller någon annan myndighet som ger den service som eftersöks. Troligen är det inte viktigt vilken organisation som gör det, bara servicen blir utförd. Låt säga att du vill boka en idrottshall för att tillsammans med några vänner spela innebandy, badminton eller tennis. Genom en app i din mobil, speciellt utvecklad för ditt intresseområde (kanske en tennis-app eller en lag app för innebandylaget), söker, hittar och bokar du lokalen helt digitalt. Hyran för lokalen betalas naturligtvis också digitalt. När du genomför bokningen vet du inte om det är kommunens lokal eller den lokala tennisklubbens lokal och för dig spelar det ingen roll. Lokalen passar ditt syfte och vem som äger den spelar ingen roll. Kanske är det en kommunal lokal som drivs av en privat aktör? Essensen är att behoven, kraven och förväntningarna på den offentliga sektorn är att kunna erbjuda tjänster och service på samma nivå som, och ibland tillsammans med, vilken annan aktör som helst. Ibland är det en kommunal eller en privat utförare, ibland är det en helt annan myndighet eller en annan kommun (kanske grann

2 kommunen). För att kunna lyckas med detta behöver digitaliseringslösningarna och verksamheternas processer utvecklas. Denna text syftar till att ge inspiration till detta. Hur bör systemen bakom tekniken vara arrangerade för en långsiktigt hållbar utvecklig och förvaltning ska vara möjlig? Hur behöver informationen vara arrangerad för att denna hantering ska vara möjligt? Hur ska olika system från olika leverantörer kunna kommunicera och utbyta information med andra system från andra organisationer? Grundläggande förståelse Det finns naturligtvis inget rakt och enkelt svar på de HUR-frågor som nämns i inledningen ovan. Men genom att skapa en grundläggande förståelse för ett antal utmaningar och alternativa lösningar kan var och en hitta sin lösning på HUR-frågorna. Sverige består av 290 kommuner som alla har sina olika förutsättningar och de skiljer sig stort mellan t.ex. de största och de minsta kommunerna. Utifrån detta kan vi dra slutsatsen att det troligen är nästan en omöjlighet att kunna ta fram EN lösning/arkitektur/plattform som passar alla. Men om alla utgår från och använder samma standarder och nationella stödfunktioner kan samverkan och informationsdelning ske. Kommungränsen Det är viktigt att se skillnad på det nationella och lokala perspektivet. På lokal nivå i en kommun finns flera olika arkitekturella utmaningar. Varje kommun har t.ex. sina förutsättningar utifrån organisation, politiska och ekonomiska förutsättningar och kommunstorlek. I vissa kommuner levereras mycket kommunal service igenom privata aktörer. I andra kommuner genomförs den mesta verksamheten i kommunal regi. Oavsett alla dessa olika förutsättningar är det gemensamt för alla att de styrs av samma lagar, förordningar och uppdrag. På nationell nivå finns utmaningen att 290 kommuner ska kunna finnas och verka tillsammans och med andra aktörer andra kommuner och/eller myndigheter. I vissa fall finns beroenden mellan dessa olika perspektiv, ibland inte. För den fortsatta läsningen av denna text är det bra om du som läsare reflekterar över skillnaden mellan det lokala och det nationella perspektivet. Vad som sker innanför kommungränsen, dvs lokalt, och den helhet som den enskilda kommunen måste vara en del av, dvs nationellt. Arkitekturområden I figuren nedan beskrivs ett annat grundläggande synsätt/perspektiv. När vi pratar om olika storheter som processer, verksamhetsutveckling, stödsystem och andra begrepp behöver vi ha en gemensam karta eller synsätt på var dessa storheter finns i förhållande till andra.

3 Kundens processtöd styrs av kundens process, dvs kundens behov och agerande, som kan vara en hel livshändelse 1 eller en avgränsad ärendeprocess. Kunden agerar i en struktur och i ett mönster som har sin logik och sina ekonomiska modeller. Det kan t ex vara en företagare som inom en specifik bransch styrs av de förhållanden och regelverk som finns för denna. Det kan också vara en ensamstående pappa som försöker få vardagen med sina små barn att gå ihop. I kundens processer är det inte ovanligt att man måste ha kontakt med flera olika kommuner, myndigheter och aktörer för att kunna lösa sin situation. Som medborgare, företagare eller förening kan jag agera i flera kommuner samtidigt eller så vet jag inte alltid exakt i vilken kommun en fråga hör hemma (det finns t.ex. gator i storstadsområden som har olika kommuner på var sida om samma gata). En kommun behöver därför bygga tjänster med en arkitektur som möter dessa olika logiker, processer och strukturer, och som dessutom behöver samverka med andra kommuner, myndigheter och aktörer. Kommunens egna processer och strukturer beskrivs som Kommunens processtöd. Här finner vi den logik som kommunens verksamheter agerar inom. Det är allt ifrån informationsmodeller, ekonomiska modeller, juridiska lagrum och modeller till ärendehanteringsprocesser och politiska processer. En kommun agerar på den lokala nivån med dess lokala beslut, processer och rutiner och samtidigt samverkar kommunen på den nationella nivån utifrån nationella regelverk, överenskommelser och best practice. Det finns också olika Gemensamma tjänster som kan nyttjas oberoende om det är i kundens eller kommunens processtöd. Det kan t.ex. vara olika informationstjänster för tillgång till grunduppgifter såsom personuppgifter eller fordonsuppgifter som en annan offentlig organisation förvaltar för hela offentlig sektors räkning. Det kan också vara tjänster av mer stödjande karaktär som t.ex. olika identifieringstjänster, såsom e-legitimation, eller generella adresseringstjänster. 1 esams vägledning Digital Samverkan, och Behovsdriven utveckling, beskriver djupare.

4 Den sista delen i bilden ovan, de grå partierna mellan de färglagda områdena, beskriver den yta där olika informationsobjekt behöver integreras med varandra för att systemet ska fungera. Det kan t.ex. vara olika typer av informationsmängder såsom ärenden som flödar mellan de olika områdena, kanske ett ärende som initieras av kunden i dennes process, verifieras och administreras med hjälp av gemensamma tjänster och sen handläggs i kommunens process. Sammanfattning Bilden visar en helhet som beskriver de olika domäner eller områden som den kommunala arkitekturen behöver kunna fungera inom. Det är viktigt att förstå att de olika områdena har olika logiker och förutsättningar som ställer krav på eller präglar området. Lägg även till resonemanget om perspektiven med det lokala och det nationella. Arkitekturella frågor för en kommun är med andra ganska komplexa.

5 Digitala tjänster Med utgångspunkt i resonemangen ovan kan vi förstå att det finns många olika typer av digitala tjänster. Det finns digitala tjänster som är utvecklade för kundens processtöd och andra digitala tjänster för kommunens processtöd. Vissa tjänster är specifika för en unik process andra är generella och ger stöd till andra tjänster - gemensamma tjänster. Tjänster kan vara lokala och finnas tillgängliga i varje kommun eller så kan de vara nationella och bara finnas tillgängliga på en central plats. Det finns med andra ord många olika perspektiv som en digital tjänst kan uppträda i. Ibland kan det uppfattas som att digitala tjänster bara är det vi brukat kalla e-tjänster. Det vi brukar kalla e-tjänst är snarare en digital tjänst som finns tillgänglig i kundgränssnittet inom kundens processtöd. Men det kan även vara en e-tjänst som finns internt i kommunens process för kommunens egna medarbetare. Kunden är då den interna medarbetaren och kundens processtöd finns internt. Det finns idag ingen generell eller beslutad definition av vad en e-tjänst är. Verva ( ) beskrev en e-tjänst som [ ] en service som medborgare och företag kan använda för att uträtta olika ärenden som de har hos en offentlig myndighet. Denna service tillhandahålls som en elektronisk tjänst och erhålls till exempel med hjälp av en dator, mobiltelefon eller via avancerad telefonservice. Oavsett om detta är den ultimata beskrivningen eller om det finns andra beskrivningar så är det inte avgörande. Här vill vi istället försöka definiera det som vi valt att kalla för olika generationer av e-tjänster. 1:a generationens e-tjänster Den första generationens e-tjänster kan beskrivas som ett webb-gränssnitt uppe på ett verksamhetssystem. Du känner igen denna typ av e-tjänster på att de levereras som olika typer av tilläggsmoduler till ett verksamhetssystem. Det grafiska gränssnittet utgår ofta ifrån leverantören av verksamhetssystemet och följer oftast inte kommunens grafiska profil. Ord och texter i e-tjänsten utgår ofta ifrån samma typ av vokabulär som det tillhörande verksamhetssystemet. Användarhanteringen för kunden bygger ofta på verksamhetssystemets logik. Logiken och strukturen från Kommunens processtöd har lagt på gränssnittet inom Kundens processtöd. Med denna ibland inte helt lyckade mix av kommunens och kundens processtöd, upplever kunden ofta en inte helt optimal digital tjänst. Det finns idag gott om kommuner som har denna typen av digitala tjänster publicerade.

6 Fördelar Rent tekniskt ganska enkelt att köpa/upphandla och att publicera Snabbt sätt att publicera digitala tjänster Nackdelar Inte tillräckligt användarvänlig och/eller tar inte hänsyn till kundens behov och livshändelse, då de oftast byggs med ett inifrån-och-ut-perspektiv Följer oftast inte kommunens grafiska profil Går inte att justera e-tjänstens informatiska innehåll Den information som e-tjänsten samlar in blir ofta inlåst i verksamhetssystemet och kan därför inte återanvändas av andra IT-system eller tjänster (inlåsningseffekter). 2:a generationens e-tjänster Med intåget av specifika e-tjänsteplattformar skapades nya möjligheter för kommuner att publicera digitala tjänster. Med dessa plattformar skapas/byggs e-tjänster ungefär som du kan skapa ett bildspel. Tekniken kallas ibland för WYSIWYG What You Se Is What You Get så som du skapar det så blir det publicerat, fritt översatt. Med 2:a generationens e-tjänster har de tekniska trösklarna sänkts rejält. Det pratats om att det inte ska behöva vara en tekniskt utbildad för att utveckla en tjänst. Om det är sant eller möjligt beror nog på flera parametrar. När det blivit så enkelt att skapa e- tjänster har det mer komplicerade arbetet med att bygga integrationer till verksamhetssystem blivit en begränsande faktor. Det blir ofta dyrt och komplext. Många verksamhetssystem saknar också APIer för att kunna ansluta integrationer. Många kommuner har idag tillgång till någon form av e-tjänsteplattform. Det är inte ovanligt att en kommun publicerar både 1:a och 2:a generationens e-tjänster. Fördelar Enkelt att skapa, ändra och publicera digitala tjänster Samma grafiska profil på alla kommunens tjänster. Kunden känner igen sig. Ger möjlighet att separera kundens och kommunens processtöd

7 Använder oftast generella stödjande digitala inloggnings- och identifieringstjänster som t.ex. Mobilt BankID Nackdel Integrationer till verksamhetssystem blir ofta dyra och komplexa och saknas därför oftast. Enkelheten i att skapa e-tjänster medför att det ibland skapas e-tjänster som är rena kopior av tidigare pappersblanketter. Möjligheterna och funktionerna som digitaliseringen medför missas. 3:e generationens e-tjänster 3:e generationens e-tjänster fokuserar på informatiken, dvs. det informatiska innehållet. Genom att standardiserat beskriva en e-tjänsts informatiska innehåll öppnas möjligheten att förenkla integrationsbyggandet. Det mest karakteristiska för 3:e generationens e-tjänster är nog ändå att kundgränssnitt inte är beroende av kommunens ordinarie kundgränssnitt. Dvs. en digital tjänst för t.ex. en kommunal anmälan eller ansökan behöver inte vara publicerad av kommunen. Genom den standardiserade beskrivningen av tjänstens informatik, kan tjänsten publiceras och utföras hos en helt annan aktör. T.ex. kan en byggfirma publicera en e-tjänst för bygglov eller så kan en app för lagidrotter publicera en tjänst för att boka en träningslokal. Naturligtvis kan kommunen också publicera egna digitala tjänster för dessa ändamål. Kundens processtöd, som beskrivits tidigare, är eller kan vara här helt frikopplat från kommunen. För att detta ska vara möjligt krävs: Att informatiken i ärenden standardiseras dvs en bygglovshandling upprättad hos byggfirman innehåller samma information som behövs för hanteringen i kommunen Att leverantörerna av verksamhetssystem levererar standardiserade APIer för integrationer Att kommunen publicerar APIer för externa aktörer att skicka in ärenden på Inom offentlig sektor finns idag inte så många exempel på denna generation av e-tjänster, men Serverat och Bokning och bidrags-projektet inom SKL samt Boverkets projekt Får jag lov? kan användas som exempel. Inom näringslivet finns flera exempel. T.ex. kan du boka ett hotellrum direkt på ett hotells hemsida samtidigt som du kan boka samma rum via en eller flera bokningssajter. Det informatiska innehållet i en hotellrumsbokning är standardiserat och hotellen har ett öppet API för

8 att bokningssajten ska kunna skicka in bokningen till hotellet. Samma mönster och strukturer kan återfinnas när det gäller sökning och bokning av t.ex. flygbiljetter. 4:e generationens e-tjänster Med 4:e generationens e-tjänster tas det manuella kundgränssnittet helt bort. Tidigare generationer av e-tjänster bygger på en logik att användaren matar in information i en tjänst. Ganska ofta kommer denna information från ett av kundens egna verksamhetssystem. Tankemönstret med 4:e generationens e-tjänster bygger på att kunden har ett IT-system eller verksamhetssystem som innehåller information. Genom att öppna kundens IT-system för direkt integration kan t.ex. en kommun ansluta till kundens IT-system och automatiskt hämta informationen. Det kan beskrivas som ett Maskin-Till-Maskin gränssnitt. Skatteverket är en aktör inom den offentliga sektorn som kommit långt i tankarna runt denna generation av e-tjänster, exempelvis med en deklarationstjänst som integrerar direkt med kundens bokföringssystem. Med utgångspunkt från detta tankemönster blir det tydligt att definitionen och begreppet e-tjänst inte längre är helt relevant. Oavsett generation handlar det om digitala tjänster i Kundens processtöd och om informationsöverföring till Kommunens processtöd. Digitala tjänster i Kundens process Detta kapitel syftar till att resonera mer om vad en digital tjänst i Kundens processtöd är för något. En tjänst av detta slag skulle lite mer strukturerat kunna beskrivas enligt bilden nedan: En digital tjänst i Kundens process kan på detta sätt delas upp i en informatik del och en teknisk- /publiceringsdel. I informatikdelen finns de olika frågor som tjänsten ställer till användaren. Till frågorna finns beskrivningstexter och hjälptexter. Svaren som tas in på respektive fråga har specifika format och dessa format beskrivs här som t.ex. text, nummer, datum eller specialformat som t.ex. fasta listor med svarsalternativ. I informatikdelen finns även krav och regler definierade, t.ex: Värdet måste vara högre än eller Om fråga 4 besvaras med JA visas fråga 5, annars visa inte fråga 5. I publiceringsdelen finns den teknik och de system som krävs för att möjliggöra publicering av tjänsten. Det kan kanske vara webb- och/eller applikationsservar och system. Publiceringen kan ske

9 genom lokal- eller central drift eller som t.ex. molnlösning. Här finns konkretiseringen av den logik som beskrevs i informatikdelen med olika typer av skript och andra lösningar. Varje organisation som publicerar tjänster vill troligen bestämma hur den ska se ut med sin egen färg och form (grafisk design), vilket också återfinns i publiceringsdelen. Genom att dela upp e-tjänster i dessa två områden kan generiska och återanvändningsbara informatikdelar tas fram (nationellt). Samtidigt som unika och lokala publiceringsdelar skapas för att realisera informatiken. En del av vinsterna med denna uppdelning är att informatikdelarna kan utvecklas av en eller flera parter och enkelt delas i både utförande och förvaltning. Genom att använda ett standardiserat format för HUR informatiken beskrivs kan detta spridas och delas som öppna standarder oavsett vilken teknisk lösning som olika organisationer använder. Effekten av detta blir inte bara möjlighet till ökad delning mellan organisationer utan även att digitala tjänster i olika kommuner ser lika ut. Dvs. jag som medborgare, företagare eller förening svarar på samma frågor i e-tjänster oavsett i vilken kommun jag befinner mig i eller om en privat aktör tillhandahåller tjänsten åt mig.

10 Vision eller mål Vad är det vi vill uppnå med arkitekturen? Vad har vi för vision eller mål? Det finns naturligtvis flera svar på dessa frågor. Beroende på kommunens förutsättningar kan olika frågor ha olika prioritet. Men här är exempel på visioner eller mål som kommuner bör överväga: Kunna hantera kundens hela behov i digitala tjänster Kunna tillhandahålla information och öppna API:er så att privata utförare kan skapa tjänster gentemot kund Standardisera begrepp och informationsöverföring så att informationen kan återanvändas och flöda mellan organisationer Kunna samverka med andra aktörer, både offentliga och privata, för att ur kundens perspektiv ge service till invånare och företag utifrån deras livshändelse och preferenser Där det är lämpligt, stimulera privata aktörer att bygga och tillhandahålla tjänster och processtöd för det offentligas verksamhet och kundservice EN information EN gång, en medborgare ska bara behöva ange en information engång i sin kommun Automation automatiska processer och beslut där möjlighet ges Robust och flexibel systemarkitektur Låt oss fördjupa oss i några av dessa punkter: EN information EN gång En kund till en organisation ska bara behöva ange en information en enda gång. Har du som kund till en kommun eller organisation angett t.ex. din e-postadress så ska kommunen inte fråga efter den igen, oavsett vilken förvaltning eller för vilket ärendeslag som informationen först inhämtades för. Detta kallar vi att minimera uppgiftslämnarbördan. För att uppnå detta krävs att all information som en kommun tar in, behöver kunna delas med alla andra enheter (system och lösningar) i kommunen. Naturligtvis kan inte känslig eller sekretessbelagd information delas fritt. En del av digitaliseringsframgångarna i både Estland och Finland bygger på att man där på nationell nivå har satt denna regel (EN information EN gång) och delar därmed information mellan alla offentliga aktörer. Har en aktör inom offentlig sektor mottagit en information från en medborgare så får ingen annan offentlig aktör fråga medborgaren efter samma information igen (så vida informationen ska ändras). Automation Kompetenta, välutbildade och erfarna handläggare inom kommunal verksamhet kommer att bli, om det inte redan är, en bristvara. Samtidigt finns en tydlig förväntan från kommunens invånare att kommunens handläggare ska kunna ge personlig service. Därför ska standardiserade och enkla ärenden inte behöva hanteras av en mänsklig hand. Om ett inkommet ärende har kompletta informationsmängder och om dessa ligger innanför ramarna eller gränserna för ett bifall eller avslag så kan en maskin lätt ta beslutet automatiskt och hela handläggningsprocessen sker då mycket snabbt och effektivt. Resurser och kompetens i form av kommunens anställda tas också bättre tillvara och får mer stimulerande arbeten då de får mer tid att hantera ärenden som utgör gränsfall eller då kunden behöver anpassad service.

11 Robust och flexibel systemarkitektur Idag har många kommuner och organisationer problem med så kallade inlåsningseffekter. Problemet kan beskrivas ur flera olika aspekter och vinklar som här kortfattat summeras som: Information och data som lagras i ett system går inte att nå från andra system Systemlösningar för ett processtöd är ofta stora och komplexa och det blir alltför dyrt och komplext att byta ut ett system eller en komponent i organisationens systemflora. Ett mål eller en vision för en kommun bör därför vara att skapa en så robust och flexibel systemarkitektur så att dessa båda inlåsningsproblem uteblir.

12 Integrationer I detta kapitel resonerar vi om integrationer. Med begreppet integrationer avser vi här informationsöverföring mellan olika system och funktioner. Ett vanligt exempel är överföring av ett inkommet ärende via en e-tjänst till ett verksamhetssystem. När är det lämpligt att bygga integrationer? Ibland kan vi höra röster som säger Att utveckla en e-tjänst utan integration till verksamhetssystemet är som att digitalisera en pappersblankett som efter ifyllnad skickas med e-post till handläggaren. Ingen större nytta uppnådd, eller hur? Argumentet bygger på att utvecklingen kan upplevas som ett inte fullvärdigt utvecklingssteg inte värd investeringen. Men är det verkligen sant? Argumentet är troligen helt rätt när det avser ärenden som har en frekvens på kanske flera hundra ärenden per månad. Men låt oss utgår från en tjänst eller service som har en frekvens på kanske 2 3 ärenden per månad. Att publicera en digital tjänst som stödjer kundens process är enkelt om vi använder os av 2:a eller 3:e generationens e-tjänster och den ger externa nytta till kunden (kunden upplever ofta hög servicenivå genom digitala tjänster). Men att bygga automatisk integration till ett verksamhetssystem, för att uppnå intern kommunal nytta, kan bli ekonomiskt svårt att försvara då kostnaden för integrationen är hög. Ett sätt att komma runt detta dilemma är naturligtvis att hitta lösningar som gör att kostnaden för integrationer sänks. Nytta utan integration Nyttan av en digital tjänst kan delas in i extern och intern nytta 2. Extern nytta är nyttan för kunden (medborgaren, företagaren eller föreningen). Intern nytta är nyttan för den egna verksamheten, dvs i detta fall kommunen. För kunden är den digitala tjänsten densamma oavsett integration till verksamhetssystem eller inte. Om en e-tjänst har integration till ett verksamhetssystem kan kunden uppleva mer extern nytta genom att det t.ex. går att hämta upp ett tidigare ärende från verksamhetssystemet och ändra i redan befintlig information. Men även utan integration till verksamhetssystemet finns extern nytta. Den externa nyttan ökar även med integrationer till olika informationstjänster. Men i ett förenklat första skede är redan tillgången till digitala tjänster en extern nytta då användaren enklare kan fylla i och skicka in sina ärenden utan att behöva skriva ut blanketter och skicka med vanlig post. De inre verksamhetsnyttor som uppnås utan integration till ett verksamhetssystem är dock inte heller att förringa: Mer komplett inkommen information ger färre kompletteringar tack vare tvingande fält i den digitala tjänsten Mer korrekt inkommen information genom olika valideringsfunktioner i tjänsten Mer lättläst inkommen information, dvs. inga konstiga handstilar Mer stöd och hjälp till kunden i tjänstens hjälp och stöd texter ger mer korrekt information I många fall kan den här typen av kvalitetshöjning på inhämtning av information ge stora interna nyttor. Beslut om att investera i integrationer mellan system bör alltså främst utgå från användningsfrekvensen och vilken intern nytta integrationen ger. Detta ska vägas mot kostnaden för 2 ESVs vägledning Nyttorealisering 2.0/, fördjupar ämnet.

13 integrationen, inte bara utvecklingskostnaden utan även eventuella driftskostnader, t ex månadskostnader för olika systems kommunikationsadaptrar eller för API:er. Ett sätt att sänka kostnaderna för integrationer är att standardisera dem. Det krävs då att det tekniska API:erna är standardiserade och att informationsmodeller för ärenden är de samma (se tidigare resonemang om 3:e generationens e-tjänster). För att lyckas med detta behöver kommuner samverka med varandra och med leverantörer. Ett exempel där detta sker är Serverat-projektet och Boknings och bidrags projektet. Informationsarkitektur Arkitektur delas upp i olika perspektiv eller delar. Olika modeller och ramverk för arkitektur delar upp detta på lite olika sätt. I detta dokument tittar vi på två delar; information och integration, där information är den mer verksamhetsnära delen och integration är den mer tekniknära delen. Alla e-tjänster hanterar information på ett eller annat sätt. Det är information som en användare matar in i tjänsten och det kan vara olika typer av registerinformation som kanske visas för användaren eller som användaren kan söka fram. Utmaningen med att hantera informationen ligger inte bara i att hantera rätt information, det vill säga korrekt och komplett information, utan även att hantera information till rätt kostnad. Här är exempel på registerinformation som är vanliga i kommunala tjänster: Personinformation Ekonomisk information Fordonsinformation Fastighetsinformation Adressinformation All denna information har idag utpekade registermyndigheter, dvs ansvariga myndigheter som har till uppgift att säkerställa att ETT nationellt register för informationen finns och är uppdaterat. Tyvärr saknar många av dessa myndigheter idag s.k. bastjänster för att på ett enhetligt sätt tillgängliggöra sin registerinformation, och ibland saknar kommuner också kunskap om att en sådan bastjänst finns. Det finns också exempel på där det är för komplext, antingen juridiskt eller tekniskt, att som kommun ansluta till en myndighets bastjänst. Av dessa skäl är det vanligt att kommuner köper automatisk tillgång till registerinformationen via externa fristående bolag. Även om dessa bolag i vissa fall förädlar informationen och höjer dess värde, blir det för kommunen en ganska dyr affär. Det är dessutom inte ovanligt att en och samma kommun har flera abonnemangsbundna avtal för inköp av samma information. Antingen till dyra månadskostnader eller ännu dyrare så kallade klickkostnader, det vill säga att den externa leverantören tar betalt per ställd fråga. Det är inte ovanligt att kostnaden är från ett par kronor till närmare hundra kronor per fråga/klick. Kommuner generellt behöver inventera sina verksamheters behov av information och utifrån det behovet ansluta till och tillgängliggöra informationstjänster. Det vanligaste exemplet som ofta kommer upp i inventeringar är personinformation. Behoven består ofta av att utifrån ett personnummer få fram namn och adresser på fysiska personer. I många kommuner finns och används ett kommuninvånarregister. Frågan är dock om detta lokala kommuninvånarregister innehåller korrekt information. Hur hålls det uppdaterat? Vanligt är också att olika systemleverantörer, integrerat i sina verksamhetssystem, erbjuder personuppgiftsinformation som de köper från Skatteverkets externa informationstjänst SPAR.

14 En bättre lösning är istället att i kommunen tillgängliggöra ett API där kommunens olika IT-system och tjänster kan hämta folkbokföringsinformation direkt från Skatteverkets informationstjänst (bastjänst) Navet. Den totala kostnaden för hantering av informationen kan på detta sätt sänkas avsevärt. Speciellt eftersom regeringen har beslutat att personinformationstjänsten från Skatteverket ska vara avgiftsfri för statliga myndigheter och nu håller på att utreda en modell för att kunna göra den avgiftsfri även till kommuner och landsting. Enligt uppgift från Skatteverket hämtar idag samtliga kommuner personuppgifter från både SPAR och Navet, dvs. med kommun interna integrationer skulle inhämtningen kunna effektiviseras. Från ord till handling: Gör en kartläggning för att identifiera vilka de vanligaste informationstyperna är som ni använder Ta reda på varifrån informationen kommer, både interna och externa källor Ta fram kostnader för informationskällorna Gör en nyttokalkyl som visar hur mycket pengar som går att spara. Glöm inte att även ange eventuella kvalitetshöjande nyttor Inventera möjligheterna att etablera centrala informationstjänster Börja med någon eller några informationstjänster och få några verksamheter eller system att använda dem Bygg därefter ut användningen och antalet tjänster Integrationsarkitektur I kommuner genomförs utvecklingsprojekt som syftar till att etablera nya IT-system eller utveckla ett nytt arbetssätt, med stöd av en ny modul eller ersätta ett befintligt system med en ny lösning. Dessa utvecklingsprojekt strävar alltid efter att nå uppsatta mål i rätt tid till lägsta möjliga kostnad. Det är i projektformens natur att vara så billiga och snabba som möjligt. Organisationer som saknar en tydlig och förankrad strategisk arkitektur riskerar dock att få integrationer som medför höga framtida kostnader både för inköp och förvaltning av hård och mjukvara. Varje projekt stävar ofta efter att bygga snabba, billiga och ibland t.o.m. kortsiktiga lösningar med den arkitektur som löser uppgiften för just detta projekt och denna del av verksamheten. Visst är det lockande att köpa den färdiga integrationsadaptern från leverantören och bygga en punkt till punkt integration mellan en e-tjänst och ett verksamhetssystem. Försäljarens säger att Vi har en färdig integrationslöning till det systemet som ni får billigt. Eller låta den mycket kunniga systemutvecklaren bygga det snabba SQL-query scriptet som snabbt och effektivt hämtar eller lämnar rätt information i en databas. Men vad händer den dagen ett system uppgraderas till en ny version och databasen byggs om? Eller om ett system byts ut mot ett annat? Eller en säkerhetspatch på en server installeras? Och varför är alltid den kunniga systemutvecklaren föräldraledig, på semester eller upptagen med andra projekt när e-tjänster plötsligt slutar fungera? Med en utarbetad strategi för integrationsarkitekturen kan dessa fallgropar undvikas eller minimeras. Från ord till handling: Börja med att ta fram en målbild för hela arkitekturen och inte bara integrationsarkitekturen. Nästa steg är att ta fram en strategi för hur målet ska nås. Vilka regler och förhållningssätt behövs för att

15 påbörja resan mot målbilden? Finns det några styrande principer som går att fastställa? Hur går vi från dagens lösning eller nivå till målet nivån? Steg för steg eller big-bang? I vilken omfattning orkar organisationen bygga förändringen? Hur det än är med nya mål och strategier så går den vanliga vardagen vidare och nya mål kan upplevas som extra pålagor. Även om detta rör tekniska frågor så är det människor som ska få det att hända. Hur ska förändringen av tankesätt genomföras? Behövs kompetensutveckling? Nya roller eller nya ansvar? Behövs förändring i hur utvecklingsprojekt styrs och genomförs? Här är några konkreta tips på strategiska vägval: Installera och använd en integrationsmotor. Sätt upp riktlinjer eller styrande principer för att punkt till punkt integrationer i möjligaste mån skall undvikas. Flytta integrationslogiken från respektive system till den centrala integrationsmotorn. Besluta om egen eller extern kompetens ska användas för att utveckla och underhålla logiken i integrationsmotorn. Sträva efter att lagra en informationsmängd på EN plats och bygg funktioner och tjänster för andra system och tjänster att prenumerera på informationen. Skapa ett gemensamt tänk och förhållningssätt till arkitekturen. Säkerställ gemensamma sätt att dokumentera lösningar. Lägg till punkter i kvalitetssäkringen för hantering av information och integrationer i den gemensamma projektmodellen. Ta beslut på och skapa styrande principer för om 1:a generationens e-tjänster ska få finnas i kommunen (denna generations e-tjänster har punkt-till-punkt integration). Figuren ovan beskriver en generell integrations arkitektur för en kommun. Färgkombinationerna motsvara de olika oråden som beskrivs i kapitlet Arkitekturområden Kundens processtöd, Kommunens processtöd samt Gemensamma tjänster.

16 Figuren ovan beskriver integrationer och arkitektur för projektet Bokning och bidrag. Färgkombinationerna motsvara de olika oråden som beskrivs i kapitlet Arkitekturområden Kundens processtöd, Kommunens processtöd samt Gemensamma tjänster.

17 Förslag på styrande principer I detta kapitel samlar vi förslag på styrande principer för övergripande arkitektur. För varje förslag på princip finns en förklarande och argumenterande beskrivning Undvik punkt-till-punkt integrationer Att bygga integrationer direkt via två stycken IT-system blir för det enskilda projektet troligen den billigaste och snabbaste lösningen. Men ur ett mer övergripande och större perspektiv är det en genväg som blir en senväg. Orsaken till detta är bl.a.: Informationen som flödar genom integrationen förblir (oftast) inlåst mellan de båda systemen. Om integrationen går via en integrationsmotor kan logik läggas på hanteringen av informationen och informationen kan göras tillgänglig för flera system, tjänster och processer. Detta är en del av det som i andra sammanhang beskrivs som inlåsning av information. Enklare byte av system eller uppdateringar av system. Det är inte ovanligt att ett större centralt IT-system i en kommunal verksamhet kan ha flera olika integrationer. Den dagen det är dags att genomföra förnyad konkurrensutsättning av IT-systemet eller av annan orsak dags att ersätta systemet är det inte ovanligt att det krävs ganska omfattande analyser av vilka integrationer som finns, hur dom fungerar och mellan vilka system de hanterar information. Genom att använda en integrationsmotor skapas betydligt färre integrationer och alla dessa går mot en och samma punkt. Det kan argumenteras för att det är onödigt att ha en integration mellan två system via en integrationsmotor, där integrationsmotorns enda uppgift är att flytta informationen från A till B utan på något sätt påverkan eller ändra i den. Det argumentet är på sitt sätt berättigat ut ett informatiks perspektiv. Men argumentet håller inte i synen på långsiktigt ägande och förvaltande av hela IT-plattformen och dess arkitektur. Informationstjänster via integrationsmotor Anslut alla externa och gör interna informationstjänster tillgängliga via en integrationsmotor. Det är vanligt att utvecklingsprojekt som ansluter en kommun till en extern informationstjänst gör det genom att skapa en direkt anslutning till det specifika IT-system som projektet ska hantera. Den typen av anslutning löser förvisso det specifika utvecklingsprojektets behov av informationsförsörjning men det är inte en långsiktig lösning. Låt säga att en kommun har ett utvecklingsprojekt som syftar till att byta ut ett verksamhetssystem mot ett annat. I arbetet ingår att ansluta det nya verksamhetssystemet till Skatteverkets informationstjänst Navet. Istället för att ansluta Navet direkt till verksamhetssystemet bör istället anslutningen ske till den interna integrationsmotorn. I integrationsmotorn kan då en intern informationstjänst publiceras personinformation. Nu kan flera, av varandra oberoende, verksamhetssystem ansluta sig till den interna personinformationstjänsten. Kommunen behöver bara hantera ETT abonnemang hos Skatteverket. Om Navet-tjänsten förändras eller någon annan förutsättning förändras, så kan logiken i integrationsmotorn hantera detta på ETT ställe och inte i ett flertal olika verksamhetssystem. Effekten av detta blir att det aktuella utvecklingsprojektet kan bli något mer komplext och dyrare, sett ur det korta perspektivet. I det långa perspektivet finns det bara effektivisering och besparing. På detta sätt görs externa och interna informationstjänster tillgängliga inom kommunen.

18 Publicera publika APIer för alla ärendetyper Alla ärendetyper som hanteras med e-tjänster och integrationer till verksamhetssystem ska finnas tillgängliga via publika APIer. För att externa aktörer, webbsidor och appar, ska kunna interagera direkt mot kommunen måste det finnas APIer för detta. Samma tekniska integrationsanslutning som kommunens e-tjänst ansluter mot ska finnas publicerad externt för externa aktörer att ansluta till. Målet är att kommunen inte ska behöva äga alla grafiska ytor där kundmöten kan ske. Istället ska invånaren, företagaren eller föreningen kunna utföra sina tjänster enkelt och digitalt mot kommunen oavsett i vilket grafiskt gränssnitt det sker. Använd standardiserade informationsmodeller och integrationer Att driftsätta och förvalta integrationer kan vara kostsamt. Ett sätt att få ner dessa kostnader är att använda standardiserade informationsmodeller och integrationer. På detta sätt kommer kommunen bort ifrån beroenden av specifika leverantörer och lösningar. Kommunen kan istället i upphandlingar kravställa att standarder ska finnas och användas. Det blir inte bara en besparing, kommunen blir också mindre låst till unika lösningar och leverantörer vilket ger långsiktiga vinster vid framtida

19 uppgraderingar eller nya upphandlingar. Genom att använda standardiserade informationsmodeller uppnås flera vinster: Externa aktörer som erbjuder samma grafiska gränssnitt till tjänster kan enkelt ansluta till kommunens publika API Förvaltning av e-tjänster förenklas då återanvändning från andra kommuner kan ske. E- tjänsten utgår från samma informationsmodell oavsett kommun Samma krav på informationsinsamling ställs på medborgaren, företagaren eller föreningen oavsett kommun EN information EN gång Denna styrande princip motsvara den målsättning eller vision som nämnts tidigare i texten och utgår från att: En kund till en organisation ska bara behöva ange en information en enda gång. Har informationen samlats in från medborgaren, företagaren eller föreningen vi ett tidigare tillfälle så skall informationen inte behöva anges igen, oavsett vilken förvaltning eller enhet som tog emot informationen. För att uppnå detta krävs att all information som en kommun tar in ska kunna delas med alla andra organisatoriska eller verksamhetsmässiga enheter. Naturligtvis kan inte känslig eller sekretessbelagd information delas fritt.