Öppen Teknisk Plattform V2.0

Transkript

1 Utfärdad Sven-Håkan Olsson Godkänd av Janne Dicander Dokumenttyp Öppen teknisk plattform Status Fastställd Identitet ÖTP V2.0 Version Dokversion 1.0 Sid 1 (102) Versionsdatum Öppen Teknisk Plattform V2.0 (ÖTP V2.0) Sambrplform_OTP_v20.doc Projektledare ÖTP Janne Dicander janne.dicander@jonkoping.se Telefon: Mobil & SMS:

2 Sambrplform_OTP_v20.doc 2(102) Öppen Teknisk Plattform V2.0 Projektnamn ÖTP Ytterst projektbeställare (YPB) Janne Dicander Aktuell beslutspunkt Delegerad projektbeställare (DPB) Janne Dicander Författare/Projektledare Sven-Håkan Olsson Fastställd, datum Historik och beslutade ändringar: Datum Ändring Ändrad av Utgåva av dokument som beskriver förra huvudversionen ÖTP v1.2 Sven-Håkan Olsson Dokumentversion Sven-Håkan Olsson Påbörjande av version 2.0 av ÖTP för att inkludera mer strukturerade upphandlingskrav, uppdaterade och utvidgade arkitekturkapitel mm Dokumentversion 0.8, utgåva för Sven-Håkan Olsson synpunktsinhämtning Dokumentversion 1.0, utgåva av ÖTP v2.0. Sven-Håkan Olsson Bilagor: Nr Beteckning Identitet 1 Vägledning ÖTP Sambrplform_vagledn_OTP_v20.doc

3 Sambrplform_OTP_v20.doc 3(102) Innehåll: 1. Inledning, förutsättningar ÖTP-dokumentets roller Mål och visioner med ÖTP ÖTP över tiden Anskaffningsdokument Dokumentstruktur Exempel på refererande text i ett icke-funktionellt kravdokument Roadmap - krav på sikt Grey-box varför specificera vissa detaljer? Funktionell bakgrund Applikationsarkitektur Översiktsarkitektur applikationsintegration generellt Översiktsarkitektur SOA Olika behov av anpassningslogik mot verksamhetsapplikation Direkta anropsgränssnitt Mönstret "läs online, skriv till fil" Screen-scraping Olika behov av anpassningslogik mot centrala register, eid mm Client/server Webblösningar hanterade av kommunen Webblösningar som tjänst Applikationsintegration EAI, ESB SOA understött av EAI/ESB Processtöd Generellt om process-aspekten Processtöd med hjälp av EAI/ESB Styrlogik inom EAI/ESB Processtöd med hjälp av några enklare workflow-funktioner Övrigt inom EAI/ESB Dataintegritetet/säkerhet inom EAI/ESB Statistik/BAM mm inom EAI/ESB Synkront/asynkront inom EAI/ESB Prestanda/tillgänglighet inom EAI/ESB Förpackade integrationer inom EAI/ESB Stöd mm inom EAI/ESB Mönster för batchuppdatering Webb-integration Webbpublicering Användbarhet Generellt Korrekt webbkodning Tillgänglighet/anpassning för funktionshindrade Tillgänglighet/upptid Prestanda Sammanhållen inloggning/användarkatalog Katalog Metakatalog Befolkningsregister Notifiering E-blankett vs interaktiv webbapplikation Vad som anskaffas/upphandlas/anordnas Var datalagring sker Stora, asynkrona dataflöden Återanvändning vid ytterligare e-tjänst Rörläggning Web Services Management...79

4 Sambrplform_OTP_v20.doc 4(102) 4. Principer för Nyttomeddelanden Nyttomeddelanden via SHS Regler, konventioner, drift Informationsöverföring Driftsegenskaper och infrastruktur Klientdatorer Operativsystem Exekveringsmiljöer Andra beroenden i klienten Citrix Servrar Operativsystem Relationsdatabas Applikationsserver Övervakning Nätverk Säkerhet Säkerhetskopiering Generellt Denial-of-service Intrång Driftprocess Kommunikationsprofiler Kommunikationsprofil SBR_KPOL Kommunikationsprofil SBR_KPBA Införandeprojekt Införandemetodik Acceptanstest Användarutbildning IT-driftpersonalutbildning, dokumentation...102

5 Sambrplform_OTP_v20.doc 5(102) 1. INLEDNING, FÖRUTSÄTTNINGAR Den tänkte läsaren till ÖTP 1 -dokumentet förutsätts vara väl insatt i IT-området och kommer ofta att vara någon person inom Sambruk, kommunernas IT-avdelningar, upphandlingsenheter, samt IT-leverantörer m fl intresserade. Ett stort antal begrepp som används inom IT-världen förekommer i detta dokument. Istället för att inkludera omfattande begreppsförklaringar i dokumentet så hänvisas till lätt tillgängliga beskrivningar på Internet, t ex på och via sökmotorer. Endast t ex då en formulering i dokumentet för sin entydighet behöver en extra noggrann begreppsdefinition inkluderas en sådan, antingen direkt i löpande text eller som fotnot ÖTP-dokumentets roller Föreliggande dokument har flera samtidiga roller: Att tillföra en delomgång leverabler till kommuninitiativet Sambruk inom projektet för ÖTP. Föreliggande dokument utgör alltså därmed en version av ÖTP (eller mer egentligt, en version av specifikationen för ÖTP). Att ge roadmap -information till kommunleverantörer så att dessa har möjlighet att med god framförhållning skapa lösningar som kommer att passa gentemot framtida kommunkrav. Att utgöra konkret kravbilaga vid anskaffanden (upphandlingar, avrop mfl former) inom Sambruk. Denna version av ÖTP bygger vidare på förra versionen (v1.2). Resonemangen kring applikationsarkitektur i v1.2 har stått sig väl och är i takt med IT-världen. Vad som framförallt tillförts är en annan struktur med ett antal mer konkreta kravformuleringar för att användas i anskaffanden. Dessutom utvidgas och moderniseras de prioriterade arkitekturmönstren som ingår i ÖTP. I ÖTP v2.0 har också tillförts kravformuleringar som inte direkt har bäring på e-tjänster utan mer kan vara till nytta vid olika IT-anskaffanden i en kommun. T ex finns kravavsnitt även för client/server-system och för infrastruktur medtagna. Sambruk har vad gäller IT framförallt fokuserat på e-tjänster (med målet att effektivisera kommunverksamhet och samtidigt ge bättre service) vilket avspeglas i ÖTP:s avgränsningar. I vissa fall har dock även i ÖTP medtagits delar som mer syftar till intern IT-effektivitet i sig. Ett exempel är kravlistor för mer allmänna icke-funktionella krav. 1 ÖTP, Öppen Teknisk Plattform inom Sambruk

6 Sambrplform_OTP_v20.doc 6(102) Tidigare ÖTP-versioner har varit tätt kopplade till specifika verksamhetsutvecklingsprojekt inom någon kommunverksamhetsgren. Föreliggande version har ingen sådan direkt koppling eftersom det inte just nu utförs sådana projekt, utan den nya versionen har snarare motiverats av vunna erfarenheter från olika anskaffanden, vidare insikter vad gäller kommunapplikationer samt den ständigt pågående teknikutvecklingen. Man bör också nämna att det pågår parallella arbeten inom t ex Verva, SKL (Sveriges Kommuner och Landsting) och Carelink. Vad vi kan förstå finns det en hög grad av samklang med ÖTP därvid, även om fokus kan vara olika Mål och visioner med ÖTP Vad gäller e-tjänster inom Sambruk, så har bl a följande mål och visioner beaktats vid framtagandet av arkitekturen (ej rangordnat): Alla IT-projekt bör leda till effektiviserad kommunverksamhet och samtidigt till bättre service till medborgare, företag, organisationer mfl intressenter. Inriktningen ska vara att så mycket som möjligt ska gå att återanvända i många sambrukskommuner trots dessas varierande IT-strategier och olika val av verksamhetsapplikationer. Inlåsningsproblem i olika leverantörers specifika lösningar ska minimeras. Tillverkning av applikation, anpassningslogik mm ska kunna ske i någon (ev. flera) vanligt förekommande utvecklingsmiljö och för någon vanligt förekommande driftmiljö, t ex baserat på ASP.NET, Java, Tomcat, JBoss, IIS, SQL Server, MySQL, Windows, Unix, Linux e dyl. Dock förutsätter vi att miljöerna ska stödja enkla Web Services (vilket inte borde bli något problem). Kommunikation med registerhållande centrala myndigheter och med e-legitimation/eunderskrifts-leverantörer ska kunna stödjas. S k Standardmeddelanden 2 via SHS 3 ska prioriteras. Både kostnads- och kalendertidsaspekterna är viktiga. Vad gäller det mer generella sambruksarbetet, så har dessutom bl a följande mål och visioner beaktats vid framtagandet av arkitekturen (ej rangordnat): Både specifikationsprojektens funktionella resultat (processdefinitioner mm) och föreliggande applikationsarkitektur ska gå rimligt lätt att använda för någon annan kommun inom ramen för samarbetet i Sambruk. Modularisering, komponentuppdelning och tillförande av maskingränssnitt ska vara väl genomförd så att andra kommuners varierande krav i rimlig grad kan tillgodoses och att återanvändning underlättas. 2 Standardmeddelande är ett begrepp som Verva tagit fram inom området informationsöverföring, man anger rekommendationer för hur detta bör utformas 3 SHS: Spridnings och HämtningsSystem. Se

7 Sambrplform_OTP_v20.doc 7(102) 1.3. ÖTP över tiden Öppen teknisk plattform har tidigare arbetats fram i flera steg, år Detta successiva arbetssätt satsar vi på även i framtiden varför vi finner det lämpligt att ha en sammanhållen versionsnumrering för utgåvor av ÖTP: ÖTP version 1.0: Dokumentfilen Sambruksplatt_tekn_V1.0.doc Grundläggande rapport från 2003 om egenskaper hos en Öppen Teknisk Plattform ÖTP version 1.1: Dokumentfilen Sambrplform_Borl_Ark_v10.doc Öppen teknisk plattform och applikationsarkitektur från 2004, dels generellt, dels för Borlängepiloten (Bistånd). ÖTP version 1.2: Dokumentfilen Sambrplform_OTP_v12.doc Våren Öppen teknisk plattform och applikationsarkitektur, dels generellt, dels för de samtidiga verksamhetspiloterna. Versionen innefattar tidigare versioners specifikationer (eventuellt i redigerad form) så läsaren ska inte behöva gå tillbaka till de tidigare versionerna (annat än av historikskäl). ÖTP version 2.0: Dokumentfilen Sambrplform_OTP_v20.doc Föreliggande dokument,hösten Med nummerbytet till 2 som major version signaleras att dokumentet tillförts en ny struktur som är mycket mer direkt anpassad för att utgöra kravbilaga vid anskaffanden. I övrigt har arkitekturmönstren utvidgats, uppdaterats samt moderniserats. Några få saker har utgått. Förutom dessa utgåveversioner av ÖTP förekommer även arbetsdokumentversioner under framställningen. Dessa sistnämnda är alltså av betydligt mer temporär karaktär. T ex: Sambrplform_OTP_v20_dokv_03.doc där v20 är utgåvan av själva ÖTP medan v03 är versionen hos ett arbetsdokument under färdigställandet av utgåvan. Det bör här nämnas (liksom det redan poängterats i ÖTP v1.0) att det blir avgörande för framgången att resurser och entusiasm finns för att över tiden förvalta/versionera plattform/arkitektur, missionera om dess egenskaper och skapa kokböcker och liknande vägledningar när plattformen ska användas och vid tillverkning och införande av e-tjänster. Föreliggande arkitektur är ett försök att finna en optimal ambitionsnivå. Kraven och förväntningarna kunde teoretiskt sett vara enormt stora. Om man skulle ta riktigt hög höjd för alla sådana teoretiska aspekter skulle kalendertidsåtgång, kostnader och genomföranderisk bli synnerligen höga. Gjorda val för arkitekturen försöker vara pragmatiska så att något vettigt går att leverera inom relativt kort tid, men att samtidigt en tillräckligt bra framtidssäkring åstadkoms. Detta synsätt tillsammans med iterationer och successiv förvaltning och vidareutveckling av ÖTP torde ge bästa optimering av kostnad/nytta/risk över tiden. Inom IT-branschen används ibland begreppet Enterprise Architecture (EA) och i det sammanhanget ofta Zachman Framework. Dessa modeller skulle kunna vara mycket fruktbara för kommunvärlden, men det finns samtidigt ett problem med rimlig ambitionsnivå enligt föregående stycke. Dock kan man säga att ÖTP definierar delar av matrisen i Zachman Framwork, framförallt inom rad 2-4 samt främst kolumnen What, men även i viss mån inom kolumnerna How, Where och Who. För mer info, se litteratur om Zachman Framework.

8 Sambrplform_OTP_v20.doc 8(102) Följande tids-skiss visar denna ansats att arbeta successivt och att ändå behålla kontinuitet och framtidssyn: Konkreta leveranser och kontinuitet Första e-tjänst, Biståndsprojektets webb-applikation + adaptrar Samtidigt skapas de ÖTP-delar som behövs just till denna e-tjänst. Inom respektive e-tjänsts budget. Flera lev. är tänkbara parallellt. Nuvarande e-tjänster inom Sambruk skapas Samtidigt skapas de ÖTP-delar som behövs just till dessa e-tjänster. Uppsyn Nästa e-tjänst... ÖTP-delar... Nästa e-tjänst... ÖTP-delar... Nästa e-tjänst... ÖTP-delar... ÖTP-förvaltning Slimmad, lätt men kontinuerlig organisation som bl a förvaltar arkitektur & planer. Missionerar för ÖTP hos kommunerna. Uppsyn över sambruksprojekten. Bevakar teknikutvecklingen. Har leverantörskontakter. tid För ÖTP v2.0 har vi ett visst undantag från huvudprincipen, det finns inget specifikt verksamhetsutvecklingsprojekt just nu som kravställer mot ÖTP, även om pågående och nyliga anskaffningsarbeten t ex kring barnomsorg, fritid och dokument- och ärendehantering gett mycket erfarenheter och visat på behov som vävs in i v2.0. Inom ÖTP-organisationen framställdes under mitten av 2006 en kravspecifikation för Generell integration. Därvid provades ett format och en struktur för återanvändbara krav vid anskaffningar. Grundprinciperna för denna kravstruktur användes, specialiserades och vidareutvecklades därefter under hösten i ett arbete som utfördes inom sambruksmedlemmen Botkyrka kommun (kallas där GIT Generella IT-krav). Sambruk har därefter fått tillgång till GIT. Botkyrka har också fått praktisk erfarenhet av ett antal upphandlingar där GIT använts. Även Jönköpings kommun har använt en sådan struktur i upphandling, där kallad GISIT (Generella IS/IT-krav). Efter detta har liknande kravspecarbete utförts i samverkan mellan Sambruk och Kommentus inom området barnomsorg. Alla dessa utgångsdokument och praktiska upphandlingserfarenheter har påverkat utformningen av kravstrukturen i ÖTP

9 Sambrplform_OTP_v20.doc 9(102) v2.0. Förhoppningen är att det ska gå mycket fortare att skapa olika IT-kravdokument i framtiden med ÖTP v2.0 som bas genom att krav kan återanvändas effektivt. Samtidigt är det mindre risk att viktiga krav råkar glömmas bort, genom att ÖTP kan användas som en slags checklista för krav. Föreliggande dokument är författat av Sven-Håkan Olsson (DocAccount), i samverkan med Janne Dicander (Sambruk och Jönköpings kommun) och Anders Thoursie (DocAccount). Stort värde för arbetet har också skapats i och med ett antal sambruksmöten med ÖTPgrupperingen, genom SKL (Sveriges Kommuner och Landsting) samt Verva.

10 Sambrplform_OTP_v20.doc 10(102) 1.4. Anskaffningsdokument Ett antal anskaffanden (upphandlingar, ramavtalsavrop etc) av IT-stöd till verksamheten görs under varje år inom Sambruk och medlemskommunerna. I kravdokumentationen för anskaffandena bör det ingå både funktionella och icke-funktionella krav. Med tanke på att återanvändning allmänt är mycket önskvärd så uppstod idén om föreliggande del inom ÖTP, dvs en generell teknisk kravspecifikation för IT-stöd. Tanken är att denna kravspecifikation ska kunna återanvändas till många olika anskaffanden/upphandlingar. Eftersom de icke-funktionella krav som härleds från funktionella nyttokrav och andra kravkällor rimligen sällan kan vara helt lika, får specifikationen formen av en slags palett eller smörgåsbord av många krav, utsedda i enlighet med Sambruks långsiktiga IT-strategiarbete. Alla kraven menas alltså inte användas samtidigt. Istället planeras det generella ÖTP-dokumentet att användas så att det vid varje anskaffandetillfälle upprättas en separat icke-funktionell kravbilaga. Denna pekar ut den konkreta delmängden tekniska krav mm från den generella specifikationen som gäller i just detta anskaffande. Den icke-funktionella kravbilagan kan dessutom innehålla extra krav utöver vad som finns tillgängligt på paletten och som behöver ställas i det specifika anskaffandefallet. (För den som är bekant med objektorientering kan man här jämföra med arvsmekanismen.) I de detaljerade kapiteln nedan används genomgående formuleringen "Krav". Det är alltså sedan upp till varje specifik anskaffning att ange vilka av dessa krav som i just det fallet ska inkluderas, samt huruvida respektive krav ska ställas som "Bör", "Skall" eller "Beskriv" e dyl. I vissa fall innebär det att några alternativa varianter av huvudsakligen samma krav kan stå bredvid varandra i ÖTP, de utgör närliggande färger där endast en tänks väljas från paletten. De konkreta kravpunkterna med generella IT-krav i dokumentet benämns ÖTP-GIT 4, för att skilja ut dem från de mer resonerande arkitekturavsnitten. Endast konkreta kravpunkter från ÖTP-GIT som refereras i den separata icke-funktionella kravbilagan (eller möjligen i annan kravbilaga) ingår alltså i en viss anskaffnings specifika kravuppsättning. Dock utgör alla resonerande arkitekturavsnitt allmän bakgrunds- och roadmap-information till leverantörer och andra, liksom att de resonerande avsnitten kan komma att refereras specifikt i olika upphandlingstexter. Ifall ett eventuella texttillägg i en punkt i det icke-funktionella kravdokumentet skulle ha omvänd mening mot text i ÖTP-GIT-kravet som refereras, så är tanken att texten i det ickefunktionella kravdokumentet gäller med företräde. Denna princip bör dessutom klart uttryckas i de formella upphandlingsdokumenten. En inriktning är att när ÖTP redigeras över åren så ska kravnummer vara stabila, för att därmed undvika kvalitetsrisker vid återanvändning av refererande icke-funktionella kravdokument. Därför förväntas nya krav läggas till allra sist eller få ett sub-nummer såsom 4 ÖTP-GIT: Öppen Teknisk Plattform, Generella IT-krav

