Ny systemgeneration Ladok

Transkript

1 Ny systemgeneration Ladok Förstudie GEM T-8004 Ny systemgeneration Therese Söderlund Mikael Berglund Pål Edström Version: Beteckning: 1.00 GEM T-8004 Rapport Status: Utkast

2 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 2 (21) Ändringshistorik Revision Datum Av Kommentar Granskare Godkännare

3 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 3 (21) Innehållsförteckning 1 SAMMANFATTNING INLEDNING SYFTE BAKGRUND MÅL FÖRUTSÄTTNINGAR AVGRÄNSNINGAR RESULTAT METODBESKRIVNING BEFINTLIG ARKITEKTUR PRODUKTUPPDELNING UNIFACE JAVA C/C INTERNATIONALISERING INTERNATIONELLT UTBYTE TEKNISKA VÄGVAL STANDARDER OCH RIKTLINJER KLIENTER Tunga vs lätta klienter Webbklienter Mobila klienter FLERSKIKTADE ARKITEKTURER INTEGRATION SÄKERHET Validering Autentisering och behörighetskontroll PROCESSTÖD NATIONELLT LADOK GRADVIS MIGRERING DRIFTASPEKTER BEFINTLIG ARKITEKTUR REDUNDANTA MILJÖER LEVERANSER SAMMANFATTNING RISKER OCH MÖJLIGHETER SLUTSATSER... 6

4 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 4 (21) 1 Sammanfattning Denna förstudie syftar till att visa på och preliminärt värdera riskerna med att stanna i dagens tekniska lösning, samt att peka på viktiga tekniska vägval som Ladokkonsortiet står inför. Den visar på att det i ladoksystemet finns en god grund att stå på för kommande systemgeneration genom den satsning på SOA-tjänster som gjorts inom LPW och LadokConnector. Det är inte tekniken som ligger till grund för en ny systemgeneration utan att kraven på systemet förändras. Nästa systemgeneration kan vara en konsolidering av befintliga produkter till färre tekniker eller ett central system i samma anda som NyA. I båda fallen rekommenderas en skiktad arkitektur med en tunn klient. Integration mot andra system kan med fördel ske med hjälp av SOA-tjänster. Uniface bör på sikt fasas ut, då kompetensförsörjningen för unifaceutvecklare blir svårare att tillgodose. För det fortsatta arbetet med framtagandet av en ny systemgeneration bör vidare utredningar ske i fråga om hur det skall driftas och levereras, samt hur systemet skall designas för att nyttjande av metadata ska kunna göra det mer flexibelt mot förändringar, då konfiguration snarare än programmering förändrar systemets beteende. 2 Inledning 2.1 Syfte Syftet med förstudien är att visa på och preliminärt värdera dels riskerna med att stanna i dagens tekniska lösning, dels peka på viktiga tekniska vägval som Ladokkonsortiet står inför och visa på visionära möjligheter som en ny teknikgeneration ger. 2.2 Bakgrund Bland de kända verksamhetsförändringarna ingår att: Studenterna fungerar som tydliga medaktörer med kraftigt förändrade förväntningar Utbytena 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, sänk utvecklings-, underhålls- och driftkostnaderna Högskolorna önskare en bättre processanpassning av stödet (workflow) En nära släkting, NyA har kommit med som ny aktör och fokuserat på behovet av effektiv samverkan mellan system, åstadkommit att en flora av utbildningsdatabaser utvecklats

5 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 5 (21) 2.3 Mål Förstudiens mål är att under augusti ta fram en rapport som kan arbetas in i ett samlat förslag till styrelsemötet i september som kan föreläggas höststämman och som kan utgöra ett beslutsunderlag för vidare aktiviteter. 2.4 Förutsättningar Inga speciella förutsättningar finns. 2.5 Avgränsningar Vi förutsätter att verksamheten i stort sett kommer se likadan ut som idag, med självständiga högskolor, Bologna-modellen, utbildning i form av kurser och program etc. De verksamhetsdelar som systemet skall omfatta är huvudsakligen Studieadministration Studenttjänster Examina Kursadministration VFU 2.6 Resultat Utredningen i detta teknikuppdrag ska innehålla två olika perspektiv, dels teknikleverantörens perspektiv och dels en extern oberoende parts perspektiv. Båda perspektiven ska omfatta följande delar: Vilka grundkomponenter vi behöver för att lösa verksamhetens behov. Redovisa de viktigaste skälen till att göra en större teknisk ombyggnad av systemet och beslutskriterier för vad som ev. skulle kunna nödvändiggöra en sådan. Vilka tekniska vägval som finns vid en större teknisk ombyggnad av systemet samt beslutskriterier och möjligheter med dessa. Beskriva riskbilden med att stanna kvar i nuvarande systemlösning oavsett hur de framtida verksamhetskraven ser ut. Vilka systemförändringar som behöver göras för att möta kända förändrade omvärldskrav. Diskussion angående visionära möjligheter med en ny systemgeneration. Säkerhetsaspekter i nuvarande situation och inför framtida ev. förändringar. Nationella tekniska samarbeten som bör tas hänsyn till.

