...
Genom att beskriva verksamheten i termer av förmågor är det inte nödvändigt att detaljera innehållet helt utan det räcker med en övergripande beskrivning av förmågan. Detta kan sättas i relation till att beskriva en verksamhet i processer vilket kan vara väldigt tidsödande och ger ändå inte en helhetssyn av vad verksamheten behöver kunna för att leverera. Det bör gå relativt snabbt att skapa en modell över förmågorna inom ett lärosäte. Efter att en modell över förmågorna är på plats kan arbetet fortsätta genom att detaljera verksamheten inom de andra arkitekturerna. Detta skapar snabbt en överblick på verksamheten och ett bra sätt att detaljera vidare där det finns behov av att detaljera - såsom processer som funkar sämre eller upphandling av nya IT-system etc.
En Funktionskarta En förmågekarta som visar N1 och N2 förmågor för en verksamhet som är aktiv inom högskola- och universitetssektorn:
Tjänsteperspektivet - skall delvis skrivas om då det i MM är förmågor som realiserar tjänster. Processer använder sig av verksamhetstjänsterna. För att beskriva in implementation av verksamheten kan processer realisera tjänster....
Genom att utgå från tjänster för att beskriva en stadsplan är på samma sätt som att använda förmågor ett sätt att förenkla och reducera detaljnivån i beskrivningen av ett lärosäte. Tjänster är det som en process eller applikation exponerar utåt genom ett gränssnitt. Genom att analysera tjänsterna blir det relativt tydligt vad verksamheten behöver för resurser för att realisera sina förmågor. Det finns både interna och externa tjänster. Externa tjänster är sådana som konsumeras av externa aktörer eller är exponerade utanför sin egen verksamhet. Interna tjänster är typiskt tjänster som stödverksamheten levererar till kärnverksamheten.
...
Inom varje arkitektur och i samband mellan arkiteturerna så finns det olika nivåer av detaljering. Nivåerna känns lättast igen genom att titta på en klassisk processkarta där man utgår från processområden som exempelvis stöd-, ledning- och huvud/kärnprocesser för att sedan detaljera vidare ner till lägsta nivån i form av aktiviteter.
Metamodellens indelningar
...
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 och hur de mappar mot de föreslagna systemområden ä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 (N2) 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 delar i systemen som samverkar:
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:
Nivåer och Element i informationsarkitekturen
Alla element i Informationsarkitekturen består av ArchiMate Business Object. Det kan upplevas som en bredare tolkning än definitionen i Archimate specifikationen - men som alltid är det kontexten som verkligen sätter definitionen. Dvs. frågan som bör ställas är vad som skall modelleras och vad betyder definitionen just i detta kontext. Metamodellen lyfter in alla nivåer i verksamheten och beskriver också ett visst kontext - dvs. en strukturering av information som används i verksamheten, från övergripande nivå till detaljerad nivå.
Metamodellen i sig har inga möjligheter att uttrycka detaljerade informationsmodeller utan är ett sätt att sortera information och se hur den används. För att göra begreppsmodeller, informationsmodeller används andra modellmetoder såsom exempelvis UML. UML kan uttrycka samtliga nivåer i metamodellen modellmässigt. Det finns givetvis en uppsjö av modellspråk som går att använda men gemensamt för alla är att objekten i dessa modeller sedan kan sorteras in i metamodellen.
(N1) Informationsområde
(N2) Informationsgrupp
(N3) Verksamhetsobjekt
(N4) Informationsobjekt
Exempel på nedbrytning av informationsarkitekturen
För att förstå vilken information verksamheten har behov av behöver en nedbrytning av informationen göras. En bra utgångspunkt för denna nedbrytning är att förstå vilka begrepp verksamheten använder sig av. Begreppen kan beskrivas och definieras samt att enklare relationer mellan begreppen kan identifieras. Begreppsmodellen nedan visar på en hur några begrepp inom Informationsområde (N1), Utbildningsinformation, är relaterade till varandra och enklare definitioner till begreppen. Begrepp inom verksamheten kan vara väldigt generella och andra kan vara väldigt specifika. Det gör att det är en utmaning att göra nedbrytningen till informationsnivå (N4). Vissa av begreppen realiseras av flera informationsobjekt, ofta lite mer generella begrepp, eller väldigt specifika begrepp som kan vara specialiseringar av enskilda klasser.
En gemensam begreppssyn är en grundbult för att kunna digitalisera verksamheten. Otydliga definitioner på begrepp går inte att entydigt bryta ner till väl definierade informationsobjekt (N4). Då går det inte heller att realisera dataobjekt (del av systemarkitekturen) som applikationstjänster utbyter, bearbetar eller förmedlar. Dessa tjänster och tillhörande dataobjekt är den digitala representationen av verksamheten - det som vanligtvis kallas "digitalisering av verksamheten".
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.
Gemensamma systemområden som finns inom samtliga myndigheter:
- Affär
- Myndighet
- Fastighet- och lokalsystem
- Infrastruktur, mjuk och hård, och till för ngn annan och inte sig själv
- Kommunikation
Systemområden som är kopplade till myndigheter inom utbildning och forskning:
- Utbildning
- Forskningsstöd
- Bibliotek
Systemområden som inte förvaltas av myndighet
- Externa system
Skillnader mot applikationsområden i ATI:s referensarkitektur
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 och hur de mappar mot de föreslagna systemområden ä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
I tabellform:
Stadsplan | Applikationsområde |
Affärssystem | Ekonomi |
| HR |
| Ledningsstöd |
|
|
Utbildningssystem | Studieadministration |
| Utbildningsstöd |
|
|
Bibliotekssystem | Bibliotek |
|
|
Relationssystem | Externa relationer |
| Kollaboration |
| Innehållshantering |
|
|
Infrastruktursystem | Infrastruktur |
|
|
Forskningsstödsystem | Forskningsadministration |
| Forskningsstöd |
|
|
”Olika” | Administration |
System (N2) ur ett verksamhetsperspektiv
Systemområde (N1), (Affärssystem) – System (N2), (Ekonomisystem) – Applikationskomponent (N3), (redovisning, finansiell styrning och uppföljning, budgetering, inköp, lönehantering)
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 delar i systemen som samverkar:
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
Applikationskomponent (N3)
Med applikationskomponent menas tillämpning och genom att standardisera tillämpningarna inom ett lärosäte går det att skapa en överblick hur många olika mjukvaror som realiserar tillämpningarna. Det är på denna nivå som det går att identifiera applikationer som realiserar samma tillämpningar. Som beskrivit tidigare är ett mål med systemarkitekturen att minimera antalet applikationer och endast i idealarkitekturen endast ha en tillämpning som realiseras av en applikation. Givetvis är det inte möjligt i alla fall men ger en indikation på vart det går att rationalisera. Genom detta arbete går det också att jämföra mellan lärosäten vilka tillämpningar lärosätet använder istället för att titta på vilka applikationer som används. Det kan vara så att två lärosäten använder samma applikation men med olika tillämpning och då är det rimligt att det är olika applikationer och ur ett samarbetsperspektiv blir det svårare att hitta gemensamma samarbetspunkter. Nedan följer en lista på förslag till tillämpningar inom ett lärosäte.
Applikationskomponent (N3) | System (N2) | Systemområde (N1) |
E-handel | E-handelssystem | Affär |
Budget | Ekonomisystem | Affär |
Redovisning | Ekonomisystem | Affär |
Finansiell styrning | Ekonomisystem | Affär |
Uppföljing | Ekonomisystem | Affär |
Inköp och upphandling | Ekonomisystem | Affär |
Fakturahantering | Ekonomisystem | Affär |
Personalhantering | HR-system | Affär |
Studentantagning | Rekryteringssystem | Affär |
Rekrytering studenter | Rekryteringssystem | Affär |
Rekrytering anställda | Rekryteringssystem | Affär |
Externa relationer | Relationssystem | Affär |
Interna relationer | Relationssystem | Affär |
Hantering hyresavtal | Avtalshantering | Affär |
Bok- och tidsskriftsutlåning | Utlåningssystem | Bibliotek |
Campusbussen | Externa transporter | Externt |
Hantering kårmedlemskap | Kårsystem | Externt |
Byggnads- och rumskatalog | Lokalhanteringssystem | Fastighet och lokal |
Inpassering lokaler | Lokalhanteringssystem | Fastighet och lokal |
Kartor | Lokalhanteringssystem | Fastighet och lokal |
Passerkortshantering | Lokalhanteringssystem | Fastighet och lokal |
Hus- och lokalkatalog | Lokalhanteringssystem | Fastighet och lokal |
Kalender | Resursbokningssystem | Fastighet och lokal |
Resursbokning | Resursbokningssystem | Fastighet och lokal |
Autentisering | Autentiseringssystem | Infrastruktur |
Integration | Integrationsplattform | Infrastruktur |
Fillagring | IT-infrastrukturssystem | Infrastruktur |
Nätverkshantering | IT-infrastrukturssystem | Infrastruktur |
Spamhantering | IT-infrastrukturssystem | Infrastruktur |
Systemövervakning | IT-infrastrukturssystem | Infrastruktur |
Utskrift | IT-infrastrukturssystem | Infrastruktur |
Övervakning IT-resurser | IT-infrastrukturssystem | Infrastruktur |
Fjärrskrivbord | IT-infrastrukturssystem | Infrastruktur |
Mediahantering | IT-infrastrukturssystem | Infrastruktur |
Applikationsinstallation | IT-infrastrukturssystem | Infrastruktur |
Hantering av digitala enheter | IT-infrastrukturssystem | Infrastruktur |
OS-installation | IT-infrastrukturssystem | Infrastruktur |
Katalog | Katalogsystem | Infrastruktur |
Organisationshantering | Katalogsystem | Infrastruktur |
Grupphantering | Katalogsystem | Infrastruktur |
Extern webb | CMS | Kommunikation |
Intranät | CMS | Kommunikation |
Enkäthantering | Informationsinsamlingssystem | Kommunikation |
Felanmälan | IT-supportsystem | Kommunikation |
IT-supportstöd | IT-supportsystem | Kommunikation |
Ärendehantering | IT-supportsystem | Kommunikation |
Chatt | Kollaborationssystem | Kommunikation |
Utvecklingsplattform | Kollaborationssystem | Kommunikation |
Dokumenthantering | Kollaborationssystem | Kommunikation |
Projekt- och verksamhetsstöd | Kollaborationssystem | Kommunikation |
Onlinemöten | Kollaborationssystem | Kommunikation |
E-post | Kommunikationssystem | Kommunikation |
E-postlistor | Kommunikationssystem | Kommunikation |
Telefoni | Kommunikationssystem | Kommunikation |
Diarie | Arkivsystem | Myndighet |
E-arkiv | Arkivsystem | Myndighet |
Tentaanmälan | Anmälningssystem | Utbildning |
Kursval | Kursvalssystem | Utbildning |
Antiplagiathantering | LMS | Utbildning |
Schemahantering | Schemaläggningsystem | Utbildning |
Digital examinering | Studieadmininstrationsystem | Utbildning |
Studiedokumentation | Studieadmininstrationsystem | Utbildning |
Utbildningskatalog | Studieadmininstrationsystem | Utbildning |
Kursvärderingsunderlag | Studieadmininstrationsystem | Utbildning |
Examenshandläggning | Studieadmininstrationsystem | Utbildning |
Labbanmälan | Studieadmininstrationsystem | Utbildning |
Konto- och livcykelhantering | IAM | Infrastruktur |
...
Infrastrukturarkitektur
...