11 Sambrplform_OTP_v20.doc 11(102) ÖTP-GIT-22a4, liksom att borttagna kravs nummer inte ska återanvändas, utan istället kravnumret stå kvar med texten "Kravet utgått". Det bör kommenteras att vissa produkt- och leverantörsnamn nämns i föreliggande dokument. Detta ska inte betraktas som ett ställningstagande inom Sambruk som helhet för eller emot just dessa produkter, utan endast ses som exemplifieringar. I de fallen finns vanligen två-tre alternativa krav inkluderade och att just de produktnamnen finns nämnda har endast med att göra att ett antal sambrukskommuner har kommit att ha köpt dem redan, så de kan ha rättmätiga behov av att koppla ihop sig med dem för att inte förlora mycket pengar och investeringar i mänsklig kunskapsuppbyggnad Dokumentstruktur Vid ett anskaffandetillfälle utformas således ett separat icke-funktionellt kravdokument : Här förtecknas de ÖTP-GIT-krav som ett specifikt anskaffande konkret ska omfatta. Olika anskaffanden kommer naturligt att ha olika kravbilder beroende på verksamhetsområde, specifika krav, aktuell teknikmiljö etc. Kraven förtecknas här som antingen "Skall" eller "Bör" och pekar helt enkelt ut exakta kravnummer ur paletten i ÖTP-dokumentet. Tanken är att inte kopiera/redigera kravtexterna in i det icke-funktionella kravdokumentet utan istället referera kravpunkterna därifrån, för att därmed minska tiden som åtgår till kvalitetssäkring och rättande av redigeringsfel. Kravpunkter i paletten kan i vissa fall också alternativt användas som "Beskriv"-krav där ansvaret mera läggs över till offerent att föreslå egenskaper som sedan kan bedömas och betygsättas, samt ingå i kontraktstext. (Huruvida Beskriv-krav alls används brukar variera mellan olika upphandlingsformer och olika upphandlarkultur, i vissa fall kommer inte den formen att förekomma.) Det är ibland lämpligt att i den icke-funktionella kravbilagan lägga till en kommentar om hur betygsättningen för ett krav i aktuellt fall kommer att ske, åtminstone ifall det inte är självklart vilket svar som är positivt i just detta kravläge. Man kan också ibland vilja lägga till mer konkret info om betygskriterier för kravet. Tillkommande krav som inte finns i paletten (eller där dessa inte passar) förtecknas som vanliga kravpunkter i text direkt i det icke-funktionella kravdokumentet. ÖTP-dokumentet kan alltså användas i flera sammanhang, beroende på aktuell faktisk kravbild, så effektiv återanvändning i samband med anskaffanden bör därmed kunna uppstå. Man kan förutse att så småningom blir vissa ÖTP-GIT-krav föråldrade och mängden krav som inte kan refereras utan måste skrivas i text direkt i ett icke-funktionellt kravdokument ökar. Därför får man förutsätta att ÖTP successivt utkommer i uppdaterade versioner där många förbättringar till ÖTP kan hämtas direkt ifrån krav uttryckta i text i olika anskaffandens icke-funktionella kravdokument.

12 Sambrplform_OTP_v20.doc 12(102) Hur krav/dokument förhåller sig till varann Aktuell situations verksamhetsbehov Kommunens IT-strategikrav Sambruks visioner Påverkar Ickefunktionell kravbilaga Pekar ut (refererar) krav ur paletten - samt anger andra krav Pekar ut ÖTP-GIT Gemensamma IT-krav Palett av alternativa krav Drift-krav Egentligen är en kravstrukturering som i detta dokument multidimensionell (aspekter skulle återkomma i olika kombinationer), men det skulle bli för komplext att ställa upp det så. Istället så har vi vid överlappsrisk mellan avsnitt helt sonika stoppat in varje specifik aspekt under någon av de tänkbara kategorierna. I enstaka fall görs för tydlighets skulle ändå en "se även"-notering för att underlätta läsandet.

13 Sambrplform_OTP_v20.doc 13(102) Exempel på refererande text i ett icke-funktionellt kravdokument Ett separat dokument utges av Sambruk för att vara en kort vägledning för hur ickefunktionella kravdokument kan utformas (se bilaga). Nedan infogas dock ett enkelt exempel på hur påhittade kravpunkter i ett icke-funktionellt kravdokument som används tillsammans med ÖTP v2.0 kunde se ut, och där specifika ÖTP-GIT-kravpunkter refereras (dvs pekas ut, inte kopieras in). Nr Skall-krav Skall anbudsgivare beskriva lösningen (här eller i bilaga)? 1 Lösningen skall uppfylla ÖTP-GIT-23 Uppfylls kravet? Ja Nej Ja Plats för beskrivsvar: 2 Lösningen skall uppfylla ÖTP-GIT-31 Uppfylls kravet? Ja Nej Nej 3 Användning av refererade Nyttomeddelanden enligt den funktionella kravspecifikationen skall finnas implementerad för kommunikation gentemot bakomliggande verksamhetsapplikation Uppfylls kravet? Ja Nej Nej... [Exempel på ett mer specifikt krav än vad som fanns i ÖTP-GITpaletten, här i samband med att en e-tjänst (webbdelen) upphandlas förtecknas alltså direkt i text här]

14 Sambrplform_OTP_v20.doc 14(102) Nr Bör-krav Skall anbudsgivare beskriva lösningen (här eller i bilaga) - ifall börkravet erbjuds? Maxbetyg (det maximala betyg som kan ges för kravsvaret 1 Lösningen bör uppfylla ÖTP-GIT -5 Uppfylls kravet? Ja Nej Ja 5 Plats för beskrivsvar: 2 Lösningen bör uppfylla ÖTP-GIT-12 Uppfylls kravet? Ja Nej Nej 10 3 Lösningen bör ha stöd för Sun Solaris 10 Uppfylls kravet? Ja Nej Plats för beskrivsvar: Ja 5... [Exempel på ett mer specifikt krav än vad som fanns i ÖTP-GIT-paletten och som en viss anskaffare kan tänkas ha förtecknas direkt i text här] Olika upphandlarkulturer brukar förorda olika sätt att vikta bedömningar av offertsvarspunkter. Här visas exempel med maxbetyg per punkt som sedan får slås ihop till totalbedömning av kvalitetsegenskaper kontra pris t ex. En annan vanlig modell är att alltid sätta betyg 0 till 4 på alla bör-kravssvar och sedan sätta olika vikter på kraven så att önskad balans uppnås i sammanräkningen. Strukturen i ÖTP-GIT påverkas inte av detta, utan betygsmodell kan fritt väljas av varje författare till icke-funktionella kravdokument. En annan sak som kan skilja är huruvida upphandlaren vill få beskriv-texterna besvarade direkt i ett svarsdokument som utgår från ett icke-funktionella kravdokument eller om man vill ha alla sådana svarstexter i separat bilaga, som i exemplet ovan. Det är ofta också lämpligt att ange en maxlängd på beskriv-texter, t ex max en A4-sida vid typsnittstorlek 10.

15 Sambrplform_OTP_v20.doc 15(102) 1.5. Roadmap - krav på sikt Vanligen ställs vid anskaffande ett antal Skall-krav och vissa Bör-krav. Förutom att de sistnämnda förstås bör uppfyllas av offerent redan i dagsläget, bör de parallellt tolkas som krav som om något år kan komma att upphöjas till Skall-krav i senare anskaffanden. På samma sätt är det med krav i den generella paletten som i en viss specifik upphandling inte refereras alls - dessa icke-refererade krav ger ändå en indikation till leverantören om vilka krav som torde ställas om några år. Stort roadmap-värde bör också de mer resonerande arkitkturavsnitten ha. Där beskrivs bl a önskade mönster och principer för samverkande IT-lösningar. På detta vis hoppas vi att vi kan ge input i förväg till leverantörernas utvecklingsverkstad om vilka krav leverantörer bör börja överväga att införa i sin roadmap - så bör hela utvecklingsoch anskaffandeprocessen totalt sett kunna bli billigare och effektivare över tiden, både för kund och för leverantör Grey-box varför specificera vissa detaljer? Detta dokument innehåller ÖTP-GIT-krav av olika detaljeringsnivå ibland relativt detaljerat. Man kan argumentera för att verksamhetsstöd och funktionalitet är det viktigaste och att hur en applikation ser ut på insidan inte bör vara relevant vid anskaffanden. Detta brukar kallas black-box, köparen ska endast se utsidan av "funktionslådan" dvs nyttan för verksamheten, inte innanmätet. Emellertid visar erfarenheten att vissa aspekter av en applikations innanmäte blir viktiga för optimering av kommunens nätverk, integration, klientkostnad, serverkostnad, hårdvarukostnad, driftpersonal mm mm. Att i viss mån intressera sig för innanmätet har därför i analogi kommit att kallas grey-box. I samband med om det är en byggsten/komponent som ska anskaffas, inte en hel lösning, blir applikationsarkitektur och andra aspekter naturligtvis synnerligen viktigt. Detta är den viktigaste anledningen till att grey-box-tanken ökat i betydelse på senare tid. Dessutom ökar kraven starkt på integration mellan hela applikationer och även då blir vissa detaljkrav mycket viktiga. I händelse av att en lösning utgörs av öppen programvara e dyl uppstår på liknande sätt en white box. Användande organisation har då även möjlighet att på egen hand modifiera lösningen så den passar bättre, men härvid måste man naturligtvis beakta att man i så fall får ett stort eget underhållsansvar ifall inte en större "community" eller annan förvaltningsorganisation deltar.

16 Sambrplform_OTP_v20.doc 16(102) 1.7. Funktionell bakgrund Sambruk arbetar bl a med den dubbla målsättningen att ge medborgare (och andra intressenter) bättre service och samtidigt göra kommunerna efffektivare internt. För att verka åt det hållet handlar en stor del av ÖTP om olika sorts öppenhet och applikationsintegration. Applikationsintegration fanns redan på hålkortens tid; man har alltid haft behov av att skicka data mellan applikationer. Däremot har behoven ökat över tiden och karaktären av behoven har ändrats. Framförallt har vi fått ökat behov av tillgång till sekundfärskt data "online". Vi har också fått en ökad kundfokusering inom IT-branschen, vilket inom kommunvärlden motsvaras av en medborgarfokusering. Det innebär bl a att en medborgare (eller annan extern intressent såsom företag, förening etc) har en ökad förväntan att kunna se samlad info om sej t ex på en kommuns e-tjänst - medborgaren är komplett ointresserad av hur kommunen har valt att organisera sitt arbete internt och bör normalt inte behöva veta vilken förvaltning en viss sak lyder under. Ett annat exempel är s k kontakt-center. Om de ska kunna ge en viss servicegrad till medborgarna bör de ha tillgång till (viss) information ifrån en mängd applikationer inom kommunen och det är inte rimligt att de ska separat logga in i och använda samma tunga, många och olika användargränssnitt som expertanvändarna har nytta av inom förvaltningarna. Exempel på behov där många applikationers information behöver nås samtidigt: Kontakt-center Medborgarkontor E-tjänster Telefonapplikationer (ton-knappar) Medborgaröverblickswebb (Mina Sidor etc) Dokument-och ärendehantering över förvaltningsgränserna. Automatiserade diariekopplingar. När tillfälliga verksamhetsprocesser kan behöva skapas (inför t ex stora evenemang eller kommunsatsningar) Generellt sett minska inlåsning i stuprörslösningar. Allt detta ger ändrade och större krav på integration. För medborgaren blir internetbanken måttstocken för hur e-tjänster bör fungera välintegrerat.

17 Sambrplform_OTP_v20.doc 17(102) Följande figur visar denna situation, uttryckt i termer av "stuprör" och "hängrännor": Hängrännor - stuprör Barnomsorgsförvaltningen Socialförvaltningen Byggnadsnämnden E-post Sedan länge Diarie Ibland befintlig integration Kontaktcenter Medb-web E-tjänster Workflow... Tillkommande potential... Integrationen är ofta av olika karaktär. Oftast beror det på vilket färskhetsbehov man har för informationen - är det sekundfärskhet online som behövs eller duger det om det kommer fram om en stund eller nästa dag? Integrationslösningarna blir ofta tekniskt mycket olika för dessa olika behov. T ex är behovet nära användargränssnittet (det som brukar kallas front-end-integration) ofta mer av onlinekaraktär med sekundfärskt data, medan överföring till t ex bokföringssystemet kan få ta längre tid (brukar kallas back-end-integration). Hybrider finns naturligtvis, bl a när man använder back-end-integration för att förse en speciell databas som ligger nära användargränssnittet med data vilket inte behöver ske sekundsnabbt, bara användargränssnittet i sin tur kan nå sin databas sekundsnabbt.

18 Sambrplform_OTP_v20.doc 18(102) 2. APPLIKATIONSARKITEKTUR I nedanstående arkitekturbilder med tillhörande kommentarer anges ett antal arkitekturprinciper och modulariseringssätt. Eftersom många avvägningar måste göras mellan önskemål om hög flexibilitet och att vara konkret och tydlig, inkluderas också en del orsaksresonemang i samband med arkitekturskisserna för att ge kravspårbarhet. Plattformen och arkitekturen måste självklart versioneras och utvecklas över tiden och därför är det extra viktigt att veta varför olika val togs vid olika tidpunkter. Först behandlas översikter, sedan följer renodlingar av ett antal aspekter Översiktsarkitektur applikationsintegration generellt Back-end front-end Engagemangsbild Skr.sytt. syst Barnoms Front-endintegration (ofta SOA) Std.syst Soc Std.syst Byggnnämnd Bokfsyst Back-endintegration (ofta EAI) Kommentar: Strecken i figuren kan utgöras av integrationslösningar Front-end-integration har under några år nu i hög grad utgjorts av Service Oriented Architecture (SOA) 5, oftast utfört med Web Services 6 som teknik. 5 SOA: Service Oriented Architecture, arkitektur orienterad mot anropbar programvara som utför tjänster 6 WS: Web Services, ett sätt att återanvända webbprotokoll för maskin-till-maskin-anrop

19 Sambrplform_OTP_v20.doc 19(102) Back-end-integration har historiskt brukat kallas Enterprise Application Integration (EAI) 7. Datafärskhetskrav i klass med sekundsnabbhet har sällan funnits med i kravbilden för EAI. Inom kommunvärlden har en dominant integrationsprodukt (Decapus) varit av enklare slag och knappast kunnat kallas EAI, men produkten har funktionalitet för att få grundläggande fil-integration att fungera (vilket ibland är fullt tillräckligt). På sistone har ett nytt begrepp dykt upp, Enterprise Service Bus (ESB) 8 som förenklat innebär EAI fast som dessutom kan gå sekundsnabbt och klara prenumeration på information. Emellertid går dessa världar ihop nu, EAI-plattformar klarar ofta SOA och ESB t ex. Dock är det inte säkert att de är fullständigt optimerade för detta, de kan också vara onödigt bra och därmed ha en dyr prislapp. SOA brukar utgöra s k funktionsintegration där man ser det som att programkod för verksamhetslogik körs i serverändan när ett anrop ankommer, och att i många fall ett svar skickas tillbaka. Dataintegration däremot är gamla EAI:s kärnområde där det vanligen endast är information som ska skickas från ett system till ett annat, utan att man inom integrationen fokuserar på exekvering av verksamhetslogik. Genom dessa skillnader passar SOA extra bra för front-end-integration och EAI extra bra för back-end-integration, även om detta börjar flyta ihop mer idag, t ex vad gäller ESB. Om nu införande av integrationslösningar bedöms lämpligt, vad står man sedan inför för utmaningar? Det svåraste brukar vara själva öppenheten, inkopplingen i stuprörssystemen. Ifall man har egna skräddarsydda applikationer så kan man själv utveckla maskingränssnitt, adaptrar etc. Vanligast i kommunvärlden är dock standardapplikationer och dessa är tyvärr ofta inte så öppna idag. Denna typ av öppenhet är däremot redan mycket vanlig inom näringslivets standardapplikationer, det finns därmed god erfarenhet av hur detta kan utformas tekniskt, oavsett man har använt äldre teknikmiljöspecifik kommunikation (som t ex LU6.2, DCOM eller RMI), eller interoperabla Web Services med XML-meddelanden (såsom enligt ÖTP:s specificerade Nyttomeddelandestruktur eller Statskontorets/Vervas s k Standardmeddelanden). Inom kommunsektorn har alltså standardapplikationerna släpat efter ur öppenhetssynvinkel. Vi förväntar oss dock att detta ska kunna lösas, dels baserat på generella systemutvecklingstrender, dels grundat på Sambruks och andras påverkan och upphandlingstryck. 7 EAI: Enterprise Application Integration, integration som betonar överföring av större dataflöden 8 ESB: Enterprise Service Bus, enkelt uttryckt EAI plus större snabbhet och vanligen ej nav-struktur

20 Sambrplform_OTP_v20.doc 20(102) Öppenhet inkopplingspunkter - maskingränssnitt Inkopplingspunkterna i applikationerna kan vara ett problem de är ofta slutna, man behöver tillföra adaptrar... SOA-trenden (och EAI) på väg att förbättra läget dock. Skr.sytt. syst A Engagemangsbild Std.syst B Std.syst C Sambruk och kommunala anskaffare bör verka för ökad öppenhet från leverantörerna Bokfsyst Det är värt att notera att de generella integrationslösningarna ofta inte idag innehåller adaptrar eller färdiga inkopplingspunkter för kommunala verksamhetsapplikationer, dessa måste då tillföras av applikationsleverantören eller tredje part etc. Sammanfattningsvis, ÖTP förordar starkt ett tänkande där hängrännor och liknande funktionella lösningar kan åstadkommas. Därvid ska SOA-principen vara grundläggande. Huruvida EAI eller ESB-plattformar behövs måste däremot bedömas beroende på aktuell behovsbild eftersom de har en viss kostnad och komplexitet att väga mot deras fördelar.

21 Sambrplform_OTP_v20.doc 21(102) Följande bild beskriver hur vi i ÖTP definierar att EAI, ESB, SOA och Web Services relaterar till varandra (och vilka överlapp som finns): SOA-tyngdpunkt: Anrop av tjänster SOA EAI EAI-tyngdpunkt: Flöden av data ESB Web Services ESB-tyngdpunkt: Anrop samt anropsinfrastruktur (samt flöden)

22 Sambrplform_OTP_v20.doc 22(102) 2.2. Översiktsarkitektur SOA Här följer en översiktsbild (generell, ej specifik för någon e-tjänst) som utgår från Sambruks tidiga utredningar, och som framförallt lyfter fram och fokuserar på integrationslogiken som behövs för e-tjänster. Detta eftersom det är en av de svåraste nötterna att knäcka för att åstadkomma modularisering/komponenter, återanvändbarhet och interoperabilitet för deltagande kommuner (vilka har gjort varierande interna val av applikationer och teknikbas). SOA-principen tillsammans med Web Services är det prioriterade mönstret för e-tjänster i ÖTP, framförallt för front-end-integration, enligt följande bild: Översiktsbild Medborgare Företag Handläggare etc SOA Service Oriented Architecture Anpassningsskikt (med ev integrationslogik - adaptrar) E-tjänst Ny webbapplikation Existerande verksamhetsapplikation Handläggare etc Exempel på adapter Registerhållande myndighet etc e-leg / e-underskrkoll etc = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services) = Anpassnings-logik (ev) = Proprietära/specifika anrop per verksamhetsapplikation/tjänst Kommentarer: E-tjänstens webb-applikation och en stor andel av adaptrarna ska kunna vara gemensamma för flera kommuner (trots att dessa kan ha gjort varierande interna val, t ex vad gäller verksamhetsapplikationer). Förutom att källkod/produkt ska kunna

