Inlägg

Försvar för enkla verktyg – del 1

En serie i serien. Med denna artikel inviger vi en artikelserie på fem artiklar om informationsmodelleringsverktyg i artikelserien Informationsarkitektens tankar.

Informationsmodellering är ett hantverk. För en hantverkare är verktygen viktiga. Låt oss se över vår verktygslåda. I den här artikeln vill jag försvara de enkla modelleringsverktygen.

Det finns ett antal specialiserade modelleringsverktyg, för både informationsmodeller och andra modeller. De är egentligen hela verktygsplattformar tänkta att stödja modelleringsarbetet genom att integrera grafiska och verbala beskrivningar på ett strukturerat sätt. De ger ofta även stöd för att bygga upp ett förråd för en organisations samtliga modeller, ett repository.

En annan väg att gå är att använda sig av en kombination av vanliga generella verktyg, såsom basala rit-, -skriv, dokumenthanterings- och samarbetsverktyg där man själv får bygga upp de strukturer man behöver. Det är en ”best of breed”- strategi, de vill säga att man strävar efter att använda det bästa verktyget man kan finna för varje enskild arbetsuppgift i modelleringsarbetet.

Jag och mina kollegor har hjälpt många team och organisationer att bygga upp verksamhets- och informationsarkitektur samt Data Management. Vi har därmed erfarenheter från många olika sammanhang och förutsättningar.

Mot denna bakgrund har jag kommit till att förorda det senare alternativet då en kombination av enkla verktyg inte bara är gångbart utan det enda verkligt framgångsrika jag känner till. Enkla verktyg är inte enkla i den meningen att de är simpla. Tvärtom! De ger den flexibilitet och uttrycksfullhet vi behöver för att göra ett bra jobb som informationsarkitekter.

Jag har upplevt att denna ståndpunkt är kontroversiell bland enterprise- och it-arkitekter. Jag vill därför i denna artikel, och fyra efterföljande, tydligt och noggrant argumentera för den vägen. Kanske kan jag få någon att bli mer öppen för det alternativet. Eller också blir jag avfärdad som Luddit. (Ludditer var de engelska teknikfientliga väveriarbetarna som bjöd våldsamt motstånd till de nya effektiva vävstolarna i början av 1800-talet.)

Den enkla verktygslådan

Här är listan på de typiska verktyg jag rekommenderar. Det finns förstås likvärdiga alternativ, men då av samma enkla slag.

  • Microsoft Visio: För att rita
  • Microsoft Word: För textdokument och för att integrera text och bild
  • Katalogstruktur på server, eller liknande: Som repository för modeller
  • Ändringshistorik i dokument samt rutin för att spara versioner i katalogstrukturen: För versionshantering
  • Wiki eller det samarbetsverktyg som används i den organisation jag jobbar: För att publicera modeller samt kommunicera ut vad som händer
  • Storformatskrivare: För utskrift av modeller
  • Whiteboard och digitala samarbetsverktyg: För modelleringssessioner.

Jag kommer i följande fyra artiklar motivera och beskriva hur man kan använda respektive verktyg i verktygslådan. I denna inledande artikel ger jag generella motiveringar för kombinationen av enkla verktyg i motsats till de specialiserade.

Motivering för enkla verktyg

Här följer ett antal motiveringar till att välja enkla verktyg.

Motivering 1: Enkla verktyg ger frihetsgrader och möjliggör den rikare och mer kraftfulla gestaltning som vi behöver

Våra modeller kan bli mycket bättre gestaltade än vad som är vanligt idag. Det gäller alla slags modeller. Om vi ska lyckas få en organisation att samlas kring modellerna och låta dem representera en gemensam förståelse måste de bli mycket mer överskådliga, tydliga och tillgängliga. Samtidigt behöver de ges ett rikare uttryck genom att kombinera olika slags kunskap. Det handlar om hur vi ritar. Det vill säga struktur, disposition, färger, gråskalor, linjetyper, typsnitt, symboler, samt hur vi integrerar text och bild. Vi behöver kombinera och integrera olika slags diagram med varandra samt med textuella beskrivningar.

Det sätt vi i branschen idag arbetar med våra modeller har en stor potential till förbättring. Det handlar också om hur vi hanterar våra modeller, och hur vi tillgängliggör dem. För att kunna göra allt detta på ett bra sätt behöver vi verktyg som ger frihetsgrader, som inte begränsar oss, låser in oss och hindrar oss i det vi behöver göra.

Motivering 2: Enkla verktyg främjar experimenterande och därmed utveckling av alla våra områden där modellering är en viktig del.

Som yrkesgrupp behöver vi utveckla informationsmodelleringsområdet. För det behöver vi verktyg som ger oss den friheten.

Jag vill jämföra med vad som hände inom systemutveckling kring millennieskiftet. Vid slutet av 90-talet var tron på specialiserade modelleringsverktyg stor. Rational Unified Process var den förhärskande utvecklingsmetoden och Rational Rose var det modelleringsverktyg som skulle stödja hela utvecklingsprocessen. De organisationer som var ambitiösa och anammade detta arbetssätt fick det svårt. Metoden framställdes och tolkades på ett sätt som gjorde den överlastad och rigid. Själva metoden och verktyget styrde tänkandet och arbetssättet i stället för att vara en verktygslåda. Det blev att man fokuserade på att betjäna verktyget och utvecklingsmetoden i stället för att koncentrera sig på vad användare och verksamhet behövde. Man blev på så sätt en operatör av ett verktyg utan egen agens och ansvar.  

I det sena 90-talet växte missnöjet hos utvecklare och utifrån några individer växte det fram en motrörelse. Några utvecklare, på lite olika ställen, började tänka på vad de själva verkligen behövde och vad som fungerade. De tog fram mer basala och hantverksmässiga arbetssätt som parprogrammering, test-first design, scrum-tavlor med mera. Det nya tänkesättet grodde och spred sig i utvecklarsamhället. Ett par år efter millenniumskiftet fick det etiketten agila rörelsen. Utvecklare byggde själva enkla verktyg för att stödja sitt arbete. Mest kända blev testverktyg för att automatisera tester samt så kallade refactoring-verktyg för att snabbt och enkelt göra ändringar i kod.

Jag menar att vi behöver en liknande rörelse bland oss informationsarkitekter. Det vi behöver är en ny vår för arkitektarbetet som ett hantverk, precis det som agila rörelsen var för systemutvecklare för två årtionden sedan. Vad gäller arbetssätt så har vi redan lärt av agila rörelsen och alla förstår nog nu att vi behöver smidiga och mer kommunikativa arbetssätt. Men då det gäller verktyg återstår att överge de stora tunga modelleringsverktygen och i likhet med systemutvecklarna gå till oss själva, och ställa oss frågan vad vi egentligen behöver. Tillbaka till hantverket, och vad som verkligen stödjer det.

