Informationsarkitektens plats bland andra arkitektroller

Informationsarkitekt, verksamhetsarkitekt, it-arkitekt, enterprisearkitekt – i många organisationer finns flera arkitektroller som delvis överlappar varandra. I den här artikeln resonerar jag om hur rollerna kan förstås i förhållande till varandra, och varför informationsarkitektur bör ses som ett eget specialiserat kompetensområde.

Behöver vi verkligen en särskild arkitektroll för informationsperspektivet?

Vi har under ett antal år sett ett ökat intresse för att arbeta med data, information, begrepp och termer i våra organisationer. Det gläder oss på IRM som grundades för 44 år sedan med ett fokus på att utveckla informationshanteringen i landets verksamheter. IRM står för Information Resource Management och är ett företag som ägs av oss anställda.

För fem år sedan, 2021, tyckte vi att det var dags att reagera på det nyväckta intresset. Vi påbörjade då det stora arbetet med att ta fram vår nya utbildning Certifierad Informationsarkitekt. Samtidigt lanserade vi den artikelserie om informationsarkitektur där du nu läser den 128:e artikeln. Året därpå, 2022, kunde vi ta emot den första kullen deltagare, och 2023 startade vi Nätverket för informationsarkitektur, NIA.

Men en del har nog undrat: Behöver vi verkligen ännu en arkitektroll i våra organisationer? Har det inte gått inflation i arkitekttitlar? Tillgodoses inte arbetet med data, information och begrepp redan av de roller vi har?

Den invändningen tycker jag emellertid att vi redan bemött genom artikelserien, där vi visat hur omfattande kunskapsområdet faktiskt är. Det är fortfarande få som har både kunskap och erfarenhet inom området, samtidigt som behoven är stora i de flesta organisationer. Det finns således mycket att göra.

Men en fråga har vi kanske inte pratat om tillräckligt: Hur kan vi egentligen positionera rollen informationsarkitekt i förhållande till andra arkitektroller? Jag vill här ge min syn på detta.

Rollens ursprung och namn

Det första man behöver veta om rollen informationsarkitekt är att den inte är något vi själva hittat på. Rollen har sitt ursprung redan i början av 1970-talet. Då var fokus visserligen främst databaser och databasdesign.

Med tiden har rollen utvidgats till all slags definition, kartläggning och strukturering av data. Ja inte bara data i sig utan också själva verksamhetsdomänen, alltså de företeelser som dessa data representerar. Och därmed det viktigaste: benämningar och definitioner för verksamhetens begrepp. Allt det som bygger organisationens gemensamma förståelse och gemensamma språk.

Men vi behöver också klara ut ett par saker om själva titeln informationsarkitekt.

• Det som i övriga världen vanligtvis kallas data, det vill säga information i strukturerad form har vi i Sverige sedan 70-talet ofta valt att kalla information. Vi har velat markera att det viktiga inte bara handlar om datastrukturen utan den information som dessa data bär och förmedlar. Därför översätter vi den engelska titeln Data Architect till Informationsarkitekt.

Se artikel: ”Data” eller ”Information”

• Termen informationsarkitekt (Information Architect) används också för en annan roll, som uppstod betydligt senare, år 1998. Då handlade det om en specialisering av UX-området, med fokus på att strukturera information på webbplatser och i andra presentationsgränssnitt. Den rollen berör vi inte här.

Se artikel: Informationsarkitekter: De två kulturerna

Ska vi diskutera befattningsroller eller kompetensroller?

Innan vi kan diskutera roller behöver vi besvara en grundfråga: Vad menar vi med roll i detta sammanhang?

Vi behöver skilja på det jag vill kalla för kompetensroller och befattningsroller. Alltså mellan kompetenser man tillgodogjort sig genom utbildning och praktik, och de befattningar eller titlar man kan ha i organisationer. Det är inte riktigt samma sak.

För att illustrera skillnaden kan jag nämna att jag är sjökapten. Det är faktiskt sant. Jag har utbildning och praktik som ger mig den behörigheten enligt svenska bestämmelser. Det är alltså en kompetensroll. Jag har ett behörighetsbevis utfärdat av Sjöfartsverket, vardagligt kallat sjökaptensbrev. Det är ett intyg på en kompetens.

Men det var mycket länge sedan jag hade en befattning som krävde denna behörighet. Och även när jag arbetade till sjöss kunde det handla om olika befattningar, inte bara den som landkrabbor brukar kalla ”kapten på båten”, alltså fartygsbefälhavare. När jag arbetade på dykerifartyg på oljefält krävdes till exempel sjökaptensbehörighet av samtliga styrmän. Jag har också varit befälhavare på fartyg där det bara krävdes styrmansbehörighet.

På samma sätt fungerar det inom många andra områden. Kompetens eller behörighet är en sak. Befattning är en annan, även när de råkar ha samma eller snarlika namn.