23 Sambrplform_OTP_v20.doc 23(102) vara gemensam i sig så bör den vara utförd för att kunna samdriftas på ett rationellt sätt för flera kommuner (trots dessas varierande interna val) ASP-typen av drift. Fokus i denna bild är online-situationen snarare än stora asynkrona, batchliknande flöden (för det sistnämnda, se separat kapitel). E-tjänstens definierade Nyttomeddelanden måste dels vara specifierade till syntax och semantik (funktionella egenskaper), dels till teknik (icke-funktionella egenskaper). För tekniken finns aspekterna rörläggning och regler och konventioner mm (se dessa kapitel). För tekniken gäller också, per Nyttomeddelande, de egenskaper som grupperas ihop inom s k kommunikationsprofiler. Services Oriented Architecture (SOA), baserat på enkla Web Services och s k Nyttomeddelanden, är grundstommen i ÖTP. Med SOA menas i ÖTP ett fokus på anrop (stora meddelandeflöden behandlas alltså i separat kapitel). Ovan försöker vi även ge en översiktsbild där både anropande och anropade parter samt eventuella mellanliggande adaptrar visas. Om man skulle se det strikt ur endast anroparens synvinkel skulle man mer fokusera på inkapsling och "black box". En huvudsak är dock betoning av informationskontrakt i anrop, i form av Nyttomeddelanden. Den L-formade SOA-delen av skissen skulle kunna vara kandidat för att utföras med någon form av Web Services Management-plattform, ESB (Enterprise Service Bus) etc, men det är i många fall helt rimligt att inte använda sådan. Se separat kapitel. ÖTP-GIT-1) Krav: Att lösningen har en öppenhet och därmed kan anropas enligt SOAprinciperna samt omvänt även kan anropa sin omvärld. Beskriv SOA-gränssnitten översiktligt. ÖTP-GIT-2) Krav: Att SOA-användningen i lösningen i övrigt är utformad för största de facto interoperabilitet mellan teknikmiljöer, genom stöd för lämpliga datatypsval, längder mm, t ex ifall generering av Web Services och/eller WSDL-filer stöds. Beskriv på vad sätt lösningen härvid strävar mot interoperabilitet. ÖTP-GIT-3) Krav: Att adaptrar gentemot omvärlden kan infogas i totallösningen. Med adaptrar menas anpassningslogik både för varierande teknikanpassning, syntaxanpassning och semantikanpassning etc. Beskriv på vilket sätt, adapterarkitektur, versionskrav, samt ev mer detaljerade krav från lösningen. ÖTP-GIT-4) Krav: Att lösningen i enlighet med ASP 9 -mönstret har möjlighet att parallellt kunna samdrifta flera kunder (kommuner) eller användningar. Gäller både webbapplikationer (inkl ev affärsobjekt-skikt, data-skikt etc) och anpassningslogik. Beskriv ASP-möjligheten översiktligt. 9 ASP: Applications Service Provider, på senare tid även SaaS, Software as a Service, samdriftning av tjänster mm.

24 Sambrplform_OTP_v20.doc 24(102) ÖTP-GIT-5) Krav: Att lösningen som följd av ASP-driftning kan konfigureras så att Web Services-anrop som hänför sig till en viss kommuns del av ASP-driftning adresseras till en specifik Web Services-adress trots att det kan vara samma sorts Nyttomeddelande som en annan kommuns del av ASP-driftningen. Beskriv översiktligt konfigurerbar Web Services-adressering i ASP-driftning.

25 Sambrplform_OTP_v20.doc 25(102) 2.3. Olika behov av anpassningslogik mot verksamhetsapplikation Direkta anropsgränssnitt Anpassningslogiken för att integrera en viss e-tjänst med den verksamhetsapplikation (i undantagsfall flera) som en kommun använder sig av, blir med nödvändighet av olika omfattning beroende på respektive applikations möjligheter (både applikationens funktionella och tekniska egenskaper). I Sambruks äldre projekt Borlänge-piloten som exempel, så heter e-tjänsten Förnyad ansökan om ekonomiskt bistånd. Specifikationsprojektet definierar ett antal Nyttomeddelanden som behövs för att webbapplikationen ska kunna förses med information från verksamhetsapplikationen, samt kunna uppdatera densamma. I Borlänge kommun används idag verksamhetsaspplikationen Sofia. Ambitionen ska självklart vara att Borlänge (eller en annan kommun som vill sambruka e- tjänsten Förnyad ansökan om ekonomiskt bistånd) istället för Sofia ska kunna använda en annan typisk verksamhetsapplikation utan att de definierade Nyttomeddelandena ska behöva ändras. Dock får man vara realist och inse att alltför stor variation inte på förhand går att förutse eller täcka in, då bleve Nyttomeddelandena så oprecisa och abstrakta att de inte vore praktiskt användbara. Man måste alltså vara beredd på att över tiden förvalta definitionen av Nyttomeddelandena och skapa nya versioner allteftersom kravbilden ändras. Det blir därmed en mycket viktig framgångsfaktor att organisationen kring Sambruk klarar av detta förvaltningsansvar. I samverkan med näringslivet eller tänkbara andra konstellationer som utvecklar verksamhetsapplikationer finns det en förhoppning att en standardiserande verkan uppkommer vad gäller Nyttomeddelandena. Detta är viktig roadmap-information till leverantörer. Helst finns därmed Nyttomeddelandena (exakt som de är definierade i Sambruks respektive e-tjänst) redan färdigimplementerade i verksamhetsapplikationen. Anpassningsskiktet består i detta gynnsamma fall (alternativ X i figuren nedan) endast av en specifikation ingen programkod eller mellanprogramvara behöver skrivas/anordnas, underhållas eller driftas. I andra fall så innehåller verksamhetsapplikationen någon annan form av proprietärt API 10 som t ex baserats på tekniska miljöer som Microsofts COM/Dotnet, på Java RMI eller på Web Services. Detta innebär att anpassningslogikens programkod måste utvecklas, underhållas och driftas i respektive teknisk miljö (alternativ Y i nedanstående figur). Hur omfattande anpassningslogiken blir är naturligtvis synnerligen beroende av respektive API:s nivå och funktionalitet. I ytterligare andra fall innehåller inte verksamhetsapplikationen något API för online-bruk överhuvudtaget. Anpassningsskiktet måste då bli ganska tjockt och beroende av den teknik som applikationen råkat vara skriven med. Ett typiskt scenario är att applikationen har en SQL-databas vars datamodell är publicerad, går att studera och förstå, varefter 10 API: Application Programming Interface maskingränssnitt för anrop emellan program

26 Sambrplform_OTP_v20.doc 26(102) anpassningslogik måste programmeras på låg nivå, direkt gentemot SQL (alternativ Z i figuren nedan). En mellanvariant är att befintliga eller nyskrivna Stored Procedures i databasen används i stället för ren SQL. Integration verksamhetsapplikation E-tjänst Ny webbapplikation I allra görligaste mån samma definierade nyttomeddelanden per e-tjänst, oberoende av verksamhetsapplikation Ex. på olika alternativa verksamhets-applikationer (vanligen endast en i taget): X Applikationen har redan infört Sambruksplf. exakta nyttomedd. via Web Service Applikationen har ett högnivå - API, t ex via COM eller RMI Y Anpassningslogiken måste bli olika omfattande (från ingenting till tjock ), beroende på resp. verksamhetsapplikations möjligheter Applikationen har inget API, tvingas gå direkt via SQL mot databasen Z = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services). Bör vara på hög nivå ( verksamhetsobjekt ). = Proprietära/specifika anrop per verksamhetsapplikation/tjänst. Helst på hög nivå men kan behöva vara på låg nivå (beroende på resp. verksamhetsapplikations möjligheter). Kommentarer: Det är viktigt att Nyttomeddelandena definieras på samma nivå som man brukar mena med verksamhetsobjekt. Det bör alltså inte vara rörlednings-meddelanden eller liknande låg nivå, utan de bör heta t ex laes_medborgarinfo och ha explicit definierade in/ut-parametrar. SOA-begreppet grov-granuläritet beskriver också detta önskade beteende. Motsvarar svart skikt i figuren ovan. Meddelanden gentemot verksamhetssystemen kan behöva vara på lägre nivå, t ex via ett rörlednings-api eller SQL. Motsvarar snedstreckat skikt i figuren ovan. Ingen allt-eller-inget-uppdatering (s k ACID) är möjlig (eller lämplig) med dagens Web Services som ju är vald teknik i ÖTP. Kompenseringsrutiner måste finnas hos aktuell kommunen för att kunna hantera eventuellt uppkomna diskrepanser, liksom

27 Sambrplform_OTP_v20.doc 27(102) information om hur loggar används för att kunna felsöka etc. Detta måste föreslås utav leverantör (motsvarande) till e-tjänst-applikation respektive anpassningslogik. Adaptern kan i värsta fall behöva innefatta egen datalagring ifall verksamhetssystemet är alltför simpelt för Nyttomeddelandenas krav. Se även kapitlet Var datalagring sker. ÖTP-GIT-6) Krav: Att lösningen har en integrerbarhet enligt mönstret X i föregående bild, enligt Sambruks definition av Nyttomeddelanden (gäller Nyttomeddelanden som är utpekade i aktuellt anskaffande). Beskriv integrerbarheten översiktligt. ÖTP-GIT-7) Krav: Att lösningen har en integrerbarhet enligt mönstret Y i föregående bild, enligt något proprietärt maskingränssnitt, med tillräckligt informationsinnehåll som är översättbart till och från Sambruks Nyttomeddelanden (gäller Nyttomeddelanden som är utpekade i aktuellt anskaffande). Beskriv integrerbarheten översiktligt. ÖTP-GIT-8) Krav: Att lösningen har en integrerbarhet enligt mönstret Z i föregående bild enligt standardiserad SQL, med tillräckligt informationsinnehåll som är översättbart till och från Sambruks Nyttomeddelanden (gäller Nyttomeddelanden som är utpekade i aktuellt anskaffande).. Beskriv integrerbarheten översiktligt. Ange särskilt ifall SQL-datamodellen är dokumenterad åt kunden. Ange även ifall uppdatering till verksamhetsapplikation via SQL är förenlig med verksamhetsapplikations ev supportvillkor. ÖTP-GIT-9) Krav: Att anbudsgivare till lösningen fogar dels upptäcktsrutiner ifall informationsöverföring inte lyckats, dels kompenseringsrutiner som måste finnas hos aktuell kommunen för att kunna hantera eventuellt uppkomna diskrepanser ifall informationsöverföring inte lyckats. Upptäcktsrutiner kan vara välbeskrivna manuella eller automatiska. Kompenseringsrutiner kan vara välbeskrivna manuella eller automatiska (de manuella kan behöva ha stöd av speciella rättningsbilder etc). Beskriv hur i totallösningen det finns sådana upptäcktsrutiner och kompenseringsrutiner Mönstret "läs online, skriv till fil" En reservlösning ifall man inte hittar vettiga sätt enligt ovan eller att applikationsleverantören inte ger rimlig offert på API eller adapter är en hybridlösning: E-tjänsten läser direkt i verksamhetapplikationens databas när den behöver läsa data. Detta kan man göra online och man kan därmed t ex åstadkomma bra indatakvalitet genom god datavalidering i användargränssnittet. Motsvarar mönstret Z ovan, dvs integration direkt mot SQL.

28 Sambrplform_OTP_v20.doc 28(102) E-tjänsten skriver till en mellanfil när den behöver skriva data. Filen importeras vid senare tidpunkt via batch in i verksamhetsapplikationen, det blir alltså inte äkta online. Troligen kan dock fördröjningen hållas låg, kanske bara några minuter. Detta blir då en något svagare funktionalitet än att vara helt online, men motsvarar ändå stor snabbhet jämfört med pappersflöden. Integration läs online, skriv till fil Samma nyttomeddelanden E-tjänst Skrivningar via mellan-fil Import-. funktion Ny webbapplikation Verksamhetsapplikaition helt utan API:er Å Läsningar online via SQL mot databasen = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services). Bör vara på hög nivå ( verksamhetsobjekt ). = Proprietära/specifika maskingränssnitt Kommentarer: Kräver ingen leverans av adapter eller nyttomeddelandeimplementation från applikationsleverantör, den läsande adaptern kan man anskaffa från tredjepartsleverantör. Nu är frågan hur man ordnar funktionen för batchimport, den ska ofta inte en tredjepartare ordna eftersom man ev kunde få problem med garanti/support mot leverantören av verksamhetsapplikationen. Å andra sidan förekommer det ofta att sådan batchimport (med rätt data i) redan existerar. Dessutom har leverantörerna vanligen utvecklat ett antal batchimporter åt kommuner genom åren, så det ska inte vara någon stor eller märkvärdig fråga för dem, de ska rimligen kunna återanvända programkod de redan har.

29 Sambrplform_OTP_v20.doc 29(102) Andra hybrider är också tänkbara, t ex att använda fil även för läsning, eller olika replikerande lösningar. Infratjänsten (ramavtal Statskontoret/Verva) innehåller även vissa tilläggstjänster som innebär mellanlagring för skrivning/läsning. Ifall dokumentation av SQL-datamodellen saknas har kommunen (enligt EU-direktiv 91/250) rätt att göra s k reverse engineering för integrationsändamål för att kartlägga datamodellen. ÖTP-GIT-10) Krav: Att lösningen har en integrerbarhet enligt mönstret Å i föregående bild, dvs läsning via SQL och skrivning via import av batchfil, med tillräckligt informationsinnehåll som är översättbart till och från Sambruks Nyttomeddelanden (gäller Nyttomeddelanden som är utpekade i aktuellt anskaffande). Beskriv integrerbarheten översiktligt. Ange särskilt ifall SQL-datamodellen är dokumenterad åt kunden. Ange även ifall batchimporten inbyggt kan exekvera automatiskt med vissa tidsintervall, eller om så inte är fallet, att batchimporten går att starta från kommandorad, API-anrop, utgörs av kö, asynkron SHS etc Screen-scraping Om inget av ovanstående alternativ visar sig görligt kan en annan reservlösning vara att använda ett bra s k screen-scraping-verktyg för att skapa adaptern mot verksamhetssystemet. Ett sådan verkyg inkräktar inte på applikationens programmering men återanvänder ändå hela verksamhets- och valideringslogiken i den existerande applikationen. Även denna variant är tänkbar för verksamhetsapplikationer som Sofia. Screen-scraping använder skärmbilderna i applikationens vanliga användargränssnitt. Användargränssnittet körs dolt i en server. Programvaran simulerar att vara användare, den registrerar det som syns på skärmen och kan mata in värden samt utföra mus-klick. I andra änden implementeras Nyttomeddelanden på vanligt sätt.

