Förstudie avveckling av EPi-Server för EBH
Förstudie avveckling av EPi-Server för EBH-stödet Alternativ 0 Behåll befintlig funktionalitet och design och behåll även EPi-Server Fördelar: o Man slipper den engångskostnad som blir med alternativ 1 respektive alternativ 2 Nackdelar: o Koden kommer även fortsatt att vara föråldrad, vilket innebär stora begränsningar i vilken nyutveckling som är möjlig att göra i systemet. o Begränsningarna i den nyutveckling som är möjlig innebär bland annat att utrymmet att göra anpassningar som underlättar för kommunernas behov är avsevärt mindre. o Det kommer även fortsatt att vara lika tidskrävande som nu för utvecklarna att rätta buggar och nyutveckla, vilket innebär fortsatt höga utvecklingskostnader per utvecklingsuppgift o Det finns inga automattester i EBH-stödet idag och är inte heller möjligt att utveckla i befintligt system. Automattester ger säkrare test vid ny utveckling och minskar den tid som verksamhetens objektspecialister måste avsätta för testning. o Det kommer även fortsatt att vara lika tidskrävande som nu för verksamhetens objektspecialister att testa och återtesta ny utveckling o Enda systemet med EPi-Server inom länsstyrelsernas driftsmiljö o Årliga licenskostnader, som kommer att öka för att få bästa kapacitet med EPi-Server o IT-enheten har ingen egen kompetens inom EPi-Server, vilket innebär merkostnad för extern konsult för hantering av EPi-Serverspecifika frågor o Ingen långsiktighet i att EBH-stödet byggs på EPi-Server, enligt IT-enhetens bedömning o Utvecklingslicensen för EPi-Server tillåter bara att en webbserver på utvecklingsservern använder licensen. Detta betyder att konsulterna får turas om för att lägga upp ny utveckling på servern, vilket utgör ett hinder i utvecklingsarbetet och är mindre effektivt. Alternativ 1 Behåll befintlig funktionalitet och design, men ta bort beroendet av EPiServer. Fördelar: o Licenskostnaderna för EPiServer försvinner o Beroendet av den EPiServer-specifika koden försvinner o Enligt konsultens uppskattning ca 10-20% mindre utvecklingstid vid ändring och tillägg av befintlig kod o OM EBH-stödet INTE ska finnas kvar på längre sikt kan det vara en ekonomisk vinst i att behålla befintlig arkitektur och endast ta bort EPiServer-kopplingarna Nackdelar: o En engångskostnad för utvecklingsinsatsen o Koden kommer även fortsatt att vara föråldrad, vilket innebär stora begränsningar i vilken nyutveckling som är möjlig att göra i systemet. o Begränsningarna i den nyutveckling som är möjlig innebär bland annat att utrymmet att göra anpassningar som underlättar för kommunernas behov är avsevärt mindre. o Det kommer även fortsatt att vara tidskrävande för utvecklarna att rätta buggar och nyutveckla, vilket innebär fortsatt höga utvecklingskostnader per utvecklingsuppgift o Det finns inga automattester i EBH-stödet idag och är inte heller möjligt att utveckla i befintligt system. Automattester ger säkrare test vid ny utveckling och minskar den tid som verksamhetens objektspecialister måste avsätta för testning. o Det kommer även fortsatt att vara lika tidskrävande som nu för verksamhetens objektspecialister att testa och återtesta ny utveckling. o Möjligheter att förbättra användarvänligheten finns alltid, men är mer begränsade med alternativ 1 jämfört med alternativ 2 Estimat uppskattad tid för utvecklingsinsatsen: 600 – 700 timmar Observera dock att detta är endast ett preliminärt estimat. Utan en komplett detaljerad lösningsspecifikation kan konsulten inte förbinda sig till en mer exakt uppskattning av antal timmar. Alternativ 2 Utgå från önskad funktionalitet och skapa ett nytt EBH-stödet 3.0. Beroendet av EPiServer tas samtidigt bort. Fördelar: o Licenskostnaderna för EPiServer försvinner o Beroendet av den EPiServer-specifika koden försvinner o Systemet blir betydligt enklare och billigare att vidareutveckla, förvalta och underhålla o Kortare utvecklingstid per utvecklingsuppgift. Enligt konsultens uppskattning ca 40-50% mindre utvecklingstid vid ändring och tillägg av befintlig kod o Kortare startsträcka när nya utvecklare ska sätta sig in i befintlig kodbas o Stor valfrihet i vilka ändringar och förbättringar som kan göras i systemet, vilket även innebär möjligheter att göra anpassningar som underlättar för kommunernas behov o Stora möjligheter att förbättra användarvänligheten o Möjlighet att anpassa till nya behov längre fram, vilket även innefattar möjlighet att anpassa till andra enheter (surfplatta, telefon) o Möjlighet att bygga in automattester. Automattester ger säkrare test vid ny utveckling och minskar den tid som verksamhetens objektspecialister måste avsätta för testning. Nackdelar: o Hög engångskostnad för denna utvecklingsinsats Estimat uppskattad tid för utvecklingsinsatsen: 1000 – 1200 timmar Observera dock att detta är endast ett preliminärt estimat. Utan en komplett detaljerad lösningsspecifikation kan konsulten inte förbinda sig till en mer exakt uppskattning av antal timmar. Hur ser framtiden ut för EBH-stödet? Roller för Länsstyrelsen, Naturvårdsverket, kommunerna? Ska EBH-stödet under ett antal år framöver finnas kvar och vara det nationella systemet för uppgifter om förorenade områden? Kommer EBH-stödet även på ett antal års sikt att vara lika viktigt som idag? Kan EBH-stödet till och med få ännu större betydelse de närmaste åren framöver? Eller ska något annat system ta över denna roll på några års sikt? Från och med i år hämtar Naturvårdsverket data till nyckeltalsredovisningen direkt från EBH-stödet. Systemet ger också underlag till bland annat miljömålsuppföljningar. Nu är det också på gång att kommunerna ges tillgång till EBH-stödet. Det är därför ännu viktigare att systemet är användarvänligt och fungerar väl. Tre aktörer finns idag med i bilden – Länsstyrelsen, Naturvårdsverket och kommunerna. Kommer alla dessa aktörer att ha kvar samma roller som idag? Finns det någon annan myndighet med annat system som kan bli aktuell att ta över motsvarande funktion inom några år? Schematisk bild av hela systemet EBH-stödet 2015-03-11 Underlaget är framtaget inför EBH-stödets beslutandegrupps möte den 17 mars. Sida 1 av 2 Jämförelse kostnader mellan alternativen 0, 1 och 2 utifrån Altrans Förstudie avveckling av EPiServer för EBH-stödet *Tabellen visar uppskattade kostnader för alternativen 0, 1 och 2. En årlig driftskostnad på 244 000 kr för produktionsmiljö, utvecklingsmiljö och testmiljö är konstanta och kommer att kvarstå oavsett vilket alternativ som väljs. Eftersom denna summa inte skiljer mellan de olika alternativen har denna kostnad inte tagits med i ovanstående tabell. Alternativ 1 Uppskattat utifrån aktuellt underlag kommer investeringskostnaderna att sparas in på i storleksordningen 1,5-2 år. Altrans uppskattning av antal timmar för att genomföra alternativ 1 är 600-700 timmar. Investeringskostnaden för alternativ 1 är 480 000-560 000 kr (beräknat på en timkostnad på 800 kr för Altran, vilket är den aktuella uppgift vi har). I tabellen har den högsta kostnaden använts, motsvarande 700 timmar. Altrans uppskattning i utvecklingstid som kan sparas vid alternativ 1 är mellan 10-20 %. I tabellen har ett medelvärde använts på 15 %. Alternativ 2 Uppskattat utifrån aktuellt underlag kommer investeringskostnaderna att sparas in på i storleksordningen 1-1,5 år. Tabellen ovan visar att med alternativ 2 kommer det att efter denna investeringsinsats att vara möjligt att antingen få ut i storleksordningen dubbelt så mycket utveckling för samma kostnad eller att alternativt få samma mängd utveckling till halva kostnaden. Altrans uppskattning av antal timmar för att genomföra alternativ 2 är 1 000-1 200 timmar. Utvecklingskostnaden för alternativ 2 är 800 000-960 000 kr (beräknat på en timkostnad på 800 kr för Altran, vilket är den aktuella uppgift vi har). I tabellen har den högsta kostnaden använts, motsvarande 1 200 timmar. Altrans uppskattning i utvecklingstid som kan sparas vid alternativ 2 är mellan 40-50 %. I tabellen har ett medelvärde använts på 45 %. 2015-03-11 Underlaget är framtaget inför EBH-stödets beslutandegrupps möte den 17 mars. Sida 2 av 2 Förvaltningskostnader Förvaltningens kostnader för kravställan och test är uppskattade utifrån användarrådets samordnares tidredovisning på dessa koder i Agresso. I realiteten tillkommer det ytterligare tid för övriga testare i användarrådet. Denna tid ersätts dock inte inom förvaltningens budget. Utifrån aktuellt underlag uppskattar användarrådets samordnare att den tid som förvaltningen lägger ner på kravställan och test kommer att kunna minskas med cirka 25 % om alternativ 2 väljs. Förstudie avveckling av EPiServer för EBHstödet Kompletterande frågor och svar 2015-02-23 1 Innehåll 1 Alternativen .............................................................................................................. 3 Alternativ 0.................................................................................................................................................... 3 Alternativ 1.................................................................................................................................................... 3 Alternativ 2.................................................................................................................................................... 3 2 Förklaring till förstudiens avsnitt 1.11 ........................................................................ 3 Hur långt fram i tiden är det som är ”några år”? .............................................................................................. 3 3 Nyttorna med alternativ 1 .......................................................................................... 3 Minskade licenskostnader .............................................................................................................................. 3 Minskad kodbas............................................................................................................................................. 3 Lättare applikation ......................................................................................................................................... 4 Ingen främmande fågel .................................................................................................................................. 4 Kompetenstillgång ......................................................................................................................................... 4 Lättare att utveckla ........................................................................................................................................ 4 4 Nyttorna med alt. 2 ................................................................................................... 4 Minskade underhålls- och vidareutvecklingskostnader ................................................................................... 4 Tillgodose dagens behov ............................................................................................................................... 5 Möjlighet att anpassa till andra enheter .......................................................................................................... 5 Modern design............................................................................................................................................... 5 Tillgänglighet ................................................................................................................................................ 5 5 Vad ingår? ................................................................................................................. 6 Alternativ 1.................................................................................................................................................... 6 Alternativ 2.................................................................................................................................................... 6 6 Tidsvinster för de olika alternativen............................................................................ 6 Allt beror på utvecklingstakt .......................................................................................................................... 6 2 1 Alternativen De olika alternativ som finns för EBH-stödet är: Alternativ 0 EBH-stödets kodbas lämnas som det är. EPiServer-beroendet och all kod i övrigt lämnas som det är, och underhåll och vidareutveckling sker på plattformen Microsoft asp.net/Webforms med EPiServer Alternativ 1 Kopplingarna till EPiServer tas bort, vilket lämnar en ren Microsoft asp.net/Webformsarkitektur Alternativ 2 Existerande ”backend1” (Reporting Services, MS SQL databas och databaslager (EBHWS från förstudien)) behålls, medan logik och användargränssnitt byggs om från grunden på Microsoft asp.net MVC-arkitektur 2 Förklaring till förstudiens avsnitt 1.11 Hur långt fram i tiden är det som är ”några år”? Med några år menade jag här 2-3 år. En mer rättvisande formulering är kanske ”Eller kommer eventuellt någon annan myndighet med annat system att ta över motsvarande funktion innan något förändringsbehov av EBH-stödet uppstår?” 3 Nyttorna med alternativ 1 Vinsterna med att plocka bort EPiServer-beroenden är: Minskade licenskostnader EPiServer är förknippat med en årlig kostnad, och föremål för versionsuppdateringar när en ny version föreligger. Utan EPiServer-beroende kapas licenskostnad och eventuella framtida licenskostnadsökningar. Minskad kodbas Varje kodrad i en applikation är en potentiell felkälla. En inte föraktlig mängd kod i EBHstödet rör kopplingar mot EPiServer. Ofta används i EBH-stödet EPiServer-specifik funktionalitet som endast duplicerar redan befintlig funktionalitet i bas-plattformen Microsoft asp.net/ Webforms. Kodbibliotek som EPiServer har kända in- och utgångar. Vad som sker ”där inne” är dock okänt. Sker något oväntat eller oförutsett inne i ett externt kodbibliotek är det inget som en utvecklare kan påverka. Ju mindre man använder 1 I ett datorystem brukar man skilja på frontend och backend. Frontend är användargränssnitt och kod för att visa information, Backend är datalager, dataåtkomst och databearbetning. tredjepartsbibliotek, desto bättre kontroll över programmet har man som utvecklare. Utan EPiServer minskas antal kodrader vilket i sin tur ger mindre mängd kod att underhålla och ett system som är lättare att sätta sig in i och förstå vid underhåll, funktionalitetstillägg och förändringar. Lättare applikation Varje kodrad tar också tid att utföra när applikationen körs. Med färre kodrader och inga anrop av funktioner i EPiServer-biblioteket, kommer EBH-stödet att blir snabbare och mer ”responsivt”. Ingen främmande fågel Inget annat system i Länsstyrelsens IT-miljö använder EPiServer. Ur driftsynpunkt är det bra med en ”homogen” miljö. Ren Microsoft-kod borde ur den synvinkeln vara att föredra. För EBH-stödets del är också EPiServer främmande. EPiServer är främst ett CMS2-system, i likhet med SharePoint (som bland annat används som ramverk för Insidan). EBH-stödet har mycket lite att göra med publicering av texter, nyheter med mera, som syftet med ett CMSsystem är. Kompetenstillgång Det finns betydligt fler IT-konsulter som är bekanta med Microsoft asp.net/ Webforms än Webforms/EPiServer Lättare att utveckla Även utvecklingsmiljön kräver en EPiServer-licens. Dock finns endast en licens för utveckling, vilket gör att utvecklarna i teamet måste vänta på varandra vid testkörning och felsökning, samt stoppa EPiServer mellan varje pass. Detta skapar onödiga stopp och avbrott i utvecklinsprocessen, och förlänger utvecklings- och felksökningstid. 4 Nyttorna med alt. 2 Med alternativ 2 får man samtliga de nyttor som erhålls med alternativ 1. Utöver nyttorna med alternativ 1 kommer alternativ 2 att ge: Minskade underhålls- och vidareutvecklingskostnader Existerande kod är, även med EPiServer-beroenden borta, snårig, och med många oväntade kopplingar och beroenden. Samtidigt är stora kodblock och delar av användargränssnittet duplicerade, där samma kod borde kunna användas. För varje fel som ska hittas eller förändring som ska göras i existerande kod, krävs en djup analys av stora delar av koden för att hitta rätt, och det är svårt att veta om förändringen har oväntade effekter på andra ställen i koden, eller om den förändring man gjort verkligen täcker in alla användningsfall. 4 2 Content Management System (innehållshanteringssystem) Eftersom användargränssnitt och logik i Webforms-arkitekturen är hårt sammanknuten, finns mycket små möjligheter att skapa automatiska tester av koden – Idag finns inga automatiska tester. Arkitekturen för alternativ 2 ger betydligt större möjligheter att skriva automatiska tester, vilket resulterar i minskad risk för oväntade följdproblem med tidsödande felsökningar som följd, när förändringar i befintlig kod görs. En ny utvecklare kan göra förändringar utan oro för oväntade följdfel. Automatiska tester kan eliminera behovet av manuell genomgång av alla aspekter av applikationen (så kallad regressionstestning3) vid varje förändring, vilket sparar tid vid acceptanstest inom verksamheten vid Länsstyrelsen. Tillgodose dagens behov Ett program som EBH-stödet modellerar en verklighet och process så som den är när programmet skapas. Över tid förändras verkligheten och processen kan behöva ändras. Man behåller dock gärna samma process som tidigare (då det är den process programmet stödjer). I stället för att underlätta processen, blir programmet ramen för processen. Den process som modellerades för 6-7 år sedan kanske inte är den optimala idag. En omskrivning av logik och användargränssnitt skulle ge tillfälle att om så önskas arbeta om den process och modell applikationen ska ge stöd till. Möjlighet att anpassa till andra enheter asp.net/Webforms lanserades långt innan den första smarta telefonen eller surfplattan lanserades. Det är gjort för presentation på datorskärm, och mycket svårt att anpassa till mindre skärmar. Med alt. 2 finns alla möjligheter att skapa användargränssnitt med vad som kallas för ”responsiv design”, dvs. att utseende och sidlayout anpassar sig till vilken typ av enhet (dator, surfplatta, telefon) som används. Modern design Vi är idag betydligt mer ”internet-vana” än för 6-7 år sedan, och har (andra) förväntningar på hur en webbapplikation ska bete sig. ”Användarupplevelse” är något man kanske mest talar om i kommersiella applikationer, men det är lika viktigt för att få acceptans för och användning av ett verksamhetsstöd. Har man använt EBH-stödet många år känner man sig hemma i den miljön, men om en mängd nya användare ska ges tillgång till EBH-stödet kan det vara värt att arbeta om utseende och pedagogik, för att bättre svara upp mot nya användares förväntningar. Tillgänglighet Tillgänglighet handlar om hur lätt applikationen är att använda, oberoende av eventuella funktionshinder. Länsstyrelsens webbapplikationer ska uppfylla tillgänglighetskraven i standarden WCAG 2.0, nivå AA. För att EBH-stödet ska uppfylla dessa krav, krävs 5 3 När man efter ett funktionstillägg eller felavhjälpning kontrollerar att de gjorda förändringarna inte förorsakat nya fel omskrivning av användargränssnittet, vilket, då koppling mellan webbsida och bakomliggande kod i befintlig arkitektur är djup, blir ett i sig mycket omfattande projekt. Med alternativ 2 kan hänsyn till tillgänglighetskrav tas med från start. 5 Vad ingår? Estimaten är Altran-tid. I samtliga fall ingår lösningsspecifikation och leverans enligt specifikation (inkl. ev. buggfixar för att uppnå detta), samt assistans vid produktionssättning. Alternativ 1 För alternativ ett är kravbilden enkel, och begränsar sig i stort sett till att EBH-stödet ska se ut och fungera på samma sätt som tidigare, utan EPiServer. Här krävs sannolikt mycket lite administrativ tid. Alternativ 2 Alternativ två är komplexare, och beror mycket på hur stora förändringar, jämfört med dagens system, som tas in i projektet. Andra faktorer som påverkar är självklart hur mycket tid som ska läggas på workshops, kravmöte, automattester mm. Jag har i uppskattningen försökt väga in en ”normalnivå” på dessa aktiviteter, samt enhetstestning4 av de viktigaste koddelarna. Enhetstestning tar tid vid det initiala utvecklingsarbetet, men eliminerar mycket tid och osäkerhet vid förvaltning, underhåll och förändringar. 6 Tidsvinster för de olika alternativen Allt beror på utvecklingstakt Då framtida (för mig okända) behov av underhåll och nytutveckling är det som styr ekonomin i de olika alternativen, är det omöjligt att uppge denna faktor i siffror. I stället 6 4 Med enhetstestning testas små kodblock med olika indata för att verifiera att utdata blir korrekt i alla lägen. Teorin är att om alla små kodblock testas och fungerar som tänkt, kommer också helheten att fungera som tänkt. försöker jag illustrera det med detta diagram: På vertikal axel har vi kostnad. Alternativ 0 har ingen initial kostnad, alternativ 2 en högre initial kostnad, och alternativ 1 befinner sig någonstans däremellan. På horisontell axel har vi hur mycket förändringar som ska utföras av EBH-stödet i framtiden. Ju mer förändringar, desto snabbare kommer den initiala kostnaden att ge avkastning i form av att utvecklings- och underhållskostnaderna blivit lägre. Man kan också komma till en punkt för alternativ 0 och 1 där en önskad förändring inte går att åstadkomma alls på den plattformen, utan man tvingas att ändå välja alternativ 2 vid en senare tidpunkt. Mycket av de utvecklingsinsatser och kostnader som lagts på ”gamla” plattformen går då förlorade. Uppskattningsvis blir, vid förändringar av och tillägg till befintlig kod, vinsten med alternativ 1 10-20%, medan vinsten med alternativ 2 troligen skulle vara runt 40-50%, dvs. 7 tillägg till och förändringar av EBH-stödets kod skulle ta ca halva tiden jämfört med hur koden ser ut idag. 8 Förstudie avveckling av EPiServer för EBHstödet 2015-02-12 1 Innehåll 1.1 EBH-stödet idag .................................................................................................................................... 3 1.2 EBH och EPiServer idag .......................................................................................................................... 4 1.3 Avveckling av EPiServer-beroenden ....................................................................................................... 4 1.3.1 Behåll befintlig arkitektur .............................................................................................................. 4 1.3.2 Nytt EBH-stöd med ASP.NET MVC – EBH-Stödet 3.0 ....................................................................... 5 1.4 Rättigheter/Behörighetsnivåer ............................................................................................................... 5 1.5 Modernisering av kod ........................................................................................................................... 6 1.5.1 Dagsläge ....................................................................................................................................... 6 1.5.2 Framtid ......................................................................................................................................... 6 1.5.3 Tillgänglighet ................................................................................................................................ 8 1.6 Kompatibilitet med andra/senare webbläsare, touchskärmar, små skärmar ............................................ 8 1.6.1 Internet Explorer 11version 11.0.9600.17501 ................................................................................ 8 1.6.2 Google Chrome version 40.0.2214.111 m...................................................................................... 8 1.6.3 Firefox version 35.0.1 ................................................................................................................... 9 1.6.4 Pekskärmar/surfplattor/telefoner .................................................................................................. 9 1.7 SharePoint-integration ........................................................................................................................ 10 1.8 Ärendehantering ................................................................................................................................. 10 1.9 Kommunernas åtkomst till EBH-stödet - Kommunaccessen ................................................................. 11 1.10 API .................................................................................................................................................. 13 1.11 Sammanfattning och rekommendation ............................................................................................ 14 1.1 EBH-stödet idag EPISERVER WEB FORMS EBH REPORTING SERVICES EBH WS SQL DATABAS ASP.NET EBH-stödet utgörs idag av tre komponenter: Webbapplikationen EBH som är en ASP.NET-lösning med Web Forms-arkitektur. Ovanpå denna finns ett starkt kodmässigt beroende till EPiServer, vars funktionalitet dock används i mycket liten utsträckning. I EBH-blocket sker all presentation och behandling av data. Data lagras i en Microsoft SQL databas All kommunikation mellan webbapplikation (EBH) och datalager sker via IISapplikationen EBH WS. Detta är en Microsoft WCF1-applikation som tillhandahåller en 3 1 Windows Communication Foundation uppsättning SOAP2-webbtjänster, som hämtar, uppdaterar och lagrar data i databas, samt hämtar data från externa system (idag endast Vattenförvaltningens IT-system Vatteninformationssystem Sverige; VISS). Reporting Services används för rapportuttag för utskrifter och export till vanliga format som PDF, Excel mm. I texten som följer, avses med ”EBH” blocket/systemdelen EBH i bilden ovan, medan EBH-stödet syftar på hela systemet; EBH, EBH WS, SQL Databas och Reporting Services. 1.2 EBH och EPiServer idag EPiServer används, i den utsträckning det går att bedöma utan en total genomlysning av existerande kod, till följande: Åtkomsthantering (auktorisering) Underhåll av texter på startsidan Lagring och uppdatering av hjälpdokument och blankettmallar Lagring och underhåll av länkar till webbgis (olika per länsstyrelse) Dock har samtliga sidor och funktioner i EBH-stödet referenser och kopplingar till EPiServer-kod. Ofta har ”inbyggd” ASP.NET/Web Forms-funktionalitet ersatts med motsvarande EPiServer-funktionalitet. EBH WS, d.v.s. skiktet mellan EBH och SQL-databas, och Reporting Services-delarna har inget beroende till EPiServer. 1.3 Avveckling av EPiServer-beroenden 1.3.1 Behåll befintlig arkitektur För att bryta beroendet av EPiServer, krävs relativt omfattande omskrivning av befintlig kod. Strategin för detta moment blir att starta ett helt nytt ASP.NET web forms projekt och bit för bit hämta in funktionalitet från befintligt system, plocka bort eventuella EPiServerkopplingar tills allt fungerar som tidigare. 4 2 Simple Object Access Protocol Alternativet att utgå från existerande kod och plocka bort EPiServer-beroenden bit för bit känns som en betydligt riskablare väg att gå, med stor risk för ännu mer svåröverskådlig och svårhanterlig kod, med ökade kostnader för underhåll som följd. Därtill kommer att skapa de delar av EPiServer som utnyttjats i EBH-stödet; auktorisering, texter, dokumentlagring och länkhantering. Målet för detta är exakt bibehållen funktionalitet och design, men utan behov av EPiServer, tillhörande licenskostnad och EPiServer-specifik kod. Även utan EPiServer kommer dock kodbasen fortsatt att vara ”snårig” och komplex med många oväntade och ovanliga beteenden och lösningar. Estimat tidsåtgång: 600-700 tim 1.3.2 Nytt EBH-stöd med ASP.NET MVC – EBH-Stödet 3.0 Som alternativ till ovan finns möjligheten att, utgående från önskad funktionalitet (snarare än befintlig funktionalitet), skriva om EBH-delen i ASP.NET MVC Förutom de fördelar som tas upp under avsnittet Modernisering av kod, ger detta ett system som är betydligt enklare och billigare att vidareutveckla, förvalta och underhålla. De olika delarna som idag utgör EBH-stödet kan angripas var för sig. Steg ett är att skriva om EBH, steg 2 EBH WS som skulle kunna förenklas och effektiviseras betydligt, steg 3 uppdatera Reporting Services till senaste version, samt att låta rapporter nyttja samma data-access (via EBH WS) som EBH för att ha samma data/frågor oavsett om rapport tas ut, eller data visas i gränssnittet. Estimat tidsåtgång (steg 1): 1000-1200 tim 1.4 Rättigheter/Behörighetsnivåer Rättighets- och behörighetsstrukturen är relativt enkel, med 6 olika behörighetsroller. Med ekonomi-funktionerna nu inaktiverade, omfattas endast objekt och dokument kopplade till objekt av åtkomstkontroll. Alla kan se och söka alla objekt, se och söka dokument kopplade till objekt tillhörande egen organisation, samt ta ut rapporter, medan endast vissa grupper kan skapa/ändra/ta bort objekt/dokument. Begränsningen utgörs alltså av tillgång eller icke tillgång till redigeringsverktyg för objekt/dokument, samt åtkomst till dokument baserat på organisationstillhörighet (kommun, Länsstyrelse, Naturvårdsverket) vilket bör vara en relativt enkel styrning att implementera. 5 1.5 Modernisering av kod 1.5.1 Dagsläge EBH är, under EPiServer, utvecklat på Microsofts ASP.NET Web Forms-teknik. Idag bygger EBH på Microsoft .net-plattform version 4.0, medan webbservice (EBH WS/databasåtkomst) bygger på Microsoft .net version 2.0. Aktuell version av Microsoft .net-plattformen är 4.5.1 Användargränssnitt skapas utifrån fördefinierade komponenter som, när systemet körs, omvandlas till den HTML-kod som bygger upp en sida med dess layout och innehåll i webbläsaren. Detta har tillåtit snabb utveckling på bekostnad av flexibilitet, då man förlorar full kontroll över hur den resulterande HTML-koden (och därmed presentationen i webbläsaren) blir. Web Forms introducerades samtidigt med ASP.NET-plattformen som ersatte ”klassisk ASP” i början av 2000-talet. ”Under huven” används View State, en teknik för att hålla reda på vilka förändringar användaren gör i en sida. Om applikationen inte specifikt talar om vad som är relevant att hålla reda på i en sida, kan detta View State bli mycket stort, något som påverkar prestanda när det skickas fram och tillbaks mellan webbläsare och server varje gång en sida öppnas eller sparas. Som exempel är den totala storleken för sidan Objektsammanfattning i visa-läge ca 400 kB, varav View State utgör dryga 3/4. Med bra prestanda på datorer och nätverk blir användarupplevelsen inte nämnvärt påverkad, men med begränsningar i processorkraft och nätverk (så som surfplattor och andra mobila enheter) påverkas användarens upplevelse av hur effektivt arbetet utförs av den mängd data som ska överföras och bearbetas. Web Forms bygger till stor del på post back, d.v.s. användaren öppnar ett formulär, fyller i information, klickar på Spara varpå sidan laddas om i sin helhet (alternativt en ny sida laddas). Det finns en hård koppling mellan användargränssnittets komponenter (textrutor, knappar, rullgardinsmenyer mm) och bakomliggande kod, vilket innebär att användargränssnittet inte kan förändras utan att bakomliggande kod också uppdateras. Utveckling sker med Microsoft Visual Studio 2010, och källkod hanteras i SVN3 1.5.2 Framtid Ett ledord vid webbutveckling idag är Responsiv Design, d.v.s. sidans layout, utseende och funktion anpassar sig till den webbläsare (och framför allt skärmstorlek) som används för att använda systemet. På så sätt kan samma webbapplikation användas oavsett vilken typ 6 3 Apache Subversion – Ett system för versionshantering av källkod av enhet (dator/surfplatta/telefon) som används. Detta kräver dock full kontroll över den HTML-kod som skickas till webbläsaren på en nivå som Web Forms inte tillåter. Responsiv design berörs också i förstudien Koncept Webb 2.0, på Länsstyrelsens uppdrag utförd av Meridium AB, 2014 Clean Code är sedan en tid ett tankesätt som genomsyrar programutveckling både hos Altran och hos de flesta större IT-konsulter. Koden ska, förutom att lösa sin uppgift, också vara skriven på ett sådant sätt att den ska vara självförklarande, lätt att förstå, lätt att underhålla och lätt att förändra. Fördelen är lägre förvaltnings- och underhållskostnader, samt kortare startsträcka när nya utvecklare ska sätta sig in i befintlig kodbas. Med generella, standardiserade kodbibliotek (ex jQuery, Angular m.fl.) underlättas utvecklingen av klient-logik så som validering av inmatning på ett sätt som fungerar på en känd mängd webbläsare. Man talar idag också mycket om one page applications, där allt informationsutbyte mellan klient och server sker i bakgrunden utan omladdning av sidan. Webbapplikationen upplevs då mer som ett vanligt datorprogram än något man kör i webbläsaren. Idag sker nyutveckling på Microsofts ASP.NET-plattform företrädesvis med arkitekturen MVC (Model View Controller). Den stora fördelen är ”separation of concerns”, d.v.s. användargränssnitt, data-modell och logik är tydligt separerade, och kan fungera fristående från varandra. Denna separation tillåter så kallad ”testdriven utveckling” (TDD4) och underlättar automattestning i allmänhet. Med automatiska tester blir riskerna för oväntade följdproblem vid förändring/uppdatering av befintlig kod mindre, och omfattningen av manuella tester av hela systemet vid varje förändring minskas. Utvecklaren ges full kontroll över användargränssnittets utformning och kan helt fritt ändra alla aspekter av användargränssnittet utan att bakomliggande kod förändras. Beroende på skärmstorlek kan exempelvis helt olika vyer av samma data visas i webbläsaren (till exempel om det finns krav som inte är möjliga att uppfylla med responsiv design). I jämförelse med Web Forms tar nyutveckling med MVC generellt längre tid, (Web Forms beskrivs ofta som en arkitektur för RAD5) men sett över ett längre tidsperspektiv där även förvaltning, underhåll och vidareutveckling vägs in, är uppfattningen att en MVCapplikation ger en lägre totalkostnad än motsvarande Web Forms-applikation. Utvecklingsmiljön bör uppgraderas till Visual Studio 2013 med källkodshantering på Länsstyrelsens Team Foundation Server Online. Samtliga systemdelar (EBH, EBH WS, EBH 4 Test Driven Development – Först skrivs program för att testa koden, sedan själva programmet 5 Rapid Application Development – Snabb applikationsutveckling 7 API) bör uppdateras till samma version av .net-plattformen (4.5) för att kunna hanteras inom samma lösning. Mina tankar kring detta är kommunicerade med lösningsarkitekt på Länsstyrelsernas ITenhet, som kommer att kommentera efter nästa veckomöte för länsstyrelsernas ITarkitekter, 2014-02-17. Eventuellt kan denna förstudie behöva kompletteras när jag fått information från detta möte. 1.5.3 Tillgänglighet Länsstyrelsens riktlinjer för webbtjänster gäller även för interna verktyg. Med tanke på kommunernas tillgång till EBH-stödet, räknas dessutom EBH-stödet då som externt, även om det inte är publikt. Webbaserade system ska uppfylla tillgänglighetskrav, samt följa standarden WCAG6 2, nivå AA. Vid ny- och vidareutveckling av EBH-stödet måste hänsyn till detta tas. Dagens EBHstöd uppfyller inte mer än undantagsvis riktlinjerna i WCAG. Utan en total omskrivning av användargränssnitt (och därmed bakomliggande kod) är det inte möjligt att leva upp till de krav Länsstyrelsens riktlinjer för webbtjänster ställer. 1.6 Kompatibilitet med andra/senare webbläsare, touchskärmar, små skärmar 1.6.1 Internet Explorer 11version 11.0.9600.17501 EBH-stödet fungerar generellt väl med IE11 om man bortser från vissa kosmetiska skillnader jämfört med IE9, så som typsnitt, storlek, fet-stil mm. Rapport-genereringen klagar ibland (sällan) över ett skript som tar lång tid att köra men visar till slut rapporten om man väljer att inte avbryta körningen. 1.6.2 Google Chrome version 40.0.2214.111 m Kosmetiska skillnader (typsnitt, storlek mm), men all funktionalitet tycks vara på plats, och fungera som förväntat. Inga skript-varningar. 8 6 Web Content Accessibility Guidelines 1.6.3 Firefox version 35.0.1 Som i Crome och IE11 fungerar EBH-stödet över lag väl. Kosmetiskt ligger utseendet väl i linje med det vi är vana vid. Rapportgenerering tar tid, och ett skript som är en del av rapporten tar, precis som för IE11, så lång tid att webbläsaren varnar: Detta skript är sannolikt en del av Reporting Services, och därmed utom utvecklarens kontroll. 1.6.4 Pekskärmar/surfplattor/telefoner För pekskärmar finns speciella hänsyn att ta; Så kallade Mouse Over-effekter så som hjälptexter/tooltip eller rullgardinsmenyer som vecklar ut sig när muspekaren vilar över en yta stöds inte alls, och knappar, menyer och andra komponenter på sidan måste generellt göras proportionellt större, för att underlätta användandet. På små skärmar måste ofta innehållet ”stuvas om” för att ge en bra användarupplevelse. Delar på sidan som på en datorskärm kan ligga sida vid sida måste på en telefon placeras under varandra.7 Detta berörs också i förstudien Koncept Webb 2.0 Beroende på plattform (Android, IOS, Windows Phone för att nämna de största) förväntar man sig också ett visst grafiskt utseende och navigationssystem, som ofta skiljer sig markant från hur en webbapplikation för datorer är gjord. Det finns inga möjligheter att anpassa EBH för pekskärmar/surfplattor/telefoner utan att skapa ett helt nytt användargränssnitt, och därmed till stora delar ny bakomliggande kod. Beroende på förväntad ”publik”, utformas ofta nya webbplatser nu enligt principen Mobile First, dvs. man börjar med en mycket enkel webbplats som ”alla” webbläsare och enheter kan hantera, och bygger på denna enkla webbplats med design, funktioner och finesser i olika nivåer beroende på vad webbläsaren kan hantera. Detta som kontrast till att börja 9 7 Se Modernisering av kod med en fullfjädrad webbapplikation, där man plockar bort funktionalitet och finesser allt eftersom man upptäcker att den anslutna webbläsaren har begränsningar. 1.7 SharePoint-integration SharePoint är först och främst ett system för innehållshantering, dokumenthantering och digitalt samarbete mellan anställda på en arbetsplats, till exempel Länsstyrelsens intranät Insidan. Beröringspunkterna med EBH-stödets funktionalitet är få, och att helt bygga EBHstödets funktionalitet på SharePoint-plattformen skulle bli synnerligen komplext om det alls skulle låta sig göras. Dock: Dokument/filer i EBH-stödet lagras idag i SQL-databas. Systemet omfattar dryga 120 000 ”filer”, på totalt ca 160 GB. Det finns inget annat sätt att hämta ut dokument än via EBHstödet. SharePoint skulle med fördel kunna användas som dokumentlager för EBH-stödet. Dokumenten skulle precis som idag kunna förses med olika metadata (typ av dokument, koppling till objekt, användare etc.). Dokumenten skulle inifrån SharePoint kunna vara åtkomliga för de som ges läs- (eller skriv-)rättighet till dokumentbiblioteket, samt som nu, inifrån EBH-stödet, med de åtkomstregler som gäller i EBH. Vår långa erfarenhet av SharePoint-implementationer säger oss att arbetet med att migrera den mängden dokument till SharePoint innebär ett inte oansenligt arbete; speciellt som befintliga dokument i EBH-stödet idag ligger i en tabell i SQL-databasen, och inte som enskilda filer i filsystemet. 1.8 Ärendehantering EBH-stödet saknar idag funktionalitet för koppling till ärendehanteringssystem. För Länsstyrelsens del är en koppling till Platina, eventuellt med direktlänkning från EBH-stödet till Platina, relativt enkel att implementera. (Sådan funktionalitet är under utveckling i ett annat Länsstyrelse-projekt.) Dock flaggar personal inom Länsstyrelsen för att det föreligger ytterligare komplexitet vad gäller ärendehantering, som kan kräva djupare analys. Situationen kompliceras också av kommunaccessen, om kommunspecifika objekt ska länkas till kommunspecifika ärendehanteringssystem. Dels kommer olika ärendehanteringssystem att kräva olika länkar och länkningsmekanismer; dels måste man sitta på samma nätverk som ärendehanteringssystemet för att kunna nå det. En tänkbar lösning är att visa länkar till, och funktionalitet för ärendehanteringssystem endast om användaren och objekt tillhör samma organisation (kommun, Länsstyrelse, Naturvårdsverk) 10 1.9 Kommunernas åtkomst till EBH-stödet - Kommunaccessen Hur externa aktörer ska kunna nå EBH-stödet påverkas inte av hur EBH-stödet är konstruerat, utan är snarare en fråga för IT-avdelningarna på Länsstyrelsen/kommunerna. Oavsett vilken väg som väljs för avveckling av EPiServer, och tidsplanen för detta arbete, påverkas tekniskt inte kommunernas åtkomst till EBH-stödet. Medför arbetet större förändringar av gränssnitt och funktionalitet kan det dock ur pedagogisk synvinkel vara mindre lämpligt att utsätta nytillkomna användare för stora omställningar i handhavande och utseende kort efter att de bekantat sig med EBH-stödet. Åtkomst till, och vad en användare kan göra i EBH-stödet styrs idag med hjälp av Länsstyrelsens Active Directory, och vilken/vilka grupper användaren tillhör där. Med inloggningsmöjlighet för användare från samtliga Sveriges kommuner, som i övrigt inte ska ha tillgång till Länsstyrelsens nät, kan det vara olämpligt att lägga in alla dessa som användare av Länsstyrelsens nätverk. Hur den frågan ska attackeras är snarast något som Länsstyrelsernas IT-enhet får fatta beslut om. Då auktoriseringslogiken i samband med avveckling av EPiServer ändå måste ses över och implementeras som del av EBH, kan det vara lämpligt att även implementera autentisering direkt i EBH-stödet. EBH-stödet skulle då behöva förses med modul för användaradministration. I det fallet skulle, ur EBH-stödets synvinkel, åtkomsthanteringen förenklas något medan användarhantering kompliceras. Oaktat hur användaren autentiseras, bör inloggningsförfarandet ske över HTTPS (säker uppkoppling) för att undvika att användarnamn och lösenord skickas i klartext över i värsta fall publika nätverk. För import/export av data från/till olika kommunala system, krävs en djupare analys av varje annat system, både vad gäller dataöverföring och vilka gemensamma data och funktioner de olika systemen har. Generellt är det olyckligt att ha data utspritt på flera enheter. Ett datalager bör alltid vara master-data som övriga enheter läser från och skriver till. Med schemalagd eller händelsestyrd synkronisering mellan EBH-stödet och kommunspecifika system borde dock en tillräckligt hög grad av dataintegritet i EBH-stödet kunna upprätthållas. Idealt exponerar kommunspecifika system ett API där EBH kan hämta relevant information. Alternativet är att EBH-stödet matas med data från kringliggande system. Detta skulle innebära allt mellan manuell inmatning av data, till ett API där externa system automatiskt kan skriva data till EBH-stödet. Här blir ansvarsfrågan för data i EBHstödet något mer komplex. Hur undviker vi till exempel dubbletter om EBH-stödet och kommunens system saknar gemensam identifierare? 11 Oavsett vilken form av synkronisering av data mellan EBH-stödet och kommunspecifika system som väljs, kommer det att innebära utveckling av funktionalitet för datautbyte i så väl kommunens som EBH-stödets ända. Dokument knutna till objekt bör inte finnas i fler än en upplaga. Risken för att olika versioner av samma dokument finns i olika system är annars överhängande. Bästa lösningen är att objektknutna dokument lagras i ett gemensamt dokumentlager som både kommunspecifikt system och EBH-stödet kan nå. Den version av dokumentet som finns i detta dokumentlager får då anses vara gällande version oavsett ”lokala” uppdateringar. I annat fall får dokument som är lagrade i andra nätverk än Länsstyrelsens, göras tillgängliga för EBH-stödet (t.ex. via API hos dokumentägaren), alternativt att dokument utanför Länsstyrelsens nätverk, knutna till objekt i EBH-stödet, endast refereras till, och respektive dokumentägare får kontaktas för åtkomst. Skulle ett för kommuner, länsstyrelser och Naturvårdsverket gemensamt dokumentlager upprättas, utesluts möjligheten att utnyttja Länsstyrelsens SharePoint-miljö som dokumentlager för EBH-stödet. Jag har kontaktat EDP Consult (EDP MiljöReda/EDP Vision Miljö) och Tekis (ECOS) för att få grepp om dessa applikationers möjligheter när det gäller import/export av data och information. Tekis är mitt i en stor omskrivning av sin applikation8 och visar ett visst mått av öppenhet för integrationsmöjligheter för kommande version. Även MiljöReda/EDP Vision Miljö9 är inte främmande för integrationsfrågor. Några generella gränssnitt för kommunikation med andra system saknas dock, varför datautbyte mellan kommunsystem och EBH-stödet kommer att kräva separata utredningar och utvecklingsprojekt. 8 Se bilaga 1 9 Se bilaga 2 12 1.10 API EBH REPORTING SERVICES EBH WS SQL DATABAS Externa system EBH API Som en del i kommunaccessen kan dataöverföring göras via en webbtjänst. Åtkomstkontroll och autentisering kan ske antingen mot Länsstyrelsens ADFS (Active Directory) eller mot separat autentiseringsmodul. Vilka data som ska kunna hämtas ut ur systemet via API, och vilka frågor som ett API ska kunna ta emot måste bli föremål för en separat förstudie, men arkitekturellt rekommenderar vi att bygga dessa webbtjänster på Microsoft ASP.Net Web API. Data kan då överföras som XML, JSON eller annat format som det externa systemet begär. Beroende på vilka som ska ges tillgång till API, kan API göras åtkomligt från allt mellan publik webbserver för vem som helst, till internt inom Länsstyrelsens ”väggar” med strikt åtkomstkontroll. För de kommuner som även i framtiden kommer att använda egna system parallellt med EBH-stödet kommer sannolikt EBH API att vara kanalen för synkronisering av data mellan de 13 olika systemen. Initialt är Vattenförvaltningens IT-system Vatteninformationssystem Sverige (VISS) angelägna om att kunna hämta data från EBH-stödet. För det ändamålet kan ett första steg mot ett fullödigt API tas inom en inte allt för avlägsen framtid. 1.11 Sammanfattning och rekommendation Frågan som måste besvaras är: Hur ser framtiden för Länsstyrelsens och EBH-stödets roll ut? Kommer Länsstyrelsens roll, och EBH-stödets vikt att vara kvar, eller till och med öka de närmaste åren? Eller kommer eventuellt någon annan myndighet med annat system att ta över motsvarande funktion inom några år? I det sistnämnda fallet kan det vara en ekonomisk vinst i att behålla befintlig arkitektur och endast eliminera EPiServer-kopplingarna. Direkt ekonomiskt kapar vi då licenskostnader, underhållsmässigt eliminerar vi en ”udda fågel” i IT-miljön, och vi får ett system som är något lättare att underhålla (färre kodrader, mindre beroenden till externa kodbibliotek). Är dock ambitionen att EBH-stödet fortsatt ska fylla sin funktion, och utvecklas i takt med nya förväntningar, standarder, krav och användare rekommenderar jag starkt att direkt ta det större steget och från grunden skriva om EBH i enlighet med de riktlinjer, önskemål och krav vi har idag, och med vad vi kan ana av framtiden i åtanke. Vi får, förutom vinsterna med att endast eliminera EPiServer, ett modernt attraktivt system som kan uppfylla användarnas krav, lättare anpassas efter nya, nu okända krav och önskemål, och med lägre underhålls-, drift- och vidareutvecklingskostnader. Estimerade tider är preliminära estimat. Utan komplett detaljerad lösningsspecifikation kan vi dock inte förbinda oss till tidsuppskattningar, eller mer exakt estimera tidsåtgången. 14 Bilaga 1 Svar från Tekis (ECOS) på frågan: I vilken utsträckning har ECOS någon form av API för import/export av data från/till andra system? Vi är mitt i en stor omskrivning av vårt system Ecos. Som det fungerar idag så kan kommunen ha en lokal Mifo-databas och vissa av uppgifterna i den databasen kan synkroniseras med de Mifo-databasuppgifter som finns i Ecos. Synkroniseringen fungerar så att om kommunen uppdaterar Mifo-databasen så kan de gå in i Ecos och välja ”Synkronisera Mifo” för att uppdatera Ecos Mifo-databasuppgifter. Har kommunen en lokal Mifodatabas kan man i Ecos hoppa över till Mifo-databasen för att se mer uppgifter om motsvarande objekt i Mifo-databasen. För att skapa integrationer med Tekis olika system krävs att man är en registrerad integrationspartner. Du kan läsa mer om det och registrera dig här. Efter registreringen kommer du ha tillgång till våra officiella gränssnitt. Observera att det ännu inte finns något API för integration mot vårt nya system avseende efterbehandling av förorenad mark. Generellt sett har vi inga problem att integrera mot andra system via öppna webbgränssnitt, men vi är just nu inte så intresserade av att skapa den möjligheten för vårt gamla system (Ecos 1), eftersom vi räknar med att helt fasa ut det inom loppet av några år från nu. I den kommande generationen av systemet (Ecos 2) har vi ännu inte tittat på om/hur en sådan integration kan se ut. Därför ser vi gärna att ni håller oss uppdaterade kring vad som händer i ert projekt så att vi kan skapa rätt förutsättningar direkt, både vad det gäller kommunernas möjligheter att läsa länsstyrelsernas data, och eventuella krav/behov av att skicka data till länsstyrelserna. Integration som handlar om återrapportering kräver viss framförhållning så att vi har möjlighet att utveckla vårt system i god tid innan kommunerna förväntas registrera och leverera data till länsstyrelserna. 15 Bilaga 2 Svar från EDP Consult (ECOS) på frågan: I vilken utsträckning har MiljöReda/EDP Vision Miljö någon form av API för import/export av data från/till andra system? Vi har inga bestämda API:er utan gör ändamålsspecifika lösningar för resp. ändamål. I framtiden kommer det att finnas tydligare gränssnitt för alla kunder när vi (EDP) lyft alla MiljöReda-kunder till nästa generations system, EDP Vision Miljö. EDP har byggt olika lösningar för import och export av data i olika filformat. Du får gärna återkomma med en mer specifik förfrågan. 16
© Copyright 2024