Referensarkitektur för U/H Ola Ljungkrona Chalmers Per Hörnblad UmU 1
Agenda ATI Nationell nätverk för Arkitektur och Teknisk integration Bakgrund referensarkitektur Referensarkitektur Innehåll Principer regler och riktlinjer Applikationsområden Översikt integrationsmönster Lösningsmönster för Ladok3 Dokumentation och namnstandard 20140910 2
20140910 3
Vad är ATI? ATI Nationellt närverk för Arkitektur och Teknisk integration 20-tal representanter från olika lärosäten Träffas bl.a. i samband med SUNET dagar ATI Task Force GU, Chalmers, LU, UU, LiU, LTU, UmU 20140910 4
ATI Organisation Beställare UNITCF HITCF ATI Sören Berglund Ledning Peers Per Hörnblad Koordinator Finansiär EA-SIG Finland ATI Task Force Chalmers GU LiU LTU LU UMU UU Inkubator ATI U/H representanter 20140910 5
ATI Varför referensarkitektur? Vinsterna i ATI-samarbetet finns i att dela lösningar och arbetssätt på konceptuell nivå. Detta leder ökad kvalité på design, dokumentation och hantering av lokala integrationer samt minskade kostnader för underhåll. En definierad referensarkitektur ger likartade strukturer och tankesätt på varje lärosäte vilket är en förutsättning för att dela tekniska lösningar. 20140910 6
Referensarkitektur vision Samarbete istället för merarbete Samma synsätt och angreppssätt Gemensamt språk och visualisering 7
Referensarkitektur målgrupp 20140910 8
Referensarkitektur för U/H Övergripande vägval EAI Patterns Gregor Hope, Bobby Woolf ArchiMate 20140910 9
Referensarkitektur Vad ingår? Begrepp Gemensamma definitioner på inom området relevanta begrepp. Principer regler och riktlinjer Styrande principer för referensarkitektur Regler och riktlinjer för integrationsutveckling Applikationsområden Vanliga applikationsområden med dess integrationer. Översikt integrationsmönster Lösningsmönster för Ladok3 Dokumentation och namnstandard för integrationer Övergripande dokumentation (TODO) Exempel implementationer (TODO) 20140910 10
Referensarkitektur Principer, regler och riktlinjer Syfte med principerna Stöd för lärosätena att navigera mot en gemensam integrationsarkitektur långsiktigt öka förutsättningarna för samarbete Principer ska: vara vägledande för beslutsfattare fungera som redskap vid beslut om tekniska lösningar vara stöd vid revisioner och granskningar Som ett komplement till de styrande principer finns regler och riktlinjer för integrationsutveckling som syftar till att likforma utformningen av integrationer vid lärosätena. 20140910 11
Referensarkitektur Principer, regler och riktlinjer Styrande principer möjliga nyttor 1. Utveckla integrationer på ett likartat sätt -> Återanvändning 2. Gemensam dokumentation-> Återanvändning, öka samarbete 3. Gemensamma begrepp -> öka förståelse, Återanvändning 4. Tjänsteorienterad arkitektur -> Återanvändning 5. Öppna standarder -> Återanvändning 6. Säkerhet > gemensam syn på säkerhet inom området, Återanvändning 7. Tekniska lösningar och upphandling -> Återanvänd och utveckla för återanvändning 20140910 12
Referensarkitektur Principer, regler och riktlinjer Principer som är värda att reflektera kring och stämma av med beslutsfattare. Kan påverka kostnader och befintliga tekniska standarder inom respektive lärosäte. - Tjänsteorienterad arkitektur - Öppna standarder - Teknisk arkitektur och upphandling 20140910 13
Referensarkitektur Principer, regler och riktlinjer Regler och riktlinjer för integrationsutveckling Principerna pekar på vikten att lärosätena likformar design och utveckling av integrationer inom lärosätena. Likformighet skapar lösningar som enklare kan återanvändas av andra lärosäten. Regler och riktlinjer för integrationsutveckling bör vara väl förankrade i ATI nätverket och bör användas som ett redskap/handbok för integrationsutvecklare inom respektive lärosäte. 20140910 14
Referensarkitektur principer, regler och riktlinjer Regler och riktlinjer för integrationsutveckling Områden: Generella Tjänstedesign Övervakning Spårbarhet Felhantering B2B Säkerhet 20140910 15
Referensarkitektur Applikationsområden Ett applikationsområde representerar en gruppering av applikationer utifrån ett eller flera perspektiv Exempel på perspektiv kan vara organisatoriskt, processbaserat eller knutet till ett visst verksamhetsområde I vårt fall har vi valt ett funktionellt perspektiv Typiska områden och integrationer inom dessa tas upp i dokumentet 20140910 16
Referensarkitektur Applikationsområden 17
Referensarkitektur Översikt av integrationsmönster - Integrationsmodeller Filöverföring Delade databaser Tjänstebaserad integration el. direkta funktionsanrop Meddelanden Manuella rutiner
Import Integrationsmodell: Filöverföring Varje IT-system producerar filer med information som andra IT-system kan konsumera. Integrationsmoduler ansvarar för att transformera informationen till ett hanterbart format. Filerna produceras och konsumeras enligt tidsregler som styrs av verksamheten. IT-system A Export Delad data IT-system B
Integrationsmodell: Delad databas IT-systemen integreras genom att de delar information lagrade i samma databaser. IT-system A IT-system B IT-system C Delad databas
Skelett Integrationsmodell: Funktionsanrop IT-systemen exponerar en delmängd av sin funktionalitet på ett sätt som gör dem åtkomstbara för andra IT-system som kan anropa funktionerna för att utföra åtgärder och utbyta data. IT-system A Stubbe Funkionsanrop Svarsresultat IT-system B
Integrationsmodell: Meddelanden IT-systemen ansluts till ett gemensamt meddelandehanteringssystem och utbyter data och utför åtgärder genom meddelanden. IT-system A IT-system B IT-system C Meddelandehanteringssystem
Referensarkitektur Lösningsmönster för nya Ladok Vilka kapabiliteter måste vi för att kunna integrera med nya Ladok Referensarkitekturen beskriver detta på en metanivå Vi har valt att uttrycka metanivån mha Archimate Namn Datum 24
Övergripande integrationsmönster Integrationsstil Direkt funktionsanrop Meddelanden Delad databas Teknik i Nya Ladok REST API ATOM ODBC/JDBC mot uppföljningsdb 25
Tjänstebaserad integration
Meddelandebaserad integration
Adapter Ändpunkter teknikberoende transportprotokoll Bearbetningskedja dekryptering, komplettering Omformning Systemberoende, kanonisk modell
Meddelandekanal
Ett exempel
Referensarkitektur - Integrationer Dokumentation och namnstandard Utkast finns framtaget Tittat på befintliga referensarkitekturer för se hur dokumentationen skall se ut Inspireras av Enfo Zystems Baseline Namnstandarder I ett integrationskontext, hur namnger vi integrationskomponenter Namn Datum 31
Referensarkitektur Övergripande dokumentation TODO-> Archimate som metaspråk Utbildning Modelleringsträffar etc Ett repository där alla kan lägga ner sina integrationsbilder så att det går att konceptuellt jämföra mellan lärosäten Namn Datum 32