30 Sambrplform_OTP_v20.doc 30(102) Integration med screenscraping Samma nyttomeddelanden Anpassningslogik, adapter, mellan Nyttomeddelande och skärmfunktionerna i verksamhetsapplikationen E-tjänst Ny webbapplikation Applikationen har inget API alls, integr, via normalt användargränssnitt Ä Screen-scraping-verktyg som fungerar som simulerade ögon och fingrar hos en användare. = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services). Bör vara på hög nivå ( verksamhetsobjekt ). = Proprietära/specifika anrop Kommentarer: Screen-scraping-verktyg kom att användas ganska mycket i samband med integration med slutna stordatorsystem, men även mot client/server-system På senare tid har utvecklats ett antal screen-scraping-verktyg för webb-användning, s k webb-scraping, dessa är ofta modernare. En nackdel är beroendet av uppgraderingar av verksamhets-applikationerna (ifall användargränssnittet ändrats kan screen-scraping-logiken behöva modifieras), liksom risker kring tillfälliga användarmeddelanden. Prestandaaspekter kan behövas beaktas så att inte en stor mängd skärmar i användargränssnittet behöver genomlöpas bara för att svara på ett enda Nyttomeddelande t ex Man får vanligen viss inlåsning i screen-scraping-verktyget och det har en kostnad. ÖTP-GIT-11) Krav: Att lösningen inte har någon teknisk mekanism som medvetet försvårar för screen-scraping enligt mönstret Ä i föregående bild. Beskriv integrerbarheten översiktligt.

31 Sambrplform_OTP_v20.doc 31(102) ÖTP-GIT-12) Krav: Att lösningen har en integrerbarhet enligt mönstret Ä i föregående bild, dvs läsning och skrivning via screen-scraping, med tillräckligt informationsinnehåll som är översättbart till och från Sambruks Nyttomeddelanden (gäller Nyttomeddelanden som är utpekade i aktuellt anskaffande). Beskriv integrerbarheten översiktligt. ÖTP-GIT-13) Krav: Att lösningen baseras på ett screen-scraping-verktyg som är robust och tillförlitligt Beskriv screen-scraping-verktyget översiktligt och ange dess namn.

32 Sambrplform_OTP_v20.doc 32(102) 2.4. Olika behov av anpassningslogik mot centrala register, eid mm Jämfört med ovan nämnda anpassningslogik mellan e-tjänstens webbapplikation och en verksamhetsapplikation så får anpassningslogiken mot andra myndigheters centrala register, kontroll av e-legitimation/e-underskrift (eid) mm vissa andra egenskaper och dessutom en ännu större återanvändningspotential. Integration centrala reg och eid E-tjänst Ny webbapplikation I allra görligaste mån samma definierade Nyttomeddelanden oberoende av leverantör av e-leg/e-underskrift. På lägre nivå vanligen gemensamt API enligt OSIF. Anpassningsskikt (med integrationslogik) Registerhållande myndighet 1 Registerhållande myndighet 2 e-leg / e-underskr-koll, leverantör 3 e-leg / e-underskr-koll, leverantör 4 Kommentarer: Som exempel på Registerhållande myndighet 1 tas någon myndighet som exponerar ett SHS-gränssnitt gentemot sin information. Det innebär att snedstreckat skikt i figuren ovan ofta är ett anropssnitt till Infratjänstens SHS-funktioner, t ex ett rörledningsanrop såsom SHSSendSync. Nyttodatat som transporteras av detta SHSSendSync-anrop bör definieras av ett Standardmeddelande/Nyttomeddelande.

33 Sambrplform_OTP_v20.doc 33(102) Rutigt skikt i figuren översätter och formatkonverterar mellan dessa snitt. Se även det separata avsnittet Principer för Nyttomeddelanden. Svart skikt bör däremot på samma sätt som gentemot verksamhetsapplikationer vara helt på verksamhetsobjekt -nivå, relativt e-tjänsten ifråga. Andra kommunikationsvägar är tänkbara, beroende på en myndighets kapabilitet, t ex skulle Registerhållande myndighet 2 kunna nås via Web Services eller annat anropssätt ( snedstreckat skikt ). Rutigt skikt i figuren översätter och formatkonverterar mellan dessa snitt. Skulle snedstreckat och svart skikt vara identiskt definierade kan naturligtvis det rutiga skiktet gynnsamt helt utgå på samma sätt som för anpassningslogik till verksamhetsapplikationer. Stora asynkrona flöden (t ex av fil- eller EAI-typ) täcks ej specifikt här. Se vidare i separat kapitel. Även mindre, asynkrona meddelanden som ej kan leveraras via Standardmeddelanden, SHS, Web Services etc får lösas med traditionella metoder. T ex kan det i tidiga skeden bli så att registerhållande myndighet inte är färdig med modernare integrationsmodeller, varvid man kanske får skapa och överföra en frågefil som ett tag senare genererar en svarsfil från den centrala myndigheten. Med eid (dvs e-legitimation/e-underskrift) menas i detta dokument lösningar enligt Statskontorets/Vervas ramavtal för elektronisk identifiering. De olika leverantörerna för e-leg/e-underskrift har numera ett gemensamt API på lägre, mer detaljerad teknisk nivå som heter OSIF. Emellertid kan det förekomma skillnader i logik på högre nivå vilket motiverar skissen med flera tänkbara implementationer varvid det behövs integrationslogik som erbjuder ett gemensamt anropssnitt i görligaste mån gentemot e-tjänstens webbapplikation. Detta gäller även om man vill byta Infratjänsteleverantör. Man bör också nämna att det även krävs viss integration för respektive eid-lösning direkt i webb-applikationen för en e-tjänst (t ex att ställa frågan om vilken eidlösning medborgaren vill använda, att lägga upp och referera BankID:s Java-applet etc). I vissa fall behövs inte så hög säkerhet som eid ger (se även säkerhetsutredningen Saekklassn_v10_ pdf tillgänglig på eller att parallella mekanismer såsom SMS-engångskod kan användas, varvid också arkitekturen med flera möjliga implementationer bakom samma Nyttomeddelande ger nytta. Det omvända kan också tänkas i ovanliga fall, att ytterligare starkare säkerhet än eid behövs - integreras på liknande sätt. ÖTP-GIT-14) Krav: Att lösningen innehåller anpassningslogik gentemot centrala myndigheter (gäller Nyttomeddelanden som är utpekade i aktuellt anskaffande). Beskriv integrerbarheten översiktligt. Ange särskilt vilken kommunikationsmekanism respektive myndighet inkopplas med, t ex SHS, Web Services, filöverföring etc. I fallet SHS, ange särskilt vilken/vilka SHS-produkter lösningen är utprovad för. ÖTP-GIT-15) Krav: Att lösningen innehåller anpassningslogik gentemot alla eid-banker samt via Nyttomeddelanden som är utpekade i aktuellt anskaffande. Beskriv integrerbarheten översiktligt. Ange särskilt vilken/vilka eid-produkter (klientprogram, köparprogram etc) lösningen är utprovad för.

34 Sambrplform_OTP_v20.doc 34(102) ÖTP-GIT-16) Krav: Att lösningen går att konfigurera så att olika inloggningslösningar stöds, såsom eid, användarnamn/lösenord, SMS-engångskod etc. Beskriv konfigurerbarheten och vilka inloggningslösningar som stöds. Se även kapitlet Säkerhet.

35 Sambrplform_OTP_v20.doc 35(102) 2.5. Client/server Huvudfokus hos ÖTP är e-tjänster och webblösningar, men nedan inkluderas ändå vissa krav för client/server. ÖTP-GIT-17) Krav: Att lösningen är av client/server-typ. ÖTP-GIT-18) Krav: Att lösningen, ifall den är av client/server-typ har en god och modern arkitektur. Det premieras ifall lösningen är flerskiktad och har små krav på klientdatorn och nätverket. Beskriv lösningens client/server-egenskaper. Framförallt: Hur många skikt det är, vilka de är, hur stor klientdelen är, om SQL-klient i klient eller server krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används, ifall lösningen är optimerad för att fungera i ett större WAN, andra beroenden, etc. ÖTP-GIT-19) Krav: Ifall lösningen är av client/server-typ, att client/server-protokollet är dokumenterat för köparen, till syntax och semantik på verksamhetsobjektsnivå och därmed anropbart från ev annan integration inom kommunen. Beskriv ifall client/server-protokollet är dokumenterat och anropbart från andra håll Webblösningar hanterade av kommunen Med "hanterade av kommunen" menas lösningar som kommunen antingen själv driftar eller har en specifikt outsourcad drift för. ÖTP-GIT-20) Krav: Att lösningen är av webb-typ. ÖTP-GIT-21) Krav: Ifall lösningen är av webb-typ, att lösningen har en god och modern arkitektur. Det premieras ifall lösningen är flerskiktad och har små krav på servrar och nätverket. Beskriv dess tekniska egenskaper. Framförallt: Hur många skikt det är inklusive serverdelar, vilka de är, om SQL-klient krävs i server (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används, ifall lösningen är optimerad för att fungera i ett större WAN, andra beroenden, etc. ÖTP-GIT-22) Krav: Ifall lösningen är av webb-typ, att protokollet mellan skikten i serverlösningen är dokumenterat för köparen, till syntax och semantik på verksamhetsobjektsnivå och därmed anropbart från ev annan integration inom kommunen. Beskriv ifall protokollet är dokumenterat på detta sätt och anropbart från andra håll.

36 Sambrplform_OTP_v20.doc 36(102) ÖTP-GIT-23) Krav: Ifall lösningen är av webb-typ, att den inte ställer komplexa krav på klientmiljön utöver ren webbklient/nätbläddrare Beskriv hur klientdelen är beskaffad (Java Applet, ActiveX Control, Flash, Acrobat Reader, AJAX/JavaScript, etc), hur stor klientdelen är (ca kb, dock, räkna ej med exekveringsmotor såsom JVM), om SQL-klient i klienten krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används från klienten utöver http, ifall lösningen är optimerad för att fungera i ett större WAN, MS Office-integration, andra beroenden, etc. ÖTP-GIT-24) Krav: Ifall lösningen är av webb-typ, att den har en rik klientlösning med bättre användarvänlighet än endast html, men ändå inte är traditionell client/server. Beskriv hur klientdelen är beskaffad (Java Applet, ActiveX Control, Flash, Acrobat Reader, AJAX/JavaScript, etc), hur stor klientdelen är (ca kb, dock, räkna ej med exekveringsmotor såsom JVM), om SQL-klient i klienten krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används från klienten utöver http, ifall lösningen är optimerad för att fungera i ett större WAN, MS Office-integration, andra beroenden, etc. ÖTP-GIT-25) Krav: Ifall lösningen är av av webb-typ men ändå inte endast har en ren webbklient/nätbläddrare, att protokollet mellan klient och server är dokumenterat för köparen till syntax och semantik på verksamhetsobjektsnivå och därmed anropbart från ev annan integration inom kommunen. Beskriv ifall protokollet är dokumenterat på detta sätt och anropbart från andra håll. ÖTP-GIT-26) Krav: Ifall lösningen är av webb-typ och tänks exponeras mot publikt nät (samt t ex skolelevnät), att kraven på brandvägg är låga och inte kräver brandväggsöppningar som ger utökade risker. Beskriv därmed kraven från lösningen på brandvägg (nära server), vilka protokoll/portar yttre brandvägg måste släppa igenom i vilken riktning, vilka protokoll/portar brandvägg innanför DMZ måste släppa igenom i vilken riktning, andra DMZ-krav, etc. ÖTP-GIT-27) Krav: Att lösningen är av webb-typ, hanterad av kommunen 2.7. Webblösningar som tjänst Med "som tjänst" menas lösningar som en leverantör driftar så att inte kommunen alls behöver vara huvudman för driften (inte ens genom specifik outsourcing), utan kommunen köper endast en funktionalitet, via ett nätverk. Ofta driftas lösningen hos leverantören enligt den s k ASP-modellen (Application Service Provider) för att skalfördelar och lägre kostnader ska uppstå. ÖTP-GIT-28) Krav: Ifall lösningen är av webb-typ, som tjänst, att den inte ställer komplexa krav på klientmiljön utöver ren webbklient/nätbläddrare

37 Sambrplform_OTP_v20.doc 37(102) Beskriv hur klientdelen är beskaffad (Java Applet, ActiveX Control, Flash, Acrobat Reader, AJAX/JavaScript, etc), hur stor klientdelen är (ca kb, dock, räkna ej med exekveringsmotor såsom JVM), om SQL-klient i klienten krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används från klienten utöver http, ifall lösningen är optimerad för att fungera i ett större WAN, MS Office-integration, andra beroenden, etc. ÖTP-GIT-29) Krav: Ifall lösningen är av webb-typ, som tjänst, att den har en rik klientlösning med bättre användarvänlighet än endast html, men ändå inte är traditionell client/server. Beskriv hur klientdelen är beskaffad (Java Applet, ActiveX Control, Flash, Acrobat Reader, AJAX/JavaScript, etc), hur stor klientdelen är (ca kb, dock, räkna ej med exekveringsmotor såsom JVM), om SQL-klient i klienten krävs (i så fall vilken/vilka), om centrala file services krävs från klient, vilket client/server-protokoll som används från klienten utöver http, ifall lösningen är optimerad för att fungera i ett större WAN, MS Office-integration, andra beroenden, etc. ÖTP-GIT-30) Krav: Ifall lösningen är av av webb-typ, som tjänst, men ändå inte endast har en ren webbklient/nätbläddrare, att protokollet mellan klient och server är dokumenterat för köparen till syntax och semantik på verksamhetsobjektsnivå, och därmed anropbart från ev annan integration inom kommunen. Beskriv ifall protokollet är dokumenterat på detta sätt och anropbart från andra håll. ÖTP-GIT-31) Krav: Ifall lösningen är av webb-typ, som tjänst, att inte komplexa krav ställs på ev brandvägg nära webbklienten. Beskriv vilka krav som ställs på ev brandvägg nära webbklienten. ÖTP-GIT-32) Krav: Att lösningen är av webb-typ, som tjänst 2.8. Applikationsintegration EAI, ESB Tidigare utgåva av ÖTP tog inte med detaljer kring avancerad applikationsintegration med EAI (Enterprise Application Integration) eller ESB (Enterprise Service Bus) utan hade endast ett övergripande kapitel. I ett separat Sambruksprojekt under 2006 skapades dock en kravskrift kring Generell integration vars innehåll nu har redigerats och inkluderats i ÖTP. Se även det inledande avsnittet Översiktsarkitektur applikationsintegration generellt. Här följer en mer detaljerad översikt:

38 Sambrplform_OTP_v20.doc 38(102) Back-endintegration Applikationsintegration och EAI/ESB Front-end Adapter EAI/ESB Webbapplikation Existerande verksamhets-applikation * * * * SOAarkitektur (front-end) Extern part, myndighet etc Ev via gamla integrationsvägar eller befintlig SHS Integrationsmotor *) I moderna/vissa fall inkoppling via Web Services Ofta kallar man den användargränssnitts-nära integrationen för front-end och den bakomliggande för back-end. EAI/ESB har mest kommit att användas för back-end. Man får räkna med att back-end ofta mera har karaktären batch/asynkront och front-end mera karaktären online/synkront (ofta räcker SOA som integrationsteknik för front-end). Inom området finns en speciell samklang med SOA, förutom fokus på funktionsintegrationen i SOA-kapitlet ovan så kan även Web Services (SOA-influerat) reduceras till att bli en kommunikationsteknik där EAI-plattformen ska koppla ihop sig med omvärlden (dvs för EAI-pilarna som stjärnmärkts i figuren ovan). Man kan notera att SHS-specifikationen (se ger vissa goda ESB-egenskaper (en delmängd av typisk ESB-funktionalitet). Vissa av de aktuella SHS-produkterna implementerar mer än specifikationen kräver och tillför därmed vissa ytterligare ESBegenskaper. ÖTP-GIT-33) Krav: Att lösningen stödjer integration via sekvensiella enkla filer.

39 Sambrplform_OTP_v20.doc 39(102) ÖTP-GIT-34) Krav: Att lösningen kan använda SOA-mönstret (via Web Services) för att lämna och hämta data i anslutna applikationer. ÖTP-GIT-35) Krav: Att anropsstekniker förutom Web Services stöds, såsom Unix RPC, Java RMI, MS DCOM mfl. Ange särskilt vilka anropsstekniker som stöds och utprovats med lösningen. ÖTP-GIT-36) Krav: Att typiska kö-programvaror stöds, såsom IBM MQ, MSMQ, JMSvarianter, X.400, SMTP mfl. Ange särskilt vilka kö-programvaror som stöds och utprovats med lösningen. Se i övrigt bl a avsnitten Styrlogik samt Synkront/asynkront nedan.

40 Sambrplform_OTP_v20.doc 40(102) 2.9. SOA understött av EAI/ESB SOA och Web Services räcker ofta till som integrationsplattform i sig, framförallt när det handlar om funktionsintegration nära ett användargränssnitt - front-end-integration. Det vill säga, i stort sett alla moderna programspråk och exekveringsmiljöer har redan inbyggt stöd för att anropa eller svara på Web Services. Denna teknik bygger i grunden på webbserverteknik och bör förväntas ha mycket god skalbarhet och feltolerans samt viss loggning i sig. Vad som dock torde hända efter ett tags lyckosam lansering av många SOA-tjänster är att de blir svåra att hålla ordning på - det uppstår ett "inter application spaghetti" för SOA. Vid en viss tidpunkt är det därmed troligt att man vill införa någon lösning som kan öka hanterbarhet, övervakning, förvaltningsbarhet mm, en slags SOA-nav eller SOA-buss. Här kan en EAI/ESB-lösning vara helt rätt ansats, förutsatt att vald EAI/ESB-plattform har den exekveringssnabbhet (framförallt latenstid) som behövs ifall SOA-användningen är online. Det bör samtidigt poängteras att man vanligen inte behöver tillföra en SOA-nav/buss redan från början när antalet tjänster är få. Tack vare SOA:s betoning på meddelandekontrakt och Web Services som teknik torde det gå utmärkt att "infoga" en nav/buss först vid den tidpunkt som den verkligen tillför något. Då slipper man onödig komplexitet i tidiga skeden. SOA plus EAI/ESB, nav/buss inkl adaptrar Medborgare Företag etc EAI/ESB, nav/buss Intern EAI/ESBlogik, processtöd, översättning etc Appl för contact center E- tjänst- webb- Medborgaröverblick...anrop, återanvändning... etc... Existerande verksamhetsapplikation Registerhållande myndighet etc Katalog, e-leg / e-underskrkoll etc Behövs vanligen i alla fall en adapter till verksamhetsappl! = E-tjänstens definierade nyttomeddelanden (anrop via enkla Web Services) = Anpassnings-logik = Proprietära/specifika anrop per verksamhetsapplikation/tjänst

