Utgåva 2.0 Ladok 3 arkitektur B Sehlberg, J Stenberg, M Berglund Sida: 1 (45) Ladok3. Nationellt system

B Sehlberg, J Stenberg, M Berglund Sida: 1 (45) Ladok3 Nationellt system

B Sehlberg, J Stenberg, M Berglund Sida: 2 (45) Innehåll 1 Introduktion... 6 1.1 Syfte... 6 1.2 Mål... 6 1.3 Begränsningar... 6 1.4 Referenser... 6 1.5 Förkortningar... 6 1.6 Definitioner och centrala begrepp... 7 1.7 Styrande effektmål... 7 1.8 Övriga förutsättningar... 8 2 Sammanfattning... 9 2.1 Fördelar... 9 2.2 Nackdelar... 9 2.3 Risker... 9 3 Arkitekturella mål... 10 3.1 Vision... 10 3.2 Icke-funktionella krav... 10 3.2.1 Prestanda... 10 3.2.2 Tillgänglighet... 10 3.2.3 Förvaltning... 10 3.2.4 Säkerhet... 11 3.2.5 Skalbarhet... 11 3.2.6 Övriga krav... 11 3.3 Effektmål... 12 3.3.1 Effektmål 6 Flexibilitet... 12 3.3.2 Effektmål 7 Användbarhet... 12 3.3.3 Effektmål 1 Förbättrad kommunikation... 12 3.3.4 Effektmål 4 Lokal kostnadseffektivitet... 12 3.3.5 Effektmål 3 Gemensam kostnadseffektivitet... 13 3.3.6 Effektmål 2 Tillgänglighet och autentisering... 13 3.3.7 Effektmål 5 Tillförlitlighet och säkerhet... 13 4 Arkitekturella principer... 14 4.1 Viktiga grundprinciper... 14 4.2 Standarder... 14 5 Logisk vy... 15 5.1 Övergripande arkitektur... 15 5.2 Ladok3 som molntjänst... 15 5.2.1 Lagringsteknik... 16 5.2.2 Meddelandehantering... 16 5.2.3 Integration med andra system (lokala och externa)... 16 5.2.4 Autentisering/auktorisering... 16 5.3 Grundfunktionalitet i Ladok... 16 5.3.1 Ladok användargränssnitt... 17 5.3.2 Ladok kärna... 18 5.3.3 Ladok Referens... 19 5.3.4 Ladok Integration... 21 5.3.5 Lokala Anpassningar... 21 5.4 Tjänster och meddelanden i Ladok3... 21 5.4.1 Tjänstemodell... 21

B Sehlberg, J Stenberg, M Berglund Sida: 3 (45) 5.4.2 Meddelandeflöde i Ladok3... 22 5.5 Processer... 24 5.5.1 Processtjänster... 24 6 Scenariovy... 26 7 Informationsvy... 27 7.1 Gemensam central lösning... 27 7.2 Rapportdata... 28 8 Driftsättningsvy... 29 8.1 Systemöversikt... 29 9 Implementationsvy... 31 10 Säkerhetsvy... 32 10.1 Autentisering och auktorisering... 32 10.2 Säkerhetsnivåer... 33 10.3 Detaljering av autentiseringen... 33 10.3.1 Lärosäte som använder central tjänst... 33 10.3.2 Lärosäte med lokala tillägg... 34 10.4 Loggning... 34 10.5 Validering av data... 34 11 Integrationsvy... 35 11.1 Core Services... 35 11.2 Ladok Integration... 35 12 4 + 1-modellen... 36 13 Grundprinciper... 37 13.1 Viktiga grundprinciper utifrån krav... 37 13.2 Övriga grundprinciper... 38 14 Arkitekturella mönster... 39 14.1 Tjänstearkitektur... 39 14.1.1 Definition av tjänst i Ladok3... 39 14.1.2 Tjänst anropar tjänst... 40 14.2 Händelsestyrd uppdatering... 40 14.2.1 Från Ladok... 40 14.2.2 Till Ladok... 41 14.3 Fråga svar... 42 14.3.1 Från Ladok... 42 14.3.2 Till Ladok... 42 14.4 Risker och möjligheter... 44 14.4.1 Decentraliserad lagring... 44 14.4.2 Meddelandehantering... 44 14.4.3 SOA... 45

B Sehlberg, J Stenberg, M Berglund Sida: 4 (45) Figurer Figur 1: Ladok3 i kontext... 15 Figur 2: Övergripande moduler... 17 Figur 3: Nyckelfärdigt Ladok användargränssnitt... 18 Figur 4: Eget användargränssnitt istället för Ladok användargränssnitt... 18 Figur 6: Användning av Ladok Referens... 20 Figur 5: Anpassade tjänster... 21 Figur 7: Tjänster i Ladok3... 22 Figur 8: Meddelandeflöden i Ladok3... 23 Figur 9: Exempel på fysisk separering av information... 27 Figur 10: Exempel på logisk separering av information... 27 Figur 11: Exempel på distribution till egna databaser... 28 Figur 12: Driftsättningsvy... 29 Figur 13: Hantering av roller i Ladok3... 32 Figur 14: Hantering av autentisering i Ladok3... 33 Figur 15: Hantering av lokala tjänster mot Ladok3... 34 Figur 16 Integrationsvy... 35 Figur 17: 4+1 scenariovyn... 36 Figur 19: Komponenter i en verksamhetstjänst... 39 Figur 19: Tjänster beroende av varandra... 40 Figur 20: Tjänster oberoende av varandra genom händelseuppdaterad cache... 40 Figur 21: Händelse till ett annat system via direkt tjänsteanrop... 41 Figur 22: Händelse till ett eller flera system via en meddelandetjänst... 41 Figur 23: Händelse till befintligt system via sammansatta händelser... 41 Figur 24: Händelse till ett system via direkt tjänsteanrop... 41 Figur 25: Händelse till Ladok och eventuella fler system via meddelandetjänster... 42 Figur 26: Hantering av mottagning av information från gamla system... 42 Figur 27: Ladok hämtar uppgift från annat system... 42 Figur 28: Annat system hämtar uppgift från Ladok... 43

B Sehlberg, J Stenberg, M Berglund Sida: 5 (45) Utgåvehistorik för dokumentet Utgåva Datum Kommentar 1.0 2011-08-09 Första publicerade version 1.1 2011-09-01 Uppdaterad med bl a använda standards 1.2 2011-09-23 Mindre korrigeringar 1.3 2011-10-29 Kompletterat masterdata, samt diverse mindre justeringar. 1.4 2011-10-09 Justerat vissa begrepp och namnsättningar, kompletterat med möjliga lokala anpassningar i kärnan. 1.5 2011-11-01 Infört diskussion kring risker i kap 14 2.0 Anpassningar mot remiss och fastställd.