Jag har sett organisationer där arkitekterna varit som slavar under avancerade verktyg. De har varit upptagna med att mata verktygsmonstret. Resten av organisationen har inte haft nytta av arkitekterna, som befunnit sig i en parallell värld utan kontakt med verksamhetsutvecklingen.

Och denna nya vår jag hoppas på har faktiskt redan grytt på en del ställen. Jag har sett organisationer där verksamhets- och informationsarkitekter till sist givit upp sina tunga arbetssätt och verktyg. De har lämnat sina slutna rum, klivit ner från elfenbenstornet och gått ut där verksamhetsutvecklingen sker, bland utvecklarna och i verksamheten. De har sett hur de kan stödja utvecklingsarbetet. De har då, för första gången, känt sig välkomnade av utvecklare och domänexperter. De modellerar fortfarande, men nu med enkla tekniker som tjänat syftet på ett helt annat sätt.

I de fall de trots allt behövt lite mer verktygsstöd har de, precis som utvecklarna, själva experimenterar och byggt de verktyg de behövt. Jag ska försöka ge exempel på sådana verktyg framöver.

Dessa egenbyggda verktyg kan sedan i likhet med vad som hänt inom utvecklarvärlden så småningom kommersialiseras och bli standard. Det är egentligen alltid så det sker då ett yrkesområde utvecklas på riktigt. Alltid utifrån professionen och hantverket. Aldrig från verktygsleverantörerna.

Motivering 3: Enkla verktyg sätter fokus på uppgiften

Att ta ansvar för något stort, till exempel en informationsarkitektur, kan vara skrämmande. Det är många saker man måste ta ställning till och kanske behöva försvara. Då är det lockande att gömma sig bakom ett ramverk, en industrimodell, en metod eller ett verktyg som synes ge objektiva svar. Det är att fly undan det ansvar vi har. Då blir jag en operatör av ett verktyg i stället för informations- eller verksamhetsarkitekt.

Vi behöver i stället fokusera på vad som behöver lösas i verksamheten och använda de verktyg som gör jobbet. Inte först välja verktyg för att sedan bara mata detta.

Motivering 4: Enkla verktyg minskar beroendet

Om man i en organisation har tagit in ett avancerat modelleringsverktyg så medföljer det ett antal metamodeller, vilka styr hur de modeller man tar fram måste se ut och relatera till varandra. Om man senare vill ändra detta kan det bli mycket dyrt och svårt. Verktygen är i själva verket ofta en hel plattform av verktyg som hänger samman. Man blir på flera sätt, på gott och ont, beroende av leverantören och dennes utveckling av plattformen.  

Vanliga argument för specialiserade verktyg

När man argumenterar för en enkel verktygslåda får man ofta mothugg. Här följer ett antal argument som man stöter på och hur jag vill bemöta dem. 

Argument 1: Specialiserade verktyg ger konsistens

Specialiserade verktyg har en metamodell som styr hur vi kan modellera. Det gör att vi alla ritar och beskriver på samma sätt vilket är viktigt. Om vi inte gör på samma sätt blir resultatet spretigt, återanvändningen svår och kvaliteten lidande. Det följer vanligen med metamodeller vi kan välja mellan och i de mer avancerade verktygen kan vi själva, eller med hjälp från konsulter, ta fram en egen metamodell som passar oss.

Mitt motargument: Sättet vi modellerar behöver utvecklas för att på allvar bli relevant för våra verksamheter. Vi behöver alltså se det som ett hantverk i utveckling. Då är experimenterandet viktigt, att vi söker oss fram och lär oss. Vi ska då inte standardisera arbetssätt, notationer, metamodeller med mera. Det skulle frysa all utveckling och fortsätta hålla oss fast på det stadium vi är idag. Däremot ska vi dela erfarenheter och inspireras av varandra. Men det är något helt annat.

Det finns alltid, inom alla områden en motsats mellan utveckling och standardisering. Vi ska standardisera det vi tycker att vi nått en mognad inom. Men bara där. Där vi behöver utveckling ska vi tvärtom befrämja att vi gör olika, inte bekämpa. Vi behöver tåla och bejaka spretigheten. Utveckling innebär experimenterande.

När vi har lärt oss vad som verkligen fungerar kommer saker och ting att mogna och vi kommer naturligt att gravitera mot något av en de facto-standard. Men att gå utvecklingen i förväg och bestämma en standard innan vi har nått den mognaden är fel. Det är att frysa all utveckling. Därför behöver vi frihetsgrader. Det betyder inte kaos, utan bara att vi i får vara beredda på varianter och förbättringar i små steg. Och även något vilt försök ibland! Det är så utveckling går till. Överallt och alltid.

Argument 2: Specialiserade verktyg ger struktur och ordning

Specialiserade verktyg styr hur och var vi spar, versionshanterar och publicerar modeller. De ger oss ett strukturerat repository. Det gör att resultatet inte bara blir högar av osorterade modeller på olika ställen med oklara syften och sammanhang.

Mitt motargument: Vi behöver alltid ett strukturerat repository. Vi vill inte ha oordning. Men det är mycket lätt att ordna det på ett enkelt sätt och på vilken lagringsyta som helst där man kan ha filkataloger av något slag, och något slag av enkel åtkomstkontroll och versionshantering.

Det är fel att tro att ett specialiserat repository krävs för ordning och reda. Ett specialiserat repository ger heller inte ordning och reda av sig självt. Vi behöver även då tänka igenom och komma överens om saker och ting. Den största faran med verktyg som styr oss är kanske just den tankefällan, att vi tror att vi inte behöver tänka själva. Vi har sett modellbibliotek som varit total kaos i verktygsbaserade repositories och jag tror faktiskt att vi sett fler välordnade bibliotek bland de som byggs mera manuellt. Jag är övertygad om att när jag behöver bygga något själv leds jag in på att tänka igenom och ta ansvar för vad som behövs.   

Argument 3: Specialiserade verktyg ökar produktiviteten

Verktyget hjälper mig. Jag kan återanvända delar av andra modeller när jag gör en ny, eller referera till befintliga. När jag vill göra en ändring av något som manifesterar sig på många ställen behöver jag bara ändra på ett ställe. När jag vill publicera en modell gör jag det automatiskt. Versionshanteringen är inbyggd vilket gör att den går lätt och smidigt. Jag behöver inte fundera så mycket på hur jag ska göra rent praktiskt med dessa hushållsbestyr så jag kan koncentrera mig på själva modellerandet.

Mitt motargument: Jo, verktyget hjälper dig förvisso med några enkla uppgifter. Men inte alls så mycket som man kan tro, och inte alls med det som är det väsentliga; hur du gör riktigt bra modeller och hur du når ut med dem. Tvärt om hindrar det dig. Så triviala uppgifter går kanske något snabbare – men till ett mycket högt pris.

