• EA (Enterprise architecture) baseras på ett klassiskt ingenjörsperspektiv.
• I de metoder som används är definitioner viktigare än processen.
• Beskrivningssätt (UML-diagram) anpassade för ordnade beteenden i IT-system appliceras på komplexa o-ordnade mänskliga system.
• I tidigare arbeten inom FM framkommer fokus på rationalism, definitioner, ordning och marginalisering av humanfrågor i relation till teknikutveckling.
• Som arkitekturramverk har realiserats inom UK MOD och FM har hitintills fokus legat på beskrivningar. Detta är i sig en klassisk ingenjörsansats som samtidigt effektivt marginaliserar humanfrågor.
• De flesta utvecklingsprocesser som finns beskrivna för EA beskrivs på en så hög abstraktionsnivå att de nästan kan betyda vad som helst. Några enstaka försök har genomförts för att konkretisera dem i praktiskt genomförande. I avsnittet Fallstudie av modelleringsprojekt, sid 44, beskrivs en fallstudie av ett sådant projekt.
ARKITEKTUR
Arkitektur anses handla om ett sätt att betrakta och beskriva helheten. Inom ramen för systemutveckling definieras det som “ett systems grundläggande struktur, uttryckt i dess beståndsdelar, deras relation till varandra och till omgivningen, samt de principer som styr systemets utformning och utveckling over tiden” [65, s. 4]. Till en början applicerades arkitekturbegreppet på systemutveckling, inspirerade av teorier inom byggnadskonst. Enterprise Architecture är en vidareutveckling där perspektivet appliceras på organisationer/verksamheter och omfattar då en verksamhets alla verksamheter,
13
resurser, relationerna mellan dem samt de regler som styrt och styr denna struktur. I detta sammanhang positioneras verksamheten som ett system och förespråkarna anser att alla system har en arkitektur även om den eller delar av den inte alltid är beskrivna. En arkitekturbeskrivning är en produkt och säger i princip ingenting om hur man ska ta fram den, alltså metodaspekten för arbetets genomförande, utan är tänkt att beskriva en viss design av en verksamhet. Detta är en svårighet i relation till humanperspektivet eftersom dessa frågor ofta hanteras genom ett fokus på processer och metoder.
En grundförutsättning inom arkitekturarbete är modellering. Med detta menas att man försöker beskriva verkligheten genom att använda förenklade beskrivningsmodeller.
Inom systemutveckling har UML (Unified Modeling Language) etablerats som en standardnotation för detta. Det består av nio olika beskrivningssätt (“språk”). De vanligaste är klassdiagram, sekvensdiagram och användningsfall. Det är ett klassiskt ingenjörsperspektiv där verkligheten förutsätts kunna beskrivas med hjälp av “boxologi”, dvs. med rutor och relationspilar. Ett stort problem som ofta uppstår med detta perspektiv är att de flesta håller med om att humanfrågorna är viktiga på en principiell nivå men i det praktiska arbetet drunknar frågeställningarna i tekniska specifikationer och modeller [13]. Detta har varit tydligt inte minst inom FM AR-projektet.
De främsta argumenten som förs fram när det gäller arkitekturarbete i olika dokument och framförallt i presentationer är: möjlighet till ökad interoperabilitet i beskrivningar, ökad spårbarhet, förenklad styrning, stärkt kostnadskontroll, ökad effektivitet samt bättre och mer stringenta analysunderlag till beslutsfattare. Man hävdar att det kommer att finnas mätbara effekter. Argumenten hamnar oftast på en hög abstraktionsnivå som är svåra att argumentera emot. De har egentligen inga exempel som visar på att andra har lyckats. I intervjuerna kan inte heller några exempel ges, tvärtom. De har även svårt för att konkretisera hur det ska fungera. Det är intressant att notera i sammanhanget att trots att man i flera år på olika håll inom FM arbetat med arkitekturfrågan så var det först när deltagarna i IML beredningen [46, 47] övertygades som arbetet tog ett stort steg framåt, detta trots att utredningen till viss del är svag och egentligen inte presenterar något som inte var känt tidigare. Det framkommer att detta berodde på interna maktstrukturer.
Utredningen i sig självt är ett exempel på hur sociala faktorer har stor påverkan på beslutsfattande, varför det även är av stor vikt att noggrant beakta hur såväl MbFU och en integrering av humanfrågorna genomförs. Bra förslag i sig självt är inte tillräckligt.
ISO-STANDARDER
Det finns många standarder som behandlar framförallt systemutveckling ur en mängd olika perspektiv. Denna studie har fokuserat på de som återkommande har hänvisats till både av deltagarna i studien och i de dokument som behandlats.
ISO 15288-2008 Systems and software engineering – System life cycle processes ISO 15288 [32] är den standard som mest frekvent refereras till i arkitekturarbetet. Den beskriver systemutveckling ur ett livscykelperspektiv på en hög abstraktionsnivå. Den baseras på tjugosex processer kategoriserade under fyra huvudprocesser: agreement (hanterar beställar-leverantörssituationen), organizational project-enabling (hanterar projektfrågor på strategisk/ledningsnivå), project (hanterar direkta projektfrågor som t.ex.
14
bemanning och riskhantering), technical (hanterar tekniska frågor, t.ex. kravhantering, design, test).
Det betonas att processerna ska användas iterativt så att det blir en progressiv förfining av resultatet [32, s. 14]: “Iteration is not only appropriate but also expected.” Dock finns det inga strukturer som direkt stödjer detta utan modellen är uppbyggd på ett sätt som med lätthet kan användas linjärt. På många sätt påminner beskrivningarna om en traditionell Vattenfallsmodell* och det har visat sig att detta beskrivningssätt är lättast att ta till sig när man utgår ifrån ett rationalistiskt perspektiv.
En viktig sak som många hänvisar till i denna standard är dess definition av system. Den har en relativt omfattande genomgång av systemkonceptet. Den definition som oftast relateras till är sammanfattningen av denna genomgång och då ser den ut såhär:
combination of interacting elements organized to achieve one or more stated purposes [32, s. 6]
Det som återkommande framkommit i intervjuer och på möten är att denna definition inkluderar människan men att så skulle vara fallet är svårt att se endast utifrån den allmänna definitionen. Men i fördjupningsdelen förtydligas det på följande sätt:
these systems may be configured with one or more of the following system elements:
hardware, software, data, humans, processes (e.g. processes for providing service to users), procedures (e.g. operator instructions), facilities, materials and naturally occurring entities.
[…] humans are considered as users and as elements of a system. In the first case the human user is a beneficiary of the operation of the system. In the second case the human is an operator carrying out specified system functions. An individual can be, simultaneously or sequentially, both a user and an element of a system. [32, s. 7]
Standarden relaterar explicit till flera andra standarder som behandlar användbarhet och humancentrering. Dock har inte dessa kopplingar överförts i tillämpningen på FMV eller FM, t.ex. finns det inte med i processwebben mer än i mindre utsträckning och när några respondenter i intervjuerna har tillfrågats om detta så känner de inte till det. De säger sig följa ISO 15288 på en allmän nivå. Troligtvis kommer ISO 15288 att bli en regel i FM AR och projektet ska då ta fram en tillämpningsanvisning för standarden. Det finns dock inte med i den senast framtagna versionen [58].
ISO 42010 Systems and software engineering – Recommended practice for architectural description of software-intensive systems
ISO 42010 [31] är tänkt att facilitera uttryck och kommunikation av arkitekturer för mjukvaruintensiva system. Den utgår ifrån ISO 15288s definition av system vilket implicit förutsätter att systemdefinitionen inkluderar människan. De kallar arkitekturnivån inom systemutveckling för den tidiga perioden av beslutsfattande och
* Vattenfallsmodellen är en linjär systemutvecklingsmodell från 1970-talet där projektet flyttar sig framåt genom att faserna (krav, design, kodning, test, förvaltning) följer på varandra och förändringar kan endast genomföras på den fas man befinner sig i och den som ligger precis innan. Trots att man redan på 1980-talet konstaterade att detta är en mycket ineffektiv utvecklingsmodell, speciellt för interaktiva system, så används den fortfarande i hög utsträckning i framtagningen av nya IS.
15
utvärdering av design. Denna nivå inkluderar övergripande designstruktur, mål, krav och utvecklingsstrategier. Utvecklingen av arkitekturer beskrivs ske evolutionärt på samma sätt som i t.ex. MODAF eller GEAP (se separata beskrivningar under avsnittet Utvecklingsprocesser, sid 31).
Det är flera detaljer som gör att ett tekniskt grundperspektiv ändå skiner igenom, t.ex.
kravet på att det inte får finnas inkonsekvenser mellan olika vyer eller fokus på input/output i det exempel som tas upp [31, s. 11]. I ett socialt system finns det alltid inkonsekvenser [4, 18], en vanlig illustration på detta är förekomsten av ordspråk där man alltid kan hitta två som står emot varandra, t.ex. “för många kockar förstör soppan”
och samtidigt “många händer gör ett lätt arbete”. Inom ramen för tekniska system ligger fokus på att eliminera inkonsekvenser, inom ramen för sociala system ligger fokus på hur man ska hantera inkonsekvenser.
Det framkommer även i relation till den konceptuella modell av arkitekturbeskrivningar som läggs fram, se figur 3. Denna modell skapar en enhetlighet som inte existerar för sociala system. Det finns två grundläggande attribut för mänsklig aktivitet som nästan utesluts i denna modell. Människor återfinns antingen i lådan “Stakeholder” eller i
“System” och de beskrivs ha något (“has” respektive “inhabits”) eller att de adresserar respektive identifierar något. Men det vi människor primärt gör inom ramen för en
Figur 3: Konceptuell modell av arkitekturbeskrivningar enligt ISO42010 [31, s. 5]
16
kommunikationssituation är tolkning. Denna tolkning påverkar i grunden hur systemet ser ut och hur det fungerar. Dessutom baseras denna tolkning på ett sammanhang. I modellen finns “environment” med men det är inte ett tillräckligt koncept för att fånga sociala kontexter.
Figur 4 erbjuder en alternativ beskrivning av mänsklig kognition och kommunikation. En närstudering av den modellen visar att även den är baserad på ett visst perspektiv, i det här fallet en traditionell transmissionsmodell (även kallad överföringsmodell) av kommunikation vilket är en psykologisk teori som många ifrågasätter idag. Det är också intressant att denna modell är betydligt mer komplex än den som återfinns i figur 3 och att figur 3 delvis inbegriper den mer komplexa modellen i figur 4. Den övergripande modellen är alltså mer generell än den undre vilket är typiskt för ett rationalistiskt perspektiv. Risken är att när modeller generaliseras så förenklas de och trots att de innehåller lika mycket information så blir de mindre innehållsrika, vilket kan vara svårt för läsaren att förstå.
TIDIGARE ARBETEN INOM FM
I intervjuer, dokument och på möten finns det ett antal dokument som återkommande refereras till eller bifogas. Fem har valts ut för att belysa vissa perspektiv och mönster som framträder:
• IML beredning FMLS [46, 47] fokuserar på struktur och definitionsproblem och landar i klassiska deterministiska argument där verktyg och modellering i sig självt tros kunna förändra hur människor agerar.
Figur 4: Konceptuell modell av mänsklig kognition och kommunikation [69, s. 9]
17
• DIT04 [64] fokuserar visserligen på hur människor ska agera men inte i relation till den verksamhetsnytta som man förväntas få av IS utan i relation till hur IT-verksamheten ska administreras. Detta landar också i en deterministisk ansats: fokus läggs på att systemen finns, inte hur de tas fram eller används.
• FM Ledsyst mål och riktlinjer [62, 63] visar vissa tendenser på att inkludera humanfrågor på ett initierat sätt men dessvärre finns samtidigt tecken på att det inte har genomförts i det praktiska arbetet.
• Metodhandbok för framtagning av TTEM [36] säger sig i början utgå ifrån en mer komplex syn på humanfrågor men detta återfinns inte i de detaljerade beskrivningar-na för hur det är tänkt att man ska arbeta.
• CIO strategiska dokument [51, 52] tar en ambitiös ansats där man säger sig sätta personalen i fokus. Dessvärre dras inte konsekvenserna av detta. I detaljeringen av mål och vision ligger fokus på teknik och de gånger som humanfrågor inkluderas så görs det generellt på ett oinitierat sätt.
IML beredning FMLS
Syftet med IML beredningens arbete var att beskriva FM behovsbild genom ett antal prioriterade och nedprioriterade behov, ta fram en myndighetsgemensam plan för teknik- och materielförsörjning inom ledningssystemområdet samt skapa förutsättningar för implementering av denna inom respektive myndighet (FM, FMV och FOI) och att omsätta detta i underlag för balansering av MP09. Arbetet skulle även resultera i föreslag på förändringar i ansvarsförhållanden, styrformer och processer.
För att identifiera behov och krav genomfördes en dokumentanalys och man anser sig därigenom lyckats fånga en total bild av de behov och krav som påverkar ledningssy-stemutvecklingen. Styrande och inriktande dokument identifierades och deras innehåll och relationer till andra dokument analyserades. Ett antal dokument valdes ut för djupanalys med hjälp av modellering.
Beredningens resultat handlar mycket om språkbruk, dokumentstruktur och dokumenthantering – dvs. information och kommunikationsfrågor. Styrande dokument var inte konsistenta eller heltäckande sinsemellan. Behovsbilden blir därför svår att överblicka och att kommunicera. Det blir ingen spårbarhet, saker missas, det blir inkonsistens och motstridigheter. Därefter dras slutsatsen att detta kan lösas med ett verktyg som kan ge en överblick av styrande behov och visualisering av förmågor och ska kunna reducera dokumentfloran.
I arbetet med att ta fram behovsbilden används en modellbaserad metod som beskrivs som användbar utan någon tydlig motivering för detta. Ett argument som förs fram är att dagens dokumentbaserade process gör att beslut knyts till vissa individer med en viss kompetens och detta kommer att förändras med en modellbaserad process. Men den vision som framträder i denna studies intervjuer och observationer är att människor nu ska övergå till att modellera vilket kräver att de får kompetens i modellering och att tolka modeller – samtidigt betonas att detta inte gäller alla. Det handlar alltså om en ny slags nyckelkompetens. Det problem som framträder i IML beredningens utredning handlar
18
mest om behovet av att samla information på ett ställe och att göra den tillgänglig. Detta skulle likaväl kunna realiseras genom en databas med bra sökmöjligheter. Varför detta kräver ett helt nytt beskrivningssätt framgår inte. Enkom för att det i en modell står att en viss term ska betyda en viss sak så leder inte det till att det i vardagligt tal och användning kommer att ha den betydelsen – det är få människor som använder en termbeskrivning på det sättet.
Beredningen anser att den främsta nyttan med MbFU är möjligheten till “gemensam datalagring, struktur, konsistens, transparens, spårbarhet och återbruk” [47, s. 9]. En slutsats är att modelleringsverktygen som prövats tillsammans med en gemensam lagringsyta “ger möjlighet att spårbart koppla operativa krav på högsta nivå till taktiska krav i förband, lämpliga förbandsstrukturer och krav på materielsystem för att realisera förmågorna” [47, s. 2]. Detta är ett klassiskt deterministiskt argument, dvs. verktyg och modellering i sig självt kommer att ge detta istället för att det i slutändan realiseras av de människor som ska använda verktygen och metoderna och att det kräver en mer komplex förståelse av kontexten.
DIT04
Direktiv för FMs informationsteknikverksamhet (DIT04) beskriver förutsättningarna för FMs IT-verksamhet, inklusive ansvar och roller. Det handlar om hur IT-verksamheten ska hanteras.
Redan här beskrivs att FM ska arbeta med arkitekturer och arkitekturramverk.
Beskrivningarna av dessa begrepp följer i stort det som återfinns på andra ställen.
Systemdefinitionen följer den generella definitionen i ISO 15288 och skulle därmed indirekt inkludera människan. FM AR ska “tillhandahålla en för FM övergripande och sammanhållen utvecklingsprocess och ett för FM gemensamt sätt att beskriva verksamhet och resurser” [64, s. 13] och man ska ta fram målarkitekturer som beskriver alla de system som sammantaget utgör FM.
Figur 5: FM livscykelmodell enligt DIT04 [64, s. 7]
19
Det finns en livscykelmodell enligt figur 5. Modellen ska stödja evolutionär utveckling genom att delar av faserna kan itereras och att man tar fram prototyper som utvärderas tills kraven anses vara uppfyllda. Men det är skillnad på att stödja och att ställa krav på.
En modern modell borde göra det senare. När man inte gör det explicit tenderar människor att använda det som är bekant och lätt att ta till sig, vilket har visat sig vara den linjära modellen.
En stor del av dokumentet beskriver långsiktiga och kortsiktiga mål och handlingsplaner.
I princip finns det ingenting MSI-relaterat i dessa avsnitt, åtminstone inte explicit.
De roller och ansvar som tas upp är produktägare, produktansvarig, systemägare, funktionsansvarig, designansvarig, driftägare och driftansvarig. Dessa roller fokuserar på formalia som logistik och administration, istället för att säkerställa att IT-verksamheten realiserar verksamhetsnytta. En intressant detalj är att den här versionen av DIT tar bort rollen användare eftersom den inte anses ha en central roll i FMs IT-verksamhet.
Resultatet blir att relationen mellan FMs IT-verksamhet och FMs övriga verksamhet blir otydlig, vilket förstärks när varje roll och ansvar beskrivs på en detaljerad nivå. Här fokuseras vilka dokument som ska tas fram och hur de administrativt ska hanteras.
FM Ledsyst mål och riktlinjer
Inom ramen för transformationen av FM så har Ledsyst-projektet varit en viktig input.
Projektets ansvar är utvecklingen av funktionerna ledning och informationshantering och är uppdelat i tre uppdrag: LedsystT, LedsystM och LedsystP. Dokumentet FM Ledsyst mål och riktlinjer är ett styrdokument för projektet.
I dokumentet beskrivs sex inriktningar: den förenklade hypoteskedjan, arkitektur, nätverksbaserad underrättelsetjänst, effects based operations och stödjande koncept, interoperabilitet, MSI och en modell av ledningssystemet.
Med “den förenklade hypoteskedjan” menas antaganden om hur modern teknik kan möjliggöra hantering av en större mängd information med bättre kvalitet och spridning i organisationen. Trots att hypotesen i sig är deterministiskt lagd så ingår i beskrivningen av hur det ska uppfyllas att man utgår från både tekniska (t.ex. robust, nätverksbaserad informationsinfrastruktur) och mänskliga/sociala faktorer (t.ex. tillit, språk, värdegemenskap, intention). Däremot kopplas inte dessa två aspekter ihop, de behandlas som två separata spår istället för att se hur de relaterar till varandra.
Här beskrivs också att arkitektur är ett viktigt område som man ska utgå ifrån i arbetet.
De har utgått ifrån NATO C3 System Architecture Framework (NAF) och säger sig använda såväl top-down och bottom-up perspektiv för att verifiera och validera sina modeller. Men hur det ska gå till framgår inte.
Det är positivt att MSI har fått ett explicit utrymme. Arbetet med att ta fram de grundläggande antagandena för detta område har genomförts bland annat av MSI-specialister och det finns ett speciellt dokument framtaget som beskriver en strategi för hur dessa frågor ska omhändertas. Dessvärre är det inte troligt att man samarbetat på det viset i sin helhet eftersom MSI-perspektivet saknas på flera ställen där det skulle ha varit relevant, t.ex. i avsnitt 2.3.7 där ledningssystemet definieras som doktrin, organisation, personal och teknik samt beskrivs i termer av en modell där dessa delar är separata moduler och där MSI hade kunnat erbjuda ett sammanbindande perspektiv.
20
Den metod som beskrivs för ledningssystemutveckling fokuserar på en lärandeprocess där man evolutionärt implementerar och utvärderar en design. Det läggs stor tyngd vid såväl aktivt deltagande av brukare som visualisering genom t.ex. demonstratorer och scenarier vilket ligger i linje med MSI-perspektivet. Däremot framgår inte hur de grundläggande MSI-aspekterna som tas upp i avsnitt 2.3.6 ska säkerställas. Evolutionär utveckling och användarinvolvering är inte tillräckligt specifikt, t.ex. har tidigare studier inom FM visat att användarinvolvering ofta begränsas till användarrepresentation vilket är en ineffektiv form av användarsamverkan.
I bilaga 1.1. där målen beskrivs på en mer detaljerad nivå, totalt 150 punkter, återfinns MSI på 5 ställen: MSI-strategi i relation till gemensam lägesbild, designregler för MSI och designförslag för vissa prioriterade tjänster, betingelser för systemanvändning, strategi för MSI-kompetens. Visserligen går det att implicit läsa in MSI-frågor på flera andra punkter men det intressanta är att man i början tar med MSI som ett uttryckligt perspektiv och sedan inte drar konsekvenserna av detta i den detaljerade planeringen. Resultatet blir att MSI i praktiken blir underminerat och osynliggjort; det blir en god ansats som har liten sannolikhet att realiseras i praktiken.
Metodhandbok för framtagning av TTEM
FOI har tagit fram en handbok för ett modellbaserat arbetssätt för framtagning av TTEM. Det betonas att systemutveckling ska ske iterativt och användarcentrerat.
Verksamhetssystemdefinitionen inkluderar följande element: teknik, organisation &
personal, metod. Människan inkluderas i systemdefinitionen, se figur 6, men i beskrivningarna av hur utveckling och kravställning ska gå till så är det ofta oklart om den definitionen verkligen bibehålls. Ofta verkar det troligare att man faktiskt menar tekniskt system och då blir det otydligt vilket fokus den aktuella uppgiften ska ha.
Dessutom ter sig många av beskrivningarna fungera ypperligt för just tekniska system men de kan vara tveksamma om man med system menar den vidare definitionen. Vad
Figur 6: Människan i systemdefinitionen i TTEM handbok [36, s. 13]
21
innebär t.ex. funktionella respektive icke-funktionella krav på mänskliga system [36, s. 17]? Problemet blir att man inkluderar människan i systemdefinitionen utan att dra konsekvenserna av det. Dessutom hanterar inte definitionen interaktionen mellan
innebär t.ex. funktionella respektive icke-funktionella krav på mänskliga system [36, s. 17]? Problemet blir att man inkluderar människan i systemdefinitionen utan att dra konsekvenserna av det. Dessutom hanterar inte definitionen interaktionen mellan