6 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 6 (21) Diskutera olika alternativ för systemarkitektur både utifrån dagens situation och utifrån en ev. framtida förändring. Kostnadsaspekter ska beaktas och jämförelser med liknande administrativa system redovisas 2.7 Metodbeskrivning Synpunkter har inhämtats i samtal med anställda på ladokenheten. En workshop har också hållits med forskare vid informatik och datavetenskap för att samla in synpunkter. 3 Befintlig arkitektur 3.1 Produktuppdelning Ladoksystemet består idag av ett antal produkter som har databasen som gemensam nämnare. Det är ett resultat av den påbyggnad och modernisering som har gjorts av Ladoksystemet genom åren. Uppdelningen innebär en försvårad leveranshantering på grund av skillnader i processerna för leverans av de olika produkterna. Affärslogiken är på många ställen duplicerad i de olika produkterna. Ett arbete har påbörjats för att skapa ett gemensamt logiklager för Java-produkterna. Det är dock väldigt svårt att återanvända logik som är skriven i Uniface utan att göra stora omstruktureringar. En utredning för dessa möjligheter föreslås inför Risken är att systemet lever kvar med stora delar duplicerad affärslogik och en högre underhållskostnad. Detta medför att större förändringar blir mer resurs- och tidskrävande. 3.2 Databas Databasen utgör kärnan i Ladok och har byggts på ifrån systemets början i mitten på 80-talet och består idag av ca 350 tabeller. Idag förekommer direkt läsning och skrivning ifrån externa system på sina håll. För framtiden bör denna direktaccess upphöra till förmån för kommunikation med ladok genom definierade gränssnitt, dels för att underlätta anpassningar av datamodellen till följd av förändrade krav, men också för att reducera risken för felaktiga inmatningar i databasen. Ladokdatabasen skulle för framtiden kunna kompletteras med en separat databas för datawarehouseverksamhet vilket kan ge användare stora möjligheter att lyfta fram specifika kombinationer av data för deras behov. Detta bör utredas vidare. 3.3 Uniface Uniface är en 4GL-miljö som lanserades Genom åren har Compuware lagt till funktioner för att exponera funktionalitet via HTTP, SOAP-gränssnitt och Unicode. Expertklienten för Ladok är implementerad i denna teknik. 3.4 Java I Ladokportföljen finns LPW, LadokPing, Online CA, Ladok Connector och Javabatchar som är implementerade i Javateknik.

7 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 7 (21) Under de senaste åren och inom en överskådlig framtid byggs de flesta Javabaserade administrativa system med en kombination av Tomcat och en applikationsserver såsom JBoss eller IBM WebSphere. Det är delvis denna teknik som används för Ladoks Java-applikationer. 3.5 C/C++ Trafla och den alternativa inloggningen är de programvaror som idag är programmerade i C- teknologi. Trafla håller för närvarande på att skrivas om till följd av databasbytet och övergår i samband med det till Java. 3.6 Internationalisering En risk med befintlig teknik är avsaknaden av internationalisering för att kunna använda andra språk än svenska i Ladoksystemet. Uniface Har stöd för flerspråkiga applikationer, både för texten i själva gränssnittet och för inmatningsfält. Detta används inte idag för texterna i gränssnittet på t.ex. knappar och menyval. LPW Har stöd för felmeddelanden och hjälptexter på flera språk. LadokPing De flesta delarna av applikationen är förberett för flera språk. STAM Har inte stöd för flera språk. Trivialt att implementera ett sådant stöd. Trafla Har inte stöd för flera språk. Javabatchar Har inte stöd för flera språk. Trivialt att implementera ett sådant stöd. Ladoksystemet är i dagsläget väl rustat för att hantera en framtida övergång till andra språk. Dock krävs en betydande arbetsinsats för att definiera alla texter i Nouveau externt. Själva programkoden och tabelldefinitionerna är skrivna på svenska, vilket försvårar ett eventuellt samarbete med andra länder. Teckenuppsättningen som används för att lagra data är ISO Denna teckenuppsättning kan hantera de flesta västerländska språk, förutom Holländska, Estniska, Franska, Finska och Walesiska. För att få en mer komplett möjlighet att lagra texter på andra språk bör en övergång till Unicode genomföras. Detta är genomförbart, då alla ingående komponenter i Ladoksystemet stödjer Unicode. Däremot måste vissa batchar skrivas om för att bibehålla dagens format. 3.7 Internationellt utbyte I Europa pågår ett antal initiativ för att förenkla studieadministration mellan länder samt att definiera gemensamma standarder för informationsutbyte. Ett av dessa initiativ heter RS3G, Rome Student Systems and Standards Group. I dagsläget pekar allting mot att dessa standarder kommer att utvecklas med öppna standarder som XML och HTTP. Ladoksystemet använder idag XML och HTTP och bör kunna anpassas till de framtida tekniker som utvecklas i ett europeiskt samarbete.