De som går vår utbildning till informationsarkitekt gör det inte alltid för att jobba i en befattning med just det namnet. Kompetensen är användbar även i andra roller. Och alla som arbetar som informationsarkitekter i organisationer har inte heller gått vår utbildning eller motsvarande.

Jag tycker därför att det är mest intressant att diskutera kompetensroller. Vad man sedan har för befattning i sin organisation och vad den råkar kallas kan vara mer av en tillfällighet. Det är därför kompetensroller som denna artikel handlar om.

Hur kan vi se på hela landskapet av arkitektroller?

För att kunna positionera rollen informationsarkitekt bland andra arkitektroller inom verksamhet och it behöver vi först försöka beskriva i vilka dimensioner vi behöver särskilja rollerna.

Jag tycker att det är belysande att tala om två huvudsakliga dimensioner då det gäller arkitektroller. Den första handlar om hur mycket rollen fokuserar på informationsteknik i sig eller på verksamheten i ett bredare perspektiv. Vissa frågor är huvudsakligen tekniska, medan andra handlar mer om verksamhetens arbetssätt, struktur, begrepp etcetera.

 

Den andra dimensionen handlar om hur starkt kompetensen är orienterad mot övergripande strategiska perspektiv, eller mot enskilda utvecklingsinitiativ och lösningar. Detta gäller oavsett om fokus främst är riktat mot it eller övrig verksamhet.

På så sätt får vi en tvådimensionell modell, med en x- och en y-axel där vi kan placera in olika arkitektroller.

Varje roll får då ett område som beskriver var dess huvudsakliga tyngdpunkt ligger. Dessa områden ska dock inte ses som staket som inte ska överträdas, utan snarare en indikation på var man kan förväntas ha sin tyngsta kompetens. Ty enskilda individer har ofta både större bredd och djup än vad själva rollen antyder.

Låt oss nu titta på hur olika roller kan placeras i grafen. Se detta som min input till en fortsatt dialog.

It-arkitekt

En it-arkitekt har vanligen en kompetens som främst fokusera på utveckling av specifika it-lösningar.

En del vill kanske invända mot denna avgränsning och mena att en it-arkitekt också måste förstå verksamhetens behov. Det är sant. Men det är inte den förståelsen vi innefattar här, hur viktig den än är.

Det vi vill markera är vad som är rollens direkta mål, alltså vad rollen primärt syftar till att utveckla. Verksamhetens sätt att fungera är en input till it-arkitekturen, men inte det direkta utvecklingsobjektet för just den rollen.

Det engelska namnet på rollen är IT Architect.

Enterprisearkitekt (i betydelsen EWITA, Enterprise-wide IT Architecture)

Termen Enterprisearkitekt (Enterprise Architect) har tyvärr kommit att användas i två olika betydelser. I den ena betydelsen har rollen, liksom it-arkitekten, fokus på teknik, fast mer övergripande, för en hel verksamhet eller för en större del av den.

Detta var egentligen inte rollens ursprungliga innebörd så som den formulerades av John Zachman, som såg rollen som bredare, omfattande både verksamhet och it.

 

De som förespråkar att termen enterprisearkitekt ska stå för denna urspungliga bredare roll brukar kalla den mer avgränsade rollen för EWITA, (Enteprise-wide IT-architecture). Alltså it-arkitektur på en verksamhetsövergripande nivå.

Men i vilket fall, trots namnförvirringen är enterprisearkitekt i betydelsen EWITA en roll som både finns och sannolikt behövs. Kompetensen är fokuserad på att ta fram och följa upp strategier och roadmaps för hela it-miljöer. Det kan handla om plattformsval, integrationsstrategi, molnstrategi och teknikstrategi för AI.

Även i denna roll är verksamhetens behov och sätt att fungera av största betydelse. Men inte heller här är verksamheten det direkta arbetsobjektet för själva rollen.

Verksamhetsarkitekt

En verksamhetsarkitekt förväntas ha kompetens och erfarenhet för arbete som fokuserar på hur funktioner, tjänster, roller, processer, värdeflöden, begrepp, språk, information och informationssystem ska samverka inom och mellan verksamheter.

Arbetet kan handla både om enskilda utvecklingsinitiativ och om mer verksamhetsövergripande frågor.

Rollen förutsätter normalts inte någon djupare teknisk specialistkompetens.

Den engelska motsvarigheten, utifrån hur rollen vanligen definieras, är Business Architect.

Vad är samlingsnamnet för alla dessa arkitektroller?

Det återstår att ge hela kunskapsområdet ett samlingsnamn. Vi behöver ju som grupp kunna skilja ut oss från ”riktiga” arkitekter, alltså de som designar byggnader, inredning, trädgårdar eller landskap.