41 Sambrplform_OTP_v20.doc 41(102) Det bör noteras att även i detta fall så behövs inkopplingspunkterna till standardapplikationerna via adaptrar (eller i bästa fall öppna maskingränssnitt) - EAI/ESBprodukten tillför inte så mycket härvidlag för en typisk kommun. Man kan vilja bevaka att en ev adapter inte blir "inlåst" eller beroende av en specifik EAI/ESB-plattform, den bör hellre ha ett interoperabelt anropsgränssnitt i sig (vanligen Web Services). ÖTP-GIT-37) Krav: Att lösningen har specifikt optimerad funktionalitet för att kunna utgöra SOA-nav/buss, specifikt vad gäller enkel Web Services-inkoppling. ÖTP-GIT-38) Krav: Att lösningen har specifikt optimerad funktionalitet för att kunna utgöra SOA-nav/buss, specifikt vad gäller att klara online-responstid. Ange särskilt typisk storleksordning på online-responsetid (förutsättningar: synkront Web Servicesanrop används, att lämplig hårdvaruplattform används, att serverkomponent som simulerar tjänst som anropas endast innehåller logik som t ex adderar två tal, att lasten i servern i övrigt är låg). ÖTP-GIT-39) Krav: Att lösningen stöder spårbarhet och loggning för vilka applikationer som en viss applikation använder (kopplar till) och omvänt vilken som använder en viss (s k uses-information och used-by information)

42 Sambrplform_OTP_v20.doc 42(102) Processtöd Generellt om process-aspekten (Se även kapitlet Processtöd med hjälp av workflow.) Detta kapitel är tänkt att beskriva några olika fall vad gäller var verksamhetsprocess-stödet egentligen hamnar. Om man skulle utgå från ett helt vitt papper så skulle man analysera verksamhetens önskade processtöd från IT-applikationer fullständigt förutsättningslöst och dessutom fullständigt oberoende av vilka verksamhetsapplikationer man har eller som finns att tillgå, liksom dessas teknikmiljöer. Därefter skulle man mappa denna önskebild mot verksamhetsobjekt som man tänker sig finns i verksamhetsapplikationer respektive som skulle behöva nyskrivas i en e-tjänste-applikation. På grund av många orsaker (tidsramar, kostnadsramar, att tillgängliga verksamhetsapplikationer inte är modulariserade i tillräcklig grad, risk för att bli överteoretisk och aldrig komma i mål, etc) har vi hittills inte valt denna mycket höga ambitionsnivå. Istället har vi utrett önskat processtöd samtidigt som vi sneglat på det processtöd som redan existerar i form av rutiner och stöd via verksamhetsapplikationer. Därmed hopppas vi uppnå en pragmatisk optimering av genomförbarhet och god verkshöjd. Vad gäller applikationsarkikturen så skulle en tänkt mycket hög teoretisk ambitionsnivå också ha krävt tekniklösningar som i praktiken inte är trovärdiga för Sambruk, bl a vad gäller kostnad, komplexitet och inlåsningsrisk. Se vidare kapitlet Rörläggning. Tanken är alltså att försöka återanvända så mycket processtöd som möjligt ur verksamhetsapplikationerna och sedan tillföra det som eventuellt saknas (eller inte passar) i e-tjänstens webbapplikation (eller möjligen i anpassningsskiktet). Det blir här viktigt att vara säker på vad som är master för processtödet och att göra arbetsrutiner tydliga för handläggarna om det i något fall skulle bli överlappning mellan processtöds-ambitioner i verksamhetsapplikationer och e-tjänst. Detta är ju för övrigt ett normalt kompromissarbete i samband med större integrationsprojekt i IT-världen. Rent praktiskt kan det alltså tänkas att handläggarna huvudsakligen arbetar direkt gentemot sitt normala verksamhetssystem, men att vissa e-tjänst-relaterade åtgärder får utföras genom att t ex gå in i e-tjänstens webbapplikation (under högre behörighet i rollen som handläggare). I andra fall är det naturligtvis tänkbart att man väljer att inte använda ett existerande verksamhetssystem alls utan låter hela processtödet både för medborgare och handläggare finnas i en e-tjänst-applikation. För exemplet Borlängepiloten blev fallet ganska enkelt, hela processtödet för handläggarna tänks ligga i verksamhetsapplikationen (dvs idag Sofia).

43 Sambrplform_OTP_v20.doc 43(102) Integration och processer Medborgare Företag Handläggare etc Anpassningslogik enligt SOA E-tjänst Helst inte process-stöd här Ny webbapplikation Ev. processtöd Ev. processtöd Existerande verksamhets-applikation Ev. processtöd Ofta torde endast ev. tillkommande processtöd ligga här Handläggare etc Registerhållande myndighet etc Ev. processtöd I vissa fall ska man samverka med processer hos annan part Ofta torde huvudsakligt processtöd ligga här Kommentarer: Även inom anpassningslogiken skulle det kunna vara tänkbart att processtöd införs (t ex i fallet att en existerande e-tjänst i ett senare skede ska integreras med en mycket mager verksamhetsapplikation, då måste anpassningsskiktet bli extra tjockt och t o m i ogynnsamma fall behöva innehålla viss processstödslogik). Denna version av ÖTP har inget specifikt mönster för fallet att en kommun själv vill utgöra annan part åt någon aktör enligt den nedersta textbubblan i figuren, det får i så fall lösas på traditionella sätt. Rent konkret kan det i detta fall t ex behövas en större SHS-implementation ifall synkrona SHS-anrop ska kunna betjänas hos kommunen. Processtöd kan också ligga i en EAI/ESB-plattform, se separat kapitel.

44 Sambrplform_OTP_v20.doc 44(102) Processtöd med hjälp av EAI/ESB De flesta EAI-plattformarna innehåller processtöd (BPM - Business Process Management mfl namn). Här menas dels möjligheter att styra en verksamhetsprocess med hjälp av regelverk (workflow) i EAI-lösningen, dels att övervaka att processen fungerar som den ska, få varningar, nyckeltal, avstämningsstatistik etc (s k BAM). Process-stöd och EAI Adapter Back-endprocesstöd Front-end Webbapplikation Huvudsakligt front-endprocesstöd Ev. processtöd Existerande verksamhets-applikation Ev. processtöd Extern part, myndighet etc EAIintegrationsmotor Ev. processtöd I denna specifikation fokuserar vi på processtöd back-end (som naturligtvis indirekt kan tjäna även användargränssnittsnära workflow) eftersom front-end-lösningarna vanligen ligger inom andra tekniska plattformar. Icke desto mindre är det förstås viktigt att front-end- och back-end-processtöd kan agera i samklang och inte har för stora överlapp.

45 Sambrplform_OTP_v20.doc 45(102) ÖTP-GIT-40) Krav: Att processtöd i form av regelverk, verksamhetslogik etc stöds. ÖTP-GIT-41) Krav: Att lösningen kan generera grafiska bilder av flödeslogik för processtyrning och generera dokumentation av annan styrlogik. ÖTP-GIT-42) Krav: Att lösningen kan använda processexekveringsspråk såsom BPEL. Ange vilka språk. Ange om exekvering/import/export av processexekveringsspråk stöds. ÖTP-GIT-43) Krav: Att lösningen använder processexekveringsspråket BPEL. Ange vilka språk. Ange om exekvering/import/export av BPEL stöds. ÖTP-GIT-44) Krav: Att lösningen kan använda processpecifikationsspråk såsom BPMN. Ange vilka språk. Ange om exekvering/import/export av processpecifikationsspråk stöds. ÖTP-GIT-45) Krav: Att lösningen använder processpecifikationsspråket BPMN. Ange vilka språk. Ange om exekvering/import/export av BPMN stöds. Se i övrigt bl a avsnittet Styrlogik nedan.

46 Sambrplform_OTP_v20.doc 46(102) Styrlogik inom EAI/ESB Med styrlogik nedan menas definitioner för formatöversättning, processtyrning, s k statehantering, routing baserat på meddelandeinnehåll/typ, styrning av en-till-många respektive många-till-en, adaptrar, insticksmoduler, driftmiljöparametrar etc. ÖTP-GIT-46) Krav: Att styrlogik kan användas för att kontrollera integrationslösningen. Beskriv särskilt formatöversättning, XML-stöd etc, processtyrning, state-hantering, routing baserat på meddelandeinnehåll/typ, styrning av en-till-många respektive många-till-en, adaptrar, insticksmoduler, driftmiljöparametrar etc. ÖTP-GIT-47) Krav: Att s k publish/subscribe stöds inom lösningen ÖTP-GIT-48) Krav: Att egenprogrammerade moduler i något välspritt programspråk kan anropas från styrlogik under meddelandes passage genom lösningen Ange vilka anropstekniker och vilka programspråk. ÖTP-GIT-49) Krav: Att batch- eller shell-jobb e dyl som kan höra till respektive verksamhetsapplikation kan startas under kontroll av lösningen för att läsa in eller läsa ut information före/efter datagenomströmningen via lösningen Ange vilka start-tekniker, hur körningsfel hanteras etc. ÖTP-GIT-50) Krav: Att kalender-information (inkl rörliga svenska helger) lätt kan styra körningstillfällen. ÖTP-GIT-51) Krav: Att införande och idrifttagande av ändrad styrlogik i integrationslösningen kan göras under drift, att ett antal sammanhörande ändringar därmed idrifttas samtidigt och att det går att backa tillbaka ifall ändringarna varit felaktiga. Beskriv särkilt ifall ett s k configuration management-verktyg eller versionshanteringsverktyg kan användas för styrlogiken. ÖTP-GIT-52) Krav: Att lösningen har ett grafiskt användargränssnitt för definition, utveckling och testning av styrlogik.

47 Sambrplform_OTP_v20.doc 47(102) ÖTP-GIT-53) Krav: Att lösningen kan generera dokumentation för styrlogiken. ÖTP-GIT-54) Krav: Att lösningen har möjlighet för detaljerad uttestning, avlusare, stegför-steg-exekvering, variabelinspektion under testkörning etc. ÖTP-GIT-55) Krav: Att återanvändning underlättas och teknikkontrakt lätt kan hittas genom någon form av tjänstekatalog, t ex via UDDI, annan katalog och/eller webbportal Processtöd med hjälp av några enklare workflow-funktioner (Se även kapitlet Process-aspekten.) Workflow tänks utredas noggrannare längre fram i tiden, men här inkluderas ändå några specifika funktioner som det framkommit behov av under ÖTP-arbetet (samt vid utredningsarbete hos vissa kommuner). Observera också att det separata Sambruksprojektet Dokument och ärendehantering har måst göra tydliga avgränsningar eftersom deras kravmassa varit mycket stor. De fokuserar framförallt på nämndadministration och inte på ärendeflödeshantering/workflow i sig. De andra Sambrukspiloterna som funnits har framförallt sett behov av följande tre workflow-nyttigheter idag: Rollbaserad inkorg till handläggargrupp för dispatch av inkomna ärenden från e- tjänsten (i det fall inkorg inte sköts av verksamhetssystemet). Notera att själva ärendelagringen i sig dock först normalt har skett direkt via e-tjänsten mot verksamhetssystemet. Kunna ge medborgaröverblick över dennes ärenden hos kommunen Mina Engagemang. Option: Att föda liknande info till Infratjänstens Mina Sidor Hantera timeout t ex att tidsgräns passerat utan att ärende blivit handlagt eller att medborgaren missat inge komplettering. Eller kravrutin dock, lägg troligen hellre denna funktion där den hör hemma, i kundreskontran i ekonomisystemet För kommuner som inte vill investera i ett helt dokument/ärende/workflowsystem skulle man kunna tänka sig att anordna endast ovanstående tre simpla funktioner, t ex att be om offerter för nerminskade workflow-produkter, att använda någon Open Source-variant eller eventuellt att utveckla. En ännu enklare interimslösning (för endast inkorg) inkluderas även sist i kapitlet.

48 Sambrplform_OTP_v20.doc 48(102) Nyttomeddelandena ska förhoppningsvis vara så generella att webb-applikationen för e- tjänsten ska kunna bli oberoende av senare val av workflowlösning etc. Nedan följer en idé-skiss för inkorg: Inkorg för dispatch Medborgare Företag Ev handläggare etc E-tjänst Existerande verksamhets-applikation Ny webbapplikation Händelsen att ärende inkommer Alt 1 Ev inkorgsfunktion Hur får man händelseutlösning vid statusändr inne i vsh-appl? SOA. Adapterskikt. Alt 2 Workflow-motor DÄHS Meddelande till roll-kö Handläggare Status Konfigurationsparameter per kommun kan avgöra ifall händelsen ska till ev DÄHS, vsh-appl (eller båda) Medborgaröverblick Kommentar vad gäller att få händelseutlösning från existerande verksamhetsapplikationer, några lösningsalternativ: En mycket modern applikation kan tänkas ha krokar för sådana händelser (eller sådana kan tillföras på beställning) Liknande teknik som används för metakatalog-snapshot/replikering kunde tänkas Man tillför SQL-triggers i databasen (vars övriga definitioner då kan lämnas helt oförändrade) Ofta har applikationerna exportmöjligheter till flata filer. Med dessa som utgångspunkt kunde skillnads-logik köras för att få fram vilka statusändringar som skett sedan förra körningen.

49 Sambrplform_OTP_v20.doc 49(102) Nedan en idé-skiss för medborgaröverblick: Överblick för medborgaren Medborgare Företag... Medborgaröverblick (Mina Sidor, Mina Engagemang, Infratjänsten etc) E-tjänst Händelsen att ärende inkommer Meborgarens ärendeöverblick tillgängliggörs direkt eller replikerat i färdig modul till DÄHSsystemet (alternativt i specialgjord modul, eller inkluderat i e-tjänsten) Alt 1 Alt 2 Workflow-motor DÄHS SOA. Adapterskikt. Konfigurationsparameter per kommun kan avgöra ifall händelsen ska till ev DÄHS, direkt till Infratjänsten etc Alt 3 Meddelande till roll-kö Status Ny webbapplikation Medborgaröverblick

50 Sambrplform_OTP_v20.doc 50(102) Och nedan en idé-skiss för tidsutlösning (s k timeout): Timeout Fysiskt brev E-tjänst Medborgare Företag... Händelsen att ärende inkommer Medborgaröverblick (Mina Engagemang och/eller Infratjänstens Mina Sidor) Timeouter kan upptäckas inne i DÄHS och generera meddelande till handläggningsansvarig och/eller till medborgare Kravinfo från kundreskontra kan också tas in. SOA. Adapterskikt. Alt 1 Alt 2 Workflow-motor DÄHS Meddelande till roll-kö Status Ekonomisystemets kundreskontra kravrutin Betalningspåminnelse Medborgaröverblick Notifiering Ny webbapplikation

51 Sambrplform_OTP_v20.doc 51(102) Här inkluderas även en alternativ, synnerligen enkel interimslösning (efter t ex Bistånds behov) för endast inkorg: Enkel inkorg Medborgare Företag Ev handläggare etc E-tjänst Existerande verksamhets-applikation Ev inkorgsfunktion Händelsen t ex att ärende inkommer Alt 1 Meddelande till Inkorg i vsh-appl SOA Alt 2 Säkert e-postmeddelande till funktionsbrevlåda Ny webbapplikation Handläggare Konfigurationsparameter per kommun kan avgöra ifall händelsen ska till ev Inkorg i vsh-appl eller till säker e-post Kommentar: Med säker e-post menas här att meddelandena aldrig färdats i osäkra nätzoner såsom Internet utan skickas direkt till funktionsbrevlådan i kommunens interna e-postsystem. ÖTP-GIT-56) Krav: Att lösningen implementerar Inkorg för dispatch enligt figuren ovan. ÖTP-GIT-57) Krav: Att lösningen implementerar Överblick för medborgaren enligt figuren ovan. Beskriv särskilt ifall optionen Att föda liknande info till Infratjänstens Mina Sidor finns, samt dess ev tilläggspris.