B Sehlberg, J Stenberg, M Berglund Sida: 6 (45) 1 Introduktion 1.1 Syfte Detta dokument beskriver ett förslag på en övergripande arkitektur för Ladok3. Med hjälp av ett antal olika vyer på arkitekturen beskrivs olika aspekter av systemet och dess uppbyggnad. Avsikten är att fånga och förmedla betydande arkitekturella val i förhållande till effektmålen, de funktionella och icke-funktionella kraven. 1.2 Mål Målet med dokumentet är att få ett underlag för bedömning av kostnader för utveckling av ett nytt Ladok, samt för att kunna gå vidare med bedömningar av olika lösningsalternativ. 1.3 Begränsningar Dokumentet behandlar enbart en övergripande arkitektur på Ladok3. Arkitekturen baseras på krav från motsvarande verksamhetsprojekt. Den beskrivna arkitekturen är inte en färdig detaljerad arkitektur, utan fokuserar främst på principer. 1.4 Referenser Referens Beteckning 1. Ladok3 Tjänstebaserad arkitektur, SOA_01.pdf 2. Övergripande kravspecifikation Process 8 v0.5.docx 3. Projektdirektiv Ladok3 Lösningsdelprojekt Referens Beteckning I. Patterns of Enterprise Application Architecture, Martin Fowler. 978-0321127426. II. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions, Gregor Hohpe, Bobby Woolf. 978-0321200686. III. Domain-Driven Design: Tackling Complexity in the Heart of Software, Eric Evans. 978-0321125217. IV. Microsoft Architecture Journal. http://msdn.microsoft.com/en-us/architecture/ Ett antal artiklar om SOA: Autonomous Services and Enterprise Entity Aggregation Data Replication as an Enterprise SOA Antipattern Using Events in Highly Distributed Architectures Event-Driven Architecture: SOA Through the Looking Glass V. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Nick Rozanski, 978-0321112293. VI. Architectural Blueprints The 4+1 View Model of Software Architecture, Philippe Kruchten, http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf VII. REST In Practice, Jim Webber, Savas Parastatidis, Ian Robinson. 978-0596805821 1.5 Förkortningar Förkortning Beskrivning ETL Extract, Transform, Load. Extrahera data från en eller flera källor, transformera och ladda, (t.ex. till en databas). MoM Message-oriented Middleware

B Sehlberg, J Stenberg, M Berglund Sida: 7 (45) NyA REST WS SMS-OTP SAML SSO IFK Nya Antagningssystemet Representational State Transfer Web Services Short Message Service One-time password Security Assertion Markup Language Single Sign-on, är en metod inom sammansatta datasystem för dess användare endast ska behöva logga in en enda gång för att nå de system som är anpassade till tjänsten. Icke-funktionella krav 1.6 Definitioner och centrala begrepp Definition Applikation Komponent Modul Tjänst Beskrivning En applikation är ett program utformat för att utföra en viss funktion direkt för användaren eller i vissa fall, till ett annat program. Är en enhet med en sammanhållen del verksamhetslogik. En komponent kan jämföras med en ljudanläggning uppbyggd av enskilda delar (komponenter) som, radio, förstärkare, etc. En större komponent kan i sig innehålla mindre komponenter. I detta dokument ser vi komponent och modul som samma begrepp. Är en autonom enhet som ansvarar för en sammanhållen del av verksamhetslogik och som exponerar funktionaliteten genom utbytande av meddelanden. 1.7 Styrande effektmål Arbetet med arkitekturen präglas av de effektmål och motsvarande direktiv, som finns satta för Ladok3 projektet. Effektmål 6 Flexibilitet Högskolorna får ett hållbart och flexibelt systemstöd, med en struktur som är generellt användbar med avseende på t ex utbildningsnivåer, valutor, periodbegrepp och ursprungsländer, och som byggs i en långsiktigt hållbar teknik med lång återstående livslängd vilket gör att investeringen kan nyttjas under längre tid än den ekonomiska avskrivningstiden Effektmål 7 Användbarhet Högskolorna får ett systemstöd som upplevs som användbart, lättarbetat, tilltalande och hjälpsamt samt möjliggör minimerad pappershantering; och som är stabilt genom att det utgår från grundläggande processer i kärnverksamheten och är enkelt och väldokumenterat. Effektmål 1 Förbättrad kommunikation Högskolorna får en gemensam plattform som snabbt och allsidigt kommunicerar med alla omgivande informationssystem av intresse och vid behov kan dela data med dessa, samt med andra högskolor, både nationellt och internationellt. Effektmål 4 Lokal kostnadseffektivitet Högskolorna har tillgång till ett systemstöd som ger möjlighet till rationalisering och lägre totala system-kostnader för hela den lokala studieadministrationen, jämfört med 2010 Effektmål 3 Gemensam kostnadseffektivitet Konsortiet får ökad kostnadseffektivitet för såväl systemutveckling som systemunderhåll, jämfört med 2010

B Sehlberg, J Stenberg, M Berglund Sida: 8 (45) Effektmål 2 Tillgänglighet och autentisering Högskolorna har tillgång till Ladokuppgifter 24/7 genom smidig och säker identitetshantering som underlättar studentmobilitet och möjliggör egenrapportering Effektmål 5 Tillförlitlighet och säkerhet Högskolorna får, jämfört med 2010, högre tillförlitlighet i applikation och data, minimerat antal fel, möjlighet att dela särskiljbara data mellan högskolor i ett systemstöd som uppfyller högskolans ökande krav på IT-säkerhet Dessa effektmål styrs av följande direktiv: Ladok3 ska byggas med sikte på kostnadseffektivitet i såväl vidareutveckling som systemunderhåll. Utvecklingen av Ladok3 ska söka optimala kombinationer av alternativen att bygga i egen regi, att bygga tillsammans med andra aktörer eller att köpa färdiga moduler. Ladok3 ska ge förutsättningar för enklare och därmed billigare hantering på högskolan vid mottagande av nya versioner, installation etc. Ladok3 ska ge Konsortiets medlemmar bättre förutsättningar att lokalt rationalisera och optimera det totala systemstödet. Systemlösningen ska möjliggöra för Konsortiets medlemmar att effektivt dela data och särskilja data i gemensamma installationer. Ladok3 ska byggas med generella och effektiva kommunikationsgränssnitt mot andra system. Det ska vara möjligt och realistiskt att byta ut enskilda systemdelar utan stora anpassningar i övriga delar av systemet. Ladok3 ska byggas med teknik som bedöms ha mycket lång återstående livslängd och som ger låga risker för inlåsning. Systemarkitekturen ska utgå från processerna i kärnverksamheten. Projektet ska, med utgångspunkt i processanalys och med beaktande av högskolornas lokala förutsättningar och behov, söka effektiva lösningar med god gemensam acceptans. 1.8 Övriga förutsättningar Arkitekturen Ladok3 ska vara tjänsteorienterad, baserat på rapport [ref. 1]. Autentisering är inte en del av Ladok3, men Ladok3 ska kunna använda de autentiseringslösningar som används inom universitets- och högskolevärlden. Auktorisering baseras på roller och hanteras primärt av respektive lärosäte. I de fall dessa inte har möjlighet till detta kan auktorisation göras i Ladok3. Hantering av skyddad identitet. Formen för dokumentet styrs av standarden IEEE 1471. Förberett för molnet krav från styrgrupp. Nationell installation beslut från expertgrupp.