8 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 8 (21) 4 Tekniska vägval 4.1 Standarder och riktlinjer Ett nytt Ladoksystem bör utvecklas i enlighet med rådande standarder för att säkerställa interoperabilitet, undvika specifika leverantörsberoenden och ge förutsättningar för framtida kompabilitet. Exempel på sådana standarder är HTTP, SOAP och SOA, men många fler förekommer. Att arbeta efter standarder bör vara utgångspunkten för allt arbete. Det finns många organisationer som utvecklar standarder, riktlinjer och rekommendationer. En sådan är W3C som beskriver standarder och riktlinjer för webben ur ett långsiktigt perspektiv, en annan är OASIS som bl.a. kompletterar med standarder för offentlig sektor. Det är viktigt att studera resultat från sådana organisationer för att utveckla ett flexibelt och långsiktigt hållbart system. Riktlinjer och rekommendationer talar även om användning av öppna standarder, exempelvis Open Source. Detta är viktigt och ska prioriteras högt, men kan inte helt utesluta andra alternativ när det verkligen krävs. Vid design av ny systemlösning har vi goda möjligheter att helt använda öppna standarder. Idag är operativsystemen för drift av Ladok baserade på Open Source. Ersättaren av Mimerdatabasen kommer med hög sannolikhet också att omfattas av definitionen för Open Source. Där inte standarder finns bör man titta på defacto-standarder, dvs. allmänt vedertagna metoder och tekniker för att få ett så tekniskt flexibelt system som möjligt. 4.2 Klienter I stort sett alla moderna systemarkitekturer baseras på Client-server-teknik, en distribuerad lösning där användarnas klienter kommunicerar mot mer eller mindre centralt placerade servrar. Exempel på andra tekniker är Peer-to-peer och Client-Queue-Client. Både Peer-to-peer (P2P) och Client-Queue-Client (CQC) är mer lämpat för fri information där man inte behöver eller vill ha kontroll över vad som lagras, vem som har rätt att accessa vad etc. Client-server-teknik är det naturliga valet för administrativa system Tunga vs lätta klienter Användning av antingen tunga eller lätta klienter tycks vara cyklisk. Under 70-talet användes billigare terminaler inom kontorets fyra väggar mot centrala, dyrbara, datorer i källaren, men i takt med att PC:n blev var mans egendom förflyttades datakraften ut från datahallen och vi kunde se fler och fler tunga klienter. Klienterna innehöll (och innehåller, ett aktuellt faktum) allt mer funktionalitet, vilket ofta gör att de administrativa kostnaderna för support, drift och underhåll av arbetsstationer kan bli stora. Det är en viktig anledning till att man sedan en tid tillbaka återigen har börjat titta på betydligt lättare klienter. De tunga klienterna innehåller oftast mycket programkod och kräver mycket processkraft av den lokala arbetsstationen, medan de lätta klienterna står för motsatsen, det mesta av all applikationskod är lagrad på servern. Ladoks Uniface-klienter går idag under definitionen för en

9 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 9 (21) tung klient. Vi har sedan början av 1990-talet använt Compuwares Uniface-miljö som på den tiden var ett bra alternativ för att utveckla administrativa system med god interaktion. Exempel på en lätt klient är en vanlig webbläsare som idag kan vara en kompetent klient; det är möjligt att utveckla klientprogramvara för webb med i stort sätt lika avancerad interaktion som traditionella klienter. Andra exempel på tekniker som möjliggör mer avancerade gränssnitt där klienterna kan vara relativt tunna är Flex, Flash, Silverlight, Ajax, Curl, Java och.net. En kort redovisning över för- och nackdelar med tunga respektive lätta klienter Fördelar tunga klienter Datakraften som behövs är fördelad på många maskiner vilket reducerar storleken på servrarna i datahallen Mindre kommunikation behövs i nätverket eftersom mycket av processandet sker lokalt på klienten Möjlighet att bygga klienter som klarar visst offlinearbete Stor tillgång till verktyg för att relativt snabbt utveckla skalbara administrativa system med god användbarhet. Nackdelar tunga klienter Distribution av uppdateringar och nya programvaror kan vara mycket krävande eftersom alla programpaket måste kunna installeras på samma sätt hos varje klient trots att varje användare normalt har stor frihet att konfigurera och förändra sin egen arbetsstation. Olika felbeteenden kan uppstå på olika klienter varför support kan bli tidskrävande och kostsam. Också svårt att kunna återskapa problem vid en supportsituation. Generellt tar uppdateringar av programvaror längre tid på tunga klienter än på lätta, där de flesta av uppdateringarna sker på servern IT-personal tappar delvis kontroll över systemet när kod exekveras på olika ställen. Risk för att olika arbetsstationer har olika versioner av samma programvara och kan därmed generera onödiga fel. Fördelar lätta klienter Installationer behöver inte utföras för varje klient vid uppdateringar vilket kan reducera support och kostnader för drift och underhåll väsentligt Möjligheten att ansluta olika typer av klienter till servrar som mobiltelefoner och handdatorer, förenklas då systemet delar på logik för olika typer av klienter. Felsökning och support underlättas då en stor del av användarinteraktionen bearbetas på servernivå. Garanti om att varje klient använder samma version av programvara. Nackdelar lätta klienter

10 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 10 (21) Fullständigt beroende till fungerande servrar; ett serveravbrott betyder totalt driftstopp varför redundant miljö kan behövas. Kräver betydligt mer kraftfulla servrar i datahallen Nätverk belastas mer då mer information transporteras Trenden inom utveckling pekar alltmer på webb och tunna klienter. Idag kan vi utveckla administrativa system med webbteknik som i princip ger lika goda möjligheter till interaktivitet som traditionella tunga klienter. All utveckling av Ladoksystemet sker idag med Java, ett av värdens mest spridda programmeringsspråk undantaget klienterna där fortfarande Compuware s Uniface används. Att även på klientsidan använda Java, eller motsvarande teknik, med god interaktivitet är idag realiserbart Webbklienter En renodlad webbklient är idag möjlig att använda som administrativ klient med godtagbar användbarhet. Java med Sun Microsystems i spetsen utvecklas kontinuerligt med nya klassbibliotek, tekniker och andra programtillägg. En av de senaste nyheterna är JavaFX som kommer att tillåta s.k. rich-content-innehåll på webben (rich-internet-applications, RIA). Swing är ett annat Javaalternativ som används i antagningssystemet NyA med framgång; en samling komponenter och klasser som bl.a. kan ge bra fönsterhantering på en relativt tunn klient. NyA har i stort sätt lyckats behålla en skiktad arkitektur med ett renodlat GUI utan inblandning av direkt affärslogik. Ladok på webb (LPW) använder JSP, Java Server Pages. Även andra tekniker utanför Javavärlden är tillgängliga som Flash, Flex, WPF (MS.NET 3.0), Silverlight, och i undantagsfall Curl. Att skriva tillämpningar i scriptspråk som PHP kan fungera bra för enklare applikationer, men rekommenderas inte till mer avancerade administrativa tillämpningar då möjligheterna är mer begränsade. En övergång till mer lätta klienter kan ge kostnadsfördelar på sikt. Med modern teknik kan god interaktivitet möjliggöras även med en ren webblösning, dvs med en lösning som använder en vanlig webbläsare. Att bygga strukturerade flerskiktade lösningar på effektivt sätt är idag verklighet för webben till skillnad för några år sedan då HTML-kod, databasanrop och annan scriptkod blandades i ett och samma lager. En konvertering av dagens Ladokklienter till serverbaserad kod är tekniskt möjlig men är en mycket kostsam lösning. Stora mängder affärslogik ligger i klientlagret (Uniface), varför hela klienten och även en hel del serverkod måste skrivas om. Ett system med webbklienter är däremot realiserbart i ett nytt Ladok. De webservices som idag finns utvecklade i LPW går också att återanvända i ett sådant system Mobila klienter Mobiltelefonen används till allt fler uppgifter än enbart telefonsamtal. Användningen av mobila klienter utmålas ofta som nästa generations naturliga val för interaktion med ganska avancerade system. I dagsläget hindras emellertid effektivt användande av liten skärmyta och svårigheter att

