Informationsarkitektur – ”To make sense of any mess”

Ett försök att ringa in vad det handlar om.

Jag och mina kollegor är informationsarkitekter. Vi tar uppdrag där man vill ha hjälp med att få koll på verksamhetens data och dess struktur. Det här är ett försök att ringa in vad det handlar om.

När efterfrågas en informationsarkitekt?

De flesta organisationer hamnar förr eller senare i ett läge där man inte har så bra koll på sina datamängder som man behöver. Problemen kommer smygande och accelererar. Tyvärr sker tillvänjning parallellt, och det är svårt att få till kraft att ta tag i saken. Det är svårt att motivera ledningen att satsa på något så föga hajpat, något som i bästa fall ger ett resultat som ser ut som status quo. Att bara städa upp i det befintliga när det finns nya spännande tekniker och affärsmöjligheter.

Man har dragit på sig något som kan liknas vid en teknisk skuld, men som borde kallas verksamhetsskuld. Hur stor en verksamhetskuld är kan bedömas av frekvensen av ”What the F—k” som hörs närhelst man behöver rota i kökkenmöddingen av begrepp och data. 

Triggers

Vanligen är det något annat som triggar till handling, så att man kallar in oss, något som känns som trängande eller attraktivt. Här följer några vanliga triggers. Man:

  • behöver byta ut sitt centrala affärssystem (ERP-program)
  • vill införa ett säljstödsystem (CRM-införande)
  • behöver få kontroll över sina kunddata (Masterdata-projekt, Kunddata)
  • vill bygga datatjänster som externa parter kan använda
  • har nya krav på rapportering till myndigheter (Compliance-projekt)
  • vill lägga en ny grund för dataanalys och rapportering (Business Intelligence-program)
  • vill lägga en grund för analys av ostrukturerade datamängder (Data Science-/Maskininlärning-/AI-/IoT-projekt)
  • behöver strukturera sin produktportfölj för bättre ordning (Product Lifecycle Management-projekt).
  • vill bygga upp en integrationsplattform och ett integrationsteam för att lättare integrera interna och externa funktioner, processer och system (Integrationsprogram)

Det dessa initiativ har gemensamt är att de ställer krav på att man har kontroll på vilka data man har, hur data hanteras och vad data representerar. Det är då vi efterfrågas. Fast inte alltid från början i ett sådant projekt utan först en bit in, när man börjat köra fast. Man vill gärna tro att projektet bara handlar om teknik, men har nu upptäckt att grundproblemet är att man inte har koll på sina datamängder, begrepp och språk.

Det är just den typen av problem vi går igång på. Den amerikanska informationsarkitekten Abby Covert är den som sagt det bäst, det vi gör: Det handlar om att ”make sense of any mess”: ”att göra en röra begriplig”.

Vad gör jag som informationsarkitekt?

Arbetet brukar följa några vanliga spår:

  • Kartlägga vilka data som hanteras, eller behöver hanteras, i en verksamhet, vad de representerar för företeelser som verksamheten behöver hålla reda på, liksom företeelsernas egenskaper och relationer.
  • Kartlägga hur centrala datamängder skapas, fångas, lagras, distribueras, hanteras och används, idag.
  • Ge förslag på vad man behöver göra och på vilket sätt, för att hantera data och komma tillrätta med brister.
  • Etablera ett tydligt och effektivt gemensamt språk för de företeelser som representeras av data, inklusive företeelsernas egenskaper och verksamhetsregler.

Det som vi vill se som den egentliga uppgiften ligger samtidigt som en underström i arbetet: att skapa en gemensam förståelse för hur man kan ta hand om sina data och sina begrepp och att få till arbetssätt och organisation för att kontinuerligt vårda och utveckla detta.

Kultur och arbetssätt behöver få mogna fram så att organisationen i fortsättningen själv ska kunna hantera kunskapen om sina data, sina begrepp och sitt språk på ett hållbart sätt. Vi vill alltid vara ”spelande tränare” till individer, team och hela organisationen. Vi utvecklar kultur och arbetssätt, inte genom att bara prata utan genom att själva dela vardagen med medarbetarna. Framför allt kan vi praktiskt visa hur, inspirera och stödja.