B Sehlberg, J Stenberg, M Berglund Sida: 9 (45) 2 Sammanfattning Dokumentet beskriver arkitekturen för ett helt nytt Ladok3, som inte bygger vidare på nuvarande Ladok. Ladok3 beskrivs utifrån en tjänsteorienterad arkitektur bestående av dels gemensam kärnfunktionalitet, dels funktionalitet som kan styras av respektive lärosäte. Funktionaliteten tillhandahålls av ett antal verksamhetstjänster och är åtkomlig via ett webbaserat gränssnitt för användare och ett tjänstegränssnitt för exempelvis högskolornas egna system. Den tjänsteorienterade och moduluppbyggda arkitekturen ger en flexibilitet som minskar förvaltningskostnader och möjliggör enklare framtida förändringar. Genom att använda autonoma tjänster får man även en lösning med hög tillgänglighet och robusthet. Den valda arkitekturen ger även bra grund för drift i molntjänst. 2.1 Fördelar Fördelen med att utveckla ett helt nytt Ladok3 jämfört med refaktorisering av befintligt Ladok, är framförallt: Att Ladok kan byggas som ett nationellt system. Att Ladok kan optimeras för de krav och behov som finns. Kompromisser som rör krav och funktionalitet på grund av begränsningar i ett befintligt system inte behöver göras. Att arkitekturen kan utformas och implementationen göras efter de bästa principer och metoder som finns idag för att få ett system som effektivt kan anpassas till framtida behov, utan att kompromissa och ta hänsyn till det befintliga Ladok. Moderna verktyg för utveckling och test kan användas som ger en mer effektiv och säkrare utveckling, sannolikt med färre fel. Med inkrementell och iterativ utveckling kan progressen enkelt följas upp och anpassa efter förändringar. 2.2 Nackdelar Nackdelar med att utveckla ett helt nytt Ladok3, jämfört med främst refaktorisering: Systemet kan troligen inte levereras till produktion med delfunktionalitet i många små steg, på grund av omfattande beroenden till gamla Ladok. Istället kommer man att behöva leverera i ett fåtal större leveranser alternativt i form av en stor. Om projektet avbryts av någon anledning, kan det (beroende på var i projektet det sker) vara svårt att enkelt dra nytta av de nya delarna. Det är svårt att ur ett kravperspektiv specificera ett komplett system. Risken finns att väsentliga delar saknas vid planeringen. 2.3 Risker De största riskerna ser vi i: Att krav inte konkretiseras och detaljeras i detalj i den fart som utvecklingsteamen behöver Att högskolorna inte kan enas om funktionalitet och krav. Att krav saknas på funktionalitet som finns idag. Att utvecklingsprojektet inte har de detaljerade kraven när implementation ska göras. Att ett utvecklingsteam inte har tillgång till en produktägare eller inte får svar på frågor, (till exempel för att det finns 37 högskolor som en produktägare måste stämma av med). Att ett utvecklingsteam inte har den kompetens som krävs.

B Sehlberg, J Stenberg, M Berglund Sida: 10 (45) 3 Arkitekturella mål 3.1 Vision Den övergripande visionen för Ladok3 är att skapa ett nationellt studieadministrativt system som är komplett och nyckelfärdigt i sitt utförande men med möjligheten att skapa lokala ersättningar till vissa delar. Systemet skall vara webbaserat och fokuserat på självservice och möjliggöra drift i molntjänst. 3.2 Icke-funktionella krav Nedanstående icke-funktionella krav är ett urval, av de totala icke-funktionella kraven, som kan ha påverkan på arkitekturen. Målet med arkitekturen är därför att dessa krav ska uppfyllas. Eftersom inte alla detaljer kring de icke-funktionella kraven för Ladok 3 är helt utredda, kan nedanstående lista komma att förändras något. 3.2.1 Prestanda PRE-04 Antalet studenter och lärare: Systemet skall initialt vara dimensionerat för 500 000 aktiva lärare och studenter på helårsbasis, men skall kunna dimensioneras upp när ökat behov uppstår. PRE-05 Antalet expertanvändare (administrativ personal): Systemet skall vara dimensionerat för 7000 expertanvändare, dvs. användare som inte är studenter. De centrala och oftast använda delarna av systemet får ta maximalt 0,9s från det att förfrågan inkommer till systemet till motsvarande svar returneras från systemet. Systemet skall klara av min. 200 000 sökningar/timme under bråd timme. Systemet skall klara av min. 50 000 registreringar/timme under bråd timme. (Bakgrunden till dessa två krav baseras på erfarenheter från NyA, där man har c:a 1 000 000 sökningar per bråd timme. Behoven i Ladok är mer väldefinierade när det gäller sökning, man vet mer om vilken information man söker och har därmed inte samma behov av omfattande sökningar. Antal registreringar kommer att vara avsevärt färre än antal sökningar.) 3.2.2 Tillgänglighet TIL-01 Tillgänglighet: Systemet skall vara tillgängligt 24 timmar om dygnet 7 dagar i veckan. Totala tillgängligheten skall vara 99 % över tid respektive 99,9% kontorstid, inkluderat både planerade och oplanerade avbrott. Detta medför att systemet sammanlagt får vara otillgängligt 87,6 timmar per år. 3.2.3 Förvaltning DES-01-01 Ett driftställe. Systemet skall ha ett driftställe. DES-01-02 Nationell installation. Alla lärosäten skall använda samma nationella installation av systemet. Det skall inte finnas några parallella instanser av systemet, annat än i lastdelnings- eller redundanssyfte. DES-04-07 Lärosätesanpassade moduler. Det skall vara möjligt att lägga till/ersätta moduler med lärosätesanpassade moduler utifrån varje lärosätes behov. DES-04-08 Gemensam kärna med fristående moduler. Systemet skall bestå av en solid kärna som kan utvidgas med moduler för specifika ändamål. DES-04-10 Tjänstebaserad arkitektur. Systemet skall bygga på en tjänsteorienterad arkitektur. DES-04-20 Designprincip: Systemet skall ha en minimalistisk teknisk design. DDB-02 En central databas för alla högskolor: Alla högskolor anslutna till Ladok3 skall använda samma databas. DDB-07 Ingen access till databasen via SQL: All interaktion med databasen skall ske via särskilda gränssnitt och inte via SQL-access.