11 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 11 (21) skriva in text på snabbt sätt. Därför tillåts egentligen bara enklare interaktion, exempelvis markeringar av fördefinierade svarsalternativ. Vilket håll utvecklingen går mot är omöjligt att säga, men historiskt har inte interaktionen med mobiltelefonen förändrats nämnvärt. Därför bör stöd till mobiltelefoni inriktas mot enklare applikationer. Det finns i huvudsak två vägar att gå vid utveckling av mjukvara till mobiltelefoni. Antingen skriver man applikationer som man laddar ner från exempelvis en webbplats och därefter installeras på telefonen, eller så körs applikationerna genom telefonens webbgränssnitt (jmf tunga vs lätta klienter). Att skriva nedladdningsbara programpaket, i exempelvis J2ME eller C/C++, som passar för alla förekommande mobiltelefoner är fortfarande mycket svårt, trots löften om överbryggande samarbeten mellan leverantörer. Utveckling av applikationer till ett visst fabrikat måste i allmänhet anpassas till ett annat och ofta även till olika modeller från samma leverantör. Eftersom syftet är att eventuellt förekommande mobila tillämpningar verkligen ska användas, föreslås följande: Fokus bör vara enklare applikationer. Använd etablerade tekniker som SMS för informationsutbyte där det är möjligt. Använd HTTP för något mer avancerad interaktion. Det finns idag programvara som mer eller mindre automatiskt konverterar webbsidor så att applikationerna passar andra klienter som exempelvis handdatorer och mobiltelefoner. JavaFX är ett exempel på sådan teknik. Det bör betyda att inga större omskrivningar kommer att behövas för att interagera med mobiltelefoner, däremot blir det alltid en fråga om vad som egentligen passar till en mobil klient, sett ur ett användbarhets- och säkerhetsperspektiv. Dagens Ladok tillåter tekniskt att lägga till funktionalitet för mobil interaktion, men skulle antagligen negativt bidra ytterligare till den redan spretiga programportfölj vi har med de redan många beroenden som finns. 4.3 Flerskiktade arkitekturer En flerskiktad arkitektur är en client/server-arkitektur där lagren oftast består av ett presentationslager, logiklager och datalager. Detta kallas som regel för en 3-skikts-arkitektur. Presentationslagret hanterar användargränssnittet, t.ex. ett webgränssnitt eller en fristående applikation Logiklagret hanterar funktionaliteten, eller som det vanligtvis kallas, affärslogiken. Datalagret hanterar läsningar och skrivningar av data. En korrekt designad treskiktad lösning har flera fördelar jämförd med exempelvis en tvåskiktad där vanligtvis GUI och affärslogik blandas. Funktionalitet ligger kapslad i varje lager vilket kan göra att skala upp eller byta ut teknik i respektive lager.

12 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 12 (21) En tydligare struktur gör att utveckling och underhåll kan ske snabbare och effektivare, förutsatt gränssnitten mellan lagren är tydliga Säkerhet kan förbättras där det mer kritiska affärslagret kan omges av säkerhetsåtgärder. GUI-lagret kan, i idealfallet, enkelt bytas ut mot andra gränssnitt, ex från traditionell tung klient till lättare webbklient. Prestandahöjande åtgärder kan lättare införas på rätt ställe, både kodmässigt och fysiskt i serverhallen, om de olika skikten befinner sig på olika servrar. 4.4 Integration Ladoksystemet är i dag och kommer i framtiden att vara en allt mer integrerad del av ITinfrastrukturen på högskolorna och universiteten än vad det tidigare varit där systemen var separerade från varandra. Behov finns av integration med lärplattformar, utbildningsdatabaser och koncernkataloger inom högskolan, mot NyA, SCB och SPAR utanför den egna högskolan. Genom att definiera och erbjuda tydliga standardiserade gränssnitt mot Ladoksystemet underlättas kommunikationen. Det ledande kommunikationssättet kommer troligtvis att vara webservices med tydliga kontrakt av vad som levereras. En tätare integration med andra system föder nya frågor att besvara: Hur ofta skall leverans ske och till vem? Vem bär ansvar för integrationen och därigenom tester av den fullständiga kedjan? Hur skall versionshantering av publicerade gränssnitt hanteras? Statens spridnings och hämtningssystem, SHS framtaget av VERVA, det statliga verket för förvaltningsutveckling är som integrationprodukt intressant och utgör en viktig brygga mellan divergerade svenska myndigheter. Både CSN och SCB som Ladok i dag kommunicerar använder SHS i andra tillämpningar. Eftersom de befintliga kopplingarna mot Ladok fungerar finns idag ingen anledning till att gå ifrån SFTP-baserad överföring till fördel för SHS. Om nästa version av SHS får ännu större utbredning nationellt, men främst internationellt, bör Ladok vara förberett för att koppla upp sig. SHS är något som Ladok bör bevaka och följa, men kanske även påverka, för att kunna använda tjänsten mot sina framtida externa parter. 4.5 Säkerhet Validering Användandet av elektroniska dokument kommer att öka och detta ställer andra krav hur lämnade uppgifter verifieras, istället för att som idag förlita sig på stämplar och underskrifter blir digitala signaturer aktuella för verifiering. Registrerings- och reslutatintyg är idag möjliga att få ut med digitala signaturer ur Ladok. Dessa är idag signerade med en opersonlig signatur men för andra typer av tillämpningar kan det komma att handla om personliga signaturer för t.ex. examensbevis. Anpassningar och tillägg behöver göras i Ladok för att detta skall ske. Vad det är som signeras bör också utredas, om det skall vara själva innehållet i dokumentet eller dokumentet i sig, eftersom det får konsekvenser för hur uppgifterna skall lagras.

