...
Metamodellens indelningar
Arkitekturer
Inom en verksamhet finns det flera områden av struktur. Dessa områden brukar kallas arkitekturområden. Den som vanligtvis brukar beskrivas är:
- Infrastrukturarkitektur- implementation - för att stödja förmågorna
- Processarkitektur - implementation - för att stödja förmågorna
- Produktarkitektur - implementation - för att stödja förmågorna
- Förmågearkitektur - funktionella förmågor - det verksamheten behöver kunna - lösning på uppdrag (utbildning och forskning) - du kan inte köra förmågor.... det går inte att realisera förmågor
- Informationsarkitektur - implementation - för att stödja förmågorna
- Systemarkitektur - implementation - för att stödja förmågorna
- Infrastrukturarkitektur - implementation - för att stödja förmågorna
Varje område har en struktur som kan beskrivas med kända mönster. Det finns en relation mellan dessa områden och för att förstå hela samspelet krävs en beskrivning av samtliga områden. Varje område behöver inte detaljeras till fullo utan det är utifrån vilka svar som arkitekturen skall ge vid exempelvis en förändring.
Organisationsarkitektur
Detta område beskriver hur organisationen är strukturerad inom en verksamhet. Förutom själva organisationsstrukturen med organisatoriska enheter så är också också aktörer och roller definierade. Inom ramen för ArchiMate så går det inte att uttrycka en organisationsskarta till fullo men det går att uttrycka vilka aktörer som finns tillgängliga inom en organisation. Detta är ofta tillräckligt för att beskriva en stadsplan då organisation inte direkt beskriver eller tillför någon nytta om i förmåge- och processperspektivet då dessa går tvärs organisationen.
För att uttrycka hur organisationen är uppbyggd är andra modellspråk såsom UML bättre anpassat för detta ändamål. För att beskriva en organisations uppbyggnad finns flera kända mönster såsom Martin "Fowlers Accountability Pattern". En organisation och dess interna struktur kan uttryckas med en s.k. riktad graf med en toppnod och sedan ett nätverk av noder med relationer under toppnoden. Relationer kan var av typen linje, samarbete, centrumbildningar mm.
Aktörer och roller är aktiva komponenter i en organisation och visar vad det är för något som utför arbete eller har ägarskap på krav och mål. Om beslut (beteende) skall tas på dessa komponeter så kommer det att krävas en informationsmodell som då kommer att synas i informationsarkitekturen.
Processarkitektur (Utförararkitektur)
Processarkitekturen beskriver en struktur på processerna. Att beskriva en processkarta i detalj är inte målet med ArchiMate utan det är framförallt sambanden mellan processerna som är intressant. Syftet med processarkitekturen är att kunna belysa vilka processer som är påverkade vid en förändring eller att identifiera processer som saknas vid en förändring. För en bättre detaljering av processerna finns det andra modeller som gör detta bättre. ArchiMate är inte ett processkartläggningsverktyg utan snarare en visualisering av hur processerna förhåller sig till sin omgivning på ett förenklat sätt. Den nivå av detaljeringsgrad av processerna definieras vilket samband/perspektiv som skall kartläggas. Det krävs ofta flera perspektiv för att visa "hela" kartan.
Processarkitekturen bör "mappa" väl mot den i arkivlagen definierade klassificeringsstrukturen.
Inom högskolesektorn är behovet av standardiserade och detaljerade processer begränsat beroende på att verksamheten i de flesta fall är beroende på individbaserat beteende. En bra distinktion på om en process behöver detaljeras är om den kan automatiseras. Med en automatisering menas att även beteendet och besluten i processen automatiseras. För automatiserade processer krävs andra modeller och i arkitekturen bör man representera det som verksamhetsprocesser på en högre nivå som inte är detaljerade. De automatiserade processerna syns istället som tjänster i applikationsarkitekturen men behöver givetvis en relation till en övergripande process i processarkitekturen.
Produktarkitektur (Leveransarkitektur)
Produktarkitekturen är för många inom högskolesektorn ett relativt okänt begrepp. Att börja identifiera produkter och se vilka värden de bidrar till externa aktörer skapar en möjlighet att identifiera externa kanaler som vanligtvis tappas bort. De ger en inblick i vilka tjänster en högskola som faktiskt exponeras externt. Det kan skapa möjligheter att hitta nya behov som idag försvinner om verksamheten bara tittar på sina processer. Andra värden visar sig och motsatsen visas också såsom produkter som inte bidrar till ett externt värde. Produktarkitekturen hjälper till att identifiera "andra värden" som blir svåra att identifiera om verksamheten bara tittar på vilket värde som processerna skall uppfylla. Processperspektivet tenderar att bli något internt även om ambitionen är att se till att det är kunden som skall få nytta. Produktarkitekturen kan hjälpa till med att tydliggöra detta.
Med produkter avses tjänsteprodukter, dvs. produkter som skapas av tjänster och inte fysiska produkter. Fysiska produkter är produkter som inte interagerar med en extern aktör under själva processen. Processen kan ha externa tjänster för att påverka konfigurationen på den fysiska produkten men då är det en separat tjänsteprodukt skilt från den fysiska produkten. I ett EA perspektiv är inte den fysiska produkten intressant eftersom den fysiska produkten inte har några kanaler under själva tillverkningsprocessen.
Förmågearkitektur
När det kommer till förmågor anses det finnas två olika förmågetyper:
- Framgångsförmågor
- Funktionella förmågor
Framgångsförmågor används vanligtvis när en verksamhet vill göra en förändring som fokuserar på ett tydligt mål eller flera mål. Ett exempel på en framgångsförmåga är "Vi skall bli världsledande inom...". Inom ramen för stadsplan så är det inte dessa förmågor som är intressanta eftersom en stadsplan handlar om att kartlägga nuläget och inte förflyttningen. Stadsplanen kan givetvis användas för att se hur en förändring påverkar stadsplanen och efter förändringen är genomförd så uppdateras Stadsplanen till ett nytt nuläge. Det kan också bli tydligt vilka förmågor som verksamheten har men inte uppfattat att den har.
Funktionella förmågor har ett internt perspektiv och inte ett framgångsperspektiv. Det kan ofta vara enklare att definiera förmågor eftersom de är en löst kategorisering av vad verksamheten skall kunna för att fungera. En förmåga består av alla de övriga arkitekturerna och dess delar. Förmågor är den centrala arkitekturen - det är utifrån förmågorna som stadsplanen skall växa fram.
Informationsarkitektur
Inom högskolesektorn i Sverige är behovet av korrekt information vid varje tillfälle helt väsentligt för att verksamheten skall kunna fungera effektivt. Det går att hävda att den typ av verksamhet som bedrivs inom utbildning och forsknings är mer förtjänta av korrekt information än att ha standardiserade processer. Dock så är detta något som är eftersatt på många myndigheter och det finns mycket att göra för att förbättra detta. En förutsättning för att digitalisera verksamheten är att begrepp och information har en entydig betydelse. I synnerhet när behovet av integrationer mellan system ökar dramatiskt så är det nödvändigt att veta vart information uppstår, vad den betyder och hur den sprids inom verksamheten. I synnerhet är informationsarkitekturen helt betydande inom BI-området. För att kunna få ut rätt mätetal måste struktur och relation mellan information vara helt korrekt annars kommer inte beslutsunderlagen/mätetalen att bli korrekta.
Ofta har behovet av korrekt information drivits från IT-avdelningarna eftersom de är dessa som ansvarat för automatisering och integration. Dock så borde verksamheten bli mer engagerad i definitionen av informationen. Metamodellen hjälper till att se hur informationen kommer in i den totala arkitekturen och också ge indikationer om vilken information som är viktig. MM kan bli ett verktyg att börja strukturera information så att den kan hjälpa verksamheten i digitaliseringen.
Kanonisering baserad på metamodellen
Systemarkitektur
Denna arkitektur är den som de flesta kan enkelt relatera till. De flesta har en relativt god uppfattning som vilka applikationer som finns inom verksamheten och vilken domän som de stödjer. Många lärosäten använder sig av en förvaltningsmodell, PM3, som är en form av systemarkitektur. Dock så brukar det vara problematiskt att se hur systemarkitekturen påverkar andra delar av verksamheten vid en förändring. Det är också så att systemarkitekturen brukar innefatta en del av infrastrukturarkitekturen, vilket leder till att det kan vara svårt att se hur infrastrukturen stödjer flera förvaltningsobjekt (PM3) eller att infrastrukturen förvaltas inom ett objekt vilket leder till suboptimering och en risk för viss stuprörsförvaltning. Genom att abstrahera ut applikationslagret mot infrastruktur och se hur hela kartan ser ut ger en bättre bild av hur infrastruktur kan återanvändas. Det blir också tydligare hur systemarkitekturen stödjer flera delar av verksamheten.
Systemarkitektur brukar slarvigt kallas för systemkarta och är en förenklad vy av systemsamband och saknar ofta en relation till verksamhetens tjänster.
Namnsättningen med "System" istället för "Applikation" är tagen för att de flesta verksamheter fortfarande referera till "System"
Systemområden - nivå 1, N1
Idén med vilka systemområden som används på nivå 1 inom systemarkitekturen grundar sig i en gemensam syn på vilken typ av myndighet som skall beskrivas. Beroende på typen av myndighet finns ett antal gemensamma systemområden för samtliga myndigheter samt några specifika systemområden som kan härledas till vilken betoning myndigheten har på sin verksamhet.
De gemensamma systemområdena som finns inom samtliga myndigheter:
- Affärssystem
- Myndighetssystem
- Fastighet- och lokalsystem
- Infrastruktursystem, mjuk och hård, och till för ngn annan och inte sig själv
- Relationssystem
Systemområden som är kopplade till myndigheter inom utbildning och forskning:
- Utbildningssystem
- Forskningsstödsystem
- Bibliotekssystem
Skillnader mot applikationsområden i referensarkitekturen
I referensarkitekturen finns ett antal applikationsområden definierade. Dessa passar dock inte riktigt in i metamodellens nivåer då de spänner sig över flera nivåer. Applikationsområdena är:
- Ekonomi - Affärssystem
- HR - Affärssystem
- Studieadministration - Utbildningssystem
- Utbildningsstöd - Utbildningssystem
- Bibliotek - Bibliotekssystem
- Externa relationer - Relationssystem
- Infrastruktur - Infrastruktursystem
- Kollaboration - Relationssystem
- Forskningsadministration - Forskningsstödsystem
- Innehållshantering - Relationssystem
- Ledningsstöd - Affärssystem
- Forskningsstöd - Forskningssstödsystem
- Administration - Kan hamna i olika
System ur ett verksamhetsperspektiv
Ett system skall definieras ur ett verksamhetsperspektiv. Ett system är en sammanhängande mängd applikationskomponenter som tydligt kan identifieras från verksamheten. System som finns för att andra system skall fungera såsom exempelvis Acitve Directory finns men syns inte i ett sambandsperspektiv mellan system eftersom AD ofta har relationer mellan flera system. Informationsutbyte mellan system görs i en vy mellan (N2) SystemA och (N2) SystemB utan att detaljera utbytet. I exemplet nedan sker ett informationsutbyte mellan Antagningssystemet och Intranätet. Dessa har då ett beroende till varandra på systemnivå.
I en detaljerad bild som visar vilka komponenter som samverkar skulle:
Element i Systemarkitekturen
Inom systemarkitekturen används 2 element i ArchiMate:
- Apllikationskomponent
- Applikationsfunktion
För nivåerna N1-N3 används Applikationskomponent enligt:
- N1 - Systemområde
- N2 - System
- N3 - Applikationskomponent
För nivå N4 används Applikationsfunktion:
- N4 - Applikationsfunktion
Infrastrukturarkitektur
Det kan vara abstrakt att dela på applikationer och infrastruktur och kräver en del tankeverksamhet. Inom infrastrukturarkitekturen hittas "hårdvara och sladdar" tillsammans med filer och databaser mm. Det finns inga logiska beteenden i infrastrukturarkitekturen. Det som kommer fram är gemensam hårdvara för olika applikationer och på vilket sätt data skickas mellan system. Förenklat går det att säga att inom systemarkitekturen ses sambanden mellan beteenden och tjänster samt vilken data som utbytes medan i infrastrukturarkitekturen ses hur filerna som innehåller data transporteras och vilken hårdvara detta sker emellan. Det är alltså de fysiska sambanden som visas här och ger en bild över exempelvis i vilken datahall hårdvaran står. Fysisk datasäkerhet eller virtualiserade applikationer är ett exempel på vad som tydligt visas tydligt i infrastrukturarkitekturen. Det kan vara en utmaning att hitta rätt detaljering på denna nivå och det är viktigt att hela tiden tänka på vad som skall beskrivas. Ofta går det att förenkla och beskriva exempelvis hur filer transporteras och inte hamna i en detaljering som beskriver alla komponenter och artefakter i en server.
Det är inom denna nivå som kopplingen till ATI:s referensarkitektur finns och det är på denna nivå som integrationsmönster syns. Dock inte alla integrationsmönster. I ESB fallet finns det komponenter som beskriver hur data flyttas baserat på routinglogik men detta kan implicit ses som att det är samma nod som "hämtar och skickar" filer. I och med att alla filer passerar samma nod så bör det rimligvis finnas logik för att "fördela" trafiken till olika mottagare. I systemarkitekturen bör det synas att det finns en applikationsfunkion som läser specifik data och sedan använder en tjänst på en annan applikation för att "lämna" data. Återigen är det viktigt att inte detaljera för mycket då bilden fort blir komplex.
Nivåer
Nivåer i arkitekturen är till för att kunna skapa en överblicksbild på hela arkitekturen. Behovet av att detaljera nivåerna beror dels på vilken typ av verksamhet som bedrivs och vilka behov den har att beskriva detaljerna. I en informationsintensiv verksamhet med krav på mycket integrationer blir det naturligt att detaljera informations-, system- och infrastrukturarkitekturen men kanske inte processarkitekturen. För en verksamhet med krav på hög standardisering av processer, exempelvis snabbmatskedjor, blir det processarkitekturen som behöver detaljeras mer. Sedan finns det givetvis verksamheter som behöver detaljera flera arkitekturer, såsom flygbolag, för att kunna se sambanden vid en förändring.
För att skapa en ingångsmodell av stadsplanen räcker det med en ganska låg detaljering av arkitekturen men vid ett förändringsbehov kan en eller flera arkitekturer detaljeras mer, givetvis beroende på vad som är viktigt för just den förändringen. Stadsplanen kommer att bestå av flera olika perspektiv med olika grader av detaljering beroende på behoven.
Nivåer
Nivåer i arkitekturen är till för att kunna skapa en överblicksbild på hela arkitekturen. Behovet av att detaljera nivåerna beror dels på vilken typ av verksamhet som bedrivs och vilka behov den har att beskriva detaljerna. I en informationsintensiv verksamhet med krav på mycket integrationer blir det naturligt att detaljera informations-, system- och infrastrukturarkitekturen men kanske inte processarkitekturen. För en verksamhet med krav på hög standardisering av processer, exempelvis snabbmatskedjor, blir det processarkitekturen som behöver detaljeras mer. Sedan finns det givetvis verksamheter som behöver detaljera flera arkitekturer, såsom flygbolag, för att kunna se sambanden vid en förändring.
För att skapa en ingångsmodell av stadsplanen räcker det med en ganska låg detaljering av arkitekturen men vid ett förändringsbehov kan en eller flera arkitekturer detaljeras mer, givetvis beroende på vad som är viktigt för just den förändringen. Stadsplanen kommer att bestå av flera olika perspektiv med olika grader av detaljering beroende på behoven.
För att skapa en initial bild av verksamheten kan det vara lämpligt att börja med förmågor och tjänster.
Arkitekturer
Inom en verksamhet finns det flera områden av struktur. Dessa områden brukar kallas arkitekturområden. Den som vanligtvis brukar beskrivas är:
- Infrastrukturarkitektur- implementation - för att stödja förmågorna
- Processarkitektur - implementation - för att stödja förmågorna
- Produktarkitektur - implementation - för att stödja förmågorna
- Förmågearkitektur - funktionella förmågor - det verksamheten behöver kunna - lösning på uppdrag (utbildning och forskning) - du kan inte köra förmågor.... det går inte att realisera förmågor
- Informationsarkitektur - implementation - för att stödja förmågorna
- Systemarkitektur - implementation - för att stödja förmågorna
- Infrastrukturarkitektur - implementation - för att stödja förmågorna
Varje område har en struktur som kan beskrivas med kända mönster. Det finns en relation mellan dessa områden och för att förstå hela samspelet krävs en beskrivning av samtliga områden. Varje område behöver inte detaljeras till fullo utan det är utifrån vilka svar som arkitekturen skall ge vid exempelvis en förändring.
Organisationsarkitektur
Detta område beskriver hur organisationen är strukturerad inom en verksamhet. Förutom själva organisationsstrukturen med organisatoriska enheter så är också också aktörer och roller definierade. Inom ramen för ArchiMate så går det inte att uttrycka en organisationsskarta till fullo men det går att uttrycka vilka aktörer som finns tillgängliga inom en organisation. Detta är ofta tillräckligt för att beskriva en stadsplan då organisation inte direkt beskriver eller tillför någon nytta om i förmåge- och processperspektivet då dessa går tvärs organisationen.
För att uttrycka hur organisationen är uppbyggd är andra modellspråk såsom UML bättre anpassat för detta ändamål. För att beskriva en organisations uppbyggnad finns flera kända mönster såsom Martin "Fowlers Accountability Pattern". En organisation och dess interna struktur kan uttryckas med en s.k. riktad graf med en toppnod och sedan ett nätverk av noder med relationer under toppnoden. Relationer kan var av typen linje, samarbete, centrumbildningar mm.
Aktörer och roller är aktiva komponenter i en organisation och visar vad det är för något som utför arbete eller har ägarskap på krav och mål. Om beslut (beteende) skall tas på dessa komponeter så kommer det att krävas en informationsmodell som då kommer att synas i informationsarkitekturen.
Processarkitektur (Utförararkitektur)
Processarkitekturen beskriver en struktur på processerna. Att beskriva en processkarta i detalj är inte målet med ArchiMate utan det är framförallt sambanden mellan processerna som är intressant. Syftet med processarkitekturen är att kunna belysa vilka processer som är påverkade vid en förändring eller att identifiera processer som saknas vid en förändring. För en bättre detaljering av processerna finns det andra modeller som gör detta bättre. ArchiMate är inte ett processkartläggningsverktyg utan snarare en visualisering av hur processerna förhåller sig till sin omgivning på ett förenklat sätt. Den nivå av detaljeringsgrad av processerna definieras vilket samband/perspektiv som skall kartläggas. Det krävs ofta flera perspektiv för att visa "hela" kartan.
Processarkitekturen bör "mappa" väl mot den i arkivlagen definierade klassificeringsstrukturen.
Inom högskolesektorn är behovet av standardiserade och detaljerade processer begränsat beroende på att verksamheten i de flesta fall är beroende på individbaserat beteende. En bra distinktion på om en process behöver detaljeras är om den kan automatiseras. Med en automatisering menas att även beteendet och besluten i processen automatiseras. För automatiserade processer krävs andra modeller och i arkitekturen bör man representera det som verksamhetsprocesser på en högre nivå som inte är detaljerade. De automatiserade processerna syns istället som tjänster i applikationsarkitekturen men behöver givetvis en relation till en övergripande process i processarkitekturen.
Produktarkitektur (Leveransarkitektur)
Produktarkitekturen är för många inom högskolesektorn ett relativt okänt begrepp. Att börja identifiera produkter och se vilka värden de bidrar till externa aktörer skapar en möjlighet att identifiera externa kanaler som vanligtvis tappas bort. De ger en inblick i vilka tjänster en högskola som faktiskt exponeras externt. Det kan skapa möjligheter att hitta nya behov som idag försvinner om verksamheten bara tittar på sina processer. Andra värden visar sig och motsatsen visas också såsom produkter som inte bidrar till ett externt värde. Produktarkitekturen hjälper till att identifiera "andra värden" som blir svåra att identifiera om verksamheten bara tittar på vilket värde som processerna skall uppfylla. Processperspektivet tenderar att bli något internt även om ambitionen är att se till att det är kunden som skall få nytta. Produktarkitekturen kan hjälpa till med att tydliggöra detta.
Med produkter avses tjänsteprodukter, dvs. produkter som skapas av tjänster och inte fysiska produkter. Fysiska produkter är produkter som inte interagerar med en extern aktör under själva processen. Processen kan ha externa tjänster för att påverka konfigurationen på den fysiska produkten men då är det en separat tjänsteprodukt skilt från den fysiska produkten. I ett EA perspektiv är inte den fysiska produkten intressant eftersom den fysiska produkten inte har några kanaler under själva tillverkningsprocessen.
Förmågearkitektur
När det kommer till förmågor anses det finnas två olika förmågetyper:
- Framgångsförmågor
- Funktionella förmågor
Framgångsförmågor används vanligtvis när en verksamhet vill göra en förändring som fokuserar på ett tydligt mål eller flera mål. Ett exempel på en framgångsförmåga är "Vi skall bli världsledande inom...". Inom ramen för stadsplan så är det inte dessa förmågor som är intressanta eftersom en stadsplan handlar om att kartlägga nuläget och inte förflyttningen. Stadsplanen kan givetvis användas för att se hur en förändring påverkar stadsplanen och efter förändringen är genomförd så uppdateras Stadsplanen till ett nytt nuläge. Det kan också bli tydligt vilka förmågor som verksamheten har men inte uppfattat att den har.
Funktionella förmågor har ett internt perspektiv och inte ett framgångsperspektiv. Det kan ofta vara enklare att definiera förmågor eftersom de är en löst kategorisering av vad verksamheten skall kunna för att fungera. En förmåga består av alla de övriga arkitekturerna och dess delar. Förmågor är den centrala arkitekturen - det är utifrån förmågorna som stadsplanen skall växa fram.
Informationsarkitektur
Inom högskolesektorn i Sverige är behovet av korrekt information vid varje tillfälle helt väsentligt för att verksamheten skall kunna fungera effektivt. Det går att hävda att den typ av verksamhet som bedrivs inom utbildning och forsknings är mer förtjänta av korrekt information än att ha standardiserade processer. Dock så är detta något som är eftersatt på många myndigheter och det finns mycket att göra för att förbättra detta. En förutsättning för att digitalisera verksamheten är att begrepp och information har en entydig betydelse. I synnerhet när behovet av integrationer mellan system ökar dramatiskt så är det nödvändigt att veta vart information uppstår, vad den betyder och hur den sprids inom verksamheten. I synnerhet är informationsarkitekturen helt betydande inom BI-området. För att kunna få ut rätt mätetal måste struktur och relation mellan information vara helt korrekt annars kommer inte beslutsunderlagen/mätetalen att bli korrekta.
Ofta har behovet av korrekt information drivits från IT-avdelningarna eftersom de är dessa som ansvarat för automatisering och integration. Dock så borde verksamheten bli mer engagerad i definitionen av informationen. Metamodellen hjälper till att se hur informationen kommer in i den totala arkitekturen och också ge indikationer om vilken information som är viktig. MM kan bli ett verktyg att börja strukturera information så att den kan hjälpa verksamheten i digitaliseringen.
Kanonisering baserad på metamodellen
Systemarkitektur
Denna arkitektur är den som de flesta kan enkelt relatera till. De flesta har en relativt god uppfattning som vilka applikationer som finns inom verksamheten och vilken domän som de stödjer. Många lärosäten använder sig av en förvaltningsmodell, PM3, som är en form av systemarkitektur. Dock så brukar det vara problematiskt att se hur systemarkitekturen påverkar andra delar av verksamheten vid en förändring. Det är också så att systemarkitekturen brukar innefatta en del av infrastrukturarkitekturen, vilket leder till att det kan vara svårt att se hur infrastrukturen stödjer flera förvaltningsobjekt (PM3) eller att infrastrukturen förvaltas inom ett objekt vilket leder till suboptimering och en risk för viss stuprörsförvaltning. Genom att abstrahera ut applikationslagret mot infrastruktur och se hur hela kartan ser ut ger en bättre bild av hur infrastruktur kan återanvändas. Det blir också tydligare hur systemarkitekturen stödjer flera delar av verksamheten.
Systemarkitektur brukar slarvigt kallas för systemkarta och är en förenklad vy av systemsamband och saknar ofta en relation till verksamhetens tjänster.
Namnsättningen med "System" istället för "Applikation" är tagen för att de flesta verksamheter fortfarande referera till "System"
Systemområden - nivå 1, N1
Idén med vilka systemområden som används på nivå 1 inom systemarkitekturen grundar sig i en gemensam syn på vilken typ av myndighet som skall beskrivas. Beroende på typen av myndighet finns ett antal gemensamma systemområden för samtliga myndigheter samt några specifika systemområden som kan härledas till vilken betoning myndigheten har på sin verksamhet.
De gemensamma systemområdena som finns inom samtliga myndigheter:
- Affärssystem
- Myndighetssystem
- Fastighet- och lokalsystem
- Infrastruktursystem, mjuk och hård, och till för ngn annan och inte sig själv
- Relationssystem
Systemområden som är kopplade till myndigheter inom utbildning och forskning:
- Utbildningssystem
- Forskningsstödsystem
- Bibliotekssystem
Skillnader mot applikationsområden i referensarkitekturen
I referensarkitekturen finns ett antal applikationsområden definierade. Dessa passar dock inte riktigt in i metamodellens nivåer då de spänner sig över flera nivåer. Applikationsområdena är:
- Ekonomi - Affärssystem
- HR - Affärssystem
- Studieadministration - Utbildningssystem
- Utbildningsstöd - Utbildningssystem
- Bibliotek - Bibliotekssystem
- Externa relationer - Relationssystem
- Infrastruktur - Infrastruktursystem
- Kollaboration - Relationssystem
- Forskningsadministration - Forskningsstödsystem
- Innehållshantering - Relationssystem
- Ledningsstöd - Affärssystem
- Forskningsstöd - Forskningssstödsystem
- Administration - Kan hamna i olika
System ur ett verksamhetsperspektiv
Ett system skall definieras ur ett verksamhetsperspektiv. Ett system är en sammanhängande mängd applikationskomponenter som tydligt kan identifieras från verksamheten. System som finns för att andra system skall fungera såsom exempelvis Acitve Directory finns men syns inte i ett sambandsperspektiv mellan system eftersom AD ofta har relationer mellan flera system. Informationsutbyte mellan system görs i en vy mellan (N2) SystemA och (N2) SystemB utan att detaljera utbytet. I exemplet nedan sker ett informationsutbyte mellan Antagningssystemet och Intranätet. Dessa har då ett beroende till varandra på systemnivå.
I en detaljerad bild som visar vilka komponenter som samverkar skulle:
Element i Systemarkitekturen
Inom systemarkitekturen används 2 element i ArchiMate:
- Apllikationskomponent
- Applikationsfunktion
För nivåerna N1-N3 används Applikationskomponent enligt:
- N1 - Systemområde
- N2 - System
- N3 - Applikationskomponent
För nivå N4 används Applikationsfunktion:
- N4 - Applikationsfunktion
Infrastrukturarkitektur
Det kan vara abstrakt att dela på applikationer och infrastruktur och kräver en del tankeverksamhet. Inom infrastrukturarkitekturen hittas "hårdvara och sladdar" tillsammans med filer och databaser mm. Det finns inga logiska beteenden i infrastrukturarkitekturen. Det som kommer fram är gemensam hårdvara för olika applikationer och på vilket sätt data skickas mellan system. Förenklat går det att säga att inom systemarkitekturen ses sambanden mellan beteenden och tjänster samt vilken data som utbytes medan i infrastrukturarkitekturen ses hur filerna som innehåller data transporteras och vilken hårdvara detta sker emellan. Det är alltså de fysiska sambanden som visas här och ger en bild över exempelvis i vilken datahall hårdvaran står. Fysisk datasäkerhet eller virtualiserade applikationer är ett exempel på vad som tydligt visas tydligt i infrastrukturarkitekturen. Det kan vara en utmaning att hitta rätt detaljering på denna nivå och det är viktigt att hela tiden tänka på vad som skall beskrivas. Ofta går det att förenkla och beskriva exempelvis hur filer transporteras och inte hamna i en detaljering som beskriver alla komponenter och artefakter i en server.
Det är inom denna nivå som kopplingen till ATI:s referensarkitektur finns och det är på denna nivå som integrationsmönster syns. Dock inte alla integrationsmönster. I ESB fallet finns det komponenter som beskriver hur data flyttas baserat på routinglogik men detta kan implicit ses som att det är samma nod som "hämtar och skickar" filer. I och med att alla filer passerar samma nod så bör det rimligvis finnas logik för att "fördela" trafiken till olika mottagare. I systemarkitekturen bör det synas att det finns en applikationsfunkion som läser specifik data och sedan använder en tjänst på en annan applikation för att "lämna" data. Återigen är det viktigt att inte detaljera för mycket då bilden fort blir komplexFör att skapa en initial bild av verksamheten kan det vara lämpligt att börja med förmågor och tjänster.
Element i metamodellen
Relationer
...