B Sehlberg, J Stenberg, M Berglund Sida: 11 (45) DDB-04 Central data skall delas mellan alla högskolor. För att underlätta underhåll av data skall data som delas mellan högskolor representeras på ett ställe. Exempel på sådana data är personuppgifter och adressuppgifter. UND-02-01 Ingen duplicering av logik: En förändring av en affärsregel skall endast innebära ändring på ett ställe i systemet. UND-02-04 Framtidsäker teknik: Systemet skall byggas i en teknik som är hållbar över tid och har lång återstående livslängd. Arkitekturen skall vara förberedd för ny teknik. UND-03-06 Partiell installation: Systemets delar skall kunna uppdateras var för sig utan att hela systemet behöver göras otillgängligt under uppgraderingen av respektive del. 3.2.4 Säkerhet DES-09-08 Säkerhet: Att förlägga en del av systemet i molnet skall inte göra systemet mindre säkert. SAK-01-02 En identitet: Alla användare i systemet skall ha endast en identitet. SAK-01-03 En identitet oavsett lärosäte: Varje användare skall ha endast en identitet oavsett lärosäte. SAK-01-04 Stark identitet: Autentiseringen i systemet skall ske med mer än bara ett användarnamn och ett lösenord. SAK-01-05 Certifikatbaserad identitet: Användarens identitet skall vara certifikatbaserad. SAK-03 Autentisering NyA: Autentisering skall kunna ske via NyA. SAK-04 Extern autentiseringsmodul: Autentiseringsfunktionen skall vara en fristående modul som möjliggör både utnyttjande av extern autentisering samt intern. SAK-05 Källsystem för behörighetssystem: Systemet skall exponera sådan information att behörighetssystemen kan hantera uppgifter om studenternas behörigheter utifrån de aktiviteter de deltar i. SAK-09 Spårbarhet: De ändringar som göra i systemet av användare skall vara tydligt spårbara och ändringarna skall vara tillgängliga via webbgränssnitt för effektiv spårbarhet. SAK-26 Extern behörighetskontroll: Behörighetskontroll skall kunna ske externt utanför systemet. SAK-10 Databastillgång för skrivning: Inga applikationer utanför systemet skall ha direkt tillgång till databasen för skrivning. SAK-15 Separering av arkivdata: Arkiven för arkivering skall avskiljas från övrigt i systemet för att undvika oavsiktlig förvanskning av uppgifter. SAK-26 Extern behörighetskontroll: Behörighetskontroll skall kunna ske externt utanför systemet. 3.2.5 Skalbarhet Den använda arkitekturen ska tillåta att Ladok3 kan skalas upp (och ner) för att kunna stödja de prestandakrav som satts i 3.2.1. 3.2.6 Övriga krav INT-04-01 Informationsutbyte: Ifall information om eller för en student som behövs i systemet redan finns i ett externt system skall det finnas möjlighet att den informationen inhämtas där istället för att behöva anges i systemet. INT-05-01 SCB, CSN: Systemet skall tillhandahålla och leverera underlag för statistik till SCB samt automatiskt överföra uppgifter om registreringar och resultat till CSN. INT-05-02 Andra myndigheter: Andra myndigheters behov av intyg ifrån systemet skall hanteras med självbetjäning och andra tekniker á la Ladok Ping. INT-10 Standardiserade gränssnitt: Systemet skall använda standardiserade gränssnitt mot andra system som skall utbyta information med systemet. INT-12-06 meddelandebaserat. Systemet skall ge lärosätena möjlighet att arbeta med meddelandebaserade tjänster.

B Sehlberg, J Stenberg, M Berglund Sida: 12 (45) 3.3 Effektmål Nedanstående tolkning av effektmålen baseras på hur dessa påverkar arkitekturen, d v s tolkningen är inte gjord utifrån hela Ladok3 projektet. 3.3.1 Effektmål 6 Flexibilitet Tolkning: De olika lärosätenas individuella behov ska kunna hanteras av Ladok3 utan krav på lokala specialanpassningar i de centrala delarna av Ladok3 (Ladok kärna). De gränssnitt som tillhandahålls ska täcka de behov, som de individuella lärosätena har för sin verksamhet. Utökningar och förändringar i en modul ska kunna göras utan risk för påverkan på andra delar i systemet. Individuella tjänster i Ladok3 ska kunna bytas ut utan krav på ny leverans av övriga delar av Ladok3. Arkitekturstöd: Tjänsteorienterad arkitektur, möjliggör ändring/utbyte av tjänster med minimal påverkan på omgivande tjänster. Lokala kopplingar kan dock påverkas. Uppdelning på olika funktionella moduler för olika ändamål, tillåter förändring med minimal påverkan på omgivningen. Meddelandebaserat informationsutbyte, möjliggör en distribuerad datalagring och ger därmed ett mer robust system. Stabila, versionshanterade tjänstegränssnitt, som kan användas för lokala anpassningar. 3.3.2 Effektmål 7 Användbarhet Tolkning: Självservice, studenten i centrum. Hindra inte utan ge stöd åt användaren. Involvera användarna i utvecklingen. Användbarhetsdesign viktig del i utvecklingen. Arkitekturstöd: En nationell installation ger bra förutsättningar för studenten i centrum. Möjliggöra lokala anpassningar för lärosätesspecifika behov. Gemensamma tjänster kan utvecklas med hög användbarhet, beroende på prioriteringar. 3.3.3 Effektmål 1 Förbättrad kommunikation Tolkning: Gränssnitt ska vara anpassade för verksamheten, se även Effektmål 7 Användbarhet, d v s gränssnitten ska vara anpassade efter verksamhetens behov. Viktigt att involvera lärosätena för att få med deras behov i gränssnitten. Etablerade och relevanta standards ska användas. Arkitekturstöd: Meddelandebaserat informationsutbyte, möjliggör en distribuerad datalagring och ger därmed ett robust system. Stabila, versionshanterade tjänstegränssnitt, som kan användas för lokala anpassningar. 3.3.4 Effektmål 4 Lokal kostnadseffektivitet Tolkning: Se Effektmål 1 Förbättrad kommunikation se Effektmål 6 Flexibilitet Arkitekturstöd:

B Sehlberg, J Stenberg, M Berglund Sida: 13 (45) Se Arkitekturstöd under Effektmål 1 Förbättrad kommunikation Se Arkitekturstöd under Effektmål 6 Flexibilitet 3.3.5 Effektmål 3 Gemensam kostnadseffektivitet Tolkning: Gemensam nationell installation. Enklare förvaltning uppgradering med nationell installation. Modularitet förenklar förvaltning, t ex utbyte av enskilda komponenter. Arkitekturstöd: Se Arkitekturstöd under Effektmål 1 Förbättrad kommunikation Se Arkitekturstöd under Effektmål 4 Lokal kostnadseffektiviteteffektmål 6 Flexibilitet Se Arkitekturstöd under Effektmål 6 Flexibilitet 3.3.6 Effektmål 2 Tillgänglighet och autentisering Tolkning: Systemet ska vara robust och tåla störningar i olika delar med minimal påverkan på andra Tillåt alternativa lösningar för autentisering. Arkitekturstöd: Se Arkitekturstöd under Effektmål 6 Flexibilitet Se kapitel 10, Säkerhetsvy. 3.3.7 Effektmål 5 Tillförlitlighet och säkerhet Tolkning: Nya arkitekturen med robusthet i fokus. Nationell gemensam lösning ger större möjlighet till att dela särskiljbara data mellan högskolor både för student och administration Autonoma tjänster och distribuerad datalagring Arkitekturstöd: Se kapitel 10, Säkerhetsvy.