Vad bör en informationsarkitekt kunna?

En informationsarkitekt kan ses som en specialiserad verksamhetsarkitekt, en som har inriktning mot data, information, språk och begrepp. Som sådan behöver jag röra mig tvärs över verksamhet och it. Jag behöver:

  • tillgång till databaser och filer, då det är där data finns.
  • intervjua it-folk, för det är de som vet var data skapas, lagras, transporteras och transformeras.
  • tala med och förstå verksamhetsfolk, särskilt de i praktiska operativa och analytiska funktioner, för det är de som använder och skapar data.

Därmed behöver jag vara bekväm med att gräva i datastrukturer i databaser och filer. Jag behöver vara analytisk och envis, hitta samband åt olika håll, knyta ihop delar med varandra och till helheter. Jag behöver tycka att det är roligt att skapa krispiga definitioner och korrekta namn på saker och ting. Men samtidigt behöver jag lyssna och kunna kommunicera pedagogiskt, både brett och djupt. Allt detta målar upp bilden av en nörd, en kommunikativ nörd.

Det jag som driver mig är det där lilla pirret när man börjar ana hur saker hänger ihop. Det får mig att gräva vidare. Till aha-upplevelsen när det plötsligt faller på plats. Bara för att strax därpå se att det öppnar upp för nya frågeställningar!

Vilka är informationsarkitektens verktyg?

I likhet med övriga arkitekter arbetar vi med modeller. Modeller är arkitekters viktigaste verktyg. Modeller är – rätt använda – kraftfulla sociala tanke- och kommunikationsverktyg. De kopplar ihop våra hjärnor, alla vi som deltar i arbetet, och hjälper oss att skapa gemensam förståelse, gemensamt språk och kan också bli den gemensamma arbetsplattform vi behöver för vårt kontinuerliga arbete. 

Den vanligaste typen av modell för en verksamhetsarkitekt är informationsmodellen. Den bär vår framväxande gemensamma förståelse för vilka data som finns och vad de betyder, samt språket för allt detta.

Utöver informationsmodellen, till och med före denna, brukar jag ta fram en funktions-/applikationskarta. Den visar vilka operativa delar verksamhetens är uppbyggd av samt hur de samverkar som ett ekosystem med varandra och med omgivningen. Den visar också hur systemportföljen är en djupt integrerad del i verksamhetens funktioner. Kartan kan jag sedan använda för att kartlägga hur data strömmar genom verksamhetens delar och it-system.
Kartan ger översikt och sammanhang. Därmed förankrar den alla övriga modeller och dialoger i sin relevanta kontext.

I övrigt behöver vi bygga upp ett bibliotek för dessa dokument samt en plattform för att publicera och kommunicera resultat och underrättelser till alla berörda parter.

Hur stort är arbetet med informationsarkitektur?

Det här är ett arbete som mår bäst av att drivas agilt. En eller ett par personer är drivande och involverar de som de behöver efter hand. Den första nyttan kommer snabbt, men det är viktigt att få till en kontinuitet. Det handlar om att med tiden få organisationen rustad för att kunna ta hand om sina data, sina begrepp och sitt språk. Det är något som inte kan forceras utan bör få tid att mogna fram. Och man blir aldrig klar. Det finns alltid nya frågor att ta sig an. Med framgång kommer hunger efter mer.  

Vad ger en informationsarkitektur?

Informationsarkitekturen ger en grund för hela organisationens hantering och utnyttjande av data, inte minst då det gäller utveckling av nya sätt att använda data. Om man verkligen tänker efter vad det betyder att ha koll på sina data och ha tydliga begrepp, så inser man hur viktigt det är.

Det första värdet av arbetet är att all utveckling, vare sig i projekt eller löpande, där data är en väsentlig del går lättare, snabbare och med mindre risk.

Ett exempel från verkligheten

I ett av mina uppdrag som informationsarkitekt på en bank fick vi så småningom ordning på hanteringen av data och alla tusentals begrepp. Då gav vi oss på att försöka uppskatta den kostnads- och tidsbesparing som detta gav, vad beträffande den ständigt pågående verksamhets- och systemutvecklingen, som var en stor del av den totala budgeten.