52 Sambrplform_OTP_v20.doc 52(102) ÖTP-GIT-58) Krav: Att lösningen implementerar Timeout enligt figuren ovan. ÖTP-GIT-59) Krav: Att lösningen implementerar Enkel inkorg enligt figuren ovan Övrigt inom EAI/ESB Dataintegritetet/säkerhet inom EAI/ESB ÖTP-GIT-60) Krav: Att s k ACID stöds inom lösningen, dvs full dataintegritet (Atomicity-Consistency Independency-Durability) ÖTP-GIT-61) Krav: Att ACID för full dataintegritet stöds i samverkan med ansluten applikation (t ex genom köprogramvara som ger end-to-end ACID eller synkron distribuerad transaktion) ÖTP-GIT-62) Krav: Att stöd för s k långa verksamhetstransaktioner (long running transactions) finns ÖTP-GIT-63) Krav: Att lösningen har stöd för säkerhetskopiering (och motsvarande återläggningsrutiner) samt att lösningen utformas så att inte information blir inkonsistent efter återläggning. Beskriv på vilket sätt, versionskrav, ifall data skyddas även emellan säkerhetskopieringstillfällen (ibland kallat deltalogg/transaktionsjournal), ifall data skyddas även mot operatörsmissgrepp (då räcker t ex inte spegling), specifikt kring ev kombination av säkerhetskopiering av relationsdatabas-data och file server-data ifall dessa data är logiskt kopplade till varann, samt ev mer detaljerade krav från lösningen. Vad gäller kryptering/sigillering, se även avsnittet Informationsöverföring. ÖTP-GIT-64) Krav: Att stöd finns för kryptering för anslutningspunkter/kommunikationslänkar (t ex https inklusive certifikatshantering för båda ändar etc)

53 Sambrplform_OTP_v20.doc 53(102) ÖTP-GIT-65) Krav: Att stöd finns för kryptering för insynsskydd end-to-end för applikationsdata (dvs mellan-noder ska inte nå datat) ÖTP-GIT-66) Krav: Att stöd finns för sigillering för manipulationsskydd end-to-end för applikationsdata (dvs mellan-noder ska inte nå datat) ÖTP-GIT-67) Krav: Att stöd finns för server-autentisering och -auktorisation dvs att en viss server/applikation/integrationsnod kan identifiera sig för en annan server/applikation/integrationsnod och få tillåtelse att kommunicera (t ex https inklusive certifikatshantering för båda ändar eller andra metoder) Statistik/BAM mm inom EAI/ESB ÖTP-GIT-68) Krav: Att automatisk logg förs med inställbar detaljering över transporterade meddelanden/anrop. ÖTP-GIT-69) Krav: Att driftsstatistik över transporterade meddelanden/anrop skapas. ÖTP-GIT-70) Krav: Att BAM (Business Activity Monitoring) stöds för att få verksamhetsstatistik och nyckeltal ur styrlogiken tillsammans med transporterat data ÖTP-GIT-71) Krav: Att stöd för Standardmeddelanden (se finns förberett/stöds i EAI/ESB-lösningen ÖTP-GIT-72) Krav: Att SHS-trafik stöds, direkt i lösningen eller som option. (Se Beskriv också ifall lösningen kräver annat tjänsteköp för att fungera (tex ev agent-mot-centrallösningar)

54 Sambrplform_OTP_v20.doc 54(102) Synkront/asynkront inom EAI/ESB ÖTP-GIT-73) Krav: Att asynkron meddelandeförmedling stöds ÖTP-GIT-74) Krav: Att synkron meddelandeförmedling stöds ÖTP-GIT-75) Krav: Att synkrona anrop med svarsparametrar stöds (att betrakta som funktionsanrop) Prestanda/tillgänglighet inom EAI/ESB Se även generella formuleringar (som ej är specfika för EAI/ESB) i avsnittet Användbarhet nedan ÖTP-GIT-76) Krav: Prestandascenario A: Att låg latenstid för onlinefallet (front-end-integration) stöds, dvs att synkront anrop eller asynkron fråga+svar med minimal styrlogik maximalt tar 3 sekund i dygnsgenomsnitt för 90% av anropen, från sista IP-paket i begäran till första i svar, mätt strax utanför lösningens server. Samtidigt att 20 anrop/sekund klaras av med det minimala meddelandetestscenariot bestående av XML med två textvariabler som ska slås ihop till en. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget. ÖTP-GIT-77) Krav: Prestandascenario B: Att hög genomströmning av data för back-offie-integration stöds, dvs att asynkron meddelandeförmedlning klarar 100 kbyte XML-data per sekund i dygnsgenomsnitt för 90% av anropen. XML-datat kan vara enkel till sin struktur, men två XML-textvariabler som meddelandetestscenario ska slås ihop till en. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget. ÖTP-GIT-78) Krav: Tillgänglighetsscenario A: Teknisk tillgänglighet med minst upptid 99,5% räknat räknat i medeltal över sämsta vecka. Driftnertagning på max en timma må ske per efternatt utan att räknas in i tillgänglighetssiffran, för t ex säkerhetskopiering. Beskriv resulterande tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget.

55 Sambrplform_OTP_v20.doc 55(102) ÖTP-GIT-79) Krav: Tillgänglighetsscenario B: Teknisk tillgänglighet med minst upptid 99,9% räknat i medeltal över sämsta vecka. Driftnertagning på max en timma må ske per efternatt utan att räknas in i tillgänglighetssiffran, för t ex säkerhetskopiering. Beskriv resulterande tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget. ÖTP-GIT-80) Krav: Tillgänglighetsscenario C: Teknisk tillgänglighet med minst upptid 99,5% räknat i medeltal över sämsta vecka, dock räknas tillgänglighetssiffran endast över dagdrift kl 07:00 till 22:00. I övrigt gäller s k best effort, dvs lösningen är normalt igång, men får tas ner för serviceåtgärder. Beskriv resulterande tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget Förpackade integrationer inom EAI/ESB ÖTP-GIT-81) Krav: Att färdiga integrationslösningar (inkl styrlogik, adaptrar etc) gentemot typiska kommunala verksamhetsapplikationer ingår eller kan tillhandahållas som option. Beskriv vilka integrationer som finns översiktligt och deras villkor. Beskriv äganderätten till ev källkod som ingår. ÖTP-GIT-82) Krav: Att färdiga integrationslösningar (inkl styrlogik, adaptrar etc) gentemot typiska verksamhetsapplikationer (ej specifikt kommunala) ingår eller kan tillhandahållas som option. Beskriv vilka integrationer som finns översiktligt och deras villkor. Beskriv äganderätten till ev källkod som ingår. ÖTP-GIT-83) Krav: Att färdiga teknikadaptrar för datakommunikationsanpassningar till anslutande system följer med i lösningen. Beskriv på vilka sätt, versionskrav, samt ev mer detaljerade krav från lösningen. ÖTP-GIT-84) Krav: Att färdig/förberedd styrlogik för olika EDI, Svefaktura etc finns medskickad eller som option. Beskriv vilka sådana som finns översiktligt och deras villkor. Beskriv äganderätten till ev källkod som ingår Stöd mm inom EAI/ESB ÖTP-GIT-85) Krav: Att lösningen inkluderar dokumentation för utvecklare, driftpersonal och säkerhetspersonal. Beskriv dokumentationen översiktligt.

56 Sambrplform_OTP_v20.doc 56(102) ÖTP-GIT-86) Krav: Att lösningsleverantören tillhandahåller utbildning för utvecklare, driftpersonal och säkerhetspersonal Beskriv utbildningen översiktligt. ÖTP-GIT-87) Krav: Att lösningsleverantören tillhandahåller konsultstöd för driftsättning, utveckling av styrlogik och adaptrar etc. Beskriv konsulterbjudandet översiktligt.

57 Sambrplform_OTP_v20.doc 57(102) Mönster för batchuppdatering För många e-tjänster blir det naturliga att online hämta information via Nyttomeddelanden (från en adapter mot verksamhetssystem). Detsamma gäller för uppdateringar. Därmed kan användbarhet/ergonomi och både medborgarnytta och verksamhetsnytta inom kommunen bli hög (se även kapitlet E-blankett vs interaktiv webbapplikation). I andra sammanhang är det inte lämpligt med online-koppling bakom e-tjänsten. Det kan t ex röra sig om en e-tjänst med stor anstormning av användare vid speciellt tidpunkt (ungefär som e-deklarationen har årsvis eller Internetbankerna har vid månadsskifte) där det inte är rimligt att dimensionera driftmiljön till bakomliggande verksamhetssystem för denna höga last. Det kan röra sig om verksamhetssystem där det inte av olika skäl blir genomförbart att anordna en online-adapter. Det kan handla om att man skulle få hårda beroenden till ett större antal samtidiga online-källor vilket försämrar chansen till god total stabilitet. Det kan också handla om att verksamhetslogiken behöver snapshot-data från en specifik tidpunkt (så är fallet för vissa kopplingar till Bistånd). I fall då online-koppling inte är lämplig behöver information överföras tidvis och satsvis, det som brukar kallas batch. Det kan vara värt att nämna att Sambruk inte specifikt berör alla de befintliga batchkopplingar som finns för verksamhetssystemen i en typisk kommun (dessa hanteras ofta med Decapus, SHS eller liknande lösningar). Sambruk fokuserar istället på e-tjänster mot medborgare/företag/föreningar etc. Däremot kan vi behöva hantera ett mönster där kommunicerande part ändå är en verksamhetsapplikation och där vi behöver tillföra ett batch-flöde för att överhuvudtaget kunna förverkliga en e-tjänst, se följande skiss:

58 Sambrplform_OTP_v20.doc 58(102) Existerande verksamhetsapplikation Batchuppdatering E-tjänst SOA Ev. återanvändning av skapat Nyttomeddelande 2 1 = Filöverföring, SHS, Web Service, direktanrop etc = Nyttomeddelanden enligt SOA via Web Services Ny webbapplikation Registerhållande myndighet etc Tvådelad adapter (med exponerat nyttomeddelandegränssnitt mitt i) Observera att batchadaptern delas i två halvor som åtskiljs av Nyttomeddelande(n) mitt i. Därvid syftar till en ökad öppenhet och återanvändningspotential. Det är dock värt att notera att även om ett Nyttomeddelande återfinns som återanvändningskandidat så kan fortfarande andra implementationsskillnader förekomma, t ex synkront/asynkront (se Kommunikationsprofiler). Det är också värt att notera att man bör väga ovanstående konstruktion mot kostnad/nytta/inlåsning med en lösning som Decapus, BizTalk eller motsvarande. Om man redan använder en sådan lösning kan marginalkostnaden att tillföra ett nytt flöde vara låg. Hybrider är också tänkbara där Decapus etc skulle kunna sköta en andel av arbetet hos någon av adapterhalvorna. För tydlighets skull följer en skiss som visar fallet när det inte är lämpligt (eller går) att kommunicera med verksamhetsapplikationen, utan istället en mycket fet adapter tyvärr måste skapas (vilken innehåller databas):

59 Sambrplform_OTP_v20.doc 59(102) Existerande verksamhetsapplikation Batchuppdatering (alternativ) E-tjänst SOA Mycket fet adapter (inkluderar databas) 1 2 = Filöverföring, SHS, Web Service, direktanrop etc = Nyttomeddelanden enligt SOA via Web Services Ny webbapplikation Registerhållande myndighet etc Tvådelad adapter (med exponerat Nyttomeddelandegränssnitt mitt i) ÖTP-GIT-88) Krav: Att batchuppdatering utförs i enlighet med mönstret i föregående bild och är tvådelat med ett öppet Nyttomeddelandegränsnitt emellan. Beskriv utbildningen översiktligt. Beskriv särskilt ifall adapter inkluderar databas.

60 Sambrplform_OTP_v20.doc 60(102) Webb-integration En av de stora utmaningarna är att få delar som är utvecklade på olika håll och i olika tekniker att uppföra sig på ett enhetligt sätt gentemot webb-användaren. Medlemskommunerna har valt helt olika tekniker för sina huvud-webbar (olika content management-system CM, olika teknikplattformar). Olika stuprörssystem som redan har webb-gränssnitt är också utförda på helt olika sätt. Det klassiska är också att vissa webblösningar kanske kan tänkas inkludera information från andra webbar (vara master ), men få brukar vara förberedda att inkluderas (vara slav ). Webb-integrationen (eller yt-integrationen som man också kan kalla det) har ett antal olika aspekter: Ett eller flera webb-fönster Ska de olika delarna samsas i samma fönster eller är det godtagbart att andra fönster startas hos användaren? Form och färg Kommunens form-profil ska användas i de olika delarna S k WAI-anpassning för funktionshindrade Kan t ex fungera sämre vid användning av s k frames. Driftbarhet på olika ställen T ex ska Sambruks e-tjänster kunna samdriftas, medan kommunens huvud-webb ofta driftas i egen regi eller i annan outsourcing. Sammanhållen inloggning single signon (SSO) Ska användaren automatiskt vara inloggad i de olika delarna om man redan är inloggad i en del, eller kan det krävas ny inloggning? Se separat kapitel. Sammanhållen katalog Även om inte SSO skulle stödjas, att slippa komma ihåg olika användarnamn/lösenord etc till olika webb-delar. Se separat kapitel. mm mm För samtliga aspekterna måste man göra en bedömnning av ambitionsnivå där man beaktar faktorer som nytta, kostnad, inlåsning/öppenhet, komplexitet och kalendertid. Teknikläget för webb-integration är tyvärr inte tillfredsställande idag. Inom Java-världen finns det en standard som kallas portlets och som är till för att t ex en e-tjänst ska kunna sticka fram sitt användargränssnitt under kontroll av en huvud-webb (portal server). Emellertid finns det oss veterligen inga sådana portlets ingående i verksamhetsapplikationer för kommuner idag, till stor del eftersom få av dem är skrivna i Java. Microsoft har ett liknande koncept som heter webparts och som används i deras Sharepoint Portal Server. Dock är detta på motsvarande sätt som för Java begränsat till Microsofts utvecklingsmiljöer. Inte heller här känner vi till att det finns färdiga sådana webparts för verksamhetsapplikationer idag. Det finns en ansats som heter WSRP som är tänkt att kunna länka ihop de här inkompatibla teknikmiljöerna bl a så att en portlet-portal ska kunna visa upp info från en webpart och vice versa. I dagsläget verkar det dock oklart hur stort stöd denna standard verkligen får i

61 Sambrplform_OTP_v20.doc 61(102) praktiken. Eftersom ÖTP bör vara konservativt vad gäller nya standarder och endast använda brett spridda och väl beprövade tekniker så är vi än så länge avvaktande. Området bör dock bevakas. I nedanstående skiss visas ett antal tänkbara alternativ för webb-integration som alla har föroch nackdelar. Vad bilden framförallt vill visa är att det trots allt finns lösningar som går att använda redan idag, även om de inte är så eleganta som portlets/webparts/wsrp skulle varit om detta varit mer öppet, väl beprövat och väl spritt. På sikt kan dock dessa tekniker vara mycket intressanta. Några alternativ för yt-integration med CM & e-tjänster Förhoppningsvis single signon Kund Företag Handläggare etc Externa tjänster Huvud-webb (CM) Huvud-webb (CM) e- tjänstdel Huvud-webb (CM) e- tjänstdel Huvud-webb (CM) e- tjänstdel Händelser Enkel länk till annan webb-app e-tjänst webb-app Lev X In-framead webb-app Portlet (begr. t. end. Java), webpart (begr. t. end Share- Point) Lev Y... helst web services här... Ny webbkod som anropar underliggande skikt Här flödar rådata eller presentations- XML etc. Ev baserat på html-proxy Sändning av händelser map kunden Verksamhetsappl-skikt Lev X Verksamhets - appl-skikt Verksamhets - appl-skikt Lev Y Verksamhets - appl-skikt Användarkatalog alternativa varianter Sambruk kan avvakta till att vi får offerter för att anordna e-tjänster för pågående piloter och därmed få förslag från leverantörerna. Emellertid är det troligt att vi på grund av den dåliga tekniska standardiseringen får tänka oss ett av de två vänstra alternativen, kanske allra mest troligt det vänstra (för att ändå minimera ett antal tänkbara tekniska krångligheter som också följer av att Sambruks e-tjänster ska kunna samdriftas rationellt s k ASP-drift).

62 Sambrplform_OTP_v20.doc 62(102) ÖTP-GIT-89) Krav: Ifall lösningen är av webb-typ: Att lösningens webbplats enkelt kan länkas till från kommunens andra webbplatser, och att därmed lösningen både ska kunna utgör ett nytt separat fönster och alternativt iframe/frame. Beskriv hur denna användargränssnittsintegration utformas. ÖTP-GIT-90) Krav: Ifall lösningen är av webb-typ: Att lösningens användargränssnitt enkelt kan infogas i kommunens andra webbplatser, utan att lösningen utgör ett nytt separat fönster (t ex som MS webpart, Java portlet, iframe/frame etc). Beskriv hur denna användargränssnittsintegration utformas. ÖTP-GIT-91) Krav: Ifall lösningen är av webb-typ: Att lösningens användargränssnitt kan förses med kommunens logotyp, minst på startsida el motsv. Beskriv hur detta utformas. ÖTP-GIT-92) Krav: Att det går att göra enklare anpassningar av färg och form till respektive kommuns stilstandard, t ex kommunlogga och CSS (style sheet) Webbpublicering Kommentar: De flesta specifika kraven på webbpubliceringsverktyg är funktionella och tas därmed inte upp här. ÖTP-GIT-93) Krav: Att webbpubliceringsverktyget har en inbyggd publicerings- och uppdaterings-lösning emellan användargränssnittet för webbpubliceraren och webbserver. ÖTP-GIT-94) Krav: Att webbpubliceringsverktyget har en säker publicerings- och uppdaterings-lösning emellan användargränssnittet för webbpubliceraren och webbserver, som inte kräver osäkra öppningar i brandvägg. ÖTP-GIT-95) Krav: Att webbpubliceringsverktyget har en säker publicerings- och uppdaterings-lösningsom har inbyggt stöd för mellanpublicering, s k staging, där webbsidorna bl a kan testas innan de tas i skarp drift.

