LADOK. Marcus Gelderman den 10 juni 2008 GEM T-8004

Transkript

1 LADOK U tvecklingsmöjligheter ny systemgeneration tekniska möjligheter och risker Marcus Gelderman den 10 juni 2008 GEM T-8004

2 Innehållsförteckning SAMMANFATTNING... 4 Utredningens uppdrag...4 Bakgrund...4 Uppdraget enligt utredningsdirektiven...4 Utredningens genomförande...5 Kortfattad summering av utredningens resultat...5 Argument för en ny version av Ladok...7 SYSTEM OCH VERKSAMHETSKRAV... 8 Indelning av krav...8 FUNKTIONELLA SYSTEM OCH VERKSAMHETSKRAV...8 Rapportering och registrering...8 Skyddade identiteter, anonyma tentor, egna kursval...8 Källa till data för kringliggande system...9 Underlag för ut och inbetalningar och statistik...9 Grundläggande katalogfunktion...9 FRAMTIDA FUNKTIONELLA SYSTEM OCH VERKSAMHETSKRAV Självadministration Högskolorna önskar en bättre processanpassning av stödet Ökat utbyte av data och mera avancerade systemintegration scenarios Effektivare drift och kontrollerade utvecklingskostnader Ökad systemintegration TEKNIK OCH SYSTEMARKITEKTUR...13 FUNKTIONELLA KRAV FÖR ATT LÖSA VERKSAMHETENS BEHOV MÖJLIGA TEKNISKA VÄGVAL MED NUVARANDE LÖSNING RISKER MED NUVARANDE LÖSNING VÄGANDE SKÄL FÖR EN TEKNISK OMBYGGNAD AV SYSTEMET Drift och underhåll Kostnader för licenser Kompetensbehov Uppfyllande av förändrade omvärldskrav TEKNISKA VÄGVAL FÖR EN FRAMTIDA LÖSNING Visionära möjligheter och enkel teknik för framtiden Ny datamodell och migration Krav på drift och underhåll Framtida kompetensbehov SÄKERHET OCH TILLGÄNGLIGHET...22 TILLGÄNGLIGHET Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 1 / 45

3 Den nuvarande lösningen Framtida krav på tillgänglighet Identifierade risker DATASÄKERHET Den nuvarande lösningen Framtida säkerhetskrav Identifierade risker ÅTKOMSTKONTROLL Framtida krav för åtkomstkontroll Identifierade risker FRAMTIDA MÖJLIGHETER Singel Sign On (SSO) och autentisering utanför systemet Elektronisk id och autentisering av studenter Rollbaserad säkerhet Kryptering, Certifikat och digitala signaturer NATIONELLA OCH INTERNATIONELLA TEKNISKA SAMARBETEN...27 FRAMTIDA MÖJLIGHETER Krav på en framtida lösning Möjligheter i den nuvarande lösningen Datastandarder Internationella samarbeten BESLUTSKRITERIER FÖR OMBYGGNAD OCH KOSTNADSASPEKTER...30 BESLUTSKRITERIERNA FÖR ETT BESLUT OM OMBYGGNAD KOSTNADSASPEKTER TEKNISKA BILAGOR...31 HIBERNATE Summering Hibernate i princip Prestanda och Hibernate Att förstå Hibernate Hibernate kunskap Snabbsummering för och nackdelar Summering Standarder och tekniker som stöds av JBoss AS WEB SERVICE, SOAP OCH WSDL Web Service SOAP Web Services Description Language (WSDL) XML XML SCHEMA Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 2 / 45

4 JAVA ARCHITECTURE FOR XML BINDING (JAXB) SPRING FRAMEWORK Inversion of Control container Aspect orienterad programmering ESB (ENTERPRICE SERVICE BUS) JAVA MESSAGE SERVICE (JMS) JUNIT ASYNCHRONOUS JAVASCRIPT AND XML (AJAX) Version 1.1 Marcus Gelderman, 3 / 45

5 Sammanfattning Utredningens uppdrag I detta avsnitt ges först en bakgrund till utredningsuppdraget. Därefter beskrivs innehållet i utredningsdirektiven, samt utredningens genomförande och slutligen en summering av det resultat som utredningen har kommit fram till samt en sammanfattning av argument för att uppgradera Ladok-systemet till en nyare systemrevision. Bakgrund Ladok-systemet har just gjort sig av med den äldsta teknikgenerationen och det finns inte några omedelbara hot eller krav på att snabbt bygga en nästa systemgeneration. Dock är man medveten om att omvärlden förändras och detta kan i sin tur motivera en förändring av det systemstöd som behövs för att effektivt stödja verksamheten. Denna utredning fokuserar i huvudsak på tekniken och vad som är aktuell teknik idag och i möjligaste mån vad man kan förvänta sig av framtiden. Utredningen utgår ifrån i att man i grova drag hanterar samma typ av information som det befintliga Ladok-systemet gör i dagsläget, men ser samtidigt att vissa omvärldsfaktorer redan har förändrats som kan föranleda systemförändringar: Studenterna förväntningar på Ladok är förändrade, de kommer i större grad fungera som medaktörer och ha ett större intresse för informationen i Ladok Utbyten av studenter och information om studenter ökar drastiskt nationellt och internationellt. Studenternas förväntningar på systemassistans har kraftigt skruvats upp och förändrats, Högskolornas ekonomiska situation nödvändiggör effektivare systemstöd. En nära släkting, NyA har kommit med som ny aktör och fokuserat på behovet av effektiv samverkan mellan system. Medvetenhet om vilka krav som kan ställas på systemstödet har mognat. Uppdraget enligt utredningsdirektiven I utredningsdirektiven stipuleras att utredningen skall redovisa de allvarligaste beslutskriterierna som kan nödvändiggöra en ombyggnad av systemet, visa på vilka tekniska lösningar som finns om man väljer att bygga om systemet, samt tydliggöra möjligheterna med dessa tekniska vägval. Utredningsdirektivet anger också att risker med den nuvarande tekniska skall tydliggöras, samt redovisa vilka systemförändringar som behöver göras för att möta de förändrade omvärldskraven. Säkerhet i den befintliga lösningen skall redovisas, samt hur krav på säkerhet kan förändras i framtiden. Hänsyn skall också tas till internationella och nationella tekniska samarbeten i nuvarande lösning och en eventuell framtida lösning. Den visionära aspekten är viktig och utredningen skall redovisa olika alternativ för systemarkitektur och preliminärt värdera de tekniska utvecklingsmöjligheterna och riskerna med utgångspunkt i dagens system och utifrån en eventuell framtida förändring av systemet. Utredningen skall även ge grund för beslut om fortsatt planeringsarbete för nästa systemgeneration och ge Konsortiet en beredskap för att snabbare kunna påbörja arbetet med teknikskifte när så krävs. I egenskap av extern och oberoende part så skall utredningen enligt direktivet, förutom ovanstående punkter, också redovisa sin syn på möjligheterna att minska riskerna för framtida leverantörsberoenden. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 4 / 45