Som en grund tog vi först reda på hur många mantimmar per år som gick till utvecklingsarbete, vare sig det var under arbetsformen projekt eller förvaltning, eller det var tid som hamnade på verksamhet eller it. Sedan intervjuade vi verksamhets- och it-utvecklare av olika slag och resonerade oss fram på följande sätt: Första frågan var hur stor del av all utvecklingstid som omfattade funktioner där förståelsen av data var en central del av problematiken. Svaret vi kom fram till blev en uppskattning på 60 procent. Nästa fråga blev följande: Hur mycket tid spar du i ett sådant arbete om vi har koll på data och begrepp? Uppskattningen blev 60 procent av tiden, tvärs över alla faser i arbetet, från analys och krav till implementation, test och förvaltning, liksom tvärs över alla involverade roller.

Det kan tyckas mycket, men alla som varit inblandade i utvecklingsprojekt i en dataintensiv verksamhet vet hur stor del av arbetet som handlar om att försöka förstå vad saker och ting egentligen betyder och hur man ska hantera det. För att inte tala om de överraskningar som kommer sent i projektet då man inser att man har pratat förbi varandra.

Mångmiljonbesparing

Detta innebar att den totala tids- och kostnadsbesparingen för utveckling, i den koncernen skulle bli 60 procent x 60 procent, vilket blir runt 36 procent. Vi multiplicerade den siffran med hela den årliga utvecklingskostnaden och fick fram en uppskattad årlig besparing på runt 70 miljoner kronor. Den summan vågade vi nästan inte visa för ledningen då de kunde se oss som orealistiska.

Men alla inblandade såg det som helt rimligt. Och man såg också att denna besparing egentligen bara var den lilla effekten. Det finns en större effekt av att kunna ta hand om sina data, och att ha ett väldefinierat språk för sina analyser och rapporter. Det visade sig att risken för försenade eller misslyckade projekt minskade dramatiskt. Vi kunde komma ut med datadrivna tjänster snabbare och smidigare. Vi kunde nu göra saker som inte tidigare var möjliga. Dessutom kunde vi använda data till nya tjänster och produkter. Det är svårt att överskatta vad det betyder.

Än idag, tio år senare, är de begrepp, språk, förståelse och arbetssätt vi tillsammans byggde upp, en självklar kärna i företagets it- och verksamhetsutveckling.

Jag har svårt att tänka mig någon annan satsning som ger mer tillbaka per spenderad krona och med större säkerhet.

Det förutsätter förstås att man som informationsarkitekt vet hur man gör. Hur man kan bygga ett effektivt och förståndigt arbetssätt. Hur man kan skapa engagemang och driva arbetet på ett hållbart sätt.

Om detta vill jag skriva.

Vad tycker du? Har du en annan syn på området Informationsarkitektur? Vill du att vi tar upp något specifikt inom området? Kommentera gärna! Vi ser fram mot en dialog

/Peter Tallungs IRM

Nästa artikel i ämnet informationsarkitektur publicerar vi torsdag 11 februari. Det handlar då om rollen informationsarkitekt. En roll med namnet informationsarkitekt har uppstått två gånger i historien i två olika sammanhang och med olika tyngdpunkt. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Vill du komma i kontakt med någon av irm:s informationsarkitekter?

