sou · H1B380 · 2013-12-05 00:00:00 — Den tänkta fasindelningen av införandet finns utförligt beskriven i dokumentet En infrastruktur för företagens uppgiftslämnande (utkast till kapitel 3 i delbetänkandet). Integrationen mot registerförande myndigheter Fortsatt förvaltning och utveckling. Logisk Översiktsvy - Fas 1 Figur 3 Logisk översiktsvy för fas 1 De delar som hanteras i fas 1 är: Komponenter - Fas 1 Figur 4 Komponentvy för fas 1 Komponentvyn beskriver mer renodlat vilka komponenter som är tänkta att tas fram och implementeras under denna fas. Logisk Översiktsvy - Fas 2 Figur 5 Logisk översiktsvy fas 2 Integrationen mot registerförande myndigheter Komponenter – Fas 2 Figur 6 Komponentvy fas 2 Figuren illustrerar komponentvyn efter genomförandet av fas 2. Logisk översiktsvy – Fas 3 Figur 7 Logisk översiktsvy fas 3 Komponenter - Fas 3 Figur 8 Komponentvy fas 3 Figuren illustrerar komponentvyn efter genomförandet av fas 3. Sammanställningen nedan visar de antaganden som gjorts beträffande kvalitet inom ett antal områden hos informationssystemet. Skall följa WCAG och 24-timmarswebbens riktlinjer Uppdatering kräver inloggning. I övrigt enligt RK:s Sammanställningen nedan visar de antaganden som gjorts beträffande prestandabehov inom ett antal områden hos informationssystemet. Inloggningar (e-legitimation): 1 per företag och vecka Samordnade uppgifter: 5 Normal svarstid inom 1 sekund Lagring och gallring ska kunna hanteras enligt svensk Ur antagandet om antal inloggningar härleds ett behov av Ovanstående figur visar de informationsområden som informationssystemet har att hantera. Även om antalet inlämningstillfällen och aviseringar kan komma att uppgå till ett antal hundra miljoner bedöms datavolymerna genomgående inte bli väldigt stora. Det som bedöms ställa krav på datalagringskapaciteten är antalet utsökningar och uppdateringar som potentiellt kan komma att ställa höga krav på systemresurser. Det finns av denna orsak anledning att se över möjligheten att hantera en så stor andel som möjligt av transaktionerna via ett batchgränssnitt, så länge som det kan ske utan att man behöver göra avkall på systemets önskade funktionalitet. Samordningsorganet (SO) Processer av initial karaktär: Inventering av uppgiftskrav och Inventering av uppgiftsdefinitioner. Bägge utifrån bolagsverkets kartläggning Kan initiera uppgiftsdefinitionsprocessen Underhåll av uppgiftsdefinitioner Kontrakt på olika nivåer Dataimport (ETL) Laddning och transformering av data Definiera och leverera nyckeltal Registrera/Uppdatera företagsuppgifter Kontrollera företagsuppgifter Översikt över uppgiftskrav Fullgörande av uppgiftskrav Avisera uppgiftskrav Avisera fullgjort uppgiftskrav Gränssnitt för åtkomst till informationen Främst program för företagsadministration Gränssnitt för leverans av företagsuppgifter Nedanstående sammanställningar beskriver antagandet att drift av IT-infrastrukturen sker helt i egen regi i egna lokaler. Ett mer troligt scenario är att den fysiska infrastrukturen inhyses i någon existerande serverhall hos någon svensk myndighet med vilken man då kan dela kostnaderna för driften. Ett annat och allt vanligare alternativ är att köpa upp kapaciteten hos en extern leverantör som en tjänst i form av ett SLA där bl.a tillgänglighet och prestanda definierats. Bägge dessa alternativ har potential att kunna sänka kostnaden för driften av infrastrukturen med mellan . Kostnadsberäkningarna har delats upp i ett antal delområden Applikationsutvecklingskostnader, drift och underhåll För informationssystemet, Webbserver, applikationsserver, databas, middleware mm För övrig infrastruktur, nätverk mm Ledning, drift, underhåll, användarstöd 1 IT-chef, 1 systemansvarig Integration (SHS) Summa Integration och e-legitimation Personal (5 IT-drift) Kostnadsberäkningarna för systemutvecklingen är enligt uppdrag gjorda på en övergripande nivå. För att kunna göra mer noggranna kostnadsberäkningar behövs detaljerade projekt- och genomförandeplaner vilka förutsätter ingående kunskaper om utvald teknisk plattform, teknisk lösning, integrationsmetoder, utvecklingsmetod, säkerhetslösning och mycket annat som endast delvis är känt. Grundat på tillgänglig information har de olika delprojekt som identifierats delats upp i tre olika typer utifrån antagen ungefärlig tidsåtgång Typ A – ett mindre projekt motsvarande 2 personer Typ B – ett lite större motsvarande 2 personer Typ C – ett större projekt motsvarande 4 personer Indelningen är främst baserad på en analys av förväntad komplexitet utifrån mängden krav, behov av integration och tidsåtgång för test. Utvecklingen av de olika ingående komponenterna behöver täcka ett antal kostnadsposter som: Utveckling (inklusive integration och viss hjälpfunktionalitet) Test (internt samt av slutanvändare) Vissa kostnader, som utvecklingstid, är specifika för den enskilda komponenten, medan andra behöver fördelas ut. Då samverkansorganet kommer att utgöra en central del inom myndigheternas informationsförsörjning kan integration, test och produktionssättning förväntas ta mycket tid och resurser i anspråk, inte minst pga behovet av samverkan med de olika myndigheterna och det behov av kalendertid som detta driver. De komponenter som innefattats i kostnadsberäkningarna är: Om en auktoriseringstjänst behöver utvecklas från grunden så innebär detta ett större projekt av minst typ C, eftersom komplexiteten i kraven och behovet av tester kommer att bli betydande. Om en existerande auktoriseringslösning från någon myndighet kan återanvändas, kan detta komma att avsevärt sänka utvecklingskostnaden. De flesta e-tjänster har bedömts vara av typ B, vilket i genomsnitt bedöms ge en rimlig kostnadsuppskattning Hämta grunduppgifter – onlinegränssnittet där myndigheterna hämtar samordnade uppgifter för företagen bedöms vara mer krävande då samverkan med de olika myndigheterna kan komma att kräva uppsättning av olika gränssnitt, omfattande testning, och tidskrävande samordning. Av dessa orsaker är tidsåtgången svårbedömd, men har uppskattats vara av typ C. Beroende på vilka lösningar som väljs kan tidsåtgången komma att variera kraftigt, varför en erfaren och tydlig projektledning kommer att vara av största vikt, liksom tillsättandet av projektsponsorer. Statistik och Batch för PSI handlar om att förbereda miljöer för dessa funktioner, och bedöms inte vara så resurskrävande utan av typ A. Extrahering av filer (Batchmotor), M2M uppdatering av kund via fil samt databasdesign har bedömts vara av typ B. Laddning av grunduppgifter handlar om att sammanställa företagsuppgifter från åtminstone tre olika myndigheter och bedöms vara en så central och grannlaga uppgift att den är av typ C. Den fysiska IT-infrastrukturen för systemlösningen är i enlighet med kraven uppdelad i tre separata miljöer för drift, test och utveckling Driftmiljön kommer att behöva kunna hantera ett stort antal inloggade användare och ett stort antal transaktioner och behöver därför konfigureras med klustrade servrar med höga prestanda. Den föreslagna lösningen kan också dynamiskt konfigureras så att testmiljön helt eller delvis kan bidra till att hantera belastningstoppar. Då tester av funktionalitet och prestanda kommer att vara centralt under utvecklingen är den föreslagna testmiljön uppsatt som en identisk kopia av driftmiljön. Miljön för utveckling behöver ha en tekniskt likartad konfigurering, men inte vara uppsatt för att kunna hantera tillnärmelsevis lika stora datavolymer. Kostnadsberäkningarna är gjorda utifrån kommersiella high-end- produkter (WebSphere och Oracle). Alternativet att använda open-source-produkter skulle potentiellt kunna förändra kostnadsbilden något och kan därför med fördel utvärderas inför ett slutligt teknikval. Figur 10 Fysisk infrastruktur 2 x Server Webb, Server Applikation, Server Databas, Backupprogram, Klustring, Databas, , Applikationsserver, , Övervakning mm 2 x Server Webb, Server Applikation, Server Databas, Backupprogram , Klustring, Databas, , Applikationsserver, , Övervakning mm Server Webb, Server Applikation, Server Databas, Backupprogram, Databas, , Applikationsserver, , Övervakning mm En systemlösning behöver även en omgivande IT-infrastruktur för att kunna fungera. Denna infrastruktur innefattar ett antal komponenter som kyld serverhall med skalskydd, nätverk, brandskydd, avbrottsfri kraftförsörjning och viss specialutrustning Omgivande system som nätverk, backupsystem, fillagring med mera och servrar för dessa. För en organisation som SO vore med stor säkerhet den lämpligaste lösningen att dela åtminstone serverhall och delar av den omgivande infrastrukturen med någon organisation som redan har en befintlig miljö för detta. En annan lösning vore En grov kalkyl för en datorhall ger en: Investering i datorhall (förutom hårdvara) ca 2 MKR Årlig drift ca 500 tkr En grov kalkyl för de omgivande systemen ger en: Investering i hårdvara 10 servrar á = ca 500 tkr Investering i mjukvara ca 1 MKR Säkerhetslösning – Autentisering (e-legitimation) Autentisering innebär att en identitet som en användare uppgivit kontrolleras och verifieras Autentisering av användare görs lämpligen med hjälp av e-legitimation. Även om detta är en etablerad och vedertagen metod så är den under utredning och utveckling. Detta innebär bl.a att ramavtal för upphandling saknas, vilket i sin tur försvårar en kostnadsberäkning. En stor del av kostnaderna kan potentiellt komma att bestå av den transaktionskostnad som en leverantör tar ut för verifiering av e-legitimationer vid inloggning. Denna kostnad är svårberäknad, dels pga avsaknaden av ramavtal, dels pga att relevanta jämförelsetal är svåra att hitta. I exemplet nedan antas att den sätts till /transaktion Övriga antaganden som gjorts är att: Grundkostnaden för tjänsten blir jämförbar med tidigare ramavtal 2 MKR Ett företag loggar in i systemet en gång Transaktionskostnad : 52 000 000 inloggningar * = 7 800 000 Det finns anledning att anta att förhandlingsläget vid en upphandling av e-legitimationer leder till att kostnaderna för hanteringen av e-legitimationer kan hållas på en rimlig nivå, men några garantier finns givetvis inte. Användandet av e-legitimation innebär att SO:s tjänster tekniskt kan integrera sin inloggning med myndigheternas, vilket i många fall också kommer att vara önskvärt. Detta leder till att en stor del av myndigheternas kostnader för verifieringen av e-legitimationer potentiellt kommer att vältras över på SO, något som kan komma att innebära totalt lägre kostnader för samhället, men som man behöver vara medveten om då kostnaden för SO kan förefalla hög. Säkerhetslösning – Auktorisering (Behörigheter) Auktorisering innebär att en användare bereds tillgång till den information som vederbörande är behörig att hantera Utredning och implementation av säkerhetslösning för systemet kan förväntas bli relativt tidskrävande, då det finns anledning att anta att auktoriseringsdelen är komplex och innehåller ett antal ännu okända problem vilka exempelvis kan följa av att: En person kan ha behörighet att hantera och därmed välja bland ett antal företag Ett företag kan hanteras av ett antal olika personer, vilka sinsemellan har rätt att hantera olika funktioner Vidarekopplingen till myndigheternas e-tjänster behöver hanteras med flera frågeställningar som lär framkomma under det fortsatta arbetet Utveckling och utredning av en säkerhetslösning har uppskattats till 4 personers arbete (Typ C), vilket exempelvis innefattar. Utredning av olika alternativ Design och utveckling av behörighetslösning Utveckling av underhållsrutiner och gränssnitt för behörighetshantering Spridnings och hämtningssystemet (SHS) är ett koncept för säkert och pålitligt utbyte av information mellan offentliga organisationer. I vilken omfattning SHS kommer att användas av SO framöver är osäkert för denna utredning. Andra tekniker för kommunikation och meddelandehantering finns och fortsätter att utvecklas. Oavsett vilken teknik för meddelandehantering som kommer att användas så kommer samarbetsorganisationen kunna behöva använda SHS under framöver. Kostnadsberäkningarna för SHS blir osäkra, beroende på att antalet transaktioner som verkligen kommer att hanteras via systemet är relativt okänt. I exemplet nedan antas att en relativt stor andel meddelanden genomförs via SHS. Transaktionskostnaden per meddelande behöver förhandlas fram med leverantören. I exemplet nedan antas att den sätts till /transaktion Kostnaden beräknas (avrundat) till / år Transaktionskostnad : 40 000 000 meddelanden * = Några utredningsbehov som framkommit under förstudien: E-legitimationer, teknisk lösning och kostnader Prismodell för e-legitimation – lösningen kan bli mycket kostnadsdrivande Vilka gränssnitt ska stödjas? Hänsyn behöver här tas till att kalendertiden kan bli mycket omfattande Bl.a säkerhetsklassificering av informationen Behovet av datakvalitetsansvarig då informationsförsörjningen kommer att vara en central verksamhet för SO. Informationsförsörjningen av PSI-intressenternas behov Hur ska den tekniskt hanteras? With more than 120,000 people in 40 countries, is one of the world's foremost providers of consulting, technology and outsourcing services. reported 2011 global revenues of billion. Together with its clients, creates and delivers business and technology solutions that fit their needs and drive the results they want. A deeply multicultural organization, has developed its own way of working, the Collaborative Business Experience, and draws on Rightshore®, its worldwide delivery model. The information contained in this presentation is proprietary. Rightshore® is a trademark belonging to . All rights reserved. Bil5Slutrapport_prototyp_uppgiftslämnar Box 576, SE-581 07 , phone +46 (0)13 37 37 00, fax +46 (0)13 37 37 90, Varför använda sig av en plattform?.............................................................................. Beskrivning av övergripande strukturer......................................................................... Beskrivning av lösning ................................................................................................................ Frågeställningar som har diskuterats under arbetet ..................................................... Lagring av uppgifter centralt eller lokalt ................................................................................... Hur ska uppgifter följa med användaren................................................................................ Hantering av inloggning ............................................................................................................ Hur hanteras ett register för företagsföreträdare........................................................................ Projektplan och utfall ................................................................................................................ Vad behöver kompletteras ........................................................................................... Systemanvändningsfall som ingår i prototypen......................................................................... Systemanvändningsfall utanför prototypen ............................................................................... Prestandakrav och driftkrav....................................................................................................... Kostnadsberäkningar – Systemutveckling................................................................... Kostnadsberäkningar – Infrastruktur ........................................................................... Säkerhetslösning – Autentisering (e-legitimation) ...................................................... Säkerhetslösning – Auktorisering (Behörigheter) ....................................................... Spridnings och hämtningssystemet – SHS .................................................................. Utredningar inför genomförande ................................................................................. Sammaställning av kostnadsberäkningar..................................................................... har fått uppdraget från att utveckla och sköta driften av en prototyp som ska simulera uppgiftsinlämning till myndigheter på ett realistiskt sätt. Denna slutrapport innehåller en beskrivning av den prototyp som har utvecklats i uppdraget. I uppdraget ingår även att utifrån de erfarenheter som vunnits i arbetet med att ta fram prototypen, översiktligt revidera den kostnadsanalys som redovisats i bilagan IT- systemstruktur och IT-relaterade kostnader för gemensamt uppgiftslämnande till delredovisning (Dnr. 2013/4). Slutrapport innehåller därför en revidering på det arbete som har gjorts i ett tidigare skede av utredningen. Revideringen har haft sitt fokus på de delar som handlar om applikationsutveckling med tillhörande mjukvara. Bilaga 1, Systemanvändningsfall fullskaligt system kontra prototyp Det PM som lämnades av den 4 2013/4) Public Sector Information (information från den offentliga Spridnings- och Hämtningssystem (SHS) är ett koncept för säkert och pålitligt utbyte av information Security Assertion Markup Language, en XML-baserad öppen standard för att utbyta autentisering och auktoriserings Den prototyp som har tagit fram i uppdraget innehåller en delmängd av de funktioner som behövs för att bygga upp ett komplett uppgiftslämnarsystem som e-tjänst. Fokus har varit på att ta fram de vitala grundläggande funktioner som behövs i ett system av denna typ. Prototypens syfte är att vara ett verktyg för utvärdering av en uppgiftslämnartjänst. Uppdraget och kravställningen till prototypen har gjorts av i den upphandling som föregicks projektet. 2.1Varför använda sig av en plattform? Prototypen är utvecklad på iipax-plattfromen. Genom att använda sig av en plattform kunde man på ett snabbt och säkert sätt bygga upp den funktionalitet som behövdes för att realisera prototypen, inom de snäva tidsramarna och med god kvalitet. Fördelar med denna ansats var: En Enterprise-arkitektur som säkerställer framtida vidareutveckling från prototyp till produktionssystem utan dyrbar omstart Baserat på öppen standardteknik Edition, JEE Baserat på den inom offentlig sektor väl etablerade och beprövade iipax-plattformen iipax-plattformen är ett ramverk med en mängd färdig funktionalitet för utveckling av just denna typ av tillämpningar –Fast prototyping av e-tjänster med formulär, online-uppslagningar, e- legitimationsstöd för både identifiering och underskrift –Konfigurerbara hierarkiska register med färdiga arbetsytor för registervård –Inbyggt stöd för SHS-kommunikation med andra myndigheter men också många andra protokoll, både synkrona och asynkrona –Händelsestyrd arkitektur. Förändringar i flöden eller objekt kan trigga automatiska aktiviteter, t.ex. aviseringar av olika slag –Tidstyrda varningar och larm för t.ex. påminnelser Stödjer out of the box alla relevanta lagar och regler som myndigheter lyder under, sekretess, diarieföring, spårbarhet etc. För att kunna implementera prototypen inom de snäva tidsramar som förfrågan anger och för framtida driftsmiljö krävs en bra plattform. iipax är en produkt med funktionalitet speciellt utvecklat för svensk offentlig sektor. Prototypen implementerar de användningsfall som beskrivs i uppdraget och som också finns sammaställt i Bilaga 1. Dessa är uppdelade i SKA-krav och BÖR-krav. I den föreslagna lösningen tar vi höjd för att lösa alla efterfrågade användningsfall, dvs både SKA- och BÖR- krav. Bilden nedan visar en översikt av de olika användningsfallen och hur de förhåller sig till varandra och hur de har realiserats i lösningen. Enskild företagare hos företag AF 10, Ladda ,,,,Ny uppg Ny uppg ,,,, Nytt/uppdatera uppgiftskrav Figur 1 Översikt användningsfall och deras relationer Genom att prototypen har utvecklats med iipax som plattform finns en stor del av den efterfrågade funktionaliteten redan på plats och den specifika lösningen kunde huvudsakligen realiseras genom konfiguration och endas ett mindre utvecklingsarbete krävdes. Figur 2 Övergripande arkitekturbild Prototypen har tre olika delar 1 Portalen - iipax receiver Portalen och dess webbsidor, som till största delen är dynamiskt genererade, utvecklas med iipax receiver. Integrerad i iipax receiver finns verktyget Digiforms. Digiforms är ett ritverktyg för huvudsakligen dynamiska webbsidor som in- och utmatningsformulär av olika slag. Data i sidorna kopplas till en xml-struktur. Alla definitioner av formulär och webbsidor lagras i xml i ett formulärförråd. Digiforms innehåller även en serverdel som sköter formatering av xml-definitioner till html eller pdf och som tar emot inmatad data. Genom att grundformaten alltid är neutral xml så kan sedan andra format genereras vid behov där html och pdf stödjs som standard. Inmatad data levereras i xml. 2 Bus – iipax communication Portalen kommunicerar med registerlagret via en ESB som implementeras i produkten iipax communication. Denna används också för aviseringarna till och från andra myndigheter. iipax communication är förberett för att kommunicera via ett antal kommunikationsprotokoll, i prototypen har SHS-protokollet använts för både intern och extern kommunikation. 3 Register - iipax communication En central del i iipax plattformen är register och registerhantering. I prototypen har registerfunktioner använts för att konfigurera uppgiftsdefinitioner, uppgiftskrav och företagsuppgifter. Ett rollregister för koppling mellan person och personens roll har också konfigurerats. Exempelvis person x -> ombud för företag y och z, person a -> handläggare på myndighet b. I prototypen har även ett register använts för uppgiftsregistret. I en fullskalig miljö kan detta register komma att läggas i en egen dedikerad databas p.g.a. den storlek som detta register kan anta. Detta för att höja prestanda och korta ned svarstider i den fullskaliga miljön. 2.3Beskrivning av övergripande strukturer Uppgiftsdefinitioner, uppgiftskrav och samordnade uppgifter Hjärtat i lösningen är objektmodellen för uppgiftsdefinitioner och uppgiftskrav. Dessa har konfigurerats enligt nedanstående struktur. Figur 3 Sammanställning av register Ett register kopplar en användare med de företag eller de myndigheter som personerna företräder, samt vilken deras roll är i respektive organisation. De roller som en uppslagning från rollregistret returnerar är styrande för vilken behörighet användaren kommer att få i systemet, i slutändan vilka e-tjänster man får åtkomst till. Till prototypen har man ett begränsat antal personer och ett begränsa antal företag har lagts in. Figur 4 Rollregister via administrationsverktyg I idealfallet kan roller fås från den nya e-legitimationens attributtjänst. I så fall ersätts det här registret med en uppslagning i attributtjänsten. Detta användes dock inte i prototypen. Register för uppgiftsdefinitioner, uppgiftskrav och företag Ytterligare separata register har införts för att bygga upp systemet enligt objektmodellen. Uppgiftsdefinitioner, Uppgiftskrav och Företag läggs in som separata register där objekten läggs in med olika attribut konfigurerade. Figur 5 via administrationsverktyget I inlämningsregistret finns alla aviseringar på krav som ska uppfyllas. I prototypen har även inlämningsregistret lagts upp som ett separat register. Med tanke på den stora volymen, kommer uppgiftsregistret förmodligen inte modelleras objektorienterat i ett fullskaligt system. Dels för att det förmodligen inte finns behov av att titta i registret eftersom det innehåller endast ett fåtal uppgifter per post (objekt). Dessutom blir prestandakraven på detta register omfattande eftersom den innehåller stora mängder data. Utformning av navigering och grundläggande sidlayout, görs för hela lösningen i ett ramverk. implementeras som komponeter och mallar som sedan har används för hela prototypen, så att den får en enhetlig arkitektur och att den av användarna upplevs som konsekvent och logisk. tar även hand om inloggning och identifiering av användare.