B Sehlberg, J Stenberg, M Berglund Sida: 14 (45) 4 Arkitekturella principer 4.1 Viktiga grundprinciper Utifrån de krav och mål som ställs på Ladok3, speciellt övergripande krav som flexibilitet, förvaltningsbarhet, etc., är följande punkter extra viktiga grundprinciper för Ladok3:s arkitektur för att uppnå ett bra slutresultat. Tjänsteorienterad arkitektur - Tjänsteorientering möjliggör lätt föränderlig verksamhet. Verksamhetslogik och regler för ett område finns på ett ställe Autonoma tjänster - Med autonoma oberoende tjänster ökar tillförlitligheten och flexibiliteten för tjänsten. Meddelandebaserat och händelsestyrt, (Event Driven Architecture, EDA) - Ger ett flexibelt sätt att hantera förändringar av information i system. Decentraliserad data-arkitektur - Minskar beroenden till datakälla och ger därmed en robustare arkitektur. Webben som plattform - Internet har under många år i praktiken visat vara en mycket stabil och kompetent infrastruktur för kommunikation. Grunden som gjort detta möjligt är ett antal enkla protokoll och principer, dessa är även en bra plattform för distribuerade system. o REST-baserat - Fördelen med REST-baserade tjänster är bland annat enkelheten och snabbheten. Dessa grundprinciper och övriga finns beskrivna i detalj i appendix kapitel 12, sidan 36 4.2 Standarder I största möjliga utsträckning ska Ladok 3 baseras på existerande standarder. De standarder som Ladok 3 primärt ska använda är: HTTP Hypertext Transport Protocol HTTPS Hypertext Transport Protocol Secure HTML Hypertext Markup Language (sannolikt HTML5) XML extensible Markup Language SAML Security Assertion Markup Language LDAP - Lightweight Directory Access Protocol Atom för publicering/distribution av meddelanden (RFC 4287 och RFC 5023) WCAG 2.0 - Web Content Accessibility Användargränssnittdelines European Interoperability Framework for Pan-European egoverment Services (EIF 1.0) EMIL - Education Information Markup Language eduperson - LDAP-schema för att beskriva person attribut inom högskole- och universitetsområdet. eduorg - LDAP-schema för att beskriva organisatoriska attribut inom högskole- och universitetsområdet. Ytterligare standarder kan bli aktuella i samband med realiseringen av systemet. Exempel på områden där nya standarder kan bli aktuella, är vid integration mot de lokala systemen på lärosätena, exempelvis för det som beskrivs som Lokala anpassningar i detta dokument. Andra områden är integration för nationell lösning för e-legitimation och andra två-faktorslösningar, som kan bli aktuella.

B Sehlberg, J Stenberg, M Berglund Sida: 15 (45) 5 Logisk vy 5.1 Övergripande arkitektur Ett viktigt krav för Ladok3 är att reducera kostnaderna. Genom att utveckla Ladok3 som ett nationellt centralt system med bra möjligheter att integrera mot lokala system och externa system (se även IFK i kapitel 3.2.3), finns potential för att kostnaden för drift och förvaltning kan minskas. Ladok3 är uppdelat i grundtjänster (Ladok kärna) och utbytbara tjänster (Ladok Referens), samt integrationer (Ladok Integration). Figur 1: Ladok3 i kontext Ladok kärna innefattar de centrala grundläggande gemensamma funktionerna i Ladok. Ladok Referens är tjänster som ingår i Ladok3, men kan i de fall man vill ha en egen lösning ersättas av motsvarande tjänster hos respektive lärosäte. En förutsättning för detta är då att denna lokala lösning använder motsvarande tjänstegränssnitt som den inbyggda tjänsten använder mot Ladok kärna. Via olika integrationer i Ladok Integration kan Ladok3 utbyta information med andra externa aktörer (t ex CSN, SCB). Integrationerna i Ladok Integration använder främst Core Services, men kan i undantagsfall använda sig av andra gränssnitt för vissa specialändamål. Vilken typ av integration, som används beror till stor del på de anslutande systemens möjligheter. Genom den tjänsteorienterade och moduluppbyggda arkitekturen får man en flexibel lösning som minimerar förvaltningskostnader och möjliggör enklare framtida förändringar, genom att möjliggöra uppdatering av enskilda delar utan att resten påverkas. 5.2 Ladok3 som molntjänst Den valda arkitekturen ger även möjlighet till drift av Ladok3 som molntjänst, men är inte direkt anpassad för någon specifik molntjänst. Det betyder däremot inte att Ladok3 har fullt stöd för alla typer av molntjänster. Beroende på vilken molntjänst man eventuellt väljer i framtiden och hur man vill använda denna, finns det ett antal olika områden man kan behöva ta hänsyn till och även då anpassa för. Nedanstående kapitel exemplifierar några specifika områden, som bör beaktas, dessa är: Lagringsteknik Meddelandehantering

B Sehlberg, J Stenberg, M Berglund Sida: 16 (45) Integration med andra system lokala och externa Autentisering/auktorisering 5.2.1 Lagringsteknik De olika molnplattformarna har olika lösningar för datalagring med olika för och nackdelar. Exempelvis Google APP Engines data store är ingen relationsdatabas (och använder därmed inte SQL), utan lagrar informationen som objekt (entiteter), med en eller flera egenskaper. Fördelen med denna typ av databas är bland annat skalningsmöjligheten och lagringssäkerheten. På motsvarande sätt har Amazon i sin molntjänst olika typer av lagringslösningar med olika användningsområden. Det är därför nödvändigt säkerställa att all åtkomst till databaser kapslas in för att göra applikationen oberoende av plattformen. Samtidigt riskerar man ett visst porteringsarbete vid byte av molnleverantör med annan datalagringslösning. 5.2.2 Meddelandehantering Även för meddelandehantering finns olika tekniklösningar beroende på plattform och vilken funktionalitet man vill använda. Det är även här nödvändigt att säkerställa att man inte skapar onödiga beroenden till den använda plattformen. 5.2.3 Integration med andra system (lokala och externa) Eftersom molnleverantörerna normalt endast tillåter kommunikation över http/https, finns vissa begränsningar i hur man kan integrera sig med molntjänsten, vilken lösning som används är ofta beroende på leverantör. Google tillhandahåller t ex ett eget API (Channel API) för kommunikation med kundens lokala system. Amazon använder en teknik Virtual Private Cloud (VPC) för att skapa ett virtuellt nätverk mellan molntjänsten och den lokala miljön. 5.2.4 Autentisering/auktorisering Vilken autentiseringsmekanism som kan användas styrs också i hög grad av molnleverantören och vald plattform. Google använder exempelvis vanliga Google konton, men kan också använda OpenID identifierare. Däremot finns inget direkt stöd för behörighet. Microsoft Azure har exempelvis möjlighet till integration med AD. 5.3 Grundfunktionalitet i Ladok Enligt IFK i kapitel 3.2.3 skall Ladok3 vara tjänsteorienterat. Följande bild visar en logisk modell över Ladok3 och dess ingående tjänster, samt hur systemet exponerar den interna grundfunktionaliteten i Ladok kärna via webbgränssnitt och även via tjänstegränssnitt, Core Services. Via tjänstegränssnitten kan andra system komma åt de olika tjänsterna i Ladok, t ex tjänster i Lokala anpassningar. Då det för närvarande inte har identifierats något behov av överordnat arbetsflöde i den övergripande arkitekturen finns inte något stöd för workflow med i arkitekturen. Skulle det visa sig finnas ett sådant behov i realiseringsfasen kommer detta då att beaktas. De regler som behövs är ganska statiska jämfört med t ex NyA, varför en generell regelmotor inte ansetts nödvändig. De affärsregler som behövs är därför inbyggda i respektive tjänst, d v s det finns ingen separat regelmotor för detta utan varje domän ansvarar för sina regler.