12 Kommentarer
  1. Stefan Asanin
    Stefan Asanin says:

    Bra skrivet Peter! Jag håller med om allt men vill gärna poängtera att begreppsmodellen är ett verktyg som tydliggör kulturella och arbetsskillnader inom ett bolag (du kommer säkert hantera denna typ av modell längre fram). De flesta vill ju gärna tro att en datamodell representerar hur saker och ting görs (och som det alltid har gjorts) men den är inte alltid en representation av affären eller processerna direkt och där kan jag se att skon klämmer för oförmågan att exekvera på de triggers du nämner. Första steget kan vid vissa tillfällen vara att koppla en begreppsmodell relaterad informationsmodell relaterad datamodell.

  2. Peter Tallungs
    Peter Tallungs says:

    Tack Stefan.
    Jo, din kommentar berör direkt flera intressanta aspekter av domän-, informations-, data- och begreppsmodellering. Jag håller absolut med dig om att en modell av detta slag, eller lite olika slag (konceptuell, logisk- fysisk- eller hur man vill dela in det), representerar mer än bara data/information. Jag kommer i en av de första artiklarna att ta upp detta.

    Fast, och nu går jag nog händelsera i förväg, vill jag visa hur man kan visa och hantera flera av dessa perspektiv i en och samma modell. Bara man är medveten om vad man gör och att man är tydlig med vad som är vad.
    Det råkar vara en av mina poänger. Den stora fördelen är att man då får en modell som kan bli ett gemensamt språk tvärs över verksamhet och it. Det vill säga både visa vilka företelser verksamheten hanterar (och hur) samt skapa gemensamma begrepp och språk för detta (inkusive kopplingen till befintligt språk i olika sammanhang: synonymer) samt även hur data som representrar dessa företeelser är strukturerat. Med mera.
    Jag är i detta inspirerad av domändriven design (Domain Driven Design) och vad Edward Tufte lär ut i sina böcker om hur man gör riktigt bra grafiska beskrivningar av olika slag som kombinerar flera perspektiv.
    Ett av skälen till att jag börjat skriva igen är att jag vill dra en lans för att vi behöver utveckla området, hur vi ser på modeller och hur vi arbetar med modeller.

    Jag förstår att mitt svar till dig inte precis skingrar dimridån om vad jag egentligen menar. För det är inte så lätt att förklara utan att visa hur. Men jag hoppas att artikelserien kommer att visa det steg för steg. Så vi får fortsätta dialogen.

  3. Lars Taxén
    Lars Taxén says:

    Tack Peter, intressant initiativ som jag ser fram emot att följa!

    Jag har en mer ’filosofisk’ fundering som jag du kanske kommer fördjupa dig i framöver. Ett centralt begrepp i ’informationsarkitektur’ är väl ’information’. Ändå verkar det vara förtvivlat svårt att enas om vad ’information’ är. I forskningen om informationssystem har man hittar åtminstone fyra olika definitioner

    • information existerar i universum, oberoende av mänskliga observatörer.
    • information finns i tecken oberoende av människor, typ röd signal på en stolpe på vägen betyder ’stopp’
    • information är något i omgivningen som transporteras från omgivningen till individen, typ ett meddelande sänds från en person till en annan
    • information finns i ett socialt sammanhang som bestämmer vad som betraktas som information

    Den här oklarheten verkar ändå inte spela så stor roll när vi arbetar med att ta fram en informationsarkitektur. Ditt exempel från bankvärlden är ju talande. Så frågan är om vi ens behöver fundera på vad information är i ett praktiskt sammanhang. Vad tror du (och alla andra)?

  4. Peter Tallungs
    Peter Tallungs says:

    Tack Lars.
    Jag har inte fördjupat mig i den teoretiska definitionen av begreppet ”information”. Inom informationsteorin blir det djupt filosofiskt och existentiellt.

    Om vi ser praktiskt på det hela. Vilket begrepp ska vi använda, ”data” eller ”information” när vi pratar om vad vi gör? Vad kommunicerar dessa termen egentligen? Jag har skrivit en artikel om det som publiceras lite längre fram. Men jag får väl här och nu säga att jag inte tror på den strikta uppdelningen som man sedan 80-talet har försökt tillämpa i Sverige.

    Det vi kallar ”informationsmodell” kallas i de flesta internationella sammanhang för ”Data Model”. Och jag tycker det är lika riktigt och kanske tydligare egentligen än att kalla det för ”informationsmodell”.
    Det var inte svaret på din fråga egentligen Lars, bara en rent praktisk vinkling.

  5. Mats Boberg
    Mats Boberg says:

    Definition/modellering av omvärlden till begrepp/attribut/information/relationer heter Ontologi inom filosofin. Det vi jobbar med är mer filosofi än fysik/teknik när jag jobbar som arkitekt. Du nämner vikten av modeller och hoppas därmed att få se ett antal i nästa artikel! 😉

  6. Stefan Asanin
    Stefan Asanin says:

    Peter, jag följer med intresse! Jag är främst nyfiken på hur en sådan låt oss säga resurssnål men övergripande modell samtidigt kan bli förvaltningsbar som den är effektiv?

  7. Marcus
    Marcus says:

    Organisationen jag arbetar i står i hyfsad närtid inför så gott som alla de utmaningar som listas i inledningen. Och den enda med titeln verksamhetsarkitekt i organisationen är jag 😬. Finns som tur är ett par till med intresse för frågorna. Kommer följa artikelserien med stort intresse.

  8. Peter Tallungs
    Peter Tallungs says:

    Svar till Mats Broberg
    Ja, den mer intressanta aspekten av det vi gör när vi modellerar handlar egentligen inte främst om data eller information utan om begrepp och benämningar, alltså språk, för det verksamheten hanterar. Enligt mig vill jag påpeka. Det vill säga att vi bygger en ontologi.

    Och det jobbet har verkligen intressanta kopplingar till olika grenar inom filosofin som har att göra med verklighetens beskaffenhet, språk och kunskap att göra. Samtidigt som det på samma gång är mycket praktiskt.
    Så visst är det ontologi. Fast oftast när man talar om ontologi inom it så verkar det som att man bara menar språket i sig. Vanligen så handlar vårt arbete om att verkligen skapa en gemensam förståelse som inte finns där innan. I bred mening innefattas den förståelsen i begreppet ”språk”, enligt Wittgenstein och framgent inom den moderna språkfilosofin. Men jag tror inte att det är den vardagliga förståelsen av begreppet,

    Jag kommer i den här artikelserien, så småningom när jag kommer in på de mer praktiska aspekterna av modellering att visa många exempel på modeller, eller åtminstone utsnitt av sådana.

    Fast det kommer att ta ett tag innan vi kommer dit. Så om du redan nu är nyfiken, kan vi väl ta ett videomöte. Mejla mig i så fall.

  9. Peter Tallungs
    Peter Tallungs says:

    Svar till Stefan Asanin
    Tack Stefan!

    Det som jag menar inte tar så stora resurser är själva arbetet med att ta fram, underhålla, använda och vidareutveckla en informationsmodell för en verksamhet. Förvaltningen handlar om enkla smidiga rutiner. Mer förtroende, dialog och samarbete med alla parter än tunga processer.

    Alltså lättrörlighet och agility. Och att man finns på plats där man behövs.
    Det handlar alltså mycket om kultur och mindset.
    Det är svårt att visa utan att visa exempel, dra lite war stories och så.

  10. Peter Tallungs
    Peter Tallungs says:

    Svar till Marcus
    Vad roligt! Det betyder att någon kan ha direkt praktisk nytta av det jag skriver. Det är en skön känsla.

  11. Olov Johansson
    Olov Johansson says:

    Tack för enkla och tydliga förklaringar av vad det är vi håller på med.
    Det är skönt att se ”sina egna tankar i andras ord”.
    All input från omvärlden gör det lättare att motivera behovet av en roll som jag upplever i många fall lever i en tillvaro bredvid verksamheten men vars bidrag till verksamhetsnyttan skulle kunna vara enormt om det realiseras. Intressant att diskussionen om information vs data kom upp här i kommentarerna.
    På min hemmaplan så blir den intressant eftersom vi bär på ett klassiskt tekniskt arv med ”en databas för varje tillämpning” även om man i mångt och mycket producerat information om samma saker. Därtill i en både gammal och spretig verksamhet med akademiska inslag.

    Ser fram emot att läsa kommande artiklar.

  12. Peter Tallungs
    Peter Tallungs says:

    Tack Olov.
    Jo, det är nyttigt att försöka formulera i text det som kan vara svårfångat. Att undvika de utslitna schablonerna och hitta till kärnan. Roligt att också du ser den stora outnyttjade potentialen i det vi gör. Jag tror att vi behöver och kan utveckla området informationsarkitektur/ Informationsmodellering/ Data Management och jag tror att vi kan göra det genom en dialog mellan oss som är verksamma inom området.

    Skillnaden mellan Data och Information kommer jag att ta upp i en artikel om några veckor. jag tycker att den gängse förklaringen inte håller. Hoppas du vill vara med och kommentera/diskutera då.

Lämna en kommentar

Want to join the discussion?
Dela med dig av dina synpunkter!

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *