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 komponenter 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. 

ArchiMate 3.0

En ny version av specifikationen av ArchiMate har precis publicerats. I 3.0 så har ytterligare element samt lager lagts till. Vissa förändringar när det gäller relationer mellan lagren tillåts numera i större utsträckning. I Archimate 3.0 finns också "Capability" elementet vilket kan tolkas både som en funktionell förmåga och en framgångsförmåga beroende på i vilket perspektiv den används. I Metamodellen kommer "Business Function"-elementet att bytas ut mot ett "Capability"-element på sikt. Vidare anpassningar till ArchiMate 3.0 i metamodellen kommer att genomföras på sikt.

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äntser/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 ....". 

En förmåga kan inte själv skapa ett resultat utan det krävs andra komponenter för att förmågan skall kunna leverera ett resultat i verksamhetensåsom:

• Processer
• Tjänster
• System
• Aktörer
• Artifakter
• IT-komponenter
• 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. 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 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. 

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 komsumeras 

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 implementerade i ett system är gränssnittet digitalt 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 processimplementationen och IT-implementationen så kan följande bild vara hjälpsam:

Det är alltså Förmågorna som realiserar verksamhetstjänsterna, VT, och Förmågan använder sig av IT-tjänster för att göra realisationen. Processerna använder sig sedan av VT för att skapa en värdekedja.

En förmåga 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.

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.

En applikationstjänst kan användas av många verksamhetsförmågor. 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 och verksamhetstjänster inom ramen för detta arbete.

Inom Nya Ladok används termen verksamhetstjänster för produkten Ladoks applikationstjänster.

Traditionell systemförvaltning

Inom traditionell systemförvaltning delas ofta verksamheten in i ett antal verksamhetsområden såsom:

• Ekonomi
• Utlbildningsstöd
• E-kanaler
• Infrastruktur
• Uppföljning
• Studieadministration

Till dessa områden kopplas sedan ett antal system. Detta är i och för sig en naturlig och logisk indelning av systemen. Varje system får en tydlig ägare och de olika verksamhetsområdena får kontroll över sina system och kan anpassa dessa till sin verksamhet. Varje verksamhetsområde ansvarar för att ta fram en handlingsplan för förändringar inom systemen. Varje verksamhetsområde har ofta en tilldelad budget som området agerar inom.

Men eftersom fokus inte ligger på vilka tjänster systemen erbjuder till verksamheten riskerar verksamheten identifiera sin verksamhet helt utifrån "sitt" system. Det blir systemet som definierar vad verksamheten gör till stora delar och varje verksamhetsområde optimerar systemet utifrån sitt område. Detta fungerar relativt bra när verksamhetsområden är väl avgränsade, såsom ekonomi, utbildningsstöd etc.

Ett av målen med en arkitektur är att optimera antalet tillämpningar som finns inom arkitekturen. Eftersom varje verksamhetsområde ser systemet som en helhet och inte vilka tillämpningar som sedan realiserar av ett antal applikationstjänster finns det en risk att flera verksamhetsområden har återkommande tillämpningar. Eftersom vissa applikationstjänster har andra kunder än själva verksamhetsområdet riskerar exempelvis dessa applikationstjänster att bli optimerade efter verksamhetsområdet snarare än de som skall använda tjänsten.

För samverkanstjänster såsom teknisk integration sker gärna dessa inom verksamhetsområdet och är ofta optimerade utifrån verksamhetsområdet snarare än hela verksamheten.

Vi förändringar av arkitekturen, såsom byte av system, sker det ofta som en detaljerad kravställning på hur verksamheten arbetar i systemet. Detta leder ofta till ett massivt arbete på att beskriva flöden i systemet snarare än vilka verksamhetstjänster och information som krävs för att verksamheten skall fungera. Detta leder till samma verksamhetsimplementation, fast med ett annat namn på systemet.

En annan svårighet som ges av att förvalta system är masterdatahanteringen. Eftersom varje system innehåller en mängd data som skulle kunna vara masterdata finns det en risk att samma data finns i ett eller flera andra system. Det finns ofta ett ganska litet incitament att tydliggöra vilken av dessa datamängder som skall vara master beroende på att det påverkar systemet att göra en förändring. Genom att identifiera att masterdata ligger i ett annat system innebär också en ökad komplexitet inom det förvaltade systemet eftersom masterdata måste hämtas från ett annat system. Dock så är vinsten stor då all data är korrekt och uppdaterad.

Verksamhetsförvaltning av förmågor som alternativ till traditionell systemförvaltning

Eftersom ett system kan ha flera tjänster som kan användas av flera verksamhetsförmågor blir det problematiskt med styrningen på systemnivå kopplat till ett verksamhetsområde. De verksamhetsområden som ofta finns definierade i en förvaltningsmodell är inte helt olikt förmågor men den stora skillnaden är att det ofta finns en organisatorisk koppling till verksamhetsområdet men inte till förmågorna. Dock så finns det fler förmågor än vad som brukar definieras som förvaltningsobjekt. Dessutom blir kopplingen till delar av verksamheten som inte riktigt passar in i de klassiska förvaltningsobjekten tydligare om dessa kopplas till förmågor istället. Det representerar bättre vad fokus skall ligga på inom verksamheten. Ett bra exempel på detta är verksamhetsområdet som brukar kallas infrastruktur. Detta område brukar innefatta allt från integration till andra infrastrukturella tjänster såsom; sök, autenticeringstjänster och katalogtjänster men även tjänster som inte syns i verksamhetsperspektiv såsom backup och andra infrastrukturella plattformar. Istället föreslås exempelvis integrationer att styras från en förmåga istället - samverkan. Samverkan har hand om all samverkan inom lärosätet och inte bara tekniks integration. Detta sätter agendan för vad teknisk integration handlar om, nämligen att samverka så att verksamheten får det informationsstöd som verksamheten behöver för att fungera. När det gäller katalogsystemen blir förvaltningen mer komplex eftersom den borde styras från flera förmågor istället baserat på tjänster och information som tjänsterna hanterar. Detta exemplifieras nedan.

Ett bra exempel på när det uppstår problem när förvaltningen styr ett system är när delar av systemet innehåller information som stödjer flera verksamhetsområden och har tjänster som nyttjas av flera områden. Exempelvis äger HR ofta linjestrukturen för en verksamhet men själva HR-systemet klarar inte av att uttrycka en hierarki för linjen. Det brukar reslutera att denna information läggs i ett annat system som kan uttrycka det. Detta system kan även innehålla annan information om verksamheten men som inte är relaterad till linjestrukturen. Det resulterar i en komplex förvaltningssituation där ett annat verksamhetsområde förvaltar ett system som en annan del av verksamheten har behov av att styra. Förslagsvis bör systemen brytas ner i tjänster som används av förmågor och den förmåga som ansvarar för informationen som bearbetas inom tjänsten förvaltar också tjänsten. Det betyder att ett system kommer att förvaltas av flera förmågor, men tjänsterna och inforamtionen förvaltas av en förmåga. Detta leder till tydlighet i hur information förvaltas och att de tjänsterna får en mer korrekt styrning utifrån behovet i verksamheten.

ArchiMate

För att uttrycka 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 relativt spritt inom sektorn och att ArchiMate är väl anpassat för att just uttrycka 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å något som tydlig kan illustreras.

Avvikelser från ArchiMate specifikationen

I stadsplanen finns det en möjlighet 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

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.

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:

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.

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.

Element i metamodellen

Relationer