...
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.
Figur 2 ArciMate v2.1 Core Model
Denna modell kan sedan användas för att beskriva exempelvis hur en specifik process använder/bearbetar information 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.
...
Dessa arkitekturer beskriver hela verksamheten uppifrån förmågor ner till infrastrukturkomponenter. Bilden nedan visar metamodellen i sin helhet. En större bild finns i som bilaga på sid 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.
Metamodellen alla arkitekturer visas nedan.
Figur 3 Metamodellen i sin helhet. Metamodellen finns i större format i bilaga 1 på sid
Inom varje arkitektur och i samband mellan arkitekturerna 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.
...
Genom att beskriva verksamheten i termer av funktioner är det inte nödvändigt att detaljera innehållet helt utan det räcker med en övergripande beskrivning av funktionen. 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 (3–4 halvdags fokuserade workshoppar med erfaren facilitator) att skapa en modell över funktionerna inom ett lärosäte. Efter att en modell över funktionerna ä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.
Bilden nedan illustrerar en hypotes till funktionskarta som visar funktioner på översta nivån som är aktiv inom högskola- och universitetssektorn. Nivåerna är ett sätt att succesivt öka detaljeringen av funktionerna, där nivå 1 är den högsta nivån och nivå 4 är den lägsta nivån av detaljering inom ramen för metamodellen En mer detaljerad beskrivning av nivåerna finner läsaren i ett senare kapitel på sida . En funktionskarta för nivå 1 och nivå 2 finns i bilaga på sid :
Figur 4 Förslag på funktionskarta nivå 1
En bra post om funktioner (Business Capabilies) finn på:
On Business Capabilities Functions and Application Features
...
En applikationstjänst (AT) kan användas av många verksamhetsförmågor (VF). Ibland används termen IT-tjänster för applikationstjänster och det förekommer även att IT-tjänster används för verksamhetstjänster som levereras av IT. Därför används endast applikationstjänster (AT) och verksamhetstjänster (VT) inom ramen för detta arbete.
Exempel på en sammanblandning av tjänst begreppet är inom Nya Ladok. Där används termen verksamhetstjänster för produkten Ladoks applikationstjänster. Dessa tjänster representerar givetvis det behov verksamheten har men i metamodellen sorteras de under Applikationstjänster som stödjer en eller flera funktioner. Exempelvis så stödjer Nya Ladoks tjänster olika funktioner inom studieadministrativa funktionen.
Att utgå från tjänster för att beskriva en stadsplan är på samma sätt som att använda funktioner 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 de tjänster som funktionerna realiserar.
Vissa IT-tjänster har ingen motsvarande verksamhetstjänst utan finns bara för att "hjälpa" andra IT-tjänster. Ett exempel på detta är en integrationsplattform som levererar en IT-tjänst som konsumeras i en integrationskontext.
Tjänster kan levereras av såväl aktörer och processer som av applikationer men också i 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 implementerade i ett system är gränssnittet digitalt, exempelvis en hemsida eller liknande. När det gäller infrastrukturella tjänster är det något 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.
För att visa hur tjänster förhåller sig till processer och applikationstjänster kan följande bild vara hjälpsam:
Figur 5 Hur verksamhetstjänster och applikatuionstjänster samverkar
Det är alltså funktionera som realiserar verksamhetstjänsterna (VT), och funktionen (VF) använder sig av IT-tjänster (PT & RT, båda är applikationstjänster, AT) för att göra realisationen. Processerna (VP) använder sig sedan av VT för att skapa en värdekedja. En "(N4) Aktivitet" (VA) som realiserar en VT kan ses som ett specifikt implementerat beteende i en funktion.
Figur 6 Både funktion och process kan realisera tjänster men med olika innebörd
I bilden ovan kan realisationsrelationen mellan verksamhetsaktiviteten och verksamhetstjänsten härledas genom att process är en aggregering av funktion som i sin tur realiserar tjänsten. I ArchiMate kallas det för en "derived" relation. Även om relationen går att härledas behövs en tolkning av den relationen och definiera vad den betyder. Bilden ovan försöker göra en sådan definition.
En funktion på verksamhetsnivå exponerar sin funktionalitet via egna verksamhetstjänster. Dessa verksamhetstjänster kan användas av andra verksamhetstjänster på olika sätt. En eller flera verksamhetstjänster kan till exempel koreograferas av en eller flera andra verksamhetstjänster.
Figur 7 Tjänster som koroegraferas för att realisera en annan tjänst
En funktionalitet på applikationsnivå exponerar sin funktionalitet via egna applikationstjänster. Dessa applikationstjänster kan användas av andra applikationstjänster på olika sätt. En eller flera applikationstjänster kan till exempel koreograferas av en eller flera andra applikationstjänster.
...
Med applikations 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 i idealarkitekturen endast ha en tillämpning som realiseras av en mjukvara. Givetvis är det inte möjligt i alla fall men det 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å vilken mjukvara som används. Det kan vara så att två lärosäten använder samma mjukvara men med olika tillämpning. Ur ett samarbetsperspektiv blir det svårare att hitta gemensamma samarbetspunkter alternativt går det att hitta nya sätt att använda mjukvaran på. En lista på förslag av tillämpningar finns som bilaga på sid
Oavsett om arkitekturen definierar tillämpningar behövs ibland en övergång från tillämpningen till den fysiska representationen av tillämpningen. I synnerhet när lärosätet skall titta på integrationer och informationsflöden mellan fysiska "system". I arbetet med att titta på LiUs "Min-IT" blir det tydligt att det är nödvändigt att gå över i ett perspektiv som beskriver den fysiska lösningen. Dock så ger möjligheten att se att det finns återkommande produkter som samma tillämpningar. Bilden nedan är ett försök att visa detta:
Figur 15 För att koppla från tillämpning till fysisk nivå kan specialisering användas
Detta ger en möjlighet att hitta "onödiga" komponenter, dock behövs detta brytas ner i applikationsfunktioner för att verkligen se om alla fysiska instanser är nödvändiga. Det kommer definitivt finnas överlapp i funktionalitet men att detta kan vara nödvändigt då infrastrukturella egenskaper kräver redundans. Ett enkelt exempel är funktionaliteten att identifiera en användare genom autentisering. Både AD (Active Directory) och AAD (Azure AD) har denna funktionalitet. Dock så skiljer egenskaperna på infrastrukturtjänsterna – den ena gör autentisering "On Site" den andra i molnet (Azure). Så finns verksamheten i molnet måste både infrastrukturtjänsterna existera.
En bild att försöka illustrera detta:
Figur 16 AAD tillhör Azure och AD tillhör lokalt. Båda behövs om verksamheten finns lokalt och i molnet.
Tidigare i rapporten har det tryckts på att informationen i verksamheten måste vara entydigt definierad för att kunna stödja digitaliseringsarbetet. Det kan vara lämpligt att övergripande titta på vilka tillämpningar som utbyter information. Eftersom det finns flera komponenter i infrastrukturen som realiserar de olika tillämpningarna betyder det att antalet integrationer blir fler än de som syns i applikationsarkitekturen när endast tillämpningen beaktas. Dock så visar modellen att informationsmängderna i de olika fysiska komponenterna behöver definieras på samma sätt. Detta är ett sätta att beskriva skillnaden mellan logik och infrastruktur. Exempelvis om lärosätet har definierat att integration skall ske genom meddelandeintegration så skall varje nod i infrastrukturen överföra meddelande mellan varandra. Dessa meddelanden innehåller data som representerar informationsmängden som skall föras över. Modellen nedan är ett sätt att minska komplexiteten på applikationsnivå men samtidigt kunna spåra hur många integrationer (transporter) som måste till för att lösa överföringen av information.
Figur 17 Flera noder realiserar samma tillämpning men informationsbehovet på tillämpningsnivå är samma, vilket leder till fler transporter än det som syns i applikationsarkitekturen
Modellen ovan kan vara abstrakt att förstå och kanske inte är användbar i verkligheten, men författaren tycker det hjälper till att förstå skillnaderna mellan ArchiMate applikationsnivå mot infrastrukturnivån.
...