13 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 13 (21) Autentisering och behörighetskontroll Autentisering och behörighetskontroll har alltid varit extern i LPW, något som möjliggjort anpassningar till den lokala IT-infrastrukturen på respektive högskola, och det är rimligt att tro att den även i framtidens system kommer att vara det. Behörighetskontrollutredningen 1 indikerar att plugin-modellen för behörighetskontroll i LPW kan komma att behöva utökas för att hantera fler roller än i dagsläget. Tyvärr har det historiskt sett varit ett hinder i driftsättningen av LPW att autentisieringen och behörighetskontrollen varit extern, då dessa tjänster inte alltid funnits tillgängliga på högskolan. Idag finns dock tjänster för autentisering på de flesta håll men fortfarande saknas behörighetskontrollsystem på många ställen. Idag det inte heller nödvändigtvis så att det är en slutanvändare som använder Ladoksystemet genom LPW, utan att det kan också vara ett annat system som kommunicerar med Ladok via LPW. Denna typ av användning måste också autentisieras och behörighetskontrolleras och dagens lösning har stöd för detta. I LadokPing används servercertifikat för autentisering mellan noderna och en accesslista för att avgöra vilka noder som är behöriga att ställa frågor mot respektive LadokPing-nod ute på varje högskola. En farhåga som fanns när LadokPing implementerades var att administrationen av accesslista och framförallt certifikatsutbytet mellan noderna skulle bli tidskrävande, men genom nyttjande av root-ceritfikat blev administrationskostnaden väsentligt lägre än befarat och inga problem upplevs idag. I NyA har man introducerat federerad inloggning, vilket möjliggör att nya studenter kan logga in på sin högskola via inloggningsuppgifterna från NyA. Dessa nya tekniska lösningar ger nya möjligheter att hantera t.ex. utbytesstudenter och utbildningar som delas av två eller flera högskolor. En ny systemgeneration bör använda sig av dessa möjligheter. 4.6 Processtöd Automatiserat processtöd kommer att bli viktigt inte bara för att reducera felkällor och spara tid, dessutom ökar förväntningarna från samhället på myndigheterna att öka servicen. Nya generationer studenter förväntar sig förifyllda blanketter som i stort sett bara kräver granskning och underskrift. Bättre systemstöd för examensansökan, så att studenten endast behöver signera ansökan efter ett meddelande från systemet att man uppfyllt kriterierna för en examen är ett exempel på vad ett automatiserat processtöd skulle kunna erbjuda i framtiden. Ett paradigmskifte är på gång inom universitetsvärden där högskolan går från att vara myndighetsutövare till att vara serviceutövare med studenterna som en målgrupp. Andra myndigheter gör samma resa, varav Skatteverket är ett exempel på detta. Detta gör att arbetsflödet förändras till följd av att de yttre kraven förändras. Ladok blir inte längre ett ärendehanteringssystem utan ett Customer Relationship Management-system (CRM) vilket innebär att individperspektivet får större betydelse än universitetsperspektivet. Detta påverkar systemet såtillvida att andra processer än de som finns i dagsläget blir viktiga att stödja. 1 Berglund, Mikael, TEK-05-T-03 Rapport för behörighetskontrollutredning