Om vi definierar produktivitet som hur mycket nytta vi gör, hur bra vi når ut och hur vi hjälper människor och team att hantera sin komplexitet så vinner de enkla verktygen överlägset. 

Det finns ett talesätt som säger ”A fool with a tool is still a fool”. Det brukar motvilligt citeras av verktygssäljare när man pekar på misslyckade införanden av deras produkter. De vill betona att deras fina verktyg trots allt inte garanterar ett bra resultat, utan att det kan finnas dumma människor som inte begriper hur de ska användas. Det finns ett tillägg till talesättet som säger ”A fool with a tool makes a faster fool”. Det vill säga att om ett verktyg ökar produktiviteten utan att verktygsanvändaren gör ett bra jobb hamnar man snabbt i ett dåligt läge.

Argument 4: Specialiserade verktyg stödjer samarbete

Verktyget stödjer att flera kan jobba samtidigt med samma modell, kanske även från olika geografiska platser.

Mitt motargument: Jo, verktyget har funktioner för detta. Men det fungerar bättre med de generella samarbetsverktygen vi använder i övrigt i våra distansarbeten.

Konflikten mellan viss automatisk hantering och stöd för rik gestaltning

Jag menar att om vi använder de specialiserade verktyg som finns så får vi visserligen stöd för vissa enkla uppgifter.

Men vi väljer samtidigt bort möjligheten till att göra riktigt bra modeller.

Vi kan inte få både och. Åtminstone inte idag. Och inte förrän vi själva inom professionen bidrar till den utveckling som kanske kan ge oss sådana verktyg.

Och vi tenderar till att både övervärdera nyttan av den lilla automatisering vi kan få samt att undervärdera vikten av att göra riktigt bra modeller som når fram.

I själva verket är det så krasst att om vi inte når fram har vi inget som motiverar vår existens.

De ivrigaste proponenter för specialiserade verktyg jag mött har nästan i samma mening beklagat att de inte har gehör hos it- och verksamhetspersoner för vad de gör, utan blir ständigt kringrända av utvecklingsprojekten. Det kanske skvallrar om något?

Fortsättning följer

Jag är medveten om att den här posten väcker många frågor. ”Peter pratar mycket om att vi ska göra bättre modeller men inte hur det går till.” Det är ett stort område, men jag vill steg för steg i den här artikelserien ge mitt bidrag till det.

Vad är din erfarenhet? Vilka verktyg använder du? Handen på hjärtat, vad fungerar på riktigt?

/Peter Tallungs, IRM

Nästa del i miniserien om informationsmodellerarens verktyg publicerar vi torsdag 22 april. Vill du prenumerera på artikelserien Informationsarkitektens tankar? Registrera din mailadress här.

Data management – se hela kedjan

För att en organisation ska få nytta av sina data behöver en hel kedja av förutsättningar vara uppfyllda. Vi behöver se och förstå hela kedjan för att hitta och förstärka svaga länkar.

En organisations data är en tillgång. Om vi kan hantera den tillgången på ett bra sätt så ger den mångfalt tillbaka. Data kan inte bara stödja verksamheten operativt utan också användas analytiskt, det vill säga ge insikter och kunskap och därmed ligga till grund för beslut och handling. Men för att en datatillgång verkligen ska ge nytta måste den tas om hand, den måste förvaltas aktivt. Det är det vi kallar Data Management.

En modell i form av en kedja

Data Management är ett område med stor spännvidd och som inkluderar alla de åtgärder som behövs för att ta hand om en dataresurs för att maximera dess värde.
För att få överblick över området kan vi använda oss av en modell över en tänkt kedja av förutsättningar, från det att data registreras någonstans tills det att man får nytta av dessa data i organisationen. Modellen är en uppräkning av förutsättningar som tillsammans bildar en kedja, där varje förutsättning behöver uppfyllas. Jag har ofta visat denna modell i olika sammanhang för att visa vad Data Management kan omfatta. Modellen kan dock kännas en aning konstlad. Man har försökt pressa in lite för mycket, speciellt i slutet av kedjan. Som jag skrev i artikeln ”Data eller information” skapas sällan kunskap direkt ur data på ett linjärt sätt vilket modellen ger sken av. Kunskapsprocessen i en organisation är en växelverkan mellan flera olika handlingar och källor, där data visserligen är en viktig källa men ändå endast en av de inblandade faktorerna. Så vi ska ta modellen med en nypa salt. Men jag tycker ändå att modellen, trots sina begränsningar, har sin poäng i att den positionerar Data Management i förhållande till angränsande och överlappande discipliner. Modellen presenteras i det följande.

Kedjan av förutsättningar

Nyttan av data uppstår bara om en serie av förutsättningar är uppfyllda. Dessa förutsättningar bildar länkar i en kedja. Varje förutsättning blir meningsfull endast om alla föregående förutsättningar i kedjan är uppfyllda. Som bekant är det den svagaste länken i en kedja som avgör om den håller. Det spelar då ingen roll hur starka de andra länkarna är. Svagheten i en länk vägs inte upp av styrkan i de andra.

Kedjan av förutsättningar kan listas som nedan. För varje förutsättning ger vi exempel på faktorer som kan bidra till att den förutsättningen kan uppfyllas.

  1. Att rätt data finns
    Att det någonstans (innanför eller utanför organisationen) finns rätt data, det vill säga som handlar om rätt saker och är anpassade till situationen.
    Bidragande faktorer: Dataplanering, dataanalys, processutveckling, utveckling av applikationer för registrering, Business Intelligence, givare för insamling av data, givare för maskindata med flera.
  2. Att man känner till att dessa data finns och var de finns
    Det händer ofta att data finns men att de som behöver den inte vet om det. Då stoppar det redan här.
    Bidragande faktorer: Aktivt sökande av datakällor och datatjänster, datakataloger, Data Dictionary, utbildning, kommunikation, informationsmodeller/- kartor med flera.
  3. Att man kan nå och få fram dessa data
    Kan vara via maskinella eller manuella tekniker.
    Bidragande faktorer: Applikationer, intranät, internet, sökmotorer, SQL, Data Warehouse, API-er, datatjänster, presentationstekniker med flera.
  4. Att man kan förstå dessa data
    Det vill säga att man kan tolka dess innebörd och syfte med stöd av sina egna referensramar.
    Bidragande faktorer: Utbildning, erfarenhet, definitionsarbete, namngivning, modeller/kartor, metadata, dokumentation, informationsanalys med flera.
  5. Att man kan lita på informationen
    Att man kan lita på att den information man tagit till sig stämmer med verkliga förhållanden.
    Bidragande faktorer: Metadata, källhänvisningar, goda erfarenheter, datakvalitetsarbete, redundans med flera.
  6. Att man kan vidarebearbeta data
    Att man kan sortera, filtrera, kombinera, summera och sammanställa data och därmed bilda sig ytterligare sammanfattad/komplex information som blir mer användbar för att dra kunskaper ur.
    Bidragande faktorer: Data-analysverktyg och metoder, Data Science, rapportverktyg, aktivt arbete med framtagning och förvaltning av rapporter med flera.
  7. Att man kan dra korrekta slutsatser från informationen
    Från informationen man fått fram behöver man sedan kunna dra slutsatser som är relevanta i sammanhanget.
    Bidragande faktorer: Domänkunskap, erfarenhet, överblick, logisk förmåga, abstraktionsförmåga, konkretionsförmåga med flera.
  8. Att man kan besluta sig för ett handlingsalternativ
    Detta baserat på slutsatserna, intuition, beslutsstil och personliga faktorer.
    Bidragande faktorer: Beslutstil, beslutsförmåga, belöningssystem, rekrytering, organisationskultur, personlig utveckling med flera.
  9. Att man kan gå från beslut till handling
    Det vill säga verkställa och agera.
    Bidragande faktorer: Genomförandekraft, motivation, handlingsberedskap, inräkning och kultur för att agera med flera.