6 Utredningens genomförande Bakgrunden till utredningen är framtagen via intervjuer av systemanvändare, systemförvaltare och representanter för konsortiet; genomgång av systemdokumentation på Ladok-webben samt dokumentation som gjorts tillgänglig för mig i samband med intervjuerna. Kortfattad summering av utredningens resultat Den bästa framtiden för Ladok ur ett drifts- och utvecklingsperspektiv är enligt utredarens uppfattning att systemet skall vara Java-baserat. En direkt fördel av detta är att man kommer att effektivt kunna nytta av den Linux-arkitektur som man valt att satsa på. Java-arkitekturen innebär också att det blir enklare och mer kostnadseffektivt att handla upp externa konsulttjänster i den mån man önskar i jämfört med den nuvarande Uniface miljön. Utöver Java som programmeringsspråk så bör man webbifiera hela lösningen och låta alla, både de som arbetar dagligen och studenter ansluta till Ladok via ett webb interface. Konsortiet bör också i möjligaste mån vara ansvarig för utvecklingen och leverera en lösning som har all eller väldigt mycket av den funktionalitet som systemet förväntas ha. Valet att välja bort Mimer som databas till fördel för MySQL anser utredaren vara strategiskt viktigt då MySQL som produkt har betydligt bättre framtidsutsikter och troligtvis betydligt bättre prestanda. Utöver bytet av databas anser utredaren att man bör nyttja ett objekt-till-relations databasverktyg för att tydligare kapsla in objekten och samtidigt korta ned utvecklingstiden. I dagsläget är det givna valet Hibernate som är en open source lösning för objekt-till-relations mappningar. För att få dessa tekniker att hänga ihop, samt att få en miljö att köra dem i, rekommenderas att man väljer applikationssevern JBoss. JBoss är också open source och anses som en av de bättre produkterna på marknaden oavsett hur licensen ser ut. En lösning baserad på Linux, MySQL, Hibernate och JBoss är till stor del en defacto standard uppsättning och det är relativt enkelt att köpa till support (exempelvis från Redpill eller något annat företag) och allt ifrån små enmans konsultbolag till de stora jättarna på marknaden har personal som kan jobba med dessa tekniker ifall man vill ha möjlighet att köpa in konsulttimmar externt. Denna mjukvarusammansättning bör ge stora besparingar på licens- och supportkostnader vilket rimligtvis är en viktig faktor i sammanhanget. Lösningsarkitekturen bör vara byggd på ett sådant sätt att inga applikationer utanför Ladok applikationerna har direkt tillgång till databasen. All kommunikation med systemet bör ske på tre olika sätt, användare interaktion via ett webbinterface, via en Web Service-koppling för de applikationer som finns lokalt i anslutning till systemet alternativt via en ESB (Enterprice service bus) lösning som på Ladok-sidan är JMS baserad och kopplad mot en integrationslösning. Valet av vilken integration-/middleware-lösning som man väljer är upp till respektive läroanstalt men med kravet att det kan prata JMS mot Ladok. Meddelanden som utväxlas mellan de olika Ladok-systemen och kring liggande system och passerar över en ESB (Enterprice service bus) lösning. ESB skall processa meddelanden som är krypterade och baserade på XML. XML-meddelandena skall valideras mot ett XML Schema som definierar hur data skall se ut syntaxmässigt. Snabba mekanismer som Java Architecture for XML Binding (se JAXB) används för att läsa upp meddelande i minnet för processning. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 5 / 45

