Ladok3 lösningsförslag

1. Ladok3 lösningsförslag NUAK 2011-09-21

2. Genomgång av Ladok3 lösningsförslag • Omfattning och avgränsning (CZ) • Effektmål, direktiv, beslut och förutsättningar (RS) • Möjliga lösningar som studerats (RS) • Lösningsförslaget (BS) • Grundprinciper, arkitekturella mål och mönster • Övergripande arkitektur • Estimering av omfattning • Migrering och samexistens med ”gamm-Ladok” (RS)

3. Omfattning och avgränsning

4. Strategiska frågor – omfattning och avgränsning Innehåll - beslutat av styrgruppen Vilken information Vilka processer som ska stödjas Förutsättningar för nationell installation Krav på eget register Krav på drift- och förvaltningsorganisation Nyckelfärdigt gränssnitt för studenter – ej lärosätesneutralt En identitet, flera autentiseringsmöjligheter genom tex Swami-ID el framtida e-legitimation

5. Omfattning och avgränsning - processtöd Processtödet i jämförelse med dagens Ladok för valda delar Stöd för hantering av utbildningar och utbildningstillfällen Inget stöd för ansöknings- och antagningsprocessen Enhetlig programadministration med ändamålsenlig inriktningshantering samt hantering av tidsperiod (termin) Individuella studieplaner Underlag för strategisk uppföljning, standardrapporter samt operativa utdata

6. Direktiv, effektmål och styrgruppsbeslut

7. Ladok3:s effektmål • Förbättrad kommunikation • Kompletta och stabila gränssnitt • Tillgänglighet och identitetshantering • Integration mot lokala användarkataloger, nationellt e-id • Ökad tillgänglighet, 24/7 (dock inte 100%) • Gemensam kostnadseffektivitet • Lägre kostnader för utveckling • Lokal kostnadseffektivitet • Lägre driftkostnader, självservice, ingen lokalt installerad klient • Enklare integration • Tillförlitlighet och säkerhet • Högre kvalitet • Flexibilitet • Bättre förberett för framtida förändringar • Enklare att integrera med tredjepartskomponenter • Användbarhet • Bättre anpassat till våra administrativa processer

8. Övriga instruktioner • Arkitekturen Ladok3 ska vara tjänstebaserad • All information ska vara tillgänglig via applikationsgränssnitt • Förberett för integration • Assemble – lärosätet ska kunna sätta ihop sin egen kombination av lösningar • Förberett för molnet • Drift, utveckling, kommunikation med omvärlden etc • Fungera i en sammansatt systemvärld

9. Alternativa lösningar som studerats

10. Alternativa lösningar • Kommersiella lösningar • Oracle/Peoplesoft Campus Solutions • Open/Community source • Kuali Student • HISinOne • Existerande plattformar • Ladok på webb • NyA (mer eller mindre integrerat)

11. Grundprinciper, arkitekturella mål och mönster

12. Vision för lösningen • Den övergripande visionen för Ladok3 lösning ä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.

13. Varför en gemensam installation? • Lägre driftkostnader (Kostnadseffektivitet) • En stor installation kostar mindre än 38 mindre • Se PENG-analys från 2009 • Enklare lösning för att kunna dela information (Användbarhet) • Bättre stöd för delade utbildningar och organisationer som arbetar åt flera lärosäten • Bättre stöd för studenten • Enklare integration med NyA (Kommunikation) • En integration istället för 38 • Förutsätter att alla krav på ett eget register kan uppfyllas!

14. Gemensam installation - multitenancy Dagens Ladok Ladok3

15. Viktiga grundprinciper • Tjänsteorienterad arkitektur (Effektmål 1 och 6) • 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 (Effektmål 6) • Beroenden mellan tjänster kan skapa problem. • Med autonoma tjänster ökar flexibiliteten och tillförlitligheten. • Meddelandebaserat och händelsestyrt (Effektmål 3, 4 och 6) • Ger ett flexibelt sätt att hantera förändringar av information i system. • Decentraliserad data-arkitektur(Effektmål 2 och 5) • Minskar beroenden till datakälla och ger därmed en robustare arkitektur. • Webben som plattform (Effektmål 4) • Använd etablerade standarder (Effektmål 1) • HTTP, HTML, XML, etc.

16. Verksamhetstjänst - princip Publicerar GUI Tjänste-gränssnitt Meddelande- hantering Medde-landen Notifieras API Domänmodell Lagring

17. Användning av tjänster - exempel En sammansatt applikation använder en eller flera tjänster för att stödja en process. Process Sammansatt applikation Tjänst 1 Tjänst 2 Tjänst 3

18. Meddelandeflöde - exempel

19. Övergripande arkitektur

20. Grundarkitektur • Kärnan • De centrala gemensamma inbördes beroende delar • Tillhandahåller tjänster till andra tjänster • Referens • Tjänster som är beroende av kärnan • Kan ersättas av lokalt utvecklade tjänster • Integration • Skräddarsydda bakåtkompatibla tjänster för integration • Lokala lärosätestjänster • Kan ersätta eller nyttjas av Ladok3-tjänster

21. Övergripande arkitektur Obs! Endast exempel på tjänster!

22. Användargränssnitt • Använd Ladok och Ladok GUI, som ett nyckelfärdigt system • Använd helt eget GUI, som använder tjänster i Ladok. • Använd delar av Ladok GUI, kombinerat med egna anpassningar, för t ex Ladok Referens.

23. Estimering – ”ConeofUncertanity” Projektet sept 2011

24. Estimering Resultat:1400 manmånader +-30%.

25. Migrering

26. Frågeställningar för införande och migrering • Pågående projekt • Stegvis införande, hur stora steg? • Migrering av information i nuvarande Ladok? • Lokala förutsättningar? • Resultatet kommer att ingå i remissen