Se hela kedjan

Varje gång en nytta av dataförsörjningen har uppstått har varje länk i kedjan hållit. Om en enda länk i kedjan brister blir värdet noll. Det vill säga ingen nytta, endast kostnader. Helheten är därmed viktig. Inom Data Management behöver vi se hela kedjan, hitta de svaga länkarna och stärka dessa. Vi behöver därmed satsa brett på informationsteknik och verksamhet samt människa och teknik i samverkan.

Var kommer Data Management in?

Vi kan succesivt dela in kedjan i större sträckningar, vilka var och en kan ges en rubrik. Låt oss se var vi som jobbar med Data Management kommer in.

  • Länk 1-3: Utdata till användaren
    Det är det som it- funktionen i organisationer vanligen avgränsar sin uppgift till. Man ser vanligen inte det som sin uppgift att tala om vad data betyder eller vilken kvalitet de har.
  • Länk 1-5: Informationsförsörjning
    Det bör vara vår uppgift inom Data Management att lyfta organisation och arbetssätt till att omfatta hela informationsförsörjningen. Vi informationsarkitekter kan kanske göra störst nytta då det gäller att stärka länk fyra och fem så att hela informationsförsörjningen håller.
  • Länk 1-7: Informationsförsörjning och användning
    Det bör även ingå i informationsarkitektens uppgift att bidra till att analytiska användare har verktyg för att bearbeta de data de har tillgång till. Vi behöver av många skäl samarbeta nära med den typen av användare. Inte minst för att det ger insikter i hur vi kan bidra med att få mer data och i rätt form.
  • Länk 1-9: Hela kedjan till och med att nytta uppstår
    Hur användarna av data drar slutsatser, beslutar och agerar, på basis av data, kan vi inte direkt påverka. Dock behöver vi observera och arbeta tätt ihop med de som gör det. För det ger insikter om vad vi som arbetar med informationsarkitektur eller Data Management behöver bidra med.

Hur långt sträcker sig ditt intresse?

Hur långt sträcker sig ditt intresse och engagemang? Hur ser du på din eller ditt teams roll? Vilken länk är svagast i din organisation? Kan du göra något för att stärka den?
Dina erfarenheter och tankar är välkomna.

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 15 april. Då inleder vi en liten serie i serien. Den kommer handla om hantverket informationsmodellering.
Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

En informationsmodell istället för flera

Vi behöver inte separata konceptuella, logiska och fysiska modeller. Vi kan kombinera perspektiven i en och samma modell och därmed få ett gemensamt språk och en gemensam förståelse tvärs över verksamhet och it.

/Peter Tallungs, IRM, 2021-03-11

Inom informationsmodellering har man vanligtvis delat in modeller efter vilken aspekt av en datadomän de beskriver. Man har tänkt sig att samma domän behöver beskrivas på olika sätt för olika intressenter. Ofta har man då skilt mellan konceptuella, logiska och fysiska modeller. Det finns andra indelningar och benämningar, men tanken är i grunden densamma. 

  • Konceptuell modell En översiktlig konceptuell beskrivning på hög nivå, för att diskutera med verksamhetsfolk. Den konceptuella modellen avbildar ”verkligheten” eller rättare sagt en översikt av de företeelser som verksamheten behöver hantera. Då är inte detaljer viktiga menar man.
  • Logisk modell För att ställa krav på vilka data som behöver hanteras behöver man en logisk datamodell. Det är en modell som visar hur till exempel en databasstruktur är designad och visar all data fullständiga i alla sina detaljer. Dock innan man gjort tekniska anpassningar och prestandaoptimeringar.
  • Fysisk modell För att visa exakt hur man implementerat en databas på en specifik plattform behöver man en fysisk modell. Den visar precis hur databasen ser ut.

Tanken är (åtminstone som den ofta har framställts) att man arbetar mer eller mindre sekventiellt när man designar en databas eller någon annan datahantering. Först tar man fram den konceptuella modellen och sedan den logiska modellen som en detaljering av den konceptuella. Till sist tas den fysiska modellen fram med de avsteg man gjort för den logiska modellen av tekniska skäl. Alla tre modeller ska sedan leva vidare tillsammans. Ty alla tre perspektiven på samma datamängd behöver fortleva kontinuerligt.

Dessutom behöver man kunna spåra alla samband mellan dessa, det vill säga att man på något sätt behöver bevara alla kopplingar mellan dessa modeller. När något förändras behöver den eventuella påverkan mellan modellerna hanteras.

Problemen med separata modeller för samma domän

Synsättet ser bra ut i teorin, men jag menar att det för det första hindrar möjligheten att skapa ett gemensamt synsätt och en förståelse tvärs över it och verksamhet, och för det andra att det är ogörligt i praktiken att ha tre olika modeller för olika perspektiv på samma sak och dessutom kopplingar däremellan.

Anledningen till att vi över huvud taget skapar en modell är för att alla inblandade ska få samma gemensamma karta i huvudet, samma spelplan för att bygga vårt forskande och lärande runt. En modell ska vara vårt gemensamma språk oavsett om man är systemutvecklare eller verksamhetsexpert. När alla intressenter har olika kartor i huvudet slöar det ner all kommunikation. Kanske inte om de bara skulle röra sig om enstaka skillnader, men små skillnader på många ställen ger en kognitiv och kommunikativ friktion som kraftigt hämmar den samverkan som vi behöver.

Jag har aldrig i praktiken sett att det fungerat med att parallellt hantera och arbeta med tre olika modeller över samma domän på detta sätt. Jag vill argumentera för ett annat synsätt och ett annat sätt att lösa att vi faktiskt behöver hantera flera perspektiv samtidigt. Vi kan göra det i en och samma modell. Det går alldeles utmärkt att förena alla tre perspektiven i en och samma modell.