14 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 14 (21) För att Ladoksystemet skall kunna vara verksamhetsnyttigt krävs att det är väl anpassat till de verksamhetsprocesser som det skall användas till och att det är dynamiskt för att möta förändringar i processerna. Det första kräver kartläggningar av processerna och det stöd systemet erbjuder. Det andra handlar om tekniska anpassningar av systemet för att kunna ta hand om förändringar. Om Ladok ska kunna anpassas till andra administrativa arbetssätt kan systemet designas så att processer, processflöden och information kan styras med metadata och snabbt kunna anpassas till nya behov. Viss statisk utveckling kommer alltid att behöva adderas men huvuddelen av ett nytt system bör kunna designas så att inställning av parametrar, konfiguration av regler, processer och flöden tillsammans med annan text-/bildinformation, utgör kärnan i ett anpassat Ladok. Det är givetvis en utmanande uppgift som kan ta ytterligare resurser i anspråk och kan därmed ge en högre utvecklingskostnad, även om fördelarna kan vara stora. Detta tillsammans med att system modulariseras, dvs. verksamhetsprocesserna byggs upp med hjälp av inkapslade aktiviteter, som kan bytas ut om processen förändras skapar ett dynamiskt system. Modulariseringen bör ske både horisontellt och vertikalt dvs systemet skall vara indelat både efter vilket verksamhetsområde och efter vilket skikt i arkitekturen som modulen tillhör. Därmed underlättas förändringsbarheten hos systemet genom att det endast är klart avgränsade delar av systemet som behöver anpassas för att möta förändringen. Sedan införandet av LPW i Ladokportföljen erbjuder Ladoksystemet en Service Oriented Architechure (SOA) som andra system på högskolorna kan dra nytta av. (Ladok Connector har också tillkommit som en komponent i SOA-lagret). Granskning av körningstatistiken för LPWtjänsterna visar att i vissa fall används enbart en av deltjänsterna i en tjänst på vissa högskolor och universitet, vilket kan tyda på att de används till ett annat syfte än de ursprungligen var tänkta för. För att möta verksamhetsbehoven kan fler mindre hjälptjänster, grupperade efter kategorier(katalog, registrering, resultat etc), behöva utvecklas för att komplettera befintliga heltäckande tjänster. På så sätt kan databasen kapslas in, vilket skapar stabilare gränssnitt mot externa system. Till skillnad från tjänsterna som erbjuds i SOA-lagret kommer tjänsterna som erbjuds i användargränssnittet för LPW dessutom troligtvis att använda sig av andra SOA-tjänster än de som är utvecklade i Ladok-regi, t ex SOA-tjänster ifrån NyA. I samband med att man använder sig av tjänster som andra tillhandahåller ökar också komplexiteten att bygga ihop applikationerna som utnyttjar dessa. Det finns i dag tillämpningar av standarder för orkestrering och koreografering av SOA-tjänster som skulle kunna nyttjas när applikationerna byggs ihop. Fördelarna med att nyttja dessa framför traditionell programmering är att de erbjuder större flexibilitet så att systemet enklare går att anpassa för att möta förändringar eller speciella krav från en viss högskola. För framtiden bör möjligheterna för att nyttja sådana verktyg i Ladok utredas. En exempelarkitektur nedan visar hur LPW och Ladok Connector kompletterar varandra för att erbjuda integrationspunkter till både den lokala högskolan och NyA.

15 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 15 (21) LPW användargränssnitt NyA Högskola och universitetsspecifika applikationer Ladok På Web SOA lager Ladok Connector Logiklager LadokDB Figure 1: Exempelarkitektur 4.7 Nationellt Ladok Dagens Ladoksystem har rötter i 1980-talets COBOL-system som utvecklades för att hantera studentinformation och sedan kompletterades med LANT för att hantera antagning. På samma sätt som att LANT och H97 ersattes av ett nationellt system kan man tänka sig att ersätta dagens Ladok med ett centralt system. Studenternas mobilitet ökar och därmed ökar också behovet av att ta del av varandras uppgifter mellan högskolorna. När fokus ändras från myndighetsperspektiv till individperspektiv minskar också behovet av att ha lokala instanser av systemet på varje högskola. Att bara behöva kommunicera med ett system skulle underlätta kommunikationen för externa parter, såsom CSN, SCB och även internationella kopplingar. Dagens lösning är otillräcklig ur ett studentperspektiv, där högskolan själv ansvarar för att exponera studenttjänster på Internet. Ett nationellt system skulle innebära att alla studenter får samma nivå på servicen och att alla högskolor får samma effektiviseringsmöjligheter. Om Ladok blir ett nationellt system bör de bakomliggande systemen Ladok och NyA abstraheras bort och all funktionalitet bör för användaren presenteras i en nationell utbildningsportal som

16 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 16 (21) även skulle kunna inrymma utbildningsdatabaser etc. Möjligheterna till ett helt redundant system med 24/7-drift ökar. 4.8 Gradvis migrering En ny systemgeneration kan åstadkommas genom att gradvis migrera till en ny teknik. Ladoksystemet har genom åren genomgått många skiftningar i teknik. Från COBOL i begynnelsen vidare till Uniface för att skapa ett grafiskt gränssnitt. De två systemen existerade parallellt under namnen Classic och Nouveau, men med samma databas i grunden. Under tiden lades Lantweb och LPW till. Genom att byta ut del för del i det nuvarande Ladoksystemet kan man uppnå en ny systemgeneration på sikt utan att behöva driva två parallella spår. I stort sett alla delar i systemet kan bytas ut, vilket vi har sett bevis på genom åren. Denna lösning kommer att bibehålla dagens lösning med en installation per högskola. 5 Driftaspekter Kravet på tillgänglighet för systemet kommer sannolikt att öka då den tjänstebaserade arkitekturen i systemet blir mer centralt och andra system är beroende av att Ladok finns tillgängligt. 5.1 Befintlig arkitektur Nuvarande system är stabilt i drift och skalbart ur prestanda synpunkt. Det är däremot komplext ur installations- och konfigurationsperspektiv på grund av flera komponenter med beroenden till varandra. Stora delar av säkerheten styrs av högskolan själv, med stor möjligheter till lokala anpassningar vad gäller kryptering användarroller etc. 5.2 Redundanta miljöer Att vi får allt större krav på oss gällande driftsäkerhet är uppenbart, speciellt med ambitionen om utökat systemstöd för studenter. Om vi går mot en centraliserad lösning med kanske ett enda driftställe blir redundanta driftmiljöer oundvikligt om vi ska kunna upprätthålla god tillgänglighet. Om vi fortsätter som idag bör vi ändå överväga att införa parallella, speglade, driftmiljöer eftersom vi lever i en värld där både studenter och administrativ personal blir alltmer beroende av Ladoks systemlösningar. 5.3 Leveranser I dag levereras ny funktionalitet för Ladokprodukterna tillsammans med felrättningar fem gånger per år. Detta är en minskning från att i början ha varit en leverans varannan vecka, till följd av att det är kostsamt både att leverera och att ta emot nya leveranser i verksamheten. Den utvecklingsmetod som följs i projekten är Dynamic Systems Development Method (DSDM) sedan slutet av 90-talet, vilket är en agil utvecklingsmetod som bl.a. förespråkar frekventa leveranser. Ladok blir allt tätare integrerat med annan IT-infrastruktur på högskolorna och