7 Arkitekturen bör också vara byggd på ett sådant sätt att ett fysiskt system kan hantera flera läroanstalter, samt att flera fysiska installationer skall gemensamt kunna adressera behovet för en läroanstalt. Fördelarna med ett sådant system är att man har en flexibilitet att flytta funktionalitet tillfälligt mellan fysiska system vid exempelvis uppgradering eller support på hårdvara, samt att man ges möjligheten att med ganska enkla medel kan höja prestandan genom att installera ytterligare maskinvara parallellt med befintliga system. För att adressera behovet av att kunna få ut rapporter ur systemet bör ett enklare rapportverktyg konstrueras som kan anpassas efter de krav läroanstalterna har. Rapportverktyget bör dels gå att använda interaktivt via webb interfacet samtidigt som man skall kunna svara på fördefinierade frågor som når Ladok via Web Service frågor eller via integrationslösningen (ESB). Utöver de tidigare nämnda teknikerna så bör man dra nytta av ramverk som Spring Framework ( för att förenkla utvecklandet. Under utvecklingen bör nyttja enhetstester och ramverket JUnit ( samt utvecklingsplattformen Eclipse ( och man bör väldigt tidigt i projektet sätta upp källkods revisions hantering (exempelvis Subversion från Webbklient-delen av systemet bör vara baserat på JavaScript och XML (Ajax) och lämpliga ramverk kan vara JBoss Richfaces ( SproutCore ( eller exempelvis MyFaces ( Vad man väljer här är avhängt hur man vill att kontroller och knappar skall se ut, samt om man har speciella funktionella krav. Beslutet om vilket ramverk som skall användas på klientsidan behöver vara väl förankrat hos de som kommer utveckla systemet. Tvingar man på utvecklarna ett klient ramverk som de inte är nöjda med kommer det påverka resultatet negativt och deras upplevelse av klient ramverket kommer i viss mån sätta tonen för om projektet är lyckat eller inte. Viktigt att förstå är att det finns en större mängd klient ramverk att välja mellan och vissa av dessa är otroligt effektiva om man använder dem på precis det sättet som de var tänkta för, om sättet att utveckla eller kravbilden avviker ifrån det optimala användningssättet kan klient ramverket istället bli ett stort problem. Utöver själva kodandet bör man ha en iterativ utvecklingsmodell och nyttja någon av de erkända agile metoder och ramverk som exempelvis Scrum, DSDM/Atern, lean programming. För att summera ovan text och placera in det i det befintliga systemets miljö är det utredarens uppfattning att man bör bygga ut den funktionalitet som LpW (Ladok på webb) erbjuder fast på en ny plattform; ersätta Nouveau- och Uniface-lösningen med en webblösning. Konsortiet bör lägga energi på att ta fram det webbinterface som behövs för att kunna nyttja funktionalitet. Man bör bygga vidare på konceptet med Web Service (SOAP) tjänster fast på en uppdaterad plattform. Ersätta LadokPing med en integration/esb lösning och skicka krypterade XML baserade meddelanden. Ersätta en del av funktionaliteten av STAM genom att nyttja http/s för användare inloggning på webben och Web Service (SOAP) anrop. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 6 / 45

8 Argument för en ny version av Ladok Svårigheter att på sikt underhålla den befintliga databaslösningen. Svårt att överblicka säkerheten i det befintliga systemet. Lappverket av applikationer gör framtida utveckling svår. Uniface-lösningen är inget att bygga en framtida lösning på. Framtida integrationskrav kommer att kräva en mer integrerad systemlösning. Svårt att möta framtida krav på mer interaktiva webbsidor i nuvarande lösning (Ajax) Databasen behöver moderniseras, risk finns att tabellerna växer okontrollerat. Ett mer objektorienterad system blir billigare att underhålla och utveckla i. Nyare tekniker kommer ge en bättre plattform för framtiden. Drift- och underhållskostnaderna blir lägre i en enhetlig miljö för alla lärosäten. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 7 / 45

9 System och verksamhetskrav Indelning av krav Den delen av verksamheten som berörs av Ladok-systemet är enligt min uppfattning så starkt kopplad till systemet att jag valt att inte i detalj separera system och verksamhetskraven. Detta för att hålla ihop faktorer som tillsammans ger ett krav från verksamheten; exempelvis leder troligtvis kravet att minska administratörernas administration av de uppgifter som användarna själva kan administrera (ett verksamhetskrav) till att man behöver öka tillgängligheten till systemet till i princip dygnet runt, 24-7 (ett systemkrav) denna separation kommer att behöva göras tydlig i samband med att med att en kravspecifikation tas fram för en eventuell ombyggnad av systemet. Funktionella system och verksamhetskrav Rapportering och registrering Huvudgruppen av användare jobbar med rapportering och registrering, exempelvis kursrapportering och examenshantering. Beroende på hur läroanstalten är organiserad kan arbetet som gör i Ladok vara uppdelad på en större mängd personer i personalen eller utförs arbetet i Ladok ett fåtal personer som då utför fler typer av sysslor i systemet. Variationen i sättet att kombinera rollerna på respektive läroanstalt ställer krav på flexibilitet för att uppnå mesta möjliga effektivitet. Skillnaderna i hur man nyttjar systemet ställer också andra krav på flexibilitet och möjligheter till lokala förändringar i systemkonfigurationen. Skyddade identiteter, anonyma tentor, egna kursval Systemet ställs också inför kravet att man skall kunna hantera personer med skyddade identiteter. Rättning av tentan skall ske utan att personen som rättar skall ha möjlighet att sen personnummer eller namn och på så sätt undanröja misstanke om orättvis bedömning eller jäv. Systemet måste också stödja det faktum att en större andel av studenterna inte går igenom utbildnings- och examensprocessen linjemässigt utan i allt större utsträckning komponerar ihop en egen utbildning av fristående kurser. Detta i sin tur ställer i sin tur krav på Ladoks möjligheter till manuell hantering för dispenser, samt möjligheter att i efterhand komplettera kursinformation som kan ha saknats vid tidpunkten för dispensgivande. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 8 / 45

10 Källa till data för kringliggande system Ladok-systemet är den ursprungliga källan för data som sedan används i kringliggande system och som källa måste data i systemet vara aktuellt och korrekt. För att korrektheten skall kvarstå i takt med att roller förändras behövs det även mekanismer för att bevara historik; exempelvis skulle man kunna tänka sig att en student börjar läsa på en läroanstalt för att senare i livet går över för att undervisa på samma läroanstalt. I en sådan situation måste man ju kunna hantera kronologin i händelserna. Även i fall där exempelvis en lärare byter befattning så är det viktigt att kronologin behålls, detta för att undvika att historisk och aktuell data blandas på ett felaktigt sätt; ett senare utdrag ut Ladok-systemet skulle kunna ge sken om att examinatorn för en kurs var professorn eftersom personen innehar professuren nu, dock inte när den aktuella examineringen skedde. Underlag för ut- och inbetalningar och statistik Ladok-systemet ger också underlag för läroanstaltens ersättning ifrån staten för utbildningsplatsen, samt studentens ersättning ifrån CSN vilket ställer tydliga krav på kvalitet och hantering av data. Utöver den data och statistik som staten och CSN behöver för in- och utbetalningar, behöver läroanstalten möjligheten att sammanställa statistik. Det kan vara uppgifter som behövs för att styra den egna verksamheten, men det kan även vara ett krav för att följa offentlighetsprincip t ex vid frågor ifrån press. Grundläggande katalogfunktion Ladok-systemet skall även fungerar som en grundläggande katalogfunktion kring en mängd uppgifter så som: Studerande och deras utbildningsnivå (grund-, avancerad och forskarnivå) Lärare Kurser Kursomgångar och anmälningsmetoder Program Läsårsplaner (kursomgångar i programmet under läsåret) Organisation och relationer (Vem som tillhör vilken institution) Externa partners Antagningsuppgifter Registreringar Resultat Tillgodoräknanden Examina Rapporter Listor Intyg Examensbevis och kursintyg Uppföljning Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 9 / 45

11 Framtida funktionella system och verksamhetskrav Självadministration Om man ser på hur förändring har skett inom andra områden som t ex bankväsendet så har en kostnadsmedvetenhet ifrån de aktuella organisationerna tvinga fram en mer utpräglad självadministration, vi registrerar själva våra räkningar i internetbanken idag; en syssla som tidigare bankkassörskan utförde åt oss. Denna självadministration har också i viss mån förändrat vår egna syn på data i systemen och våra krav på insyn i de olika systemen. En högst trolig utveckling även för Ladok-systemet är att studenterna fungerar som tydliga medaktörer, graden av självadministration ökar och kraven på insyn i systemet är kraftigt förändrade. Kravet på genom vilka kanaler kommuniceringen skall ske kan komma att förändras, i dagsläget kan man ju se teknik som webb och e-post som självklara. I den ganska nära framtiden kanske kraven ställ på annan mer mobil teknik som SMS eller att webben är anpassad för mobila plattformar som t ex Apples iphone. Det troliga är också att man expanderar kommunikationskanalerna, e-post kommer inte ersättas med SMS, utan användaren vill kunna välja kommunikationssätt beroende på vad som skall kommuniceras; exempelvis kanske man vill ha kursplanen tillgänglig på webben och samtidigt kunna få den utskickad via e-post vid eventuella förändringar. Studenten kan ha en önskan om att se den grundläggande tentamens planeringen via webben, hemma vid sin dator, men samtidigt vilja få en påminnelse via SMS om plats och tidpunkt till sin mobiltelefon en kort period innan den aktuella tentamen skall ske. Möjligt är också att studenten genom att svara på SMS meddelandet även kan meddela om han eller hon tänker närvara. Troligt är också att man kommer vilja ha tillgång till systemet i princip dygnet runt, året runt (24-7) och kravet på realtids-access till data ökar markant. Rätt utvecklad och nyttjad ger den ökade självadministrationen både ekonomiska fördelar; man kan frigöra resurser ifrån en del av student- och kanske även läraradministrationen och nyttja de mer effektivt inom andra områden och man når även administrativa fördelar; uppgifter som t ex kontaktuppgifter eller liknande är lättare att hålla aktuella och uppdaterade av de som direkt berörs av uppgifterna. För att detta skall kunna uppnås måste det finnas tydliga incitament till självadministration. Funktionaliteten måste vara lättanvänd och kunna användas utan att allt för omfattande krav på utbildning i hur systemet fungerar. Balanserar man inte incitamentet med användarvänlighet så kan motsatt effekt uppstå; exempelvis om kravet för att få ut sina studiemedel är att man fyller i uppgifter i systemet (ett tydligt incitament) och det är svårt att förstå hur man skall kunna mata in de uppgifter som krävs (dålig användarevänlighet) kommer support och administration att bli kontaktade av ett flertal användare som behöver hjälp och därefter från användare som vill verifiera att det som matats in är korrekt. Enkelt förklarat måste Ladok-systemet vara tydligt och enkelt att använda, det måste i möjligaste mån följa den gällande uppfattningen av vad som är standard. Högskolorna önskar en bättre processanpassning av stödet Administratörernas sätt att arbeta i Ladok-systemet kommer troligtvis också behöva ses över, i takt med att studenterna och lärarnas användande av Ladok kommer förändras kommer detta troligtvis också förändra administratörernas sätt att arbeta. Vissa administratörsuppgifter kan komma att försvinna eller minska i omfattning i och med att fler användare administrerar i viss mån sina uppgifter själva, vissa administratörsuppgifter kommer att tillkomma i och med det förändrade användandet, men framför allt kommer kravet på uppdaterad och korrekt information öka med en kraftigt ökad insyn. För att detta krav skall kunna tillgodoses bör man se över hur administratörernas arbete utförs och försöka anpassa systemet efter hur deras arbetssituation ser ut. Ett ökat workflow tänk kan vara en lösning, där man identifierar och underlättar de vanligaste arbetsuppgifterna i Ladok Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 10 / 45

12 och ser till att dessa är snabba och okomplicerade att genomföra. Användaren bör få information om vad som är förväntat att utföra samt få påminnelser gällande saker som inte är utförda. Genom att ha tydliga formulär och tydligt indikera vad man vill ha svar på kan man effektivisera kontakterna mellan exempelvis studenter och personalen som sköter administrationen. Ökat utbyte av data och mera avancerade systemintegration scenarios Dagens studenter är mer rörliga än innan och behovet av utbyte av information rörande studenter ökar drastiskt nationellt och internationellt. I dagens systemvärld är det sällan ett system det enda och vanligtvis arbetar företag och institutioner med en större mängd datorsystem som stödjer olika delar av verksamheten. Skälen till detta kan vara många, allt ifrån rent historiska till en tydlig inriktning mot ett best of breed -tänk där man nyttjar varje system till det de anses vara bäst på. Oavsett anledning till en varierad systemflora så skapar detta ett krav på goda möjligheter till att överföra information i mellan de olika systemen, att integrera systemen. När det gäller systemintegration så brukar man separera den i två delar, intern systemintegrationen, samt extern systemintegration. Traditionellt så brukar man ställa andra krav på teknikens tillförlitlighet och standarder när det gäller systemintegration mot en extern part; exempelvis kan kommunikation gå över nätverk som man inte kontrollerar inom verksamheten och man ställer andra krav på kvittenser och liknande. I Fallet med Ladok så skulle jag vilja dela upp det integrationsbehovet som läroanstalten har lokalt som intern systemintegration och i de fallen man kommunicerar med omgivande parter som CSN, andra läroanstalter, både nationellt och internationellt, som extern systemintegration. I och med den ökade kommunikationen med kringliggande system blir kravet på dataintegriteten betydligt mycket högre och mycket mer utförliga kontroller av data behövs innan det tas in i systemet. Kravet blir att tydligt definierade interface för systemintegration måste finnas tillgängliga. En vinst av att ha en tydlig policy och tydligt definierade interface vid all systemintegration (både intern och extern) är att mycket av tekniken kan återanvändas och att det är tydligt specificerat hur det skall göras. Två viktiga faktorer vid val av lösning och teknik är dels att underhållet måste hållas minimalt; i takt med att antalet kopplingar ökar blir underhållskravet väldigt betungande i annat fall. Den andra faktorn är att lösningen måste gå att övervaka effektivt, det är samma sak här som med underhållet, ett fåtal kopplingar går att övervaka ganska enkelt oavsett lösning men blir dessa fler så blir det genast svårare utan bra verktyg. Effektivare drift och kontrollerade utvecklingskostnader Läroanstalternas ekonomiska situation nödvändiggör effektivare systemstöd, dels behöver man sänka utvecklingskostnaderna för att kunna effektivt driva systemutvecklingen vidare, dels kommer man vilja minska driftskostnaden. Ett problem med den nuvarande lösningen är att en del av utvecklingen lämnats åt respektive läroanstalt. Det finns en API att nyttja (Web Service API) men själva webb utformningen har lämnats åt respektive läroanstalt. Bakgrunden till detta var att man ursprungligen ansåg att utformningen av webben kunde vara ett sätt för respektive läroanstalt att profilera sig mot studenterna. Tanken var säkert god men resultatet blev att systemet ur ett webb perspektiv inte nyttjas fullt ut. Underhålls- och driftskostnaderna påverkas ju också av att läroanstalten är ganska unik med sin lösning och inga direkta möjligheter till enhetlig drift och dela kostanden på flera ges med en sådan lösning. Önskemål från verksamheten är att kunna sänka kostanden för lokal utveckling; göra informationen i Ladok enklare att nå för lokala system på läroanstalten med bibehållen säkerhet för data. En önskan finns om att kunna minimera underhållbehovet av kopplingar mot lokala system rent generellt, men särskilt vid släpp av nya system versioner. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 11 / 45

13 På konsortienivå finns det önskemål av att sänka utvecklingskostnaderna. Minska antalet fel i leveranserna, samt minimera kostnaderna vid utrullning av nya versioner, då utan att försvåra för snabba rättningar av fel. Ökad systemintegration I takt med att Ladok-systemet nyttjas mer kommer behovet att föra över kataloguppgifter och meriter på elektronisk väg öka. Redan har man noterat att systemet NyA har påverkat behovet av effektiv samverkan mellan system. Om man väljer att modernisera systemet är ökad tillgänglighet via integration en av de punkterna som man bör lägga mycket energi på. I dag är det mer regel än undantag att man nyttjar information från flera system i de olika verksamhetssystemen. Det man med säkerhet kan säga är att det är väldigt svårt att veta när man bygger systemen vilken information som man vill kunna nyttja i omkringliggande system. Dessa faktorer visar tydligt på kravet av bra integrationsmöjligheter. Tittar man specifikt på Ladok-systemet så finns ju redan kravet på integration med kringliggande system. I dagsläget löser man det via SQL frågor mot databasen, vilket inte är helt lämpligt om man har höga krav på säkerhet och vill ha kontroll på hur prestandan nyttjas. Lämpligt är en ESB (Enterprise service bus) lösning och tydligt definierade XML meddelande, där man kan hantera kryptering och validering. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 12 / 45

14 Teknik och systemarkitektur Funktionella krav för att lösa verksamhetens behov Verksamheten använder idag informationen i Ladok som en källa för information till omkringliggande system och behovet av ett öppet system som man enkelt kan integrera mot omgivningen kommer bara att växa. I den nuvarande lösnigen finns det risken med att data kan förvanskas och nyttjas felaktigt då man inte har ett riktigt tillfredställande dataskydd. Tydligare interface för integration behöver definieras; exempelvis kan användning av text fält i vissa vyer ge ett oväntat resultat då man inte vet vad som kommer över till de kringliggande systemen. Verksamheten behöver ett kraftigt förbättrar och processorienterat stöd för de mest vanligt förkommande sysslorna. Användarinterfacet, då framför allt i Ladok Nouveau, behöver ses över och helst ersättas med en modernare lösning för att ge ett effektivare och förbättrat stöd för användare. Möjliga tekniska vägval med nuvarande lösning De vägval man kan göra med nuvarande plattform är något begränsade i och med den starka bindningen till Uniface. Även om det i princip går att hänga på mer modern teknik i efterhand tenderar dessa lösningar inte att bli optimala ur hänseende på prestanda och underhåll. En möjlighet är att man behåller databasen och i övrigt baserar sin lösning på mer modern teknik. Nackdelen med en sådan lösning är att databasens omfattning är en del av problemet. En genomgång av databasen där man migrerar data till en ny tabellstruktur och rensar bort tabeller som bara ligger kvar av historiska skäl skulle ge en databas som är betydligt lättare att underhålla. Bland riskerna som finns med att bygga vidare på en gammal grund är att man upprepade gånger tvingas ta designbeslut baserade på en omodern teknisklösning vilket kan resultera i att man inte fullt ut kan nyttja den nya tekniken. En annan möjlighet kan vara att på sikt flytta över all funktionalitet ifrån Ladok Nouveau till LpW för att minska Uniface beroendet, fast i praktiken så innebär ju det att man bygger nytt fast utan möjlighet till den senaste tekniken. Risker med nuvarande lösning Enligt Compuwares egna produktutvärdering av Uniface 1 så är det största problemet med deras lösning att 4GL/RAD baserade utvecklingsmiljöer är helt ur mode till fördel för kodbaserade miljöer som Visual Studio.Net och Eclipse. Detta är en helt riktig analys och i takt med att kunderna lämnar plattformen kommer nyutveckling och underhåll bli lidande. I samma utvärdering påpekar de att även om man fortfarande kan bygga monolitiska klient/server applikationer så det mest troliga att man vill bygga för webben. Frågan man skall ställa sig är om man vill bygga vidare på en lösning som i möjligaste mån och vad arkitekturen tillåtigt har anpassats för att göra något helt annat än vad det ursprungligen utvecklades för eller om man skall välja en lösning som är designad och utvecklad för att lösa dagens svårigheter inom webbutveckling. I dagens för föränderliga värld så är det också viktigt att snabbt kunna följa med de förändringar som sker. Väljer man att bygga vidare på den befintliga Uniface lösningen blir man beroende av att Compuware 1 Compuware Uniface 9 An Product Evaluation paper by Bloor Research (Author: Philip Howard) Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 13 / 45

15 ( har samma strategiska syn på framtiden. Exempelvis har man i Uniface valt att ha stöd för Microsofts Mobile Windows som operativsystem i mobila enheter (avancerade mobiltelefoner), vilket kanske inte så konstigt med ur amerikanskt perspektiv där Mobile Windows är ganska vanligt. Tittar man på fördelningen av operativsystem i mobila enheter ur ett globalt perspektiv så är Mobile Windows ganska litet med 12% av marknaden och det vanligaste, Symbian OS, dominerar med 65% av marknaden 2. Symbian OS används i vissa Sony Ericsson modeller och är också vanligt i Nokias telefoner och de globala siffrorna avspeglar nog mer förhållandet i Sverige. Ett annat möjligt problem är datasäkerheten, det nuvarande Ladok-systemet i princip är två system, LpW och Ladok Nouveau, med delad databas och separerad användaradministration. Den separerade användaradministration gör det svårt att hantera användarna enhetligt och upprätthålla en policy gällande byte av passord och liknande. Det finns en tydlig risk att även små förändringar blir ganska omfattande uppdrag eftersom det är lite av ett lappverk. Risken finns också att man skapar små öar med information inne i databasen då tabell strukturen är ganska omfattande och svåröverblickad. I och med att man låter externa processer integrera mot lösnigen via SQL så blir det väldigt svårt, för att inte säga omöjligt att göra tabellförändringar och risken finns att databasen växer till en punkt där det blir väldigt svårt att underhålla systemet då man inte längre har någon överblick över vad som händer vid en eventuell förändring. Vägande skäl för en teknisk ombyggnad av systemet Drift och underhåll Som Ladok ser ut i dag så är systemet lite spretigt med olika program som löser olika problem. I en optimal underhålls situation så byggs systemet på kända och etablerade standarder vilket innebär att man enkelt kan få del av buggrättningar och uppdateringar och att man kan applicera dessa under kontrollerade former utan att få överraskningar i form av funktionalitetsbrister. I en lösning där fler separata komponenter utgör systemet som exempelvis LpW (Ladok på Webb) och Ladok Nouveau är det svårare att se konsekvenserna av en förändring eller uppdatering. Ytterligare ett problem uppstår i och med att man tillåter varje läroanstalt att göra förändringar och ha direkt anslutning till databasen. I praktiken måste det vara väldigt svårt för de centrala utvecklarna att veta att det kommer fungera som det skall för respektive läroanstalt. Ett av de enklare sätten att få ner driftsoch utvecklingskostnaderna är försöka få en så enhetlig miljö som möjligt, se till att systemet har all den funktionalitet man behöver och minska behovet av omgivande produkter. Likaså uppfyller man idag inte helt de krav på funktion som användarna säger sig vilja ha och stödet för att kunna arbeta processorienterat är i princip obefintligt. Systemet behöver bli mer användarvänligt och lättanvänt. Ett stöd för rapportgenerering är något som saknas i systemet (Det kan inte vara lätt för läroanstalterna att hitta duktig administrativ personal som samtidigt är bra på SQL för att kunna generera rapporter). 2 Siffror för mobila OS, Market Share Sales Q4 2007: Symbian OS from Symbian Ltd. - 65%, Windows Mobile from Microsoft - 12%, RIM BlackBerry operating system - 11%, iphone OS from Apple Inc. - 7%, Linux operating system - 5%. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 14 / 45

16 Kostnader för licenser Hela den föreslagna lösnigen bygger på öppen källkodsbibliotek och open source produkter man slipper onödiga licenskostnader och kan välja i vilket utsträckning man vill köpa in support. I och med den flexibla supportmodellen kan man antingen köpa support konsortienivå, driftscentral nivå eller låta respektive läroanstalt själva välja hur man vill köpa in support; denna möjlighet borde ju innebära goda möjligheter för att förhandla till sig en kostnadseffektiv lösning. Kompetensbehov Lösningsförslaget bygger till viss del på open source produkter, exempelvis JBoss AS, som man redan använder inom verksamheten vilket gör att viss kompetens redan finns att tillgå inom verksamheten. Alla delar av lösningsförslaget bygger på öppna standarder vilket också gör det betydligt enklare att hitta litteratur, utbildningar och vid behov extern kompetens. Det är också betydligt enklare att hitta och utbyta information i forum på internet när det är stora kända standarder. Uppfyllande av förändrade omvärldskrav Med den nuvarande systemlöningen kan man säkert följa omgivningens krav på förändring, men utredaren ställer sig tvekande om detta kan göras med bra systemsäkerhet och utan att lösningen blir ett lappverk av olika lösningar som var för sig löser något specifikt problem. Andra krav som kan komma att ställas är ökat mobilitet bland användarna och studenterna kommer att röra sig mer mellan läroanstalterna både inom Sverige men även utomlands. För att kunna möta detta förändrade beteende så behövs det förbättrade möjligheter till integration. Om integrationsmöjligheterna skall gå att nyttja effektivt så behövs det ett mer sammanhängande system och en gemensam meddelande buss som kan nå alla system komponenter. Vidare kommer antagligen det ställas krav på att kunna nyttja funktionaliteten via terminaler som mobiltelefoner och att information skall skickas via andra kanaler som exempelvis SMS och för att möta detta krav behövs det en arkitektur som mer effektivt stödjer integration mot omgivande system. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 15 / 45

17 Tekniska vägval för en framtida lösning Visionära möjligheter och enkel teknik för framtiden Verksamhetens behov av ett enkelt och driftsäkert system ligger till grund för att välja en Java baserad lösning med. Eftersom man redan inom konsortiet gjort det strategiskt riktiga valet att byta ut Mimer databasen mot MySQL, samt valt att satsa på Linux som plattform. Även applikationsservern JBoss AS är en produkt som redan är känd inom verksamheten och det finns ingen anledning att inte dra nytta av den kunskap som redan finns när man valt så starka produkter som grund. Nästa del av förslaget är att ta bort möjligheten till att direkt ansluta sig till databasen. Även om detta ofta är ett enkelt och snabbt sätt att integrerar system med varandra så ger det små eller inga möjligheter att effektivt validera inkommande data, man har svårt att utreda hur systemets prestanda fördelas över processerna. En bra integrationslösning med väldefinierade XML meddelanden och möjlighet att validera dessa mot ett XML Schema skapa en betydlig högre informationssäkerhet. En bra integrationslösning (ESB) ger även möjlighet till övervakning och spårbarhet av meddelande flöden. Integrationslösningen (ESB) ligger externt utanför systemet och föder Ladok-systemet med data via JMS. Figur 1: Meddelandet tas emot via Integrationslösningen (ESB) och skickar in det via JMS till Ladok systemet. Integrationslösningen (ESB) transformerar inkommande meddelande från de meddelade standarder som man valt att acceptera. Det inkommande meddelandet klassificeras och loggas. Innan meddelandet läggs på JMS kön in i Ladok-systemet så transformeras det till XML om det inkommande meddelandet inte var i XML-format och valideras mot ett XML Schema. Skulle valideringen av meddelandet indikera att något är felaktigt så loggas detta och ett e-post meddelande skickas till någon som kan åtgärda felet, alternativt skicka det felaktiga meddelandet och felmeddelandet ifrån valideringsprocessen till någon person som är ansvarig för det avsändande systemet. Väl inne i Ladok-systemet så valideras XML meddelandet igen mot XML Schemat i samband med att man löser upp meddelandena med JAXB. Valet Integrationslösningen (ESB) behöver inte vara samma för alla Ladok installationer det kravet som måste uppfyllas är att man kan prata JMS med Ladok-systemet ifrån integrationslösningen (ESB). Rent praktiskt är det givetvis en fördel om även integrationslösningen (ESB) är standardiserad ur ett drifts- och underhållsperspektiv men det kan finnas historiska eller praktiska skäl till att man vill hålla fast vid en tidigare vald lösning. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 16 / 45

18 Figur 2: Ett meddelande skickas in till integrationslösningen ( ESB). 1: Loggning, 2: Konvertering 3: Validering 4: Eventuellt skickas ett felmeddelande till någon ansvarig. Om inga fel har inträffat så skickas meddelandet vidare via JMS in i Lador systemet. Själva Ladok-systemet är uppdelad i flera skikt (n-tier) där botten skiktet utgörs utav databasen, ett mellan skikt med JBoss AS som kör Hibernate och de övriga ramverken och som kommunicerar med databasen via JDBC. I toppen på ligger klientskiktet med HTML och Ajax (Asynchronous JavaScript And XML). Kommunikationen mellan applikationsserverns/webbservern och klienten sköts via standard http/s, förslagsvis så sitter det en brandvägg i mellan för att skydda installationen mot intrång. Vill man ytterligare stärka säkerheten kan man även ha en brandvägg mellan applikationsservern servern och databasservern (Innan man gör några för drastiska försök att förbättra säkerheten skall man noga analysera vilken hotbild man har mot systemen, risken är stor att man investerar i fel lösningar utan att ha analyserat vart bristerna i systemet är) Arkitekturen tillåter möjligheten att skapa ett kluster av applikationsservrar ifall man anser att prestanda eller tillgänglighet inte kan garanteras med endast en uppsättning av maskiner. Vill man förbättra prestanda eller tillgänglighet för databasen kan man nyttja de tekniker som databasleverantören rekommenderar. Vid utveckling kan hela lösningen komprimeras och utvecklingsmiljön (Eclipse), Webbläsare, Applikationsserver (JBoss), samt databas server (MySQL) installeras på utvecklarens dator. Figur 3: Flerskitslösning Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 17 / 45

19 Webbklient-delen av systemet bör vara baserat på JavaScript och XML (Ajax) och lämpliga ramverk kan vara JBoss Richfaces ( SproutCore ( eller exempelvis MyFaces ( Vad man väljer här är avhängt hur man vill att kontroller och knappar skall se ut, samt om man har speciella funktionella krav. Beslutet om vilket ramverk som skall användas på klientsidan behöver vara väl förankrat hos de som kommer utveckla systemet. Tvingar man på utvecklarna ett klient ramverk som de inte är nöjda med kommer det påverka resultatet negativt och deras upplevelse av klient ramverket kommer i viss mån sätta tonen för om projektet är lyckat eller inte. Viktigt att förstå är att det finns en större mängd klient ramverk att välja mellan och vissa av dessa är otroligt effektiva om man använder dem på precis det sättet som de var tänkta för, om sättet att utveckla eller kravbilden avviker ifrån det optimala användningssättet kan klient ramverket istället bli ett stort problem. Rätt implementerat kommer användaren uppleva att funktionaliteten hos webbläsaren ligger i samma nivå som om det hade varit en fet klient installerat på klientmaskinen. I och med att servern har möjlighet att se vilken typ av enhet eller webbläsare som anropar server så kan man också anpassa det svaret som skickas tillbaka för den typ av enhet som efterfrågar webbsidan. Figur 4: Servern anpassar sin vad som skickas som svar beroende på vilken typ av plattform som är mottagare av informationen. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 18 / 45

20 Databasen och själva logiken i bör vara uppsatt på ett sådan sätt att man i samma miljö hantera flera instanser av Ladok. Detta är väldigt viktigt vid felrättning och utveckling. En utvecklare kan då flytta hela datamängden från ett system in till sin egen utvecklingsmiljö för att kunna felsöka och testa i en kontrollerad miljö, men med riktig data. Utöver fördelarna vid utveckling får man flexibilitet att flytta funktionalitet tillfälligt mellan fysiska system vid exempelvis uppgradering eller support på hårdvara, samt att man ges möjligheten att med ganska enkla medel kan höja prestandan genom att installera ytterligare maskinvara parallellt med befintliga system. Under utveckling bör enhetstester via JUnit användas för att ge utvecklarna möjlighet att verifiera och validera funktionaliteten i systemet. Samtidigt får man inte glömma att ta höjd för riktiga definierade funktions och integrationstester. Enhetstester är ett bra verktyg för utvecklaren att testa funktionalitet men inget säkert sätt att testa system på. För att underlätta utvecklarnas arbete bör man dra nytta av ramverk som Spring Framework ( Utvecklingsplattformen Eclipse ( är en av de absolut bästa på marknaden och även den är open source och gratis att nyttja. Eclipse är plugin-baserad och det finns en uppsjö med plug-in:er för att utöka funktionalitet eller förbättra stödet för exempelvis JBoss AS. Eclipse har ett bra stöd för kod revisionshantering och i lite större projekt med fler än en deltagare är det ett absolut måste med en centraliserad lösning för kod revisionshantering. Om man inte redan har valt något system för kod revisionshantering så är Subversion ganska enkelt att använda och få igång. En fördel med Subversion är att all meta information om revisionerna ligger på hårddisken tillsammans med koden och vid backup räcker det med att man gör en kopia på directory strukturen på servern för att få med allt. Vissa mer avancerade lösningar kan vara rätt svåra att göra backup på. Subversion fungerar för ett flertal Linux- och Unix-miljöer och finns att hämta ifrån Ett viktig användningsområde som man inte får missa är möjligheterna att generera rapporter ifrån Ladoksystemet. I den nuvarande Ladok-lösningen har de som jobbat med systemet kunnat knåpa ihop några rader SQL och kört frågan mot databasen. Att köra SQL mot databasen är tekniskt möjligt även i det nya lösningsförslaget, men inte önskvärt utav fler skäl. Kör man SQL mot databasen är det väldigt svårt att kontrollera vilka resurser som krävs för att svara på frågan; en klumpigt ställd SQL-fråga kan skapa låsningar och prestanda problem i nästan vilken databas som helst. Ställer man dessutom SQL-frågor mot en databas som kontrolleras av Hibernate så passerar frågan utanför hela Hibernate ramverket och man kan inte dra nytta av de mekanismer för ökad prestanda som Hibernate erbjuder, som exempelvis cache och optimerings funktionalitet. Lösningen för att behålla flexibiliteten i SQL samt dra nytta av fördelarna hos Hibernate är att använda Hibernates egna SQL liknande språk HQL. Om man är duktig på SQL är det inget stort steg att förstå och skriva HQL. En annan lösning är att man lägger tid och energi på att utveckla ett rapportverktyg som ger användaren möjlighet att skapa egna frågor mot datamängden via ett webbinterface. Verktyget bör även ge möjligheten att spara frågor både lokalt bara för mig som användare och system globalt ifall jag vill dela med mig av mina mer lyckade HQL frågor. Rapportverktyget behöver dessutom ge en möjlighet att exportera som Excel- och XML-format för export till andra verktyg där man vill ha möjlighet att processa data ytterligare. En möjlig produkt att använda här skulle kanske kunna vara Jasper Reports ( eller något liknande. Ny datamodell och migration I den nuvarande Ladok-lösningen så är det problem med att attribut använd även som nycklar. Detta skapar problem vid exempelvis byte av personnummer. I samband med ett systemskifte så behöver databasen se över och förslagsvis börjar man ta höjd för datamigration redan vid utvecklingsstart. Ett sätt att adressera detta är att Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 19 / 45

21 man använder sig av data som kommer ifrån det befintliga systemet redan under utveckling och att man bygger funktionalitet för datamigration samtidigt som man utvecklar den nya funktionaliteten. Exempelvis skulle arbetsflödet kunna gå till så här: 1. Identifiera ett begränsat område som man vill migrera (Lättast är det om man kan ta bit för bit av funktionaliteten) 2. I den befintliga lösningen identifierar man de tabellerna som innehåller den data man behöver. 3. Skapa Java-objekten som kan hantera data från den befintliga lösningen och lägg till egna nyckelbegrepp till objekten och var noga med att använda rätt Java-typer; exempelvis Integer osv. 4. Låt Hibernate genererar de tabeller som behövs för att spara Java-objekten ifrån punkt Undersök hur databasen blev skapad och upprepa punkt 3 5 tills man uppnår ett tillfredställande resultat. 6. Skriv kod som via en SQL anslutning kopierar (migrerar) och in till de Java-objekten man skapat och låt Hibernate spara objekten i databasen. Se även till att göra en typ konvertering mellan data så exempelvis numerisk data blir konverterade till Java typerna Long, Integer eller motsvarande 7. Validera att data i de nya tabellerna ser ut som förväntat, upprepa punkt 6 7 och eventuell punkt 3 och framåt tills ett tillfredställande resultat har uppnåtts. 8. Bygg de grafiska gränssnitt som behövs för att kunna se och editera data som migrerats. Upptäcker man något saknas eller är fel upprepar man processen ifrån punkt 2 och framåt. 9. Bygg enhetstester för att kunna validera funktionaliteten. Följer man schemat ovan så kommer man i slutändan har all den generella kod som behövs för att migrera databasen. Man kommer ha konverterat data till dess naturliga format, samt ha tester att validera funktion och data. Ett problem kan vara de lokal variationer av databasen som existerar och där får man ta höjd för detta genom att göra anpassningar i den generella lösningen för att täcka dessa lösningar. Målet är att få en generell databas modell för alla Ladok-system och lokala avvikelser skall undvikas i mesta möjliga mån. Ur ett underhållsperspektiv blir det väldigt kostsamt att underhålla ett flertal system med små lokala skillnader och risken är överhängande att man får problem vid gemensamma uppdateringar av systemet. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 20 / 45

22 Krav på drift och underhåll De tekniska drifts- och underhållskraven på Ladok skiljer sig inte nämnvärt ifrån andra webb-baserade system. Det som framför allt är viktigt är att hålla kostnaderna nere så mycket som möjligt och det bästa sättet är att man göra systemen för respektive läroanstalt så lika som möjligt. Förslaget att ett Ladok-system skall kunna hålla olika instanser av Ladok för olika lärosäten ger driftsorganisationen möjlighet att konsolidera flera system på samma hårdvara kan vara ett sätt att underlätta för driftsorganisationen och spara pengar på. En möjlighet som ligger lite utanför själva Ladok-systemet är att nyttja virtuella servrar. Systemuppsättningen blir snarlik eller samma som beskrivet i detta dokument, men skillnaden ligger i att istället för att installera på Linux hårdvara så installeras miljöerna i virtuella maskiner. Fördelen ligger i att i den virtuella miljön finns ingen koppling till hårdvaran och det är helt upp till drift personalen att fördela prestanda, diskutrymme och andra resurser till de virtuella miljöerna. Möjligheterna öppnas att nyttja resurserna i datahallarna mer effektivt och man brukar kunna spara pengar på att mindre mängd el går åt att driva och kyla maskinerna. Grön IT innebär ju även vinster utanför datorhallen som kan var önskvärda. Framtida kompetensbehov I det lösningsförslag som tagits fram ligger kompetens tonvikten på Java, JavaScript, Ajax, JBoss AS, Hibernate, XML Schema, XML och Spring framework detta är stora öppna standarder och kunskapen som förvärvas under utvecklingen går utmärkt att använda i andra webbaserade projekt. Denna kunskap är inte heller något problem att köpa in externt. Väljer man att inte uppdatera Ladok till en ny systemgeneration kommer man fortsättningsvis ha ett krav på Uniface-kompetens som kan vara svårt att uppfylla externt. Version 1.1 Marcus Gelderman, marcus.gelderman@blueroom.se 21 / 45