B Sehlberg, J Stenberg, M Berglund Sida: 17 (45) Figur 2: Övergripande moduler Med början i den övre delen av figuren, finns ett inbyggt användargränssnitt Ladok användargränssnitt som används av både administrativ personal och studenter. Ladok kärna innefattar de centrala gemensamma funktionerna i Ladok. Ladok Referens innefattar en uppsättning utbytbara standardtjänster. Ladok Integration används vid integration mot externa aktörer. Lokala anpassningar är inte en del av Ladok3, men kan innefatta tjänster som de lokala lärosätena vill använda istället för motsvarande i Ladok Referens. 5.3.1 Ladok användargränssnitt Ladok användargränssnitt tillhandahåller ett gemensamt användargränssnitt för Ladok kärna och Ladok Referens. Ladok användargränssnitt kan användas nyckelfärdigt, anpassat med avseende på logotype, färgsättning och viss placering med hjälp av style sheet (CSS). Det finns några principiella sätt att hantera användargränssnittet: Lärosätet har inga egna anpassningar (förutom logotyp och färgval) utan använder Ladok och Ladok användargränssnitt som ett nyckelfärdigt system Lärosätet använder inte Ladok användargränssnitt utan har ett helt eget användargränssnitt, som använder Core Services och motsvarande i Ladok Referens. Lärosätet använder en del av Ladok användargränssnitt, för Core Services och Ladok Referens men har även ett eget användargränssnitt med egna anpassningar, för t ex Lokala anpassningar, eller anpassade tjänster i Ladoks kärna. Integration av egna utökningar, kräver även att man säkerställer att dessa utökningar även kan hantera single sign-on, lämpligen med SAML 2.

B Sehlberg, J Stenberg, M Berglund Sida: 18 (45) Ladok3 tillhandahåller ett eget inbyggt användargränssnitt för Ladok Kärna och Ladok Referens. Används detta användargränssnitt kan man som användare dels komma åt olika delar i systemet via menysystemet, men också enkelt komma åt olika information och funktioner via vanliga hyperlänkar. Exempelvis skulle man kunna tänka sig att via kurs hitta ett kurstillfälle, för att därifrån kunna se vilka studenter som finns registrerade och via en student kunna se vilka andra kurser denne är registrerad på, etc. Nedanstående figurer visar en konceptuell bild av detta d v s layouten exemplifierar endast förhållandet mellan användargränssnitt och Ladok kärna och Ladok Referens. Den slutgiltiga layouten är något som hanteras i utvecklingsprojektet. Figur 3: Nyckelfärdigt Ladok användargränssnitt De lärosäten som har andra krav än vad som kan tillhandahållas i Ladok användargränssnitt kan antingen utveckla ett helt eget användargränssnitt, genom att använda de tillgängliga tjänstegränssnitten i Ladok kärna och Ladok Referens eller från eget användargränssnitt länka in fristående delar av Ladok användargränssnitt (exempelvis från Ladok Referens). Figur 4: Eget användargränssnitt istället för Ladok användargränssnitt 5.3.2 Ladok kärna Ladok kärna innefattar de grundläggande centrala funktionerna i Ladok:

B Sehlberg, J Stenberg, M Berglund Sida: 19 (45) Core Services Tjänstegränssnitt för Ladok3. Studiedeltagande Ansvarar för information om alla typer av deltaganderegistreringar. Studieresultat Ansvarar för information om resultat på tentamen, kurser och motsvarande samt examen. Kataloguppgifter Ansvarar för registrering och hantering av examensdefinitioner, provuppsättningar, organisationsstruktur på den egna lärosätet, etc. Även gemensamma standarduppgifter, som t ex kommunnamn och länder hanteras här. Hantera utbildningsutbud Ansvarar för registrering och lagring av information om kurser, kurstillfällen, program och examina. Tar emot information från bland annat Utbildningsdatabas. Student Ansvarar för registrering och lagring av information om student Spårbarhetslogg (infratjänster) Lagrar en logg över alla händelser i systemet. Enskilda tjänster kan uppgraderas eller bytas ut utan krav på att övriga delar måste bytas ut eller uppgraderas samtidigt. De tjänstegränssnitt som dessa tjänster tillhandahåller är i möjligaste mån bakåtkompatibla. Vid större förändringar kan nya kompletterande tjänstegränssnitt skapas och gamla versioner av dessa kan senare fasas ut enligt uppgjorda planer. Även enskilda moduler ska kunna bytas ut utan krav på att övriga delar måste bytas ut/uppgraderas. 5.3.3 Ladok Referens De tjänster som inte har samma nära koppling till de funktioner som finns i Ladok kärna, läggs i Ladok Referens. Ladok Referens innefattar därför en uppsättning standardtjänster, t.ex. en funktion för att registrera utbildningsinformation. Lärosäten kan välja att använda den inbyggda funktionen för att registrera utbildningsinformation eller att använda en egen lokal utbildningsdatabas, som då kommunicerar via Core Services. Enligt IFK 3.2.4 ska det vara möjligt att använda olika autentiseringsmetoder, därför innefattar Ladok Referens även autentisering och auktorisering, vilket ger möjlighet att använda olika typer av externa mekanismer för detta, exempelvis: Referens Services Tjänstegränssnitt för de tjänster som finns i Ladok referens. Hantera Utbildningsutbud Ansvarar för att skapa information om kursutbudet och kurstillfällen Anmälan till examination Ansvarar för att hantera examinationstillfällen och anmälan till dessa. Autentisering (infratjänster) Ansvarar för att antingen kommunicera med eget lärosäte för autentiseringsinformation eller den inbyggda identitetsutfärdaren beroende på konfiguration. Auktorisering (infratjänster) Ansvarar för att antingen kommunicera med eget lärosäte för rollinformation eller den inbyggda katalogen.

B Sehlberg, J Stenberg, M Berglund Sida: 20 (45) Enligt de icke-funktionella kraven skall Ladok3 kunna anpassas till lokala processer. Ladok3 är i grunden ett centralt system med kompletta tjänster, men tillåter att ett lärosäte väljer att ersätta vissa moduler med sin egen lösning. Dessa utbytbara moduler kallas tillsammans Ladok Referens. För att detta skall vara möjligt krävs att Ladok3 tillhandahåller ett väldefinierat tjänstegränssnitt, med stöd för dessa anpassningar. En viktig grundprincip för en modul i Ladok Referens är att den kan fungera som en fristående applikation/funktion. Ladok kärna får inte ha något beroende till modulen i Ladok Referens. En modul i Ladok Referens kan däremot ha ett beroende till Ladok kärna (t ex för att hämta vissa grunduppgifter för sin egen hantering). Ett exempel kan vara den inbyggda tjänsten för att hantera utbildningsutbud (t ex utbildningstillfällen) i Ladok3 som tillhör Ladok Referens. Hantera utbildningsutbud använder motsvarande tjänst (Utbildningsutbud) i Ladok kärna. Om ett lärosäte vill använda sin egen lösning för att hantera utbildningsutbud, finns det ett tydligt tjänstegränssnitt och en inställning som kopplar bort den inbyggda modulen. Figur 5: Användning av Ladok Referens Funktionaliteten i Ladok Referens visas normalt sett i Ladok användargränssnitt, men för de som har valt att använda sin egen implementation försvinner de menyalternativen och liknande representationer och får därmed ersättas av den egna lösningens motsvarigheter. Dessa implementationer måste därför tillhandahålla sitt eget användargränssnitt. En fördel med en egen lösning är att man t ex kan tillhandahålla specialanpassningar för sitt eget lärosäte. I vissa undantagsfall kan det, för ett lärosäte, finnas behov av att utöka funktionaliteten i Ladoks kärna på ett sätt som inte är kompatibelt med andra lärosäten. Ett exempel skulle kunna vara ett lärosäte som behöver en utökad funktion med tillhörande extra information för en tjänst. Anpassningen hanteras då genom att systemet kan känna av att användaren kommer från ett lärosäte med en anpassad tjänst, med tillhörande anpassat användargränssnitt. Systemet dirigerar användaren till det anpassade användargränssnittet för de delar, som använder den anpassade tjänsten.

B Sehlberg, J Stenberg, M Berglund Sida: 21 (45) Figur 6: Anpassade tjänster För att den anpassade tjänsten ska kunna samexistera med övriga tjänster, krävs det att de grundfunktioner den ordinarie tjänsten har även används av den anpassade tjänsten. De anpassade tjänsterna ska naturligtvis också följa de arkitekturella principerna som är beskrivna i kapitlet Grundprinciper. 5.3.4 Ladok Integration För att kommunicera med externa parter såsom CSN, SCB och NyA, används Ladok Integration. I Ladok Integration placeras olika adaptrar för integration mot externa aktörer. Ladok Integration använder sig av Core Services i Ladok kärna för att hämta och lämna data, samt den händelsestyrda arkitekturen i Ladok3. För de system, som inte har stöd för detta kan man ta fram olika typer av adaptrar, som anpassar integrationstekniken till den externa parten. För mer detaljer se även kapitlen 14.2.1.1 och 14.2.2.1. Notera att lärosätena främst använder Core Services för att kommunicera med Ladok3 förtjänster i Lokala anpassningar. 5.3.5 Lokala Anpassningar I denna del finns alternativa lokala anpassningar, som ersätter motsvarande inbyggda moduler i Ladok Referens. I Figur 2: Övergripande moduler, har till exempel Studieplan, Hantering utbildningsutbud, Autentisering och Auktorisering ersatts av lokala anpassningar. De motsvarande inbyggda modulerna i Ladok 3 kopplas då bort. Gränssnittet länkar istället till den lokala motsvarigheten. 5.4 Tjänster och meddelanden i Ladok3 Ladok3 bygger på en tjänsteorienterad och meddelandebaserad arkitektur. Följande sektioner beskriver Ladok3 ur motsvarande perspektiv. 5.4.1 Tjänstemodell Följande figur visar möjliga viktiga verksamhetstjänster i Ladok. De visade tjänsterna ska ses som exempel och kan komma att förändras i realiseringsfasen av projektet.

B Sehlberg, J Stenberg, M Berglund Sida: 22 (45) Figur 7: Tjänster i Ladok3 Uppbyggnaden av tjänsterna i Ladok kärna i ovanstående figur finns beskrivet i 14.1.3. Ladok användargränssnitt,(composite Application) Användargränssnitt för Ladok3 som innehåller två delkomponenter, Studiedeltagande och Studieresultat. Applikationen använder de två delkomponenterna för att bygga ett sammanhållet gränssnitt för användaren utan att skapa beroenden mellan de två motsvarande tjänsterna i Ladok kärna. Studiedeltagande Prenumererar på och hanterar meddelanden om antagna studenter, (meddelanden som idag kommer från NyA), och sparar antagningarna. Hanterar logik och regler för registrering av studiedeltagande, exempelvis registrering och avbrott. Exponerar ett publikt tjänstegränssnitt som kan användas av externa system, till exempel ett lärosätes egen webbplats. Publicerar meddelanden som rör studiedeltagande. Studieresultat Hanterar logik och regler för registrering av studieresultat såsom kurser, tentamen, etc. Exponerar ett publikt tjänstegränssnitt som kan användas av externa system, till exempel ett lärosätes egen webbplats. Publicerar meddelanden som rör studieresultat. Utbildningsutbud Ansvarar för att ta emot och kontrollera nya och ändrade kurser från utbildningsdatabaserna. Exponerar ett publikt tjänstegränssnitt som utbildningsdatabaserna använder för att registrera kurser. Publicerar meddelanden som rör nya och ändrade kurser. 5.4.2 Meddelandeflöde i Ladok3 Ladok3 bygger på en meddelandebaserad arkitektur (se även 14.2, respektive 15.1) vilket innebär att tjänster som ansvarar för en viss information publicerar förändringar som rör denna information (händelser som har inträffat) och att tjänster som är beroende av den informationen prenumererar på dessa meddelanden (händelser). De meddelanden som skickas ut definieras av meddelandeinterfacet i Ladok3. Endast en delmängd av alla meddelanden kommer att publiceras till externa parter. Det beror på att man vill kunna lägga på säkerhet och även kunna hålla interfacet

B Sehlberg, J Stenberg, M Berglund Sida: 23 (45) stabilt. Den föreslagna arkitekturen ger en lösning med hög tillgänglighet och robusthet, genom att inte skapa onödiga beroenden mellan olika delar i systemet. Följande bild visar ett exempel på hur meddelanden kan flöda mellan publicerande och konsumerande tjänster, enligt ett Publish/Subscribe-mönster, i Ladok3. För transporten av meddelanden mellan tjänsterna används en meddelandeförmedlare. Flödet kan beskrivas enligt följande: Figur 8: Meddelandeflöden i Ladok3 1. Ett utbildningstillfälle skapas och registreras i Utbildningsutbud i Ladok3 av en administratör. 2. Utbildningsutbud publicerar ett motsvarande meddelande, som NyA prenumererar på. 3. Utbildningstillfället blir tillgänglig i NyA och en student anmäler sig på kursen. 4. Studenten blir antagen i NyA, som publicerar ett meddelande som Studiedeltagande i Ladok3 prenumererar på. 5. Studenten registrerar sig på kursen mot Studiedeltagande, som publicerar en händelse om registreringen till NyA, som prenumererar på händelsen. 6. När studenten är klar med kursen går administratören in den sammansatta applikationen Registrera resultat och läser upp information om studentens kursdeltagande och registrerar resultatet i Studieresultat. 7. Studieresultat publicerar ett meddelande, som NyA prenumererar på. Meddelande mot NyA hanteras via Ladok Integration. På motsvarande sätt kan t ex ett lärosäte prenumerera på motsvarande information.