63 Sambrplform_OTP_v20.doc 63(102) Användbarhet Användbarhetsområdet är egentligen mycket stort. Här infogas några grundläggande krav. Ifall ett anskaffande behöver så får man tillföra mer detaljerade krav i icke-funktionellt kravdokument etc Generellt ÖTP-GIT-96) Krav: Ifall lösningen är av webb-typ: Att lösningen stödjer de vanligaste webbläsarna (av nyare versioner), t ex Internet Explorer, Firefox, Opera, Safari. Beskriv vilka webbläsare och versioner som stöds ÖTP-GIT-97) Krav: Ifall lösningen är av webb-typ: Att lösningen följer "Vägledningen 24-timmarswebben", Beskriv hur vägledningen följs och hur detta verifierats. ÖTP-GIT-98) Krav: Att lösningen skall gå att använda även om användarens bildskärm har upplösning så låg som 800x600, samt att lösningen ska fungera mycket väl i högre upplösning än så Korrekt webbkodning ÖTP-GIT-99) Krav: Ifall lösningen är av webb-typ: Att lösningens webbplatser tillämpar W3C:s riktlinjer för webbkodning såsom det uttrycks på validator.w3.org samt jigsaw.w3.org/css-validator. Beskriv hur riktlinjer för webbkodning följs och hur de verifierats Tillgänglighet/anpassning för funktionshindrade ÖTP-GIT-100) Krav: Ifall lösningen är av webb-typ: Att lösningens webbplatser tillämpar W3C/WAI:s riktlinjer, prioritet 1. Beskriv vilken WAI-anpassning som följs och hur den verifierats Tillgänglighet/upptid (Se även specifikt avsnitt om EAI/ESB) ÖTP-GIT-101) Krav: Tillgänglighet alternativ A: Teknisk tillgänglighet minst kl 07-22, då med upptid 99,5% räknat i medeltal över sämsta vecka, plus övrig tid s k best effort dvs lösningen är normalt igång, men får tas ner för serviceåtgärder.

64 Sambrplform_OTP_v20.doc 64(102) Beskriv tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget. ÖTP-GIT-102) Krav: Tillgänglighet alternativ B: Teknisk tillgänglighet minst kl 06-24, då med upptid 99,5% räknat i medeltal över sämsta vecka, plus övrig tid s k best effort dvs lösningen är normalt igång, men får tas ner för serviceåtgärder. Beskriv tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget. ÖTP-GIT-103) Krav: Tillgänglighet alternativ C: Teknisk tillgänglighet minst kl 04-03, då med upptid 99,5% räknat i medeltal över sämsta vecka, plus övrig tid s k best effort dvs lösningen är normalt igång, men får tas ner för serviceåtgärder. Beskriv tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget. ÖTP-GIT-104) Krav: Tillgänglighet alternativ D: Teknisk tillgänglighet minst kl 04-03, då med upptid 99,9% räknat i medeltal över sämsta vecka, plus övrig tid s k best effort dvs lösningen är normalt igång, men får tas ner för serviceåtgärder. Beskriv tillgänglighet/upptid hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget Prestanda (Se även specifikt avsnitt om EAI/ESB) ÖTP-GIT-105) Krav: Att lösningen har prestanda enligt följande (m a p serverprestanda): Svarstid från sista paket i http-begäran till första i svar, mätt strax utanför leverantörens brandvägg: Att i dygnsgenomsnitt 90% av anropen har svarstid mindre än 3 sek. Gäller både användargränssnitt samt ev maskingränssnitt. Beskriv prestanda hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget (med ett antagande om 100 samtidigt inloggade användare el motsv. ÖTP-GIT-106) Krav: Att lösningen har prestanda enligt följande (m a p "tunga" sidor): Svarstid från http-begäran till komplett web-sidöverföring via modem på 56 kb/s anslutet strax utanför leverantörens brandvägg: Att i dygnsgenomsnitt 90% av anropen har svarstid mindre än 30 sek. Beskriv prestanda hos lösningen. Beskriv typisk ungefärlig dimensionering av serverhårdvara och servermjukvara för att klara detta krav i dagsläget (med ett antagande om 100 samtidigt inloggade användare el motsv).

65 Sambrplform_OTP_v20.doc 65(102) Sammanhållen inloggning/användarkatalog Sammanhållen inloggning single signon (SSO) och användarkatalog är två viktiga och svåra teknikområden (ibland tyvärr också kostnadsdrivande). Sambruks ansats i detta läge är att ha en något konservativ attityd eftersom området både är snårigt och kostsamt. Vi kan därmed inte ha ambitionsnivån att klara SSO gemensamt med alla de tänkbara webbinloggningar som kommunerna redan idag har eller skaffar, var för sig. Däremot måste ansatsen vara att alla nya e-tjänster som tillverkas efter nuvarande specifikationsfas ska ha chans till SSO, enligt nedanstående skiss: Inloggning/ katalog E-tjänst Medborgare Företag Handläggare etc Vid inloggning anropas eid och/eller ÖTP-katalog Adapter Ev kan katalog/rollinfo finnas här också och nås via adaptern t ex i Sofia Existerande verksamhetsapplikation Ny webbapplikation Handläggare etc Synkronisering med andra kataloger inom kommunen eid: e-leg / e-underskrkoll etc ÖTP-katalog LDAP Ev metakatalogprodukt Det är värt att poängtera att SSO och integrerad (eller synkroniserad) användarkatalog är två separata frågor att ta ställning till från fall till fall. SSO kan i vissa fall tänkas utföras utan integrerad/synkroniserad användarkatalog liksom att det sistnämnda utan SSO trots allt ger

66 Sambrplform_OTP_v20.doc 66(102) en stor bekvämlighetsökning för medborgaren genom att man endast behöver hålla ordning på en omgång användarnamn/lösenord (även om man måste logga in upprepat). Den äldre Borlängepiloten för Bistånd har verksamhetskrav på eid-inloggning, liksom att roll-info ligger i verksamhetsapplikationerna. De nyare piloterna har däremot endast verksamhetskrav på användarnamn/lösenord varför SSO ändå inte skulle göra nytta gentemot Bistånd. I fallet SSO kan vi inom den närmaste framtiden välja två ansatser: Att låta utveckla e- tjänsterna webb-applikationer för samma teknikplattform varvid denna torde klara SSO. Nackdelen bleve att lägga flera ägg i en korg. Ska man med disparata teknikmiljöer ändå klara SSO får man skapa ett sätt att skicka med credentials emellan applikationerna. Flera sådana sätt finns tillgängliga även om de medför ett visst krångel. En ytterligare anledning till att inte i dagsläget göra dyra åtaganden vad gäller stora SSOprodukter är att teknikutvecklingen fortgår relativt snabbt. Mekanismer som SAML, Passport, Live ID förs fram samt vidareutvecklingen av operativsystem mm pågår. Området bör alltså bevakas noga. ÖTP-GIT-107) Krav: Att lösningen är förberedd så att s k single signon (SSO) kan tillföras. Detta gäller helst på båda sätten, dvs dels att lösningen kan vara master där inloggnin först sker och annan webb ska kunna ärva inloggningen, dels att lösningen ska kunna vara slav och överta en redan gjord inloggning i annan webb. Beskriv på vad sätt lösningen uppfyller detta. ÖTP-GIT-108) Krav:Att lösningen är klar specifikt för SSO enligt standarden SAML. Detta gäller främst så att e-tjänsten ska kunna vara "slav" under annan inloggning/autentisering, t ex kommunhuvudwebb. Det ska gå att med konfigurationsparameter definiera ifall denna mekanism ska användas, per kommun i ASP-fallet (sista utväg är vanligt användarnamn/lösenord). Beskriv SAML-implementationen, SAML-version mm. ÖTP-GIT-109) Krav:Att lösningen är klar specifikt för SSO enligt standarden SAML. Detta gäller främst så att e-tjänsten ska kunna vara "master" över annan inloggning/autentisering, t ex del i kommunwebb. Det ska gå att med konfigurationsparameter definiera ifall denna mekanism ska användas, per kommun i ASP-fallet (sista utväg är vanligt användarnamn/lösenord). Beskriv SAML-implementationen, SAML-version mm. ÖTP-GIT-110) Krav: Att SSO-stöd skall ingå i lösningens roadmap för de närmaste tre åren. Beskriv kort er strategi för SSO i framtiden Katalog

67 Sambrplform_OTP_v20.doc 67(102) ÖTP-GIT-111) Krav: Att lösningen använder MS Active Directory Beskriv på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. ÖTP-GIT-112) Krav: Att lösningen använder Novell edirectory 8.8. Beskriv på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. ÖTP-GIT-113) Krav: Att lösningen använder Novell edirectory Beskriv på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. ÖTP-GIT-114) Krav: Att lösningen använder Active Directory 2003 aktivt och online, hellre än att katalogdata importeras. Kan export i så fall även ske? ÖTP-GIT-115) Krav: Att lösningen använder Novell edirectory 8.8 aktivt och online, hellre än att katalogdata importeras. Kan export i så fall även ske? ÖTP-GIT-116) Krav: Att lösningen använder Novell edirectory aktivt och online, hellre än att katalogdata importeras. Kan export i så fall även ske? ÖTP-GIT-117) Krav: Att lösningen stödjer katalog enligt LDAP v3. Beskriv på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. ÖTP-GIT-118) Krav: Att lösningen använder katalog enligt LDAP v3 aktivt och online, hellre än att LDAP-data importeras. Kan export i så fall även ske? Metakatalog Med metakataloglösningar menas här programvara som möjliggör synkronisering och replikering av data om användare, roller mm.

68 Sambrplform_OTP_v20.doc 68(102) ÖTP-GIT-119) Krav: Att lösningen har färdigt stöd för metakataloglösningar. Beskriv vilka metakataloglösningar (t ex MIIS, edirectory) på vilket sätt, versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. ÖTP-GIT-120) Krav: Att lösningen har stöd för metakataloglösningar utformat enligt ÖTP:s mönster för Nyttomeddelanden och anpassningslogik/adaptrar. Detta innebär att metakataloglösningen inte ansluter direkt till ett verksamhetssystem vars katalog ska integreras, utan en adapter tillförs som översätter till Nyttomeddelande enligt avsnitt Principer för Nyttomeddelanden. Se även avsnitten Olika behov av anpassningslogik mot verksamhetsapplikation samt Mönster för batchuppdatering. Beskriv lösningen för metakatalog relativt kravet på Nyttomeddelanden och adadptrarm versionskrav, samt ev mer detaljerade krav från lösningen. ÖTP-GIT-121) Krav: Att lösningen har färdigt stöd för att leverera ändringshändelser till metakataloglösningar så att metakataloglösningen slipper ta snap-shot och jämföra med föregående tillfälle). Beskriv kort hur händelsehantering är itförd, om endast vissa metakataloglösningar stöds (t ex MIIS, edirectory), versionskrav, vilket data (t ex användarnamn, lösenord, roller, grupptilhörigheter mm) samt ev mer detaljerade krav från lösningen. ÖTP-GIT-122) Krav: Att lösningen har färdigt stöd för synkronisering av lösenord via LDAP Befolkningsregister ÖTP-GIT-123) Krav: Att lösningen har koppling till något befolkningsregister för att få in uppdateringar eller göra kontroller, t ex för bostadsadress, folkbokföringsort etc.. Beskriv på vilket sätt, om det är indirekt via någon kommersiell tjänst, samt ev mer detaljerade krav från lösningen.

69 Sambrplform_OTP_v20.doc 69(102) Notifiering Med notifiering menas här att skicka någon slags meddelande till en medborgare som innebär att en status som är relevant för medborgaren har förändrats, t ex att handläggningsbeslut i ett ärende nu är fattat. Notifiering kan tänkas skickas via osäkra kanaler varför ingen känslig information ska inkluderas i meddelandet i sig i sådana fall är notifieringen endast en signal om att medborgaren bör logga in i e-tjänsten och där på ett tillräckligt säkert sätt kunna ta del av statusändringen. Typiska kanaler idag är vanlig e-post och SMS till mobiltelefon. I många fall kan det vara önskvärt att notifieringstexten innefattar en URL till e-tjänsten. Se även kapitlet Processtöd med hjälp av workflow. Notifiering Medborgare Företag Handläggare etc E-tjänst Adapter Vid statusändring som uppstår direkt i e-tjänsten Ny webbapplikation Handläggare etc T ex: e-post SMS Existerande verksamhetsapplikation Notifieringssändare Vid statusändring som uppstår på annat håll (kan dock vara oklart hur man får ut denna info ur sluten verksamhetsapplikation) Se även workflow.

70 Sambrplform_OTP_v20.doc 70(102) ÖTP-GIT-124) Krav: Att en sammansatt notifieringslösning enligt föregående bild ingår. ÖTP-GIT-125) Krav: Att en enkel notifieringslösning genom e-post ingår. ÖTP-GIT-126) Krav: Att en enkel notifieringslösning genom SMS ingår. ÖTP-GIT-127) Krav: Att kommunanställd/handläggare kan få händelseinformation via kommunens generella ärendehanteringssystem då verksamhetsaktiviteter sker i lösningen. Att person kan slå på/av denna notifiering. Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc ÖTP-GIT-128) Krav: Att medborgare, företagare etc kan få händelseinformation via kommunens generella ärendehanteringssystem då verksamhetsaktiviteter sker i lösningen. Att person kan slå på/av denna notifiering. Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc ÖTP-GIT-129) Krav: Att lösningen har en specifik teknisk anpassning för notifiering/avisering gentemot ärende/workflow-systemet WM-Data LEX (t ex vid.händelser som etablering av rekryteringsärende, avslutande av rekryteringsärende och inkommen jobbansökan). Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc. ÖTP-GIT-130) Krav: Att lösningen har en specifik teknisk anpassning för notifiering/avisering gentemot ärende/workflow-systemet Formpipe W3D3 (t ex vid.händelser som etablering av rekryteringsärende, avslutande av rekryteringsärende och inkommen jobbansökan). Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc. ÖTP-GIT-131) Krav: Att lösningen har en specifik teknisk anpassning för notifiering/avisering gentemot ärende/workflow-systemet EBI Platina (t ex vid.händelser som etablering av rekryteringsärende, avslutande av rekryteringsärende och inkommen jobbansökan). Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser för vilka aktörer etc.

71 Sambrplform_OTP_v20.doc 71(102) ÖTP-GIT-132) Krav: Att lösningen har en specifik anpassning för händelser i lösningen som är av karaktären att de enligt kommunalt regelverk/lag ska diarieföras. I detta fall gentemot kommunens valda system för diarium. Beskriv på vilket sätt, hur integrationen går till, notifiering för vilka händelser etc.

72 Sambrplform_OTP_v20.doc 72(102) E-blankett vs interaktiv webbapplikation Detta avsnitt handlar främst om avvägningen mellan pappersblankett-efterliknande lösningar och mer interaktiva webbapplikationer (i stil med Internetbanker och webbutiker). Det kan vara värt att tydliggöra möjligheterna att i varierande grad uppfylla verksamhetskrav på effektivitet och nytta, liksom hur väl man kan betjäna medborgaren. Problembild vid alltför simpla formulär o Trol ej anpassning av användardialog successivt efter vad som tidigare kryssats i (dvs logiskt döda fält fortfarande ifyllbara) o Trol ej presentation av strikt korrekta värdeförråd (t ex drop-down-listor) vem ska översätta fritt inmatat Gymnasiet i Lidköping eller De la Gardieskolan till Lidköpings gymnasium som det står i databasen, ger risk för manuellt extraarbete o Trol ej verksamhetslogik som tätt samverkar med användargränssnittet o Trol ej stark indatavalidering, risk för många kompletteringar Blankettarkiv E-blankett Webbblankett Interaktiv webbapplikation Endast blanketter för utskrift och ifyllnad med penna Relativt snabbt och billigt att införa. Ibland blanketthotell. Ofta verkligt dålig indata-validering, komplicerat ordna förifyllnad eller online-validering. Ibland krångliga produkter som Acrobat. Viss likhet med e-blankett. Ofta tjänste-hotell. Eventuell förifyllnad, eventuell bättre validering. Inlåsning i verktyg. Html istället för t ex Acrobat. Kan ge tät koppling med verksamhetsapplikation Kan ge god användbarhet/ ergonomi. Html. Kan ge högre införandekostnad. Dyrare förvaltning. Ökande indata-kvalitet, förbättrad intern effektivitet och höjd medborgarnytta

73 Sambrplform_OTP_v20.doc 73(102) Interaktiv webb-appl vs andra källor Interaktiv webb-appl Stark datavalidering E-blanketter Andra källor Skanning Ev länkning Verksamhetsapplikation (el workflow) Mottagning Grov indatakontroll Grov felkomplettering Handläggning steg 1 (ev annan komplettering)... Handläggning steg n Beslut Meddela beslutet Mina Sidor Utskick Brev, e-post etc Kommentarer till ovanstående bild: Den högra varianten med tratten är den som brukar förekomma inom stora statliga verk etc. Dock riskerar man där att missa indata-kvalitetsproblemet, att ärendehandläggning kan bli så oerhört mycket effektivare ifall data verkligen är korrekt och antalet kompletteringar kan hållas lågt eller obefintligt. T ex ifall en e-blankett-lösning innehåller viss validering så kastar man ner den högre kvaliteten i samma röra av skannade blanketter med mycket lägre datakvalitet. En interaktiv webb-appl som har en stark indatavalidering (jmf Internetbank) har mycket större möjlighet att lågt kompletteringsbehov, men så måste också det datat föras in på rätt kvalitetsnivå i handläggningsstegen. Vissa legala aspekter måste tillgodoses. Även om en Internetbank kan ha gjort sig av med blankett/dokument/ärende-begreppet fullständigt kan en kommun t ex behöva lagra undan en ärendelogg där exakt utseende på ifylld ansökan etc i undantagsfall ska kunna sökas fram vid efterhandsutredning. Inom Sambruk fokuserar vi hittills på interaktiva webb-applikationer men vi måste också i framtiden hitta mönster för att avgöra när en viss ärendetyp förtjänar en investering i en avancerat interaktiv e-tjänst, eller när det totalt sett blir vettigare med en enklare lösning. Troligen ska frekventa ärendetyper hanteras med mer avancerade lösningar, medan sällanärenden kanske får tas om hand med e-blanketter e dyl.

