...
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änsertjä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 ....".
...
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 beskrivningen av ett lärosäte. Tjänster är det som en process eller applikation exponerer exponerar utåt genom ett gränsnitgränssnitt. Genom att analysera tjänsterna blir det relatiivt 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.
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 implementerade i ett system är gränsnittet gränssnittet digitalt via en hemsida eller liknande. När det gäller infrastrukturella tjänster är det ngt 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.
...
Traditionell systemförvaltning
Verksamhetsförvaltning av förmågor som alternativ till tradiotionell systemförvaltning
Archimate
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 abstraktionen inte sker på för 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 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 ett antal IT-tjänster finns det en risk att flera verksamhetsområden har återkommande tillämpningar. Eftersom vissa tjänster har andra kunder än själva verksamhetsområdet riskerar exempelvis dessa tjä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.
Verksamhetsförvaltning av förmågor som alternativ till tradiotionell systemförvaltning
ArchiMate
För att uttrycka metamodellen har projektet valt att göra detta med 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 relativt spritt inom sektorn och att ArchiMate är väl anpassat för att just utrycka uttrycka en arkitektur.
Archimate 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 något som tydlig kan illustreras.
...
I stadsplanen finns det en mjöighet 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.
...