B Sehlberg, J Stenberg, M Berglund Sida: 24 (45) 5.5 Processer Processerna i Ladok 3 är inte inbyggda i tjänsterna, (d v s tjänsterna styr inte processen), däremot stödjer tjänsterna de olika processerna. Processflödet styrs istället av den applikation (Composite Application) som använder de enskilda tjänster. Detta förutsätter naturligtvis att inte något regelverk hindrar valet av ordning (t ex ett kurstillfälle måste finnas registrerat innan man kan registrera sig på kursen). En process kan använda en eller flera tjänster. 5.5.1 Processtjänster De processer som Ladok3 skall stödja behöver motsvarande IT-tjänster. Följande del visar exempel på två av de processer som tagits fram i projektet verksamhetskrav och hur de skulle kunna realiseras som tjänster/operationer. Modul: Studiedeltagande Nr Processnamn Tjänster/operationer Indata Utdata 35 Förstagångsregistrera på kurstillfälle 36 Registrera utresande student på utbytesperiod 39 Hantera avbrott på utbildningstillfälle 41 Registrera student på forskarnivå Skapa förstagångsregistrering Skapa registrering för utresande student Skapa avbrott på utbildningstillfälle för student Skapa registrering för student på forskarnivå 44 Omregistrera på kurs Skapa omregistrering för student på kurs 46 Hantera individuell studieplan för student på grund- och avancerad nivå 48 Automatiserad eller manuell gruppindelning 49 Stödja studiefinansiering Inte färdig Skapa individuell studieplan Uppdatera individuell studieplan Ta bort individuell studieplan Dela upp studenter inom {kurstillfälle, program, institution} i grupp Student Kurstillfälle Student Utbytesperiod Student Student Student Kurstillfälle Student Studieplan Student Kurstillfälle Program Institution Avbrott Registrering Förstagångsregistrering Bekräftelse Omregistrering Individuell studieplan Grupp 50 Hantera individuell studieplan för student på forskarnivå Skapa individuell studieplan för student på forskarnivå Uppdatera individuell studieplan för student på forskarnivå Ta bort individuell studieplan för student på forskarnivå Student 51 Hantera byte av lärosäte Byt lärosäte Student Ansökan 52 Hantera studieuppehåll Ansök om studieuppehåll Bevilja studieuppehåll Avslå studieuppehåll Student Ansökan Individuell studieplan Bekräftelse Bekräftelse Beslut

B Sehlberg, J Stenberg, M Berglund Sida: 25 (45) 53 Hantera byte av ort m.m. inom lärosäte 54 Hantera byte av program /ämne 57 Fortsättningsregistrera student på kurstillfälle Ansök om byte av kurstillfälle Bevilja byte av kurstillfälle Avslå byte av kurstillfälle Ansök om byte av {utbildningsprogram, inriktning, ämne} på forskarnivå Bevilja byte av {utbildningsprogram, inriktning, ämne} på forskarnivå Avslå byte av {utbildningsprogram, inriktning, ämne} på forskarnivå Skapa fortsättningsregistrering Student Ansökan Student Ansökan Student Kurstillfälle Bekräftelse Beslut Bekräftelse Beslut Fortsättnings registrering Modul: Resultat Nr Processnamn Tjänster/operationer Indata Utdata 79 Sammanställa underlag för betygssättning 80 Göra bedömning och sätta betyg 81 Dokumentera resultat/tillgodoräknande 82 Offentliggöra resultat/tillgodoräknande 83 Göra en ansökan om tillgodoräknande 84 Bedöma och granska meriter Inget IT-stöd Skapa underlag Studenter Prestationer Underlag Betygssätt Underlag Arkivlista Prestation Fastställ resultat Arkivlista Fastställd arkivlista Offentliggöra resultat Student Resultat Resultat Ansök om tillgodoräknande Student Bekräftelse Ansökan 85 Besluta om meriterna ska tillgodoräknas Godkänn tillgodoräknande Avslå tillgodoräknande Ansökan Beslut

B Sehlberg, J Stenberg, M Berglund Sida: 26 (45) 6 Scenariovy Scenariovyn innehåller en mindre mängd användningsfall eller scenarios för att identifiera arkitektoniska element och för att illustrera och validera arkitekturens design. De tjänar också som en utgångspunkt för test av en arkitekturprototyp, se även appendix kapitel 12. Scenariovyn kommer att beskrivas i en senare fas i realiseringsprojektet.

B Sehlberg, J Stenberg, M Berglund Sida: 27 (45) 7 Informationsvy 7.1 Gemensam central lösning En gemensam central lösning kan ge både förvaltningsmässiga och driftsmässiga fördelar, samtidigt ställer en sådan lösning högre krav på att informationen separeras mellan de olika lärosätena. Att separera information på olika sätt mellan olika aktörer i en molntjänst är ett vanligt behov. Beroende på vad och var man vill separera finns det olika lösningar. Det är därför viktigt att klassa den information man lagrar och hanterar, så att man får den önskade separationen, men också får fördelarna av att ha gemensam information (jämför t ex behovet av Ladok Ping). Exempelvis vill man separera de lokalt unika delarna, så att man inte har tillgång till andra lärosätens information. Samtidigt kan man mycket väl samordna annan information, som generella kataloguppgifter (kommunnamn, länder, etc.). En central gemensam lösning underlättar även för de studenter, som kanske har eller håller på att studera på flera lärosäten, genom att de kan få alla sina uppgifter samlat på ett ställe via en inloggning. Dessutom förenklas möjligheten för olika högskolor att bedriva gemensamma utbildningar. Nedanstående figurer jämför en lösning med lokala Ladok-installationer och en central gemensam lösning. Figur 9: Exempel på fysisk separering av information Dagens Ladok har en fysisk uppdelning, enligt ovanstående figur, där varje lärosäte har sin egen fysiska installation. Figur 10: Exempel på logisk separering av information Ett gemensamt centralt Ladok har istället en logisk uppdelning mellan lärosätena, enligt ovanstående figur, där varje lärosäte har sin egen logiska lokala installation. Den logiska uppdelningen görs genom att respektive lärosätes information märks med en identifierare för lärosätet. Detta används sedan av Ladoks tjänster kopplat till vem som loggar in och vilket/vilka lärosäte man tillhör. I ovanstående figur kommer alltså användare H1 endast åt information märkt H1 och gemensam information. På motsvarande sätt kommer användare H2 endast åt information märkt H2 och gemensam information. Ovanpå detta appliceras sedan behörighet till information och funktion baserat på användarens roll.