17 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 17 (21) universiteten. När fler system är beroende av leveranserna är det svårare att hitta lämpliga tidpunkter för leverans, samtidigt som fler intressenter kräver att få tillgång till ny funktionalitet och felrättningar så snart som möjligt. Alternativ till nuvarande leveransmodell som är tänkbara är skilda leveranser för felrättningar och leverans av ny funktionalitet, samt att olika moduler av Ladoksystemet levereras vid olika tillfällen istället för de fullständiga leveranser som sker idag. Båda dessa alternativ kommer sannolikt att innebära en ökad kostnad för leveransprocessen då det blir nödvändigt att administrera parallella versioner av programvaran. För att möta behovet av att anpassa och testa andra system som är beroende av Ladoksystemet ute på högskolorna kan det också bli aktuellt med testleveranser innan riktiga leveranser sker. En fråga som dyker upp i samband med den ökade integrationen som Ladoksystemet utsätts för är också vem som blir mottagare av leveransen i framtiden. Idag meddelas Ladokansvariga och driftställena om nya leveranser av Ladoksystemet. I och med att andra system kopplas mot Ladok kommer deras behov av information rörande Ladokprodukterna också att öka. Driften av Ladoksystemet sker i dag på tre olika driftställen, på uppdrag av varje enskild högskola. Ett alternativ är att tjänsten för Ladokdrift köps av Ladokkonsortiet som i sin tur upphandlar driften. Denna konstruktion skulle underlätta hanteringen av de driftsfrågor som högskolorna tillsammans driver i konsortiet, men isolerar samtidigt driften av Ladoksystemet ifrån driften av andra system på högskolan. Vilken betydelse detta får när integrationen med andra system på högskolan ökar bör utredas närmare. Ett framtida alternativ kan vara en mer centraliserad drift. Om s k lätta klienter dessutom används bör arbete kring leveranser bli avsevärt enklare eftersom i stort sätt all leverans kan ske på servernivå. Om en viritualiserad miljö används förenklas installationen ytterligare. Endast insticksmoduler till webbläsare kan behöva distribueras eller på annat sätt göras åtkomlig för nedladdning och installation 6 Sammanfattning risker och möjligheter Nedan följer en sammanfattning, dels över vilka möjligheter ett nytt Ladoksystem kan ge och dels vilka risker, men även fördelar, som finns om vi behåller nuvarande Ladok en längre tidsperiod. Vilka skäl finns det som talar för ett nytt Ladoksystem? En ny strukturerad lösning med tydliga lager mellan användargränssnitt, affärslogik och information betyder: o Förändringar och rättningar kommer att gå snabbare att utveckla än idag eftersom komplexiteten reduceras. o Bättre skalbarhet kan uppnås med avseende på arkitektur, funktionalitet och prestanda. Teknik kan bytas ut eller optimeras i dedikerat lager. o Med en tydlig objektmodell möjliggörs tillägg av funktionalitet med mindre insatser.

18 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 18 (21) o Moderniseringar i exempelvis GUI-lagret kan göras utan att behöva skriva om annan kod Införande av tunna klienter innebär: o Säkrare leveranser av utvecklad programvara. o Snabbare leveranser av utvecklad programvara o En garanti om att alla klienter använder samma version o Klientspecifika fel i utvecklad programvara reduceras. o Duplicerad kod försvinner. Idag krävs duplicerad logik om samma information både ska visas internt i Nouveau och externt för studenter på webben. o Bättre möjlighet att mäta och kontrollera användares beteenden och därmed en mer effektiv support. Dessutom kan ett nytt Ladok ge möjligheter att o införa ny teknik snabbare, mer effektivt och därmed även mer kostnadseffektivt än idag tack vare en förberedd och strukturerad arkitektur. o Betydligt mindre komplexa migreringar och uppgraderingar av standardprogramvaror än idag. o förbereda för andra språk och andra standarder. o förbereda för andra arbetsmetoder än de vi känner till idag (dynamik i processer och flöden). o en modern utvecklingsmiljö med modern teknik gör det lättare att rekrytera rätt personal. o ett från början inbyggt stöd för andra klienter och annan meddelandehantering, exempelvis för mobiltelefoner. o ge ytterligare stöd för lokala högskolor att interagera med Ladok genom en tjänsteorienterad arkitektur. o förbättra användbarheten för användare när ny klient utvecklas. o tillgodose att lösningen i möjligaste mån följer öppna standarder. o ge lägre förvaltningskostnader trots ett mer anpassat system, orsakade av de effektivitetsvinster som tidigare omnämnts. Vilka risker kan finnas för att behålla befintlig lösning en längre tidsperiod? o Svårigheter att finna rätt kompetens till förvaltning, anpassningar och vidareutveckling av Nouveau, dvs Unifacekompetens. Det går att lära upp personal i Uniface, men ålderdomlig teknik utgör inte ett attraktivt alternativ för utvecklare. o En spretig programportfölj med många beroenden tack vare ett historiskt arv, gör större vidareutveckling och anpassningar komplex, tidskrävande och kostsam.