Det har funnits tendenser att använda ”it-arkitektur” som det övergripande namnet för alla våra arkitektroller, men jag tycker det blir missvisande. Alla våra roller handlar ytterst om verksamheter som helhet, oavsett vilka olika specialiseringar vi råkar ha.

Verksamheten som helhet är alltid det övergripande målet, även om vi behöver roller med olika fokus och orientering.

Namnet verksamhetsarkitektur hade egentligen kunnat fungera bra som samlingsnamn, om det inte redan vore etablerat som beteckning för en mer specifik inriktning.

Jag tycker därför att Enterprisearkitektur (Enterprise Architecture) hittills är det bästa samlingsnamnet. Men då måste vi vara tydliga med att vi menar begreppet i dess ursprungliga och breda betydelse, och inte den mer avgränsade variant som här kallats EWITA.

Jag har försökt introducera en svensk översättning: Företagsarkitektur. Det har dock stupat på att många uppfattar ordet företag som begränsat till kommersiella organisationer. Egentligen är det inte så. Enterprise och företag har i sin grundbetydelse ungefär samma innebörd: människor är organiserade för att åstadkomma något tillsammans, oavsett organisationsform.

Om vi tills vidare kan ducka för problemet med svensk översättning och sammanblandning med EWITA, så kanske ”Enterprisearkitektur”, ändå är den mest praktiska lösningen på problemet med ett samlingsnamn. Då blir vi alla enterprisearkitekter, med olika specialiseringar.

Detta kan jämföras med andra yrkesroller, till exempel läkare. Alla läkare har en gemensam profession som grund, men kan sedan ha mycket olika roller, både vad gäller kompetens och befattning.

Specialiserade arkitektroller

Den indelning vi hittills diskuterat skiljer bara på de två tidigare dimensionerna. Vi har ännu inte tagit hänsyn till arkitektroller som är specialiserade på särskilda aspekter av verksamheten, som till exempel affär, infrastruktur eller säkerhet.

För att beskriva detta behöver vi tänka oss ytterligare en dimension i modellen, en z-axel som går ortogonalt mot de två andra axlarna, alltså ut ur eller in i papperet som den tvådimensionella grafen är ritad på.

Denna tredje dimension fungerar dock inte som en gradient, alltså inte som en gradvis ökning eller minskning av något, på samma sätt som x- och y-axlarna. I stället kan vi se modellen som ett antal skivor staplade bakom varandra, där varje skiva representerar ett specialiserat arkitektområde.

Samtidigt är dessa specialiseringar inte alltid kompletta ”skivor”. De kan själva vara begränsade både vad gäller teknikfokus och hur strategiskt orienterade de är.

Affärsarkitektrollen är ett exempel. Den är främst orienterad mot strategiska frågor kring verksamhetens affär, det vill säga de existentiella frågorna: Vilka är vi? Vilka finns vi för? Vad behöver dessa parter? Och hur når vi dem? Rollen blir därmed mer koncentrerad på affärsutveckling än på den mer handfasta verksamhetsutveckling som sker i utvecklingsinitiativ, där vi oftare återfinner de mindre specialiserade verksamhetsarkitekterna.

Säkerhetsarkitektens roll bör däremot vara betydligt bredare. Den behöver sträcka sig från strategi till genomförande och omfatta både teknik och verksamhet i övrigt.

Informationsarkitekt

Det behövdes en lång inledning för att måla upp själva frågeställningen. Nu blir svaret ganska kort:

Som informationsarkitekt har du en kompetensroll som en specialiserad verksamhetsarkitekt.

En informationsarkitekt är någon som har kompetens att arbeta med data, information, begrepp och språk. Rollen sträcker sig över verksamheten och en bit in i teknikdomänen. En informationsarkitekt behöver, enligt min mening, vara starkt praktiskt orienterad, det vill säga djupt involverad i utvecklingsinitiativ och dagligt förändringsarbete, men kan också kompletteras med en mer strategisk inriktning.

Om vi i stället pratar om informationsarkitekt som befattningsroll så får personen ofta en nyckelroll i arbetet med att bygga upp och vidareutveckla organisationens arbetssätt för data- och informationsförvaltning. Det är i dataförvaltningsgänget man behöver tillbringa sin tid och vara djupt delaktig i arbetet med data, information, begrepp och språk.

Se artikeln Vilken roll har informationsarkitekten i verksamheten

I en annan artikel resonerar vi mer praktiskt om var informationsarkitekten kan höra hemma organisatoriskt – på verksamhetssidan, it-sidan, i arkitektteamet eller nära dataförvaltningen.

Se artikeln Var i organisationen hör en informationsarkitekt hemma?

Så kan man alltså resonera kring detta.

Om du vill ha en dialog om dessa frågor, eller om arbetet med att bygga upp dataförvaltning och informationsarkitektur, är du varmt välkommen att höra av dig!