Introduktion till. Öppen Teknisk Plattform (ÖTP) V2.1

Utfärdad Sven-Håkan Olsson Godkänd av Janne Dicander Dokumenttyp Öppen teknisk plattform Status Fastställd Identitet Intro till ÖTP V2.1 Version Utgåva av 2.1 Sid 1 (12) Versionsdatum 2011-03-08 Introduktion till Öppen Teknisk Plattform (ÖTP) V2.1 Sambruk_intro_OTP_v2_1_2011-03-08.doc Projektledare ÖTP Janne Dicander janne.dicander@jonkoping.se

2(12) Historik och beslutade ändringar: Datum Ändring Ändrad av 2010-02-08 Arbetsversion 0.1 Sven-Håkan Olsson 2010-05-23 Arbetsversion 0.2, Sven-Håkan Olsson för synpunktsinhämtning 2010-08-30 Arbetsversion 0.3, Sven-Håkan Olsson några mindre redigeringar 2011-03-08 Utgåva till ÖTP v2.1 Sven-Håkan Olsson Bilagor: Nr Beteckning Identitet - Referenser: Referensnamn Beteckning Identitet [ÖTP-Hvd] ÖTP:s huvuddokument Sambruk_OTP_v2_1_2011-03-08.doc [ÖTP- Upphandl] Dokument om upphandling eller andra anskaffanden, baserat på ÖTP. (De konkreta kravformuleringarna som fanns inom huvuddokumentet för ÖTP2.0 är numera utbrutna i detta sseparata dokument.) Sambruk_kravmaster_OTP_v2_1_2011-03-08.xls samt relaterade dokument Innehåll: 1. Inledning, dokumentets roll... 3 2. Öppen Teknisk Plattform... 4 2.1. Det grundläggande behovet av ÖTP... 4 2.2. Återanvändning genom referensarkitektur... 7 2.3. Återanvändning av konkreta kravformuleringar... 7 2.4. ÖTP relativt andra specifikationer... 8 3. ÖTP:s viktigaste delar... 9 3.1. Byggklossar och maskingränssnitt... 9 3.2. Nyttomeddelanden... 10 3.3. Säkerhet... 10 3.4. Att vara ÖTP-kompatibel... 10 3.5. Icke-funktionella krav... 11

3(12) 1. INLEDNING, DOKUMENTETS ROLL Den tänkte läsaren av föreliggande dokument Introduktion till ÖTP tänks främst arbeta verksamhetsnära, eller mera ha ett översiktligt intresse av ÖTP. Den mer tekniknäre läsaren, som kan förutsättas vara väl insatt i IT-området torde ha ett intresse att också läsa det egentliga ÖTP-dokumentet, se [ÖTP-Hvd] i referenslistan i inledningen. Specifikt i samband med upphandlingar eller andra anskaffanden hänvisas till ÖTP:s upphandlingsdokument, främst referensen [ÖTP-Upphandl]. Föreliggande dokument tillhör dokumentationen för ÖTP version 2.1, den femte utgåvan totalt sett, sedan 2003.

4(12) 2. ÖPPEN TEKNISK PLATTFORM 2.1. Det grundläggande behovet av ÖTP Bakgrunden till att ÖTP började skapas år 2003 var främst att kommunerna som bildade Sambruk inte riktigt kände att de fick tillgång till sin egna information den var instängd i verksamhetsapplikationer som kanske fungerade bra ur ett visst perspektiv, men ur andra inte alls så bra. Det var några saker som höll på att hända samtidigt: Medborgarna hade vant sig vid internetapplikationer under många år och kanske använt en så kraftfull och säkerhetsmässigt avancerad lösning som en Internetbank i över fem år redan. Då kändes det konstigt att en kommun inte kunde erbjuda e- tjänster enligt medborgarnas önskningar. En av anledningarna till att kommunerna inte kunde skapa e-tjänster var att information och funktionalitet som behövdes fanns inom befintliga verksamhetsapplikationer som inte var öppna på ett relevant sätt det vill säga saknade möjligheter att integreras med nyskapade e-tjänster. Vissa e-tjänster erbjöds av leverantörerna av standardapplikationer men kanske inte alltid på det sätt som kommunerna egentligen ville. På liknande sätt som i föregående punkt, på grund av bristande öppenhet i existerande applikationer så gick det inte att utforma e-tjänsterna enligt önskan. Kommunerna kände sig i underläge eftersom de inte själva kunde skapa lösningar, eller kunde konkurrensutsätta leverantörerna genom att köpa konkurrerande e-tjänster till de som eventuellt fanns från ordinarie leverantören av verksamhetsapplikationerna. Genom dålig öppenhet kände sig alltså kommunerna i förhandlingsunderläge både vad gäller pris och funktionalitet. Medborgarna hade länge vant sig vid att banker, försäkringsbolag och även vissa myndigheter hade erbjudit sammanställningar över kundens affärer med företaget. Motiveringen var att kunden inte rimligen borde avkrävas att lära sig hur företaget valt att organisera sig internt, utan via Internet skulle man få en samlad bild. Samma önskemål ställdes mot kommunen som ju traditionellt varit mycket strikt uppdelad i förvaltningar, nämnder och liknande s k stuprör som medborgaren egentligen är helt ointresserad av. För att i en och samma webbsida kunna presentera en samlad bild för en medborgare, oavsett stuprör, krävdes förstås att ett antal olika verksamhetsapplikationer från vardera stupröret kunde integreras mot en och samma webbapplikation här duger det ju inte med en e-tjänst per stuprörsapplikation. Men behöver en slags byggklossprincip alltså. Men öppenheten var så dålig att en sådan överblick, exempelvis kallad Mina Sidor, inte lät sig utvecklas. Vissa kommuner började arbeta med koncept som medborgarkontor och servicecenter. En av idéerna med dessa var att personalen som mötte medborgarna

5(12) inte skulle vara uppdelade enligt stuprören. Med andra ord skulle denna personal behöva IT-stöd som var sammanhållet och slippa logga in i trettio helt olika applikationer med i värsta fall olika lösenord och med olika stilar i användargränssnittet att lära sig. På grund av dålig öppenhet gick det inte bra att skapa sådana sammanhållna applikationer till servicecenter/medborgarkontor. 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... Figur 1 Hängrännor vs stuprör Fler exempel på behov där många verksamhetsapplikationers information behöver nås samtidigt: Kontaktcenter Medborgarkontor Medborgaröverblickswebb (Mina Sidor etc) E-tjänster Telefonapplikationer (tonvalsknappar) 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 för att 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.

6(12) Även om vi sju år efter första ÖTP-skriften har sett en hel del förbättringar åt det öppnare hållet måste vi tyvärr säga att vissa förändringar har gått mycket långsammare än vi hade hoppats. Flera av lösningarna enligt punkterna ovan har inte materialiserat sig, eller har inte gjort det i tillräckligt bra omfattning, eller med tillräcklig kvalitet. Det är därmed fortsatt minst lika viktigt att ställa krav på öppenhet och integrerbarhet som det var 2003. Därför ges en ny version ut av ÖTP i vår, 2.1, och ÖTP-arbetet bör fortsätta med en planering för fler framtida versioner som följer med i tiden och i IT-utvecklingen. Sambruks Öppen Teknisk Plattform (ÖTP) är en specifikation för hur e-tjänster och verksamhetsstöd bör designas tekniskt för att kunna både leda till höjd servicegrad för medborgarna och höjd inre effektivitet i kommunen. Ordet öppen syftar främst på att ett av de viktigaste medlen för att uppnå detta dubbla mål är att olika delar av kommunens IT-stöd inte är inlåsta utan ska kunna samfungera vara interoperabla. Det återkommande temat är alltså bristande öppenhet och det var därför Öppen Teknisk Plattform skapades. Tanken var att kunna vara duktigare kravställare på leverantörerna kring relevant öppenhet: Om många kommuner inom Sambruk går samman och ställer samma krav så ökar tyngden i kravställandet. Sambruk kunde göra en kraftsamling och också arbeta med gemensam kostnadsdelning för att få möjlighet att skriva en modernare typ av kravspecifikationer som betonade saker som applikationsöppenhet, integrerbarhet och säkerhet. I den traditionella kommunen hade man kanske haft en IT-avdelning som skötte infrastruktur och drift medan det vanligen var någon ganska ensam person inom förvaltningen som arbetade med kravställning de få gånger en ny verksamhetsapplikation skulle upphandlas/anskaffas. För många av dessa medarbetare var det inte lätt att bekosta utbildning i applikationsarkitektur och annan teknik som det helt plötsligt behövde stå om i kravspecifikationerna för att skapa önskad öppenhet. En lika viktig sak som att ÖTP finns är att se till att ÖTP dessutom verkligen används som det är tänkt. Som med alla specifikationer finns det en inlärningströskel. Den nämnda utbildningsfrågan, att ibland varken IT-avdelningen eller förvaltningens systemansvariga har djup kunnighet i applikationsarkitektur ger också en tröskel kring att börja använda ÖTP aktivt.

7(12) En av de saker som måste rekommenderas är alltså att kommunen arbetar med utbildningsplaner för medarbetare som ska komma att skriva upphandlingsunderlag (eller specifikationer för annan form av anskaffande). 2.2. Återanvändning genom referensarkitektur ÖTP beskriver ett stort antal mallar för hur en konkret applikationsarkitektur kan tänkas utformas, ur olika aspekter. Man har alltså arkitekturen i ÖTP som en referens, det är utgående ifrån dessa mallar som man ska kunna hitta de delar som ska tas med för att ge önskad öppenhet etc. Man ska således kunna utgå ifrån aktuella verksamhetskrav, nyttoformuleringar samt kommunens teknikstrategier mm. Dessa förutsättningar jämför man med referensarkitekturen och mallarna i ÖTP så att man med god sannolikhet ska hitta mallar att återanvända så man slipper uppfinna hjulet på nytt varje gång. Viktigt är alltså att betona att en storlek inte passar alla. Det går åt ett visst arbete att vaska fram de relevanta varianterna från referensarkitekturen inför varje anskaffande. Dock ska det förhoppningsvis vara ett mycket mindre arbete än att starta från noll varje gång. Dessutom borde risken minska att man råkar glömma någon viktig aspekt av applikationsarkitekturen. 2.3. Återanvändning av konkreta kravformuleringar De senaste versionerna av ÖTP inkluderar också konkreta kravformuleringar att använda i upphandlingsunderlag eller andra anskaffandespecifikationer. ÖTP har alltså en hel palett av krav som man väljer bland och återanvänder från. Det torde finns att antal fördelar med detta, dels att man inte ska glömma någon kravformulering, dels att formuleringarna troligen har testats i ett antal upphandlingar och därmed är provade i verkliga livet redan. Även här måste poängteras att man måste utgå ifrån verksamhesbehov och reknikförutsättningar för att kunna välja ut relevanta krav ur kravpaletten. Dock finns det ett antal s k typupphandlingar att tillgå ibland ÖTP-dokumenten som ska göra det ännu enklare att välja ut en uppsättning krav. En egentligen ännu svårare sak än kravformuleringar är offertbedömningsmallar eftersom LOU 1 kräver en mycket objektiv offerthantering. ÖTP innehåller även ett antal sådana betygsättningsförslag. Den ganska nyligt ändrade LOU föreskriver en annan sorts ramavtal än vi tidigare haft. En konsekvens av detta är att numera måste många ramavtalsavrop göras med konkurrensutsättning vilket innebär att men behöver en noggrann kravspecifikation samt att man måste göra en fullödig genomgång av offertsvaren och betygssätta för att vara objektiv enligt lagen 1 LOU, Lagen om offentlig upphandling

8(12) och ifall det skulle bli en överprövning i rätten. Härvid torde det också vara en fördel med återanvändbara krav enligt ÖTP. I och med den senaste versionen av ÖTP (2.1) är det också förberett för att de konkreta kravformuleringarna ev. ska gå att tanka in hel- eller halvautomatiskt i kravhanteringsverktyg, detta genom att den s.k. kravmastern finns i kalkylbladsformat. Därmed skulle anskaffningsarbetet bli rationellare och risken minskar för avskrivningsfel eller klipp-och-klistra-misstag. 2.4. ÖTP relativt andra specifikationer Förutom ÖTP finns det ett stort antal andra initiativ inom privat och offentlig sektor för att beskriva referensarkitekturer och andra specifikationer. Jämfört med många andra specifikationer inom offentlig sektor är dock ÖTP extra mycket inriktad just på applikationsarkitektur medan många andra skrifter mer behandlar infrastrukturfrågor. Båda sakerna behövs naturligtvis, men vi har ansett att ÖTP kompletterar de andra dokumenten väl genom denna fokusering. Huvuddokumentet för ÖTP innehåller en genomgång av hur den relaterar till dussinet av dessa andra specifikationer. Där uttrycks också att något av de andra dokumenten gärna kan refereras vid behov.

9(12) 3. ÖTP:S VIKTIGASTE DELAR 3.1. Byggklossar och maskingränssnitt En mycket viktig del av ÖTP är att den grundar sig på en s k SOA Service Oriented Architecture, en tjänstearkitektur. Främst betyder det i vår tappning att verksamhetsapplikationer ska ses som byggklossar. För att detta ska kunna fungera måste byggklossarna ha gränssnitt. Dels ska många applikationsdelar ha användargränssnit så att användarna kommer åt dem direkt. Men det vi mest tänker på är maskingränssnitt, alltså sådana som andra program använder för att integrera mot byggklossarna. Maskingränssnitten kan vara av många olika slag, för helt olika behov, vilket innebär att ett antal av mallarna inom referensarkitekturen definierar egenskaper hos olika sorters maskinggränssnitt. Till exempel: Tjänsteanrop, filöverföring, kommunikation via kö, meddelanden via den statliga meddelandespecifikationen SHS etc. Medborgare Företag Handläggare etc SOA Service Oriented Architecture Översiktsbild Maskingränssnitt E-tjänst Ny webbapplikation Existerande verksamhetsapplikation Exempel på adapter Användargränssnitt för handläggare etc Registerhållande myndighet etc e-leg / e-underskrkoll etc

10(12) 3.2. Nyttomeddelanden En annan viktig princip är att Sambruk behöver specificera exakt hur informationsöverföringen ska se ut vid maskingränssnitten. Det handlar delvis om att ange tekniska detaljer, det kan heta SOAP eller SHS e dyl men minst lika viktigt är att definiera informationsinnehållet. Sambruk har i ÖTP angivit en struktur för hur information ska skickas via s k Nyttomeddelanden. För att informationsfälten som skickas ska ha någon relevans måste man också beskriva vad fälten står för. Och hur fälten relaterar till varann. Därför har Sambruk också skapat en Begreppsmodell. Både dokumenten för Nyttomeddelanden och för Begreppsmodell finns publicerade på. 3.3. Säkerhet Ett antal säkerhetsaspekter tas upp i ÖTP, dels i huvuddokumentet, men framförallt i de konkreta kravformuleringarna, i [ÖTP-Upphandl]. En viktig ansats är att säkerhet inte är något absolut, säkerhet måste relateras till vad det är som ska skyddas. Informationsklassning är alltså viktig för att inte ta i för mycket när det inte alls behövs eftersom för hög säkerhet är komplex, har dålig användarvänlighet och är kostnadsdrivande. Samtidigt måste naturligtvis nivån vara hög när så är motiverat. Särskilt viktigt blir att betona säkerhet eftersom vi i hela ÖTP betonar öppenhet. Självklart får inte ordet öppenhet tolkas som att all informationstillgång ska vara vidöppen för vem som helst. Ordet ska mer tolkas som att relevanta integrationer och ihopkopplingar ska vara möjliga att göra. 3.4. Att vara ÖTP-kompatibel Det finns ett behov av något sätt att uttrycka att en viss applikation eller komponent övergripande följer ÖTP eller är ÖTP-kompatibel. Dock finns det ett problem med ett sådant uttryckssätt eftersom ÖTP är en referensarkitektur med ett antal mallar för olika användningsområden och en palett med ett stort antal kravformuleringar som ska kunna återanvändas i helt olika sammanhang i kommuner.

11(12) Alltså behöver man egentligen veta vad det är en viss lösning ska åstadkomma för att kunna bedöma ifall dess utförande följer ÖTP. Icke desto mindre finns det en styrka med att uttrycka ÖTP:s kärna med några få krav. Priset man får betala för detta är att kraven nedan måste innehålla några relativiserande formuleringar. En lösning är övergripande ÖTP-kompatibel ifall den: 1. Är öppen i så motto att den är interoperabel med andra lösningar hos kunden. Denna interoperabilitet ska gälla för relevant information i relevanta processteg inom verksamhetsområdet. 2. Inte ger inlåsning i begränsande lösningar och går att byta ut med rimlig insats. En leverantör ska alltså också kunna uttala att vår lösning är ÖTP-kompatibel, på den här mycket övergripande nivån. Med ovanstående menar vi särskilt: Relativt punkt 1: Interoperabilitet är som motiverats tidigare i dokumentet mycket viktig för att skapa större kommun/medborgarnytta. Å andra sidan kan det ge vissa kostnader att införa interoperabilitet, så vi ska heller inte kräva interoperabilitet där den aldrig skulle vara till relevant eller till nytta. Relativt punkt 2: Ett exempel är att den information som kommunen rättmätigen äger, kan var omöjlig att få fram (i dataformat) ur en färdigköpt verksamhetsapplikation, t.ex. för att göra en nyttig integration med något annat av kommunens system. Eller att det blir smått omöjligt att konvertera informationen om man vill byta ut till en annan verksamhetsapplikation. 3.5. Icke-funktionella krav Upphandlingsunderlagen inom ÖTP innehåller en hel del tekniska krav (s.k. ickefunktionella krav). Om man nu använder principen med byggklossar enligt ovan, varför ska då en upphandling/avrop överhuvudtaget ställa icke-funktionella krav vad gäller innanmätet i en byggkloss som man köper färdig? Den främsta anledningen är att kommunens IT-drift behöver ta vissa strategibeslut. Som helhet i kommunen blir det klart fördyrande ifall inte samma mjukvarulicens kan användas till många applikationer (t.ex. en licens till ett visst databasfabrikat) och det blir också

12(12) fördyrande ifall kommunen behöver hålla driftkompetens och ge utbildning i en stor flora av produkter (t.ex. om det funnes fem olika databasfabrikat installerade). Serverresurser kan också samutnyttjas effektivare. Dessa kostnadsökande faktorer måste alltid dock vägas mot nytta som kan uppstå med en viss applikation, genom att anlägga ett kostnads/nyttoperspektiv. Kommunens säkerhetsmässiga angreppsträffyta vad gäller den tyvärr ökande mängden säkerhetshål i mjukvara minskas likaså avsevärt om antalet mjukvaruplattformar hålls ner.