74 Sambrplform_OTP_v20.doc 74(102) Vad som anskaffas/upphandlas/anordnas Många sätt kan tänkas för att anskaffa/upphandla/anordna leverans av behövd mjukvara för e-tjänster och Öppen teknisk plattform. Här ska endast nämnas lite kort om några tänkbara gränsdragningar för beställning. Med ordet anordna förstås här även andra varianter än köp från en normal IT-leverantör eller IT-konsult, det kan röra sig om olika sorters Open Source, egen programutveckling driven inom Sambruk (eller inom en kommun) etc. Vad som upphandlas (anordnas) IT-infrastruktur måste väljas E-tjänst IT-infrastruktur måste väljas Existerande verksamhetsapplikation IT-infrastruktur måste väljas Ny webbapplikation Registerhållande myndighet etc e-leg / e-underskrkoll etc IT-infrastruktur måste väljas Ovalerna i figuren ovan motsvarar respektive upphandlingsdel (som kan genomföras mot en eller flera leverantörer/anordnare).

75 Sambrplform_OTP_v20.doc 75(102) Det bör finnas olika förväntningar på återanvändbarhet hos olika delar, se separat kapitel. Man bör i sammanhanget också påpeka att Öppen teknisk plattform på många sätt endast är en specifikation och kanske bara på några sätt utgörs av faktisk programkod. För e-tjänstens webb-applikation: Bör vara ganska lätt att upphandla/anordna utgående ifrån en traditionell funktionsspecifikation. IT-infrastruktur (Dotnet, Java, Tomcat, Linux, Windows etc) måste väljas, antingen redan i upphandlingsunderlaget eller när man jämför offerter (motsvarande). Beroende på finansieringsmodell kan man t ex tänka sig att antingen första kommunkunden bestämmer detta, eller att man initialt tar ett majoritetsbeslut bland återanvändande kommuner. För en viss anpassningslogik (mellan en viss e-tjänst och en viss verksamhetsapplikation): Bör vara ganska lätt att upphandla/anordna utgående ifrån en traditionell funktionsspecifikation (består i hög grad av e-tjänstens definierade Nyttomeddelanden och verksamhetsapplikationens egenskaper). IT-infrastruktur måste väljas, vanligen baserat på verksamhetsapplikationens teknik (beroendet av e-tjänst-applikationens teknik är lågt i och med att Web Services används emellan). För en viss anpassningslogik (mellan de allra flesta e-tjänster och centrala register): Bör vara ganska lätt att upphandla/anordna utgående ifrån en traditionell funktionsspecifikation (består i hög grad av e-tjänsternas definierade Nyttomeddelanden och registerhållande myndighets info-specifikation, ofta Standardmeddelanden via SHS. IT-infrastruktur måste väljas. Tämligen oberoende av både e-tjänst-applikationens teknik och registerhållande myndighet. För en viss anpassningslogik (mellan de allra flesta e-tjänster och e-leg/e-underskrift): Bör vara ganska lätt att upphandla/anordna utgående ifrån en traditionell funktionsspecifikation (består i hög grad av e-tjänsternas definierade Nyttomeddelanden och specifikation för respektive leverantörer av e-leg/e-underskrift samt i förekommande fall något specifikt gränssnitt hos någon av Infratjänsteleverantörerna). IT-infrastruktur måste väljas. Tämligen oberoende av e-tjänst-applikationens teknik. Kan vara beroende av teknikval hos leverantörer av e-leg/e-underskrift samt hos avropad Infratjänsteleverantör.

76 Sambrplform_OTP_v20.doc 76(102) Nedan följer en illustration av ett exempel på vad som kan tänkas upphandlas/avropas: E-tjänst vs verksamhetsapplikation Medborgare LOUupphandling Avrop mot existerande avtal Ex. på kommuners olika bakomliggande verksamhetsapplikationer: E-tjänst Ny webbapplikation Applikation inkl anpassning till Nyttomeddelanden X Föreliggande upphandling Applikation inkl anpassning till Nyttomeddelanden Y SOA Ur Sambruks synvinkel syns i detta fall ingen anpassningslogik (s k adaptrar) utan verksamhetsapplikationerna implementerar Nyttomeddelandena inom sitt ansvar Applikation inkl anpassning till Nyttomeddelanden Z SOA = Service Oriented Architecture = E-tjänstens definierade Nyttomeddelanden (anrop via Web Services enligt SOA-mönstret).

77 Sambrplform_OTP_v20.doc 77(102) Var datalagring sker Beroende på verksamhetskraven för e-tjänsten och på kapabiliteten hos använd verksamhetsapplikation kan det uppstå behov av datalagring på fler ställen än i verksamhetsapplikationen i sig. Dessutom, beroende på återanvändningsaspekter och när i tiden olika delar implementerats kan datalagringsbehov uppstå både i e-tjänste-applikationen och i anpassningsskiktet. Man bör dock vara noggrann med att definiera ett tydligt Master -förhållande och manuella processer för att undvika data-diskrepanser. Frågan om var datalagring sker är mycket parallell med resonemangen i kapitlet om processaspekten Stora, asynkrona dataflöden Stora asynkrona dataflöden bör behandlas i särskild ordning. Arkitekturbilderna i denna skrift behandlar mest online-fallet och i viss mån kort asynkron fråga-svar. Samtidigt finns det traditionellt sett ofta befintligt stöd för filöverföring och batchuppdateringar. Att välja att gå ifrån dem bör göras ur ett cost/benefit-perspektiv. Asynkrona flöden har naturligtvis fördelar (lösare koppling ger bättre chans för bra tillgänglighet, svarstider är inte problematiska etc) men också nackdelar (dålig infoaktualitet, risk att processer inte kan utformas så att de utförs i ett enda svep vilket vanligen är billigast för verksamheten etc). Denna version av ÖTP har fått tillagt stöd för EAI/ESB-perspektivet (vilket ofta lyfts fram när man vill modernisera gamla fil-flöden). Dock kan man även med framgång använda SHS för vissa former av EAI/ESB. Här bör dock nämnas att Web Service-gränssnittet till SHS (version 1.2) som anpassningsskiktet främst tänks använda, troligen endast klarar ca 1 MB per asynkront meddelande. Vill man skicka större mängder utan att segmentera datat så kan man installera en SHS-satellit/klient/nod i samband med integrationsskiktet så att de äldre SHS-API:erna som klarar större datamängder per meddelande kan användas. Detta alternativ stöds också av Infratjänsten. Se även kapitlet Principer för Nyttomeddelanden. Om man inte skulle välja SHS och inte heller traditionell filöverföring kan man gärna överväga temporärlagring i relationsdatabas. Som front-api kan man t ex använda Web Services. Därmed har man skapat en mycket drifttålig kö för asynkront bruk som vanligen inte kräver några extra plattformsinvesteringar (såsom MSMQ, IBM MQ etc) Man bör också notera att gammaldags avstämningsrutiner e.dyl. oftast är nödvändiga för att kvalitetssäkra asynkrona flöden. Se även kapitlen Mönster för batchuppdatering och Applikationsintegration EAI/ESB.

78 Sambrplform_OTP_v20.doc 78(102) Återanvändning vid ytterligare e-tjänst Återanvändningsaspekten är en av kärnfrågorna i visionen för Sambruk. Lyckas man med detta kan kostnader och ledtider sänkas rejält per kommun. Samtidigt måste man vara realist, en stor mängd förväntningar på hög återanvändningsgrad under 1990-talet kom på skam. Ofta berodde det på ett överteoretiskt förhållningssätt, flummiga förväntningar och framförallt på organisatoriska aspekter (vem ska ansvara, förvalta, missionera, svara för flexibilitet) ego, not-invented-here och bristande ekonomimodeller. Nedan följer några återanvändningsnoteringar per del av Sambruk i denna version: För e-tjänstens webb-applikation: Återanvändning av webb-applikation bland många kommuner borde vara ganska lätt, förutsatt att: o Processen och detaljutförandet som stöds av utvecklad e-tjänst-applikation kan accepteras ego-less av återanvändande kommuner utan modifieringar. o IT-infrastrukturen som valdes vid programutvecklingen godtas av de återanvändande kommunerna. o Samma verksamhetsapplikation används av återanvändande kommun, eller att den verksamhetsapplikation man använder är rimligt typisk så att anpassningslogik-skiktet har en chans, och inte e-tjänsten måste modifieras. För en viss anpassningslogik (mellan en viss e-tjänst och en viss verksamhetsapplikation): Återanvändning av anpassningslogiken bör vara rimligt lätt om samma Nyttomeddelanden efterfrågas och samma version av verksamhetsapplikationen används. För en viss anpassningslogik (mellan de allra flesta e-tjänster och centrala register): Återanvändning bör vara lätt eftersom troligen samma Nyttomeddelanden efterfrågas i många e-tjänster. För en viss anpassningslogik (mellan de allra flesta e-tjänster och e-leg/e-underskrift): Återanvändning bör vara lätt eftersom troligen samma Nyttomeddelanden efterfrågas i många e-tjänster. Dock förutsatt att samma Infratjänsteleverantör och leverantörer av e-leg/e-underskrift används. Fallet att en kommun inte anser att existerande Sambrukslösning helt skulle räcka till relativt upplevd behovsbild är värt en liten genomgång. Ifall Sambruk äger programkoden eller Open Source eller liknande principer används är det förstås möjligt att en återanvändande kommun gör modifieringar, men då blir naturligtvis den totala förvaltningssituationen sett över hela Sambruk mycket mindre optimal. Förvaltning kommer ändå att bli en komplicerad utmaning, även utan en mängd kommun-specifika varianter. En annan lösning är att designa e-tjänste-applikationen till att vara parameterstyrbar för att kunna anpassas till varierande kommunkrav. Detta kan fungera väl om mängden parametrar hålls lågt, i annat fall blir varje införande dyrt och komplext (jämför med den ofta mycket höga införandekostnaden för stora, parameterstyrbara ERP-system såsom SAP).

79 Sambrplform_OTP_v20.doc 79(102) 3. RÖRLÄGGNING Detta kapitel berör kortfattat val som gjorts inom Öppen teknisk plattform vad gäller grundläggande kommunikationssätt och integrationsteknik. En av de faktorer som gjort Öppen teknisk plattform överhuvudtaget rimlig att börja arbeta med är tekniken som för några år sedan kommit att etableras och som ger stor interoperabilitet mellan olika tekniska plattformar, nämligen enkla Web Services enligt SOAP/http. Alla de olika kommunerna kan inte förväntas göra exakt samma teknikval och dessutom finns många investeringar redan gjorda i verksamhetsapplikationer utvecklade/driftade i diverse tekniker. För Sambruk tänker vi oss att parter som kommunicerar via Web Services är kända för varandra och exekverar i kontrollerade, interna driftsmiljöer. Därmed bör inte säkerhetsfrågor ge problem. Därmed finns det heller ingen direkt anledning att idag använda en aktiv UDDI (en Web Services-katalog). Möjligen kunde man använda UDDI som en ren dokumentations-katalog. Här kan beröras den process/objektmodellering som nämns i kapitlet Process-aspekten. Den hypotetiska mycket höga teoretiska ambitionsnivån som där nämns skulle ha krävt modeller, utvecklingsverktyg, driftmiljöer mm för tämligen fingranulära objekt samtidigt med välfungerande objektkommunikation mellan disparata teknikmiljöer. För detta fanns det stora förhoppningar i början av 1990-talet, men de infriades huvudsakligen aldrig. Istället har vi alltså valt att i plattformen kapsla in verksamhetsapplikationer relativt grovgranulärt, utgå ifrån deras inneboende möjligheter och i e-tjänstens webbapplikation lägga till det som sedan inte visade sig räcka till. Integrationen mellan e-tjänsten och verksamhetsapplikationen blir därmed mera av Service Oriented -slag (SOA) med relativt lösa kopplingar (t ex utan den distribuerade object life cycle management som ställt till stora problem i tätt kopplade arkitekturer) och med Web Services som grundprincip. Denna version av ÖTP anger SOAP som transport i samband med Web Services. Ifall den enklare varianten för "Web Services" som kallas REST slår igenom, bör vi i framtiden överväga den Web Services Management Med Web Services Management menas lösningar speciellt framtagna för att ge övervakning, kontroll och hanterlighet i de fall då man använder många SOA-tjänster via Web Services. Det brukar ingå t ex tjänstekatalog, adresssöversättning, spårbarhet, rättighetsstyrning och övervakning. ÖTP-GIT-133) Krav: Att Web Services Management ingår i lösningen. Beskriv på vilket sätt, versionskrav, samt ev mer detaljerade möjligheter i lösningen.

80 Sambrplform_OTP_v20.doc 80(102) ÖTP-GIT-134) Krav: Att Web Services Management går att integrera emot, från lösningen.

81 Sambrplform_OTP_v20.doc 81(102) 4. PRINCIPER FÖR NYTTOMEDDELANDEN Nyttomeddelanden infördes i ÖTP V1.1 (till Borlängepiloten för Bistånd). Vi valde under det spec-arbetet (år 2004) att vara mycket konkreta och även skriva XML-definitionsfiler för att markera att skapande/införande av en lösning kunde ske tämligen omedelbart. I och med att vi i de senare projekten skapar flera krav-specar samtidigt får vi ett utökat strukturbehov för hur vi ska hantera Nyttomeddelande-definitioner, varför vi i ÖTP v1.2 förfinade sättet att specificera meddelanden. Samtidigt har vi lärt oss av erfarenheter och framförallt har nu Statskontorets/E-nämndens/Vervas 05:01 Riktlinjer för utveckling av standardmeddelanden för förenklat informationsutbyte med elektroniska standarddokument getts ut i februari Sambruks inriktning är att så långt möjligt följa dessa riktlinjer och vad vi förstår kommer alla Nyttomeddelanden i de pågående projekten kunna anges att tillika vara Standardmeddelanden. Det nya sättet att speca består av följande: Ett dokument innehållande Begreppsmodell. Här definieras naturligtvis begrepp (semantik). Detaljdefinitioner inkluderas av paket, grupper, typer och termer, se figur nedan. Ett dokument innehållande Nyttomeddelanden. Här beskrivs syfte och användning av meddelanden, som i sin tur pekar ut detaljdefinitioner specade i Begreppsmodellen. Dokumentet definierar också de anrop som använder Nyttomeddelandena (begäran samt svar). Framgent har vi höga förväntningar på att en mycket god återanvändningsgrad av Nyttomeddelanden ska uppstå. Återanvändning ställer som bekant mycket stora krav på missionering, struktur, ordning, versionshantering, förvaltning och ekonomiska incitament. Vi kan därför räkna med att sättet att definiera och underhålla Nyttomeddelanden kommer att behöva utvecklas vidare över tiden. På sikt kanske uppdelning i ett stort antal del-filer behövs, liksom användning av ett configuration management-verktyg samt i övrigt strikta versionshanteringsprocesser och tydligt utpekade ansvar.

82 Sambrplform_OTP_v20.doc 82(102) Återanvändning förväntas ske på alla nivåer i skissen; Anrop, Nyttomeddelanden, paket, grupper och typer. Detta får bli beroende av respektive verksamhetsbehov. Ju högre upp som återanvändningen sker, desto bättre återvinningseffekt, men ibland kommer det inte att bli möjligt. Då kanske återanvändningen t ex ofta sker på Paket-nivån. Som man förstår av följande bild blir det synnerligen viktigt att ha god ordning på återanvändning, configuration management och kravspårbarhet: Successiv återanvändning av nyttomeddelanden/begrepp över tiden Verksamhetsbehov från e-tjänst 1 Verksamhetsbehov från e-tjänst 2... Begreppsmodell skapad när e-tjänst 1 specas Nydefinitionspilar Återanvändningspilar Nydefinitionspilar Begreppsmodell tillkommande detaljer när e-tjänst 2 specas Nyttomeddelanden skapad när e-tjänst 1 specas Nyttomeddelanden tillkommande detaljer när e-tjänst 2 specas tid

83 Sambrplform_OTP_v20.doc 83(102) Följande skiss belyser hur Nyttomeddelanden förhåller sig till Standardmeddelanden samt ger även kopplingen till konkret XML: Standardmeddelanden Nyttomeddelanden Ex XML Anrop/överföring SBAXyz etc SBAHamtaElevData SOAP WSDL (eller batchfil etc) SBAXyz.wsdl etc Nyttomeddelanden SBNXyz (Element) SBNHamtaElevDataSvar XML-schema SBNXyz.xsd (ej oblig. nivå) Paket SBPXyz (Element) Grupper SBGXyz Element SBPMedborgare SBGPersTel (Ex på element: Mobiltelefon) XML-scheman (som inkluderas i ovanst.) SBPXyz.xsd (ingen motsv, end. spec-begrepp) Typer SBTXyz SBTTelefonnummer XML-typer E-nämndens riktlinjer 05:01 Sambruk ÖTP V1.2 Pilotspecar mars 2005 En anmärkning är att Nyttomeddelanden förväntas kunna transporteras inte bara av SOA- Web Services, utan lika väl av SHS eller enkla filer etc. Detta är anledningen till uttrycket "Anrop, överföring" i översta boxen i figuren. En viktig aspekt av SOA, Web Services och modelleringen av storleken på de Nyttomeddelanden som förmedlas är avvägningen av det som brukar kallas chatty vs chunky, dvs ska maskingränssnittet småprata ofta med små datamängder i taget eller mer sällan och istället med större datamängder i taget. All erfarenhet pekar på att man inte bör ha SOA av chatty-karaktär, det skulle strida mot tankar på självständighet/inkapsling, att SOA har mer teknisk overhead än t ex SQL-protokollen, andra prestandaproblem mm. Att endast kapsla in ett existerande client/server-gränssnitt av småprats-karaktär i Web Services fungerar alltså vanligen inte bra.