Jag påstår inte att alla andra typer av modeller över en verksamhet kan ersättas av en enda. Det finns perspektiv som verkligen behöver beskrivas separat. Vi kan till exempel inte trycka in en funktionskarta eller en processmodell i en informationsmodell. Men vi kan faktiskt hantera de olika perspektiven för informationsmodellering i samma modell. Jag har gjort så i många år och jag visar gärna hur, men det får bli i senare artiklar. I denna artikel ger jag en första inblick i tankesättet.

Men först, låt mig ta stöd i min argumentation från två olika håll. Det handlar om inflytelserika tankeriktningar vad gäller modellering och informationsdesign inom två delvis andra områden. De har båda varit viktiga inspirationskällor för mig.

Inspiration 1: Modellering inom programvarudesign – Domändriven design

Det finns en filosofi inom modern programvarudesign som heter ”domändriven design” (förkortat DDD), beskriven i boken Domain-Driven Design av Eric Evans. Den handlar om hur man designar den del av programkoden som representerar domänen i fråga. Det vill säga där vi har klasser som heter saker som ”Customer”, ”Product”, ”Product type”, ”Order” etcetera. Den delen av programkoden är en domänmodell, det vill säga en modell av det som verksamheten behöver hantera med hjälp av programvaran i fråga. Författaren hävdar att när man designar den delen av programkoden bör den i största möjliga utsträckning vara identisk med den mentala modell som man vill att alla inblandade, både från it och verksamhet, ska ha i huvudet. Det innebär att när man designar domänmodellen i programvaran, designar man samtidigt den mentala modell som verksamheten behöver. Det vill säga att domänmodellen i programkoden verkligen blir det gemensamma språket, tvärs över verksamhet och it. De konceptuella och logiska modellerna (vad folk i verksamheten har i huvudet) blir samma som den fysiska modellen (hur programkoden som representerar detta är strukturerad och namngiven).

Detta är i skarp kontrast till en vanlig tidigare uppfattning bland systemutvecklare där man ofta såg det som att koden gjorde man på sitt eget sätt (den fysiska modellen), sedan översatte man fram och tillbaka i användargränssnitten till hur användarna behövde se det hela (den konceptuella modellen).

Domändriven design är allmänt accepterat inom systemutveckling idag, även om tankesättet kanske inte helt och hållet har nått ut till alla systemutvecklare i sin fulla innebörd.

Boken Domain-Driven Design är även i övrigt en av mina största inspirationskällor då det gäller informationsmodellering (trots att den egentligen handlar om programvarudesign). Det är en bok jag varmt vill rekommendera till alla som arbetar med informationsmodellering. Eric Evans har en förmåga att förmedla djupa klokheter om modellering.

Det finns dock några allvarliga begränsningar med idéerna inom domändriven design:

  1. Domänmodellen är manifesterad i programkoden och därmed otillgänglig för andra än programmerare och egentligen bara de programmerare som arbetar med just den applikationen. Vi behöver en gestaltning av modellen som är tillgänglig för alla.
  2. Domänmodellen är endast uttryckt i programkod, vilket inte ger samma överblick som en grafisk beskrivning. Vi behöver en gestaltning av modellen som både ger visuell överblick och detaljerade definitioner och beskrivningar.
  3. Domänmodellen omfattar endast en enda applikation. Vanligen har vi i en verksamhet att göra med många samverkande applikationer, databaser, integrationer med mera. Vi behöver modeller som sträcker sig över flera samverkande applikationer.

Det är här jag menar att informationsmodellen kommer in. Vi kan låta den vara en domänmodell för hela den domän vi behöver hantera, tillgänglig för alla.

Inspiration 2: Informationsdesign – Multidimensionella grafer

Edward Tufte

Informationsdesignern Edward Tufte har betytt mycket för hur synen på hur man designar grafer och kartor för att förmedla data, information och kunskap ser ut idag. Han argumenterar, med många olika exempel, att alla riktigt intressanta grafer sammanför flera olika typer av kunskap eller information. Han kallar det för multidimensionella grafer. Tänk bara på vanliga geografiska kartor som sammanför naturgeografi (sjöar, höjdkurvor, naturtyper), politisk geografi (landskap, län, kommuner) och transportinfrastruktur (vägar, järnvägar, färjelinjer) i samma karta. Tufte har skrivit många böcker i ämnet men beskriver just detta bäst i boken Beautiful Evidence.

Hur hanterar vi då alla tre perspektiv i en och samma modell?

Okej, säger du. Så om vi översätter detta till databasdesign så behöver strukturen i databasen så mycket som möjligt stämma överens med hur vi tror att verksamheten behöver se på sakerna? Men i verkligheten har vi inte så ofta lyxen att designa en ny databas. Oftast finns det redan en databas, där saker heter som de gör och är strukturerade som de är, ofta med inkonsekvent och inte så bra namngivning och struktur. Då måste jag väl ha två olika modeller? Dels en fysisk som visar hur det ser ut i databasen samt en konceptuell som visar hur vi tror att verksamhetens personer behöver se på sakerna i verkligheten? Det vill säga att vi både skapar ett korrekt, tydligt och användbart gemensamt språk för verksamheten och samtidigt dokumenterar hur det ser ut rent fysiskt i datalagringen?

Ja, det stämmer att vi behöver beskriva och hantera de två perspektiven, fast det betyder inte att vi rent fysiskt behöver två informationsmodeller. Vi kan hantera båda perspektiven i samma modell. Det underlättar mycket om vi på detta sätt kan koppla ihop vad verksamheten faktisk hanterar med hur informationen om detta är strukturerad.

Jag går tillväga på följande sätt. Den informationsmodell jag tar fram är i grunden konceptuell. Det vill säga att den struktur jag visar och de namn jag använder är det vi kommer överens om som det mest korrekta, användbara och tydliga sättet att se på och benämna företeelserna och deras egenskaper och relationer. Så om jag hittar en tabell i en databas som heter ”Customer”, men jag inser att det inte bara finns kunder i denna utan även leverantörer, så skapar jag två entiteter för dessa. Fast jag anger också att de båda återfinns i tabellen ”Customer”. Om jag sedan hittar att någon har lagt kundens personnummer i den kolumn som heter ”PhoneNbr2” (jo det har faktiskt hänt!) så skriver jag in ett attribut i min modell som heter ”Personnummer” men anger att den ligger i kolumnen  ”PhoneNbr2”.

På så sätt blir modellen alltså i grunden konceptuell, och blir med tiden det gemensamma språket för verksamheten. Men den har också krokar ner i var och hur informationen om dessa företeelser ligger lagrade. Den blir på detta sätt en modell som verkligen kan bygga ihop de två perspektiven.

Synonymer

I verkligheten har ett och samma informationsobjekt ofta fler än två namn. Det kan heta olika saker i databasen, i programkoden, i API-er, i filer och i Data Warehouse och i rapporter. Det hanterar jag i informationsmodellen som synonymer, att en och samma egenskap heter olika saker i olika sammanhang. Det spelar mindre roll om det är av bra eller dåliga anledningar, det måste i varje fall hanteras. Då redogör jag i informationsmodellen för vilka olika synonymer som förekommer och i vilka sammanhang de förekommer. På det sättet får vi spårbarhet åt alla håll.

Informationstätheten

Det hävdas ofta att vi inte ska ha för mycket information i en och samma modell. Överblicken blir lidande. Allt flyter ihop till en enda röra. Men då kommer vi in på området grafisk gestaltning. Vi kan bli mycket mycket bättre på hur vi ritar. Vi kan få både överblick, tydlighet och detaljrikedom i samma graf om vi gör på rätt sätt. Det handlar om disposition, struktur, gråskalor, färger, linjebredder med mera. Det är ett område som är sorgligt eftersatt inom informationsmodellering. Där finns mycket att lära från andra discipliner som behöver kommunicera grafiskt, som byggnadsarkitektur, grafisk design, informationsdesign, ritteknik, kartritning. Jag planerar att visa hur i artiklar framöver.

Skillnad på modell och diagram

När vi resonerar om hur vi gestaltar modeller behöver vi skilja på ”modell” och ”diagram”. En och samma modell kan vara gestaltad i flera diagram. Jag brukar, när jag tar fram lite mer omfattande modeller, göra ett översiktsdiagram över hela modellen. Där har jag med alla ämnesområden och entiteter, men inga attribut, och bara de viktigaste relationerna. Det blir som en översiktskarta. Sedan tar jag fram flera detaljerade diagram, ett för varje ämnesområde eller sammanhållen grupp av ämnesområden. På så sätt får jag både en ”ut-zoomad” vy och en ”in-zoomad” vy på en och samma modell. I varje diagram samsas det logiska perspektivet (vad data representerar i verksamheten) med det fysiska (hur data lagras och transporteras).

Kanske är det hopblandningen av begreppen ”modell” och ”diagram” som har skapat behovet av att vilja skilja ut vad man kallar för en konceptuell modell från en logisk modell? Det vill säga att behovet av att ha olika detaljeringsgrad vid olika tillfällen har tvingat fram två separata modeller?

Men vad är då villkoret för att flera diagram ska kunna sägas vara samma modell? Jo, de måste beskriva samma domän och ha samma kontext (det vill säga sammanhang) och vara konsistenta (de vill säga inte säga emot varandra).

Vi behöver ju kunna använda alla uttrycksmedel som står oss till buds då vi modellerar. Då måste vi lämna begränsningen att en gestaltning av en modell består av endast ett diagram. Den kan bestå av flera diagram och flera olika typer av diagram, den kan bestå av diagram och text integrerat.
Mer om detta beskriver jag i artiklar framöver.

Att skapa en världsbild

På det här sättet kan vi få en och samma modell att avbilda inte bara informationen i sig utan även det som informationen handlar om, de företeelserna som informationen representerar. Vi får en och samma verklighetsbild, som omfattar både vad och hur saker hanteras i verksamheten samt hur detta representeras i informationssystemen, inklusive de diskrepanser vi tyvärr kan ha däremellan.

På så sätt riskerar vi inte att få det som vi så ofta ser i våra verksamheter, två grupper av individer med olika världsbild. En på it-sidan som ser ”verkligheten”, det vill säga hur det verkligen ser ut i databaserna. Och en annan på verksamhetsidan som också ser ”verkligheten”, och då en annan verklighet, det vill säga hur det fungerar i verksamheten utanför it.

Det är dags att vi börjar se det som en och samma verklighet. It-systemen är idag en integrerad del av verksamheten, inte som tidigare bara ett ”stöd” till verksamheten.  

Modellen blir ett gemensamt språk för alla parter. Detta är i min mening det mest intressanta och kraftfulla med informationsmodellering. Som modellerare skapar du faktiskt, tillsammans med de berörda, en gemensam världsbild över allt det som behöver hanteras i en verksamhet. Det är ett stort ansvar med stora möjligheter om vi tar det ansvaret på allvar. Liksom stora missade möjligheter om vi inte gör vårt bästa, utan bara fortsätter på samma sätt som vi en gång lärt oss.

Det skulle vara intressant att få höra dina synpunkter på detta. Kommentarer är välkomna.

/Peter Tallungs /IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 18 mars. Då handlar det om modeller på papper och modeller i huvudet.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Det är skillnad på data och data

När vi ska bygga upp Data Management i en verksamhet, det vill säga verksamhetens förmåga att vårda och utveckla sin dataresurs, behöver vi en grundläggande indelning av data i kategorier. Ty olika kategorier av data behöver lite olika ansatser.

Det är praktiskt att dela in data i olika kategorier. Man stöter också på många olika indelningssätt i litteraturen. Varje sätt har sina styrkor och svagheter och passar därmed sina speciella syften.

Säg att vi ska bygga upp någon form av Data Management, det vill säga förmågan att vårda och utveckla vår organisations data som en värdefull resurs. Då finns det en grundläggande och praktisk indelning som jag tror är allmänt accepterad och som visat sig användbar tvärs över alla verksamheter.

Det är en grov indelning av verksamhetsdata i tre kategorier som skiljer sig åt beträffande vilka typiska problemställningar respektive kategori är förknippad med då det kommer till att ta hand om dataresursen. Därmed behöver varje kategori av data hanteras på lite olika sätt och med olika prioritet. Det som i grunden skiljer kategorierna i det avseendet är vilken livscykel verksamhetobjekten (som data i fråga representerar) har, i vilken mån data i den kategorin refereras eller uppdateras från olika funktioner i verksamheten samt i vilken grad dessa data har ett naturligt ägarskap.

De tre kategorierna är masterdata, globala referensdata och händelsedata. Dessa kommer jag nu gå igenom och ge exempel på.

Masterdata

Masterdata är vanligen kund- och produktdata, men kan också vara andra data. Det är data som uppfyller följande kriterier:

  1. Representerar centrala verksamhetsobjekt som har en livscykel över tid.
    Exempel: En och samma kund finns i vår verksamhet över en längre tid och kan ändra adress, status och till och med namn och andra uppgifter under sin livstid som kund och ändå ha kvar samma identitet. Ett annat exempel: En och samma produkt lever över en längre tid trots att den kan ändra status och andra egenskaper under sin livstid.
    Observera att det här inte handlar om hur länge man behöver spara data över tid, utan bara om hur länge verksamhetsobjektet har en aktualitet. 
  2. Refereras av många andra dataobjekt, särskilt händelseobjekt, och bildar därmed en bas för övriga data.
    Exempel: Kunder refereras av offerter och transaktioner, produkter likaså. Man kan säga att de verksamhetsobjekt som representeras av masterdata är centrala för verksamheten i det att de är mer eller mindre beständiga och refereras från många håll. Data som representerar dessa fungerar därmed som en slags bas och ankare i dataresursen. 
  3. Saknar ofta naturligt ägarskap. Många behöver kund- och produktdata men det är oklart vem som ska vara ansvarig för dessa. Masterdata är i likhet med gemensamma tillgångar i övrigt utsatt för det ekonomisk-sociala fenomen som kallas ”tragedy of the commons”: Hur en gemensam resurs riskerar att misshushållas, då ingen känner ansvar.
  4. Uppdateras ofta från olika verksamhetsfunktioner. Till exempel kan både sälj och marknad registrera nya kunder. Ofta har man ännu helt separat hantering av olika säljkanaler vilket betyder att online-kunder läggs upp helt separat. Eller så har man slagit ihop två verksamheter med överlappande kundregister. Adresser behöver kanske uppdateras både från offentliga källor och av kunden själv, via kundtjänst eller självbetjäning. Allt detta skapar typiska masterdataproblem som vi behöver hantera.

Globala referensdata

Referensdata är data som är till för att vara värdeförråd för egenskaper hos andra dataobjekt, det vill säga uppräkningar av giltiga värden. Det kan till exempel vara listan med Sveriges postnummer, alla produkttyper vi har, SNI-koder (Svensk Näringslivsindelning), länder i världen etcetera.

Kanske känns referensdata bäst igen som ”koder”, men en kod är egentligen endast ett av attributen för en förekomst av referensdata.

Vi inkluderar här inte lokala referensdata, till exempel de olika kundstatuskoder som finns ifall de endast används som värdeförråd för attributet kundstatus för kund. Skälet är att lokal referensdata har en naturlig hemvist. Ansvaret för vilka kundstatuskoder som finns hänger naturligt samman med ansvaret för kunddata. Det ingår i beskrivning av attributet kundstatus.

Referensdata har likt masterdata en livscykel. En statuskod kan till exempel ändra namn, börja vara giltig vid en tidpunkt eller upphöra vid en annan.

Globala referensdata har ofta inte ett naturligt ägarskap. Postnummer har visserligen en naturlig källa, Sveriges postnummerregister, men man behöver ändå se till att någon tar ansvaret för att tillhandahålla, tillgängliggöra och uppdatera listan internt i organisationen.

Referensdata representerar inte några egentliga verksamhetsobjekt i kontext av den aktuella verksamheten, utan varje entitet representerar bara en lista av giltiga värden för en viss egenskap hos ett eller flera verksamhetsobjekt.

Speciellt för referensdata är att de har en typisk uppsättning attribut som gäller för de flesta fall. Oftast ser man bara kod och namn, men en bruttolista över möjliga attribut borde kanske se ut enligt nedan. Detta gäller för alla referensdata, både globala och lokala.

Attribut för referensdata – bruttolista

AttributBeskrivning
KodKod eller id. Kan också fungera som kortnamn.
NamnFullständigt namn.
KortnamnEtt kortare namn för användning i de fall hela namnet inte får plats i något sammanhang, som till exempel i en valbar lista i ett användargränssnitt eller i en kolumnrubrik i en rapport.
DefinitionDefinition av värdet. Viktigt, men glöms ofta bort. Bör finnas med i informationsmodellen, och också vara tillgänglig i användargränssnitt.
BeskrivningBeskrivning utöver definition, i de fall det behövs.
NoteringEventuella noteringar i övrigt.
SorteringsordningEn siffra som anger i vilken ordning värdet ska listas, i en valbar lista eller dylikt, för det fall att sorteringsordningen inte ska vara alfabetisk. Glöms ofta bort, men behövs för att värdena ska listas i en naturlig ordning och på samma sätt överallt där de visas.
Gäller från och med – datumFör de fall att listan med giltiga värden ändras.
Gäller till och med – datumFör de fall att listan med giltiga värden ändras.

Händelsedata

Data som inte är masterdata eller referensdata avser vanligen något som är en händelse i tiden, som en transaktion av något slag, till exempel ett köp eller en order. Hit kan man också hänföra sådant som en offert eller faktura. De har kanske en viss giltighet över tid, men ändrar aldrig någon egenskap utöver status.

Händelsedata har därmed till skillnad mot masterdata och referensdata ingen längre livscykel. De är att betrakta som ett snapshot i tiden och kan därmed aldrig ändras, utöver möjligen sin status. Dessutom hör händelser tydligt hemma i speciella verksamhetsfunktioner, då de inträffar i ett speciellt sammanhang. Därmed är de inte på samma sätt en delad resurs som masterdata och globala referensdata. Sist men inte minst viktigt, om du har fått ordning på masterdata och globala referensdata har du en fast grund att stå på. Allt detta talar för att händelsedata blir smidigare att hantera.

Viktigt att veta är att det som i en verksamhet har kort livslängd och därmed kan klassas som händelsedata kan i en annan verksamhet ha en beständighet och därmed behöva klassas som masterdata. Ett exempel kan vara avtal. I en verksamhet kan ett avtal gälla för endast en leverans och därmed snabbt vara överspelat. I en annan verksamhet löper avtal över lång tid och används för många leveranser. I det första fallet är det händelsedata, och i det andra fallet masterdata.

Jämförelse mellan kategorierna av data

Vi kan nu jämföra de tre kategorierna av data beträffande de faktorer som bör påverkar i vilken ordning vi bör adressera att ta hand om dataresursen. De fyra faktorer som jag kan se redovisas i tabellen nedan.

Vilka faktorer som påverkar prioriteringen för Data management för en datatyp

PåverkansfaktorMasterdataGlobal referensdataHändelsedata
Lever över tidJaJaNej
Refereras från många ställenJaJaNej
Saknar ofta naturligt sällskapJaJaNej
Uppdateras ofta från flera ställenJaNejNej

Syftet med indelningen

Varför är det bra att dela in data på detta vis? Jo, om vi verkligen ska ta hand om våra datamängder så ställer de här kategorierna olika krav på oss som verksamhetsförmåga. Masterdata och global referensdata utgör grunden och själva förankringen för all data. Det vill säga all övriga data är beroende av masterdata och global referensdata. Därför behöver vi först få ordning just där. Har vi gjort det så faller det övriga på plats ganska naturligt. Att däremot börja med händelsedata när vi har en skakig grund i till exempel kund- och produktdata är ogörligt.    

Jag brukar jämföra det med strategin för att röja hemma i villan. Om man först skapar ordning i förvaringsutrymmena, det vill säga på vinden, i källaren och i garaget, så blir det mycket lättare att ordna upp i resten av huset. Tvärt om är ingen bra idé.

Masterdata kommer som sagt först i prioritet, tillsammans med global referensdata. Händelsedata kommer naturligt senare i prioritet.

Detta är förstås en förenkling. Det kan finnas annat som gör att man behöver prioritera annorlunda. Men då blir det kanske till ett pris. Utan en fast grund är det svårt att göra någonting bra.

Data management

Vi bör givetvis ta hand om all data. De olika kategorierna av data har mer gemensamt än som skiljer i detta avseende. Men masterdata har ändå en nyckelroll i detta arbete. Därför brukar man se masterdatahantering som ett eget område. Globala referensdata har i viss mån liknande problem men är vanligen lättare att komma till rätta med.

Vi ska i nästa artikel titta på vad Data Management handlar om.

Till dess, vad anser du om indelningen som jag beskriver här? Har du en annan syn? Eller bättre beskrivning av respektive kategori?

/Peter Tallungs, IRM 

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 4 mars. Peter Tallungs tittar närmare på vad Data management handlar om och ställer frågan: Hur kan vi bygga en förmåga att ta hand om den resurs som vårt data är?  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

Informationsarkitekter: De två kulturerna

En roll med namnet informationsarkitekt har uppstått två gånger i historien i två olika sammanhang och med olika tyngdpunkt. Det kan skapa förvirring. Men det kan också vara en möjlighet.

Informationsarkitekten – sprungen ur databasadminstratörens roll

Den första gången någon kallades ”informationsarkitekt” var på mitten av 1970-talet, men professionen växte först fram på allvar ur databasadministratörernas värld på 1980-talet. I början handlade det om att designa databaser. Rollen utvecklades så småningom till att handla om det större perspektivet, att bringa ordning i en verksamhets data och information tvärs över olika källor, verksamhetsfunktioner, databaser, applikationssystem, integrationer, tjänster, rapporter med mera.

Tack vare den nära kopplingen som en verksamhets data har till begreppen och språket i en verksamhet så växte det fram så småningom på sina håll ett ansvar för begrepp och språk. Men fortfarande handlar det oftast om en nära koppling till informationstekniska system, och vanligen med ett mycket brett fokus över många enskilda tillämpningar, databaser, integrationer, rapporter. Ibland är uppgiften att skapa en gemensam grund tvärs över flera verksamheter.

Det är i det skrået jag och mina kollegor på IRM arbetar. Det finns ingen särskild utbildning för detta, men det finns branschorganisationer som DAMA (Data Management Association International) med konferenser och på webbplatser som TDAN (The Data Administrators Newsletter) finns ett rikt material att ta del av.

Informationsarkitekten – sprungen ur webbdesignerns roll

Den andra rollen med samma namn uppstod ett par decennier senare.  Boken ”Information Architecture for the World Wide Web” av Louis Rosenfeld med flera som kom 1998 brukar nämnas som startpunkt. Boken kallar man ofta för ”Isbjörnsboken” med anledning av förlaget O’Reillys gimmick med djur på omslaget. Den manifesterade informationsarkitektens roll som en utbrytning ur webbdesignernas skrå. Författarna skrev om hur man skulle strukturera information på en webbplats. Rollen har sedan breddats till att handla om hur man strukturerar information för en viss tillämpning, vilken som helst, inte bara webbsidor.

För denna roll finns det idag flera utbildningar på svenska och utländska universitet. När man googlar på ”Informationsarkitekt” eller liknande får man nästan bara träff på rollen eller kunskapsområdet i denna nyare betydelse.

Två skilda skrån

Vi behöver för den fortsatta diskussionen kunna skilja dessa två rörelser åt. Det finns de som har börjat kalla vårt äldre område för Enterprise Information Architecture” vilket jag tycker är klargörande. Ty vårt arbete är ju inte begränsat till en specifik tillämpning utan spänner över en hel verksamhet, eller i alla fall stora delar av en verksamhet. En svensk översättning av termen kunde vara ”Verksamhetsinformationsarkitektur” om det inte vore så långt och tungvrickande. Den andra nyare inriktningen skulle kanske kunna heta Service Information Architecture” eftersom den handlar om hur information presenteras inom en enskild tjänst, till exempel en webbapplikation, en webbsida, en elektronisk tjänst, en broschyr eller liknande. Men som sagt, det är endast min egen tanke.

Det finns ingen motsättning mellan dessa roller. Det finns beröringspunkter, men också skillnader i tyngdpunkt. Det märkliga är att det här är två olika kulturer som sällan möts. Vi inom dessa två områden borde interagera mera, men i stort sett har det fortsatt som två olika yrkesgrupper utan vidare kännedom om varandra.

Vad skiljer oss åt?

Det finns mycket som är gemensamt mellan rollerna eftersom det i båda fallen handlar om information och data.

Den stora skillnaden ligger i den yngre rollens fokus på hur man som användare brukar någon form av interaktiv tjänst. Rollen har ju sitt ursprung inom interaktionsdesign. Detta avspeglas i utbildningsinnehållet som har fokus på olika typer av användargränssnitt som kurser i webbutveckling och interaktionsdesign.

Detta saknas nästan helt och hållet i den äldre rollen som jag och mina kollegor är en del av. Den fokuserar på struktur, mening och egenskaper hos data och information i sig, gemensamt över alla tillämpningar, liksom över hela datadistributionen vilket naturligtvis ändå är en nödvändig grund för användbarheten för alla tillämpningar av data. Man kan säga att vi är ”presentationsagnostiker”. Det vi tar fram måste fungera för en hel verksamhet (eller ibland flera samverkande verksamheter eller hela branscher) tvärs över alla enskilda kommunikationskanaler och sammanhang.

Jag har också förstått att eftersom informationsarkitekter av den yngre rollen ligger så nära interaktionsdesigners i sitt arbete har de haft och har kanske fortfarande svårt att urskilja sig från de senare och motivera sin existens i den världen.

Kan vi närma oss varandra?

Om jag fick önska något skulle det vara att vi informationsarkitekter, oavsett inriktning kunde jobba närmare varandra och lära av varandra. Jag är säker på att vi av den äldre skaran skulle behöva bli bättre på informationsdesign och att de av den nya skaran skulle må bra av att lyfta blicken från enskilda tillämpningar till det större sammanhanget.

Men första steget måste då bli att vi känner till varandras existens. Det är med förhoppningen att bidra till den kännedomen jag skriver detta.

Vad säger du? Vad gör vi åt detta?

/Peter Tallungs IRM

Nästa artikel i ämnet informationsarkitektur publiceras torsdag 18 februari. Det handlar då om informationsmodellen som domänmodell. En informationsmodell beskriver inte bara data i en verksamhet utan även det som data representerar.  Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

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?