19 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 19 (21) o Risken finns att Ladok inte når målen med den utökade service som eftersträvas pga låg flexibilitet för större anpassningar och omstruktureringar. Att gå från dagens Ladok till ett CRM-system är ett sådant exempel. o En internationalisering är idag möjlig att genomföra i fråga om språk, men kräver mycket extra arbete. Att ändra på arbetsprocesser för att passa andra användargrupper är svårt utan stora arbetsinsatser. Vilka skäl kan finnas för att behålla befintlig lösning en längre tidsperiod? o Vi har idag en stabil lösning utan direkta prestandaproblem som går att skala upp om behov uppstår. o Ett fungerande system som stöder verksamhetens behov relativt bra o Ett driftsäkert system som även bedöms vara driftsäkert framöver. o Välbekant för användarna och det finns en tröskel för att börja använda ett nytt system o Möjligheter finns att fortsätta anpassa systemet, till viss del, för kommande behov. o Tekniska förutsättningar för internationellt samarbete finns. 7 Slutsatser För att kunna tillgodose verksamhetens framtida behov behövs en strukturerad och flexibel lösning där hastigt ändrade krav och anpassningar mot enskilda högskolor kan göras snabbt. Gränsytor mot andra system kan med fördel utgöras av en meddelandebaserad tjänsteorienterad arkitektur (SOA - Service Oriented Architecture) vilken tillåter flexibelt och strukturerat informationsutbyte och exponerar utvald funktionalitet mot andra systembyggare på exempelvis högskolor. Integration med andra system bör, där det är tillämpligt, ske med färdiga plattformar för integration exempelvis Biztalk eller open-source-alternativ för att säkerställa funktion, transaktionssäkerhet och prestanda. Möjligtvis bör lösningen kompletteras med separat databas för datawarehouseverksamhet vilket kan ge användare stora möjligheter att lyfta fram specifika kombinationer av data för deras behov. Genom nyttjande av SOA-tjänster från olika system kan studenterna erbjudas en enda arbetsyta, ett gränssnitt, oavsett vilka de underliggande systemen är och oavsett vilken högskola som är aktuell. Detta kan ske genom att exponera Ladok, antagningssystem (NyA) och utbildningsdatabaser från en enda webbplats. Ett gränssnitt för studenter kan dessutom erbjuda förbättrade studenttjänster då information från olika system kan vävas samman i en vy. Dessutom blir utbudet likartat för studenter vid alla högskolor. Det finns i dagsläget inga tekniska orsaker till att byta ut den interna strukturen i Ladok, det som istället ställer krav på en ombyggnad är att kraven på systemet förändras. Ladok kommer inte att vara ett isolerat system utan kommer att fortsätta interagera med övrig IT-infrastruktur på högskolorna i högre utsträckning. En risk med dagens system är att målen inte uppfylls för utökad service som efterfrågas pga låg flexibilitet för anpassningar och omstruktureringar. Ladok

20 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 20 (21) måste därför bli mer flexibelt mot ändrade krav. Hur detta skall ske bör utredas vidare. Uniface bör på sikt ersättas då kompetensförsörjning kan bli svår att trygga, jämför övergången från COBOL till java. Man kan se två spår för en ny systemgeneration. Det ena spåret är att konsolidera dagens systemportfölj till färre tekniker och ersätta Uniface och Nouveau med en tunn klient. Underhållskostnaden reduceras då logiken idag är duplicerad. Det andra spåret är att skapa ett nytt centralt Ladok, på samma sätt som antagningssystemen centraliserats i NyA. En centralisering av Ladoksystemet kan medföra en kostnadsreduktion för drift och underhåll för verksamheten. Genom ett centralt Ladok kan t.ex. produkter som LadokPing ersättas med betydligt enklare funktioner och förutsättningarna för internationella kopplingar förbättras. Om valet faller på ett nationellt system, bör det utredas hur man genomför en övergång från lokala system till ett nationellt system utan att tappa funktionalitet under övergångsperioden. Beträffande drift av Ladok, blir konsekvensen av ett centralt system att driftställena reduceras till ett. Kommer Ladoksystem i fortsättning att vara lokalt men med tunna klienter är det möjligt att fortsätta som idag med tre driftställen. Vi skulle antagligen fortfarande uppnå effektivitets- och kostnadsfördelar genom att förlägga Ladoksystemet till de idag existerande driftställena men slippa distribuera applikationer till varje klient. Vi kan däremot inte se några tekniska hinder till att centralisera helt och skapa en enda nationell driftcentral. Frågan måste däremot utredas då vi inte har full insikt i de beroenden respektive driftställe har till sin omgivning. Dagens system är stabilt i drift men komplext vad gäller leveranser, installation och uppgradering. En ny systemgeneration kan förenkla leveransarbetet genom en konsolidering av produktportföljen. Redundanta driftmiljöer bör/ska finnas för förbättrad driftssäkerhet. En framtida lösning bör vara en s k flerskiktad lösning med tydliga gränser mellan affärslogik, datalager och GUI. Objektmodellen bör vara strukturerat uppbyggd där arv och objektrelationer nyttjas men inte överutnyttjas, vilket annars kan ge ett svårförvaltat system. Två utredningar har gjorts vad gäller säkerhetslösningar för befintligt system, dessa bör beakta i framtagandet av nästa systemgeneration. Tunna klienter bör utvecklas där affärslogik i huvudsak blir förlagd på servernivå, för att erhålla de administrativa kostnadsfördelar som tidigare omnämnts. Redan i ett kravställningsskede bör det förberedas för andra klientalternativ som exempelvis mobilklienter så att informations-, dataoch objektstruktur redan är förberedd.

21 Therese Söderlund, Mikael Berglund, Pål Edström GEM T-8004 Rapport 21 (21)