Inledning

Grundtanken med en metamodell för att uttrycka stadsplanen för ett lärosäte är att skapa ett gemensamt sätt att beskriva arkitekturen för ett lärosäte. Genom att använda metamodellen kommer det vara möjligt att se vilka gemensamma strukturer och komponeter som delas mellan lärosätena. Det går att säga att alla verksamheter kan använda samma metamodell för att uttrycka sin verksamhet. 

När ett lärosäte beskriver sin verksamhet med hjälp av metamodellen kommer det gå att se vilka potentiella samarbeten som finns. Även om fokus för uppdraget är att hitta samarbeten inom IT så behöver IT-stödet sättas i en relation till vilken verksamhet som systemen och infrastrukturen är aktiv inom. 

Funktionella förmågor och tjänsteperspektiv

Förmågor beskriver på en väldigt övergripande nivå VAD en verksamhet GÖR. Detta i motsats till HUR en verksamhet GÖR. HUR beskrivs genom detaljerade processkartor.

För att inte riskera i att hamna i en allt för detaljerad beskrivning av verksamheten har utgångspunkten var att använda funktionella förmågor. När det gäller förmågor brukar det hänvisas till två typer av förmågor:

• Funktionella förmågor
• Framgångsförmågor

Funktionella förmågor har ett intern perspektiv - det är de förmågor som verksamheten har för att få verksamheten att fungera. Genom att beskriva en verksamhet med förmågor och relatera de till vilka tjänser/produkter verksamheten vill exponera internt och extern kan det visa i en analys att vissa förmågor saknas. Framgångsförmågor är externa förmågor som realiseras av de funktionella förmågorna. Ett exempel på Framgångsförmågor är exempelvis "Vi skall bli världsledande inom ....". 

För att realisera en funktionell förmåga krävs ett antal resurser såsom:

• Processer
• Tjänster
• System
• Aktörer
• Artifakter
• IT-komponeter
• mm

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.

Tjänsteperspektivet

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 beskrviningen av ett lärosäte. Tjänster är det som en process eller applikation exponerer utåt genom ett gränsnit. Genom att analysera tjänsterna blir det relatiivt 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. 

Tjänster kan levereras både av processer och av applikationer men också som form av infrastrukturella tjänster. När det gäller applikationstjänster och processtjänster kan man generalisera och säga att det är gränssnitten som skiljer. För processtjänster som inte är automatiserade i ett system är gränssnittet mänskligt medan för processtjänster som är implememterade i ett system är gränsnittet digitalt via en hemsida eller liknande. När det gäller infrastrukturella tjänster är det ngt som användare har ganska svårt att relatera till. Ett tydligt exempel på en infrastrukturell tjänst som användare kommer i kontakt med är sin dator. Med dator som tjänst menas här den fysiska produkten, inte själva användandet av datorn.

Archimate

För att utrycka metamodellen har projektet valt att göra detta med hjälp av modellspråket ArchiMate. Valet att använda ArchiMate är att modellspråket är att ArchiMate är reltivt spritt inom sektorn och att ArchiMate är väl anpassat för att just utrycka en arkitektur.

Archimate är inte avsett att användas som ett komplett verktyg för att uttrycka den kompletta bilden över en verksamhets processer då vissa element saknas. Det går exempelvis inte att uttrycka fysiska produkter såsom producera bilar (med viss fantasi och avvikelse från standarden kan man det) men är ett utmärkt verktyg att uttrycka det informationsbehov som processerna har behov av, vilket är det perspektiv som är väsentligt när det gäller att uttrycka potentiella samarbetsytor inom IT-området. Även inom en verksamhet som levererar fysiska produkter finns det behov av att uttrycka de olika arkitekturerna för att säkerställa att verksamheten har rätt stöd. Det går att visa på att det är produkter som är resultatet av en tillverkningsprocess genom att exempelvis visa det med en händelse - "bil tillverkad". Råmaterial för processen syns inte heller men istället ses materialspecifikationen som en input till processen. Även användandet att tjänster inom verksamheten är också ngt som tydlig kan illustreras.

Avvikelser från ArchiMate specifikationen

I stadsplanen finns det en mjöighet att uttrycka funktionella förmågor som inte är en del av ArchiMate specifikationen. I metamodellen är dessa uttryckta som "Business Function", vilket i specifikationen inte är samma sak. Dock så är egenskaperna på funktionella förmågor av samma typ som "Business Function" i relation till övriga objekt i metamodellen. Därför fungerar "Business Function" att användas som funktionell förmåga. 

Vad är en metamodell

En metamodell är en generell beskrivning på hur olika generiska element är relaterade till varandra. Med hjälp av en metamodell går det att beskriva en specifik implementation baserat på de element, relationer och regler som definieras i metamodellen. Ett exempel på en metamodell är core-concept i modelleringsspråket ArchiMate.

Denna modell kan sedna användas för att beskriva exempelvis hur en specifik process använder/bearbetar informattion och vilken roll som är tillsatt att utföra arbetet. Det är inte säkert att den specifika implementationen använder alla element i metamodellen.

Stadsplanen är en specialisering av den helt generella metamodellen för att beskriva kontexten stadsplan för lärosäte.

Metamodell för stadsplan

Metamodellen för att beskriva ett lärosäte utgår från ett antal arkitekturer. Dessa arkitekturer beskriver hela verksamheten uppifrån förmågor ner till infrastrukturkomponenter. Bilden nedan visar metamodellen i sin helhet. Utöver basarkitekturerna finns även en koppling till mål och krav för verksamheten samt en koppling till kund. Vissa av de begrepp som används i modellen kan verka främmande för den typ av verksamhet som finns inom utbildningssektorn. Exempel kan det verka främmande att uttrycka student som en kund till lärosäte men mönstermässigt så sammanfaller synen på student som en kund till ett lärosäte väl med generella mönster av vad en kund är.

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

Arkitekturer

Inom en verksamhet finns det flera områden av struktur. Dessa områden brukar kallas arkitekturområden. Den som vanligtvis brukar beskrivas är:

• Organisationsarkitektur
• Processarkitektur
• Produktarkitektur
• Förmågearkitektur
• Informationsarkitektur
• Systemarkitektur
• Infrastrukturarkitektur

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

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

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

Informationsarkitektur

Systemarkitektur

Infrastrukturarkitektur

Nivåer

Element i metamodellen

Relationer