Definitionen av verksamhetsarkitektur

Det finns många definitioner av vad verksamhetsarkitektur är. I stället för att återge någon av dem så ska vi i stället beskriva begreppet utifrån dess historia och frågan varför man valt att låna begreppet “arkitektur”.

Lånet skedde ursprungligen under slutet av 1950-talet och användes då inom design av datorer för att beskriva den uppsättning instruktioner som en “familj” datorer använde. Ett program kunde vara skrivet för en viss arkitektur och var då körbart på samtliga varianter av datorer inom familjen. Detta är dock en betydelse som är rätt fjärran dagens bruk av begreppet.

Ett drygt årtionde senare började de som var med om att mynta begreppet “datorarkitektur” att tala om “mjukvaruarkitektur” som den fullständiga beskrivningen av ett användargränssnitt. Han liknande systemarkitekten vid byggnadsarkitekten som ställföreträdare för byggnadens “användare”, vars ansvar det är att engagera olika kompetenser i användarnas intresse, och skapa ett system som är anpassat för dem. Åven detta är en användning som skiljer sig från dagens.

Dagens användning av “mjukvaruarkitektur” har mer att göra med ett systems insida, även om insidan reflekterar utsidan (och vice versa). Den är ett resultat av att datasystem blivit större och mer komplexa och programmeringsspråken i takt med detta blivit mer inriktade på att strukturera systemens källkod. Med “mjukvaruarkitektur” avses en beskrivning av ett system på en övergripande nivå, som åskådliggör ingående komponenter samt relationerna och samspelet dem emellan.

Begreppet “verksamhetsarkitektur” kan sägas ligga en nivå över mjukvaruarkitektur och där den senare används för att beskriva samspelet mellan komponenter inom ett system beskriver en verksamhetsarkitektur samspelet mellan system inom en verksamhet, eller till och med mellan verksamheter.

Men varför tyckte man ursprungligen, för snart 50 år sedan, att “arkitektur” var ett lämpligt beskrivande begrepp att låna till området datordesign? Varför “arkitektur”?

Svaret på den frågan är att det är grundat på en naiv uppfattning om vad arkitekter gör och vad arkitektur är (den som rör byggnader). Arkitekter ritar byggnader. De producerar ritningar och räcker över dem till bygglaget, som sedan ser till att byggnaden blir verklighet. Arkitekturarbetet är någonting som sker före byggnadsarbetet. När det väl påbörjats är det försent att göra annat än förändringar av detaljer i ritningarna, av arkitekturen. Då är det försent att göra övergripande förändringar.

I takt med att datasystem blivit större och ökat i komplexitet så har förutom anpassningar av programmeringsspråken efter denna trend även sättet att genomföra utvecklingsprojekt förändrats. Olika metoder har prövats och de som har varit dominerande sedan 1970-talet har varit sekventiella. Gemensamt för dem har varit att man inleder med analys, följt av design och implementering, och till sist test och leverans. Ett projekt har setts som bestående av ett antal faser, vilka genomförs i tur och ordning.

Med detta sätt att se på utvecklingsprojekt är det lätt att förstå hur liknelsen med arkitektur fått fäste. De inledande faserna rör planering och de resulterar i en plan för det som ska implementeras, eller en “ritning” över det som ska “byggas”. De senaste fem åren har inneburit en trend mot iterativa och inkrementella metoder. Då utför man i ett antal kortare tidsintervall, så kallade iterationer, analys och design, implementering och test, varpå iterationen avslutas med en leverans av ett fungerande system. Men projekten måste ändå inledas med någon sorts övergripande design, en arkitektur. Och när projekten genomförs iterativt måste arkitekturen dels lämna öppet för respektive iteration att påverka designen, dels begränsa designen så att systemets övergripande design förblir en helhet.

Så för att summera: begreppet “arkitektur” har lånats till IT-området baserat på en naiv föreställning om det som är byggnadskonsten och har kommit att betyda “en övergripande plan eller beskrivning för ett datasystem”. När datasystemen började kommunicera utåt i högre grad, till andra avdelningar och till andra verksamheter, uppstod behovet att tala om den övergripande planen för hela verksamheten eller den verksamhetsöverskridande samverkan, varpå begreppet “verksamhetsarkitektur” myntades.