Sambruksplattformen. Öppen teknisk plattform

Transkript

1 1(15) Sambruksplattformen Öppen teknisk plattform Sambruksplatt tekn V1.0

2 2(15) Innehåll: 1. Bakgrund och mål Sammanfattning Introduktion Trender och visioner Sambruksplattformens tekniska delar för horisonten Rörläggning Slutsatser Aktiviteter/leverabler Nyttomeddelanden Slutsatser Aktiviteter/leverabler Regler och konventioner Slutsatser Aktiviteter/leverabler Teknikadministrativa delar Slutsatser Aktiviteter/leverabler Förvaltning av Sambruksplattformen... 15

3 3(15) 1. BAKGRUND OCH MÅL Sveriges kommuner står inför stora utmaningar. På många håll måste besparingar göras. Befolkningsstatistiken påvisar ofta dels att andelen äldre som behöver omvårdnad mm ökar, dels att andelen arbetande/skattebetalande minskar och dels att stora pensionsavgångar av kunnig kommunpersonal kommer att ske. Parallellt förväntar sig medborgarna högre service och öppenhet i linje med visionen om 24-timmarsmyndigheten. Samtidigt finns här en potential genom att IT kan användas för att parallellt lösa två behov, dels av ökad service till medborgaren, dels av ökad rationalisering inom kommunverksamheten. Det gäller nu att befrukta kommunernas verksamhetsutveckling med möjligheter som IT ger, utveckla goda IT-system, skapa en trovärdig långtidshantering/förvaltning av dessa system samt hitta sätt att hålla nere kostnader. Ett initiativ finns nu bland en grupp av kommuner för att skapa en sk Sambruksplattform för IT-stöd till verksamheten, och speciellt relaterat till visionen om 24-timmarsmyndigheten. Under våren 2003 har gruppen bl.a. a med stöd från Statskontoret arbetat med att skapa ett underlag för finansiering/organisering av ett genomförandeprojekt. Inom detta arbete har man framförallt fokuserat på organisation, processer, funktionella frågor mm. Däremot har man där inte arbetat med den tänkta tekniska plattformen för att möjliggöra en framgångsrik Sambruksplattform. Föreliggande kortrapport fokuserar istället på detta. Ifrån det övriga arbetet med Sambruksplattformen har följande mål angivits för en s k Öppen teknisk plattform: Skapa en teknisk plattform inom kommunsektorn för utveckling av e-tjänster Möjliggör utvecklingen av kommunala e-tjänster som vilar på befintliga verksamhetssystem Ska stödja de mest frekventa e-tjänsterna och verksamhetssystemen Lägre totalkostnad för drift och utveckling Rapporten har två aspekter, dels att kunna ingå som bilaga i underlaget för finansiering/organisering av genomförandeprojekt, dels att kunna vara en fristående belysning av teknikaspekter på framtida kommunalt IT-stöd. Vad gäller kalendertid så innehåller kortrapporten två tidshorisonter, dels konkret användbara lösningar för 2003 och 2004, dels mer forskning och utveckling-inriktade delar för en femårshorisont. Rapporten är finansierad av Svenska Kommunförbundet. Research, möten och rapportarbete har tillsammans haft en timbudget på 40 timmar varvid ambitionsnivå och omfattning har fått anpassas därefter.

4 4(15) 2. SAMMANFATTNING Viktiga noteringar IT-stöd måste utformas parallellt med verksamhetsutveckling Plattformar för applikationsintegration (sk EAI) har potential att gynna oss på sikt IT-framväxten gynnar oss just nu, framförallt vad gäller enkla Web Services Genomförbarheten bör vara god ifall amibtionsnivåer hålls i schack Delarna i Öppen teknisk plattform: - Rörläggning - Nyttomeddelanden - Regler och konventioner - Teknikadministrativa delar Ett antal FoUområden finns för femårs-horisonten. Successiv förvaltning av Sambruksplattformen krävs Kokbok, missionering och utbildning blir synnerligen viktiga komponenter för framgång

5 5(15) Öppen teknisk plattform inom Sambruksplattformen rekommenderas få följande huvuddrag i sammanfattning (först poängteras några huvuddrag, sedan följer plattformens omfattning). Här poängteras tidshorisonten Samverkan verksamhets- och IT-stödsutveckling Verksamhetsutveckling på 2000-talet kan i praktiken inte göras utan att vara i samklang med utveckling av IT-stöd, och IT-stöd får å andra sidan inte skapas som inte stämmer med nytto/kostnads-aspekter. Dessutom står aldrig IT-sektorn stilla utan det sker hela tiden en utveckling som fungerar möjliggörande på sätt som strax innan inte kunde ha tänkts. Därför är det viktigt att projekten för att utveckla verksamhet och IT-stöd utförs parallellt och i samverkan det ena fungerar inte utan det andra. Enkla Web Services är möjliggörande Det är inte trovärdigt att, för alla deltagande kommuner, göra definitiva val vad gäller specifika produkter, mjukvaruleverantörer etc. därtill är inte kommunernas inköpskulturer tillräckligt lika. Därav skulle ha kunnat följt att det konkreta innehållet i en öppen teknisk plattform hade blivit urvattnat. Emellertid spelar oss nylig teknikutveckling i händerna så att en ökad teknisk öppenhet faktiskt kan åstadkommas nu. Framförallt gäller detta framväxten av s.k. enkla Web Services. Teknologin med enkla Web Services ger rätt hanterad god interoperabilitet mellan olika tekniska plattformar och är numera dessutom praktiskt väl beprövad när den används inom en organisation eller på ett välkontrollerat sätt mellan organisationer. En mycket bred skara av leverantörer stöder initiativen kring Web Services. Plattformar för applikationsintegration Dock löser inte enkla Web Services alla problem. Enkla Web Services inneboende egenskaper passar i sig självt bäst för online -fallet av integration mellan delar av hela IT-lösningen. För annan applikationsintegration, t ex när information lämpligen förs över satsvis eller efterhand skulle enkla Web Services endast lösa en del av problemet. Härvid finns i många sammanhang istället behov av egenskaper som s k EAI-produkter har (Enterprise Application Integration). EAI har dock brukat vara ganska dyrt både vad gäller licenser och införande. Det har dock kommit billigare produkter på senare tid. Det finns dessutom s k Open Source-initiativ mm inom området (dock inte alltid så beprövade ännu). Skulle inte dessa lösningar passa kan även Öppen teknisk plattform beskriva mönster där enkla Web Services skräddarsytt kombineras med olika kö-tekniker. Förutsatt att maskingränssnitten är välmodellerade bör inte val av något av ovanstående integrationssätt ge alltför stark inlåsning.

6 6(15) Fyra huvuddelar i plattformen För tidshorisonten bör följande huvuddelar ingå i Öppen teknisk plattform: Rörläggning Här definieras den tekniska rörläggningen för att förmedla meddelanden. Som nämns ovan tänks den bli baserad på enkla Web Services och på andra mönster kring applikationsintegration. Observera att plattformen inte specificerar produkt(er) för detta utan endast en standard/konvention att följa. Respektive kommun kan sedan välja exekveringsplattform enligt sin inköpskultur. Nyttomeddelanden Här beskrivs HUR nyttomeddelanden som utväxlas mellan delar av IT-lösningen ska specificeras när de tänkts ut i samband med verksamhetsutvecklingen. Det bör poängteras att arbetet med att specificera nyttomeddelandena kommer att bli lejonparten av arbetet med att skapa e-tjänster och utnyttja Öppen tekniska plattform inom Sambruksplattformsinitiativet. Regler och konventioner Hur anges hur nytto-anrop ska ske, vilka saker måste vara givna, avstämningar, kokbok etc. Teknikadministrativa delar Här specificeras diverse tekniska kring-saker som användarhantering, loggning mm. För en längre tidshorisont beskrivs nedan i kapitlet Forskning och utveckling områden som successivt bör utredas och specificeras. Följande skiss beskriver översiktligt hur samverkan mellan delar i en komplett E-tjänst skulle kunna gå till: e-tjänst A e-tjänst B Medborgare Företag Ex på samverkan inom Öppen teknisk plattform Verksamhetsapplikation X Verksamhetsapplikation Y Registerhållande myndighet 1 Registerhållande myndighet 2 Handläggare

7 7(15) Genomförbarhet Många av de kritiska framgångsfaktorerna vad gäller genomförbarhet är av organisatorisk art. Dessa tas inte upp i denna kortrapport utan behandlas i andra delar av initialarbetena för Sambruksplattformen. Nämnas bör dock att missionering, förvaltning av någon slags kokbok mm är oundgängligt för framgång. Vad gäller teknisk genomförbarhet så har, som nämnts ovan, den tekniska utvecklingen förbättrat genomförbarheten mycket för den skissade Sambruksplattformen. Detta gäller framförallt framväxten av enkla Web Services. Därmed får man anse att genomförbarheten för avsnittet Rörläggning är god. Även vad gäller koncept och plattformar för applikationsintegration (EAI) så ökar insikten brett i branschen nu. Vissa saker får anses helt trovärdiga redan nu, just ur Sambruksplattformsaspekt, medan andra bör hänskjutas till en senare tidshorisont. Genomförbarhet vad gäller former för Nyttomeddelanden bör också vara god, tekniskt sett. Här bör dock markeras att arbetet med verksamhetsprocessanalys, begreppsdefinitioner och annan semantik är avgörande förutsättningar för att definitionen av själva meddelandena ska bli lyckad. Rekommendationen blir dock att arbeta iterativt och inte t ex försöka definiera hela begreppsdomänen samtidigt, då riskerar man allvarliga förseningar. Generellt sett bör man i alla fall förstå att en mycket stor del av arbetet med att använda Öppen teknisk plattform handlar om att definiera nyttomeddelandena. För Regler och konventioner bör genomförbarheten vara god. Detta är en mindre del av plattformen, men icke desto mindre, viktig. Det som benämnts Teknikadministrativa delar kan ha den mest svåröverblickade genomförbarheten. Som nämns nedan så spelar ambitionsnivå enormt stor roll här. Om man håller en modererat försiktig ambitionsnivå (rekommenderas) bör genomförbarheten vara god, men i annat fall kan risken och kostnaden bli hög. Forskning och utveckling för en femårshorisont Sambruksplattformen måste förvaltas och nya utgåvor/versioner måste skapas allteftersom behov utvecklas, tekniken framskrider och erfarenheter erhålls. För femårshorisonten finns alltså helt naturligt ett successivt behov av forskning och utveckling (FoU) som stöd till normal versionshantering. För att hålla nere risker och förbättra beslutsöverblick rekommenderas på flera ställen i denna kortrapport iterativ plattformsutveckling vilket också på ett självklart sätt medför ett FoU-arbete. Ett specifikt FoU-område som förväntas är applikationsintegration (av EAI-typ). Framförallt rör detta sig om olika sorters bakgrunds överföring av information (asynkrona flöden). Här finns en framväxt av mönster och produkter som gör att vi ser ett rörligt mål i dagsläget. Detta bör följas under den kommande femårsperioden. På många sätt medför EAI en intressant potential till IT-nytta för framtiden. Statskontorets Infratjänste-upphandling, andra sätt att köpa IT-stöd som tjänst samt eventuellt även kommersiella tjänster över Internet av Web Service-typ är också givna områden att bevaka under femårsperioden. Ett annat speciellt FoU-område är konsekvenser av EU. Det kan vara allt ifrån ev. EMU över nya formkrav på kommuner till info-kommunikation via kommande EU-standarder (SHS Government e-link, TESTA etc.). Ett komplicerat teknikområde som behöver bevakas för framtiden är användar/rollhantering, där nivån allmänt idag inte är speciellt bra.

8 8(15) 3. INTRODUKTION Till att börja med bör konstateras att tekniskt sett är e-tjänster (dvs. interaktiva webbsidor kopplade mot verksamhetssystem) inte något speciellt obekant i dagens läge, utan stor erfarenhet finns i IT-branschen sedan ca 1996 att skapa sådana och klara av integration med diverse gamla och nya verksamhetsapplikationer. Ett av de bästa exemplen är Internetbanker, där man samtidigt lyckats få kunderna att uppleva höjd servicegrad samtidigt som bankerna har kunnat rationalisera sina interna processer. De flesta Internetbanker har en tät och välfungerande integration med gamla verksamhetssystem. Ett område som tidigare har varit ett problem för myndighetsstjänster har varit legitimation av medborgaren över Internet. Detta torde också vara undanröjt i och med Statskontorets upphandling av olika bankbaserade e-legitimationstjänster (som bör kunna framgångsrikt driftas via Statskontorets Infratjänste-upphandling). På många sätt handlar alltså e-tjänster för kommuner (enligt visionen om 24-timmarsmyndigheten) om systemintegration av olika sorter enligt samma huvudmönster som för Internetbanker, web-butiker mm: Std.syst Bankkonto Std.syst Fondkonto Skr.sytt. syst Leasingkonto Engagemangsbild Frontendintegr Bokfsyst Backendintegr Det som här kallats Front-end-integration och Back-end-integration har ofta olika behovsprofiler, t ex att informationen måste vara sekundfärsk eller att överföring kan få ske på några timmar eller nästa natt. Det som framförallt skiljer ut olika andra interaktiva e-tjänste-webbprojekt mot Sambruksplattformen är att Öppen teknisk plattform däri ska ha en högre generalitet och ge praktisk återanvändning mellan många kommuner. Generalitet och flexibilitet är i många fall praktiskt sett motståndare till tydlighet, väldefinierade kravspecifikationer och väl följda tidplaner. För att minimera sådana risker poängteras på flera ställen i denna kortrapport frågan om modererade ambitionsnivåer och iterativ utveckling av plattformen.

9 9(15) En mycket viktig sak att förstå i sådana här projekt är behovet av att definiera och standardisera överenskommelser mellan de (del)system som ska kommunicera för att ge en e-tjänst, t ex mellan en interaktiv webb-applikation och ett gammalt verksamhetssystem: Definitioner i femlagers-stack Processdefinition Processdefinition Visio-fil eller BPML etc Svårast Svårt Välj integrationsprodukt Överenskommelser Syntaxdefinition Semantikdefinition Semantikdefinition Syntaxdefinition Välj integrationsprodukt Word-dokument eller RDF-schema etc XML-schema t ex I vårt fall Web Services (ofta annars MQ eller förr Corba etc) Ren datakom Ren datakom TCP/IP dominant idag HW Även om det ska poängteras hur viktigt det är med de övre delarna så får man heller inte ha alltför hög ambitionsnivå så arbetet blir överteoretiskt. Man bör hellre arbeta med iterativa, successiva utgåvor.

10 10(15) 4. TRENDER OCH VISIONER Såsom nämnts i inledande delar så bör vi ha stor nytta av att tekniken med enkla Web Services (dvs. SOAP/http) har växt fram. Det problematiska plattformsberoende som tidigare har hindrat oss blir mycket mindre genom att Web Services (rätt använda) ger bra interoperabilitet. Tidigare var Corba relativt lovande, men fick ingen stor framgång, självständigt sett. Ett annat alternativ hade varit en produkt som IBM MQ Series som finns för en stor mängd plattformar, men då finge man en produktinlåsning och en licenskostnad som man slipper med Web Services. Såsom också nämnts så ökar medvetenheten i Sverige nu om olika EAI- plattformar för applikationsintegration (Enterprise Application Integration). Detta område blir mycket intressant att följa. Det har nyligen anats en viss prispress inom området. Förr var produkterna mycket dyra, men genom ankomsten av t ex BizTalk (i o f s dyr för att vara en Microsoftprodukt) och olika Open Source-lösningar kan kostnadsbilden framgent förmodas bli annorlunda och kanske mer differentierad. På sikt kommer troligen mycket att ske inom Web Services-världen och anknutna sektorer. Standardutveckling som WS-Transactions, WS-Security och WS-Reliability, liksom olika delar av ebxml kommer att påverka både enkla Web Services och EAI. Ett problem kan möjligen bli att dessa nya standarder tillför en stor komplexitet som kan överskugga en av finesserna med enkla Web Services idag: just enkelhet. Utvecklingen måste noga bevakas. I dagsläget finns det två dominerande och konkurrerande teknikplattormar för modern applikationsutveckling. Den ena inkluderar Microsoftverktyg som ASP.NET, Visual Basic och C#, Den andra baseras på Java. Båda är rimliga och vettiga miljöer som kan producera bra lösningar om än kulturerna har skillnader. De senaste åren har tätplatsen varannan gång växlat mellan de här två lägren då nya lanseringar gjorts. Just nu ligger kanske.net något före men detta kommer säkert att växla igen. Båda lägren verkar hängivna till Web Services. Om man studerar de senaste tjugo åren kan man också förutse att det borde komma någon helt ny utvecklings- och teknik-plattform om något år, men detta går inte att säga något om i dagsläget. En parallellt rörelse är olika sorters gratis programkod, Open Source, Freeware, Shareware och vad det kan heta. Så här långt kan vi se att Linux har blivit en helt etablerad företeelse av detta slag, men det kan bli mer. Man ska dock vara medveten dels om att det brukar behövas ett förpackande bolag som levererar lösningen (en roll möjligen Sambruksplattformen skulle kunna ta) dels att det ofta krävs en stor community av hängivna programmerare som gratis och med endast äran som betalning ( cred ) vidareutvecklar, letar fel mm. Om Open Source-tanken ska användas inom Sambruksplattformen måste man ha tänkt ut hur det här ska organisatoriskt fungera Open Source är inte nödvändigtvis något som lyckas automatiskt och av sig själv. Sammanfattningsvis kan man säga att Sambruksplattformen tekniskt sett ligger bra till i tiden och bör ha god potential framöver.

11 11(15) 5. SAMBRUKSPLATTFORMENS TEKNISKA DELAR FÖR HORISONTEN Nedan följer förslag för hur Öppen teknisk plattform för Sambruksplattformen bör utformas. Tidshorisonten är vald för att den är näraliggande vilket tvingar oss att tänka på konkret genomförbara lösningar och inte vad som utlovas i framtiden (framtidsbevakning bör OCKSÅ göras, men det är en annan aktivitet). Tiden är naturligtvis också vald för att man vill kunna använda Sambruksplattformen så snart som möjligt Rörläggning Eftersom det inte är trovärdigt för Sambruksplattformen att diktera exakt vilka teknikplattformar och utvecklingsmiljöer som alla kommuner ska använda behövs en hög grad av interoperabilitet i Öppen teknisk plattform. Denna interoperabilitet tänks tillföras genom användning av enkla Web Services, dvs. SOAP/http(s). I nästa skede blir det viktigt att definiera exakt vilka varianter av SOAP/http(s) som ska användas så att utmärkt funktionalitet och interoperabilitet samtidigt erhålls (områden såsom returparametrar och binärdata är exempel som måste definieras). Det är värt att poängtera att enkla Web Services enligt SOAP/http(s) inte är någon speciell middlewareprodukt som ska installeras/driftas. Istället så har alla moderna och vanliga exekveringsmiljöer i sig stöd för detta, t ex frekvent använda Javamiljöer såsom BEA och IBM, liksom.net från Microsoft. e-tjänst A e-tjänst B Medborgare Företag Handläggare etc Ex på integration inom Öppen teknisk plattform Tunn webapplikation Hel webapplikation Ex: Onlinefråga via Web Service Ex: Onlinefråga via SHS. Ofta via Infratjänsten Existerande verksamhetsapplikation X Existerande verksamhetsapplikation Y Registerhållande myndighet 1 Registerhållande myndighet 2 Ex: Satsvis överföring via Web Service och kö Handläggare etc = integrations-logik Vad gäller online-anrop av synkron karaktär som mellan e-tjänst B och verksamhetsapplikation X i figuren ovan fungerar Web Services rakt av.

12 12(15) Däremot för asynkrona flöden (vanligen mera av back-end-integrations -karaktär) som mellan B och Y i figuren, räcker inte enkla Web Services enligt SOAP/http(s) i sig. För tidshorisonten bör man inte räkna med att asynkron Web Services-meddelandeförmedling kan anses vara beprövat. Här föreslår vi att man så länge använder SOAP/http(s) som gränssnitt till en egen-implementerad kö i respektive kommuns utvecklingsmiljö. Här innehåller alltså inte Öppen teknisk plattform hela definitionen för överföringsmekanismen, utan endast ett mönster, t ex: Sändande appl. SOAP/http(s) Mottagande kö-yta Egen kö i relations-databas etc Mottagande appl. (hämtar i tabell i db I vissa fall behövs ingen mellan-kö, utan mottagande applikation kan anses vara så snabb och ha så hög tillgänglighet att anrop direkt kan ske. För mer avancerad EAI kan en mer omfattande lösning behövas, t ex interoperabla sätt att integrera med BizTalk, Open Source EAI-lösningar etc. Här har tiden för denna kortrapport inte räckt till utan detta för studeras senare. Web Services bedöms för den aktuella tidshorisonten inte få beprövad transaktionshantering, varför man inte kan utgå från att allt-eller-inget-transaktioner (sk. ACID) kan uppnås. Mönster för s k långa transaktioner bör då istället användas. För integration via SHS med t ex registerhållande myndigheter förutsätts att SHS version 1.2 finns implementerad så att enkla Web Services kan användas för att anropa SHS-tjänster. Troligen kommer man ofta att vilja drifta sådana kopplingar inom Statskontorets Infratjänst-upphandling. Skulle inte version 1.2 finnas klar vore det en relativt liten insats att specifikt integrera mot det gamla SHS-API:et. I något fall kan t ex en stor kommun också finna det mycket rimligt att använda SHS även internt, som en EAI-motor Slutsatser Rörläggning utgörs av enkla Web Services enligt SOAP/http(s) Online/synkront fungerar väl med denna lösning Asynkrona flöden kan behöva egenimplementerade köer för meddelandeförmedlingen Aktiviteter/leverabler A. Definiera exakt vilka varianter av SOAP/http(s) som ska användas B. Förtydliga mönster för långa transaktioner C. Förtydliga mönster för asynkron meddelandeförmedling D. Förtydliga integrationsmöjligheter med EAI-motorer.

13 13(15) 5.2. Nyttomeddelanden Nyttomeddelandena är de som skapar den egentliga nyttan de överför applikations-informationen. Inom Öppen teknisk plattform definieras endast HUR dessa ska specificeras, inte själva definitionerna, dessa måste göras inom respektive verksamhetsstödsmodellering. Aspekter som ska anges i regelverket för definitionen av nyttomeddelanden är saker som syntax, semantik, sekvens, kontext etc. För att förenkla arbetet är det troligt att man vill gruppera ett antal s k icke-funktionella egenskaper i kommunikationsprofiler som sedan är enkla att referera till vid definitionen av nyttomeddelandena. Se Regler och konventioner Slutsatser Det är mycket viktigt att definiera ett regelverk för HUR nyttomeddelanden definieras för att undvika anarki och för att skapa förutsättningar för funktionell interoperabilitet Kommunikationsprofiler är ett sätt att förenkla genom att gruppera icke-funktionella egenskaper Aktiviteter/leverabler A. Definiera regelverket för definition av nyttomeddelanden B. Skapa exempel på nyttomeddelanden definierade på detta sätt Regler och konventioner Ett antal givna förutsättningar och konventioner måste beskrivas för att datakommunikation ska kunna bli framgångsrik. Vid definitionen av nyttomeddelanden vore det praktiskt att kunna referera till ett mindre antal uttänkta kommunikationsprofiler vad gäller icke-funktionella egenskaper. Icke-funktionella egenskaper kan vara t ex: Latenstidskrav Genomströmningskrav för olika stora datamängder Tillgänglighetskrav Säkerhetsnivåkrav (här menas framförallt intrångsskydd etc.) Aktualitetskrav (hur färskt datat behöver vara) Asynkron eller synkron kommunikation Krav på transaktionshantering (ACID, kö med leveransskydd, Långa transaktioner etc.) Här bör också definieras hur man gör undantag från de givna kommunikationsprofilerna. En synnerligen viktig del av plattformen är en kokbok som på ett mycket praktiskt sätt ger vägledning i hur en e-tjänst baserat på plattformen kan skapas. Kokboken behöver inte på något sätt visa alla möjliga varianter, utan endast några typiska. Kokboken skulle också kunna kompletteras t ex med webforum och träffar för erfarenhetsutbyte mellan kommunerna. Utanför denna kortrapport ligger de organisatoriska frågorna, men det bli mycket viktigt att kokboken får en förvaltning och vidareutveckling, liksom att det finns missionärer som säljer in det här sättet att arbeta så att inte plattformsanvändandet blir spretigt och ge minskade skalfördelar.

14 14(15) Slutsatser Regler och konventioner är viktiga Kommunikationsprofiler torde vara till god hjälp vid definition av nyttomeddelanden Kokbok, missionering m.m. är avgörande framgångsfaktorer Aktiviteter/leverabler A. Regler och konventioner behöver beskrivas. B. Ett antal kommunikationsprofiler behöver beskrivas C. Kokbok ska skapas 5.4. Teknikadministrativa delar Här hanteras det som ibland beskrivs som ramverksfunktioner. Det gäller kring-saker som användarhantering, rollhantering, aktivitetsloggning, felhantering, säkerhet mm. Många av dessa saker är ganska lätta att skapa, det är mest att bestämma sig för några val bland alla tänkbara varianter. Vad gäller säkerhet menas här främst intrångsskydd, brandväggar etc. Det finns idag ganska etablerade mönster för hur sådant utförs. Vad gäller e-legitimation/e-underskrift tänker vi oss att basera oss på Statskontorets upphandling. Den svåraste delen är användarhantering (här inkluderas rollhantering, rättigheter etc.). Det finns stora s k BKS-lösningar (Behörighetskontrollsystem), det finns initiativ vad gäller s k metaanvändarkataloger mm. Inget av detta känns helt beprövat idag, och erfarenheterna från genomförda projekt avskräcker ofta både vad gäller teknik och kostnad/tid. Nästan alla verksamhetssystem har egen användar/roll-hantering var för sig, LAN-inloggning brukar ha egen, telefonväxeln har egen, intranätwebben har egen, web-butik-lösningar har egen etc. I och med komplexiteten, svårigheten att göra något generellt och flexibelt som samtidigt är lättimplementerat och billigt etc. så tvingas man nog rekommendera att Öppen teknisk plattform för tidshorisonten inte innehåller någon heltäckande lösning för detta. Istället får man lösa detta specifikt per implementation, vilket är lättare. Området bör bevakas noga för framtiden. Emellertid rekommenderas att definiera några teknikmeddelanden för inloggning, roller mm som bör kunna standardiseras redan nu även om implementationen bakom blir specifik Slutsatser Många teknikadministrativa delar är relativt lätta att definiera Användar/roll-hantering är tyvärr ett mycket besvärligt område idag om lösningen ska bli generell Aktiviteter/leverabler A. Definiera teknikadminstrativa delar som aktivitetsloggning, felhantering mm B. Skapa några mönster för hur intrångsskydd, brandväggar mm kan användas C. Definiera teknikmeddelanden för inloggning, roller mm

15 15(15) 6. FÖRVALTNING AV SAMBRUKSPLATTFORMEN Öppen teknisk plattform inom Sambruksplattformen måste ges en organisation och ett ägarskap som medför ansvar, aktiv förvaltning och vidareutveckling. Erfarenheten av olika sorters återanvändning genom de femton år som begreppet använts aktivt är att det ofta faller på hur det som ska återanvändas ska förvaltas (och finansieras). Tyvärr är det heller inte ovanligt att återanvändningen har gett dålig effekt. Därför är det synnerligen viktigt att dessa frågor ägnas mycket stor omsorg. Några av utmaningarna: Att hänga med i den allmänna teknikutvecklingen, inte för snabbt, inte för långsamt Att inte bli en stat i staten som inte klarar att svara upp till förändrade verksamhetsbehov eller tekniska behov Att övertyga utvecklare, IT-arkitekter och leverantörer att verkligen använda det som finns i en plattform och inte hitta på nya varianter. Not-invented-here -syndromet är mycket starkt. En plattform måste oupphörligen säljas in och missioneras för utav entusiastiska människor. Tekniskt stöd måste till ( help desk ). Kokbok, förebildskod, info om lyckade applikationer mm måste spridas mycket aktivt.