Vi kan göra bättre modeller – om gestaltning med grafik och text

Jag påstår att vi arkitekter kan bli bättre på hur vi utformar våra modeller. Mycket bättre! Detta är introduktionen till en serie artiklar där jag kommer att ge mina råd om hur vi med hjälp av bättre grafik och strukturerad text kan få våra modeller att bära mer kunskap och bli mer effektiva tanke- och kommunikationsverktyg.

Modeller är våra viktigaste verktyg

Modeller är arkitektens viktigaste verktyg. Vi arkitekter – vare sig vi är informations-, verksamhets- eller it-arkitekter – är i grunden modellerare. En nestor i branschen sa en gång: ”Jag modellerar vad som helst, var som helst, i vilket sammanhang som helst”. Jag brukar tänka på det.

Modeller är på samma gång ett tanke-, analys och kommunikationsverktyg. De blir mycket kraftfulla verktyg om vi förstår att utforma och använda dem rätt. En modell kan, rätt utformad, bli till en samarbetsplattform för lärandet i en organisation. 

Modellering är ett hantverk

Det är ett hantverk att göra bra modeller. Det kräver kunskap, vana och handlag. Och för en hantverkare är verktygen allt, de är som en förlängning av kroppen, sinnena och hjärnan. En hantverkare behöver därmed hålla sina verktyg i gott skick, så att de är skarpa och precisa.

Låt oss göra det.

Gestaltning är viktigt

En modell står och faller med hur den är utformad, i grafik och text. Om den tydligt förmedlar det som modelleraren vill förmedla, om den är krispigt klar, då gör den sitt jobb. Oavsett om den är en sann och användbar representation av det som modelleras, egentligen. Ty om modellen är tydlig går innehållet alltid att kritisera och förbättra. Den är lika mycket en fråga som ett påstående: ”Kan vi se det så här?”. Och frågor är minst lika viktiga som påståenden.

Om modellen inte är tydlig går idéinnehållet egentligen inte ens att kritisera. Ty det som man inte kan förstå kan man inte heller kritisera. Därför är det oerhört viktigt hur vi ritar våra modeller. Hela vårt yrke och yrkesområde, både som individer och som yrkesgrupp, står och faller med detta. Fast inte bara hur vi ritar. Modeller bör ha text också, och vi bör integrera grafik och text så att det bildar en helhet. Därför vill jag hellre säga gestalta och inte rita trots att grafiken har en framträdande roll.  

Hur står det egentligen till där ute?

Om man googlar på ”informationsmodell”, ”datamodell” eller liknande får man upp många olika exempel på diagram. Bilden som inleder denna artikel visar några slumpvisa träffar. Jag har inte valt ut vare sig bra eller dåliga exempel, utan bara det jag tycker kan vara representativt för hur det ser ut i våra verksamheter.

Jag tycker inte att man i något av dessa exempel, eller andra man kan hitta när man letar, har lyckats få modellerna att kommunicera på ett effektivt sätt. Vi kan göra mycket bättre, och det med enkla medel.

Hur ska man då göra?

Det finns inte mycket skrivet om hur man gestaltar modeller, och det lilla som är skrivet brukar vara upp åt väggarna enligt mig. Det är en stark åsikt och jag kommer att motivera den. Och inte bara motivera utan även visa på bättre sätt i de artiklar jag planerar att skriva framöver.

Det gäller inte bara informationsmodeller utan även andra modeller inom it- och verksamhetsarkitektur, så som förmågekartor, systemkartor, processmodeller med flera.

Låt oss bli bättre – tillsammans! 

Jag har i ett par decennier arbetat med att försöka utveckla hur man kan rita och skriva, för att göra bättre modeller. Jag har varit nyfiken på hur man gör inom andra yrkesområden där man gör modeller, ritningar, kartor och grafik i största allmänhet. Det jag lärt mig har jag sedan prövat att tillämpa på vårt område, i första hand informationsmodeller samt förmåge- och systemkartor. Och jag vill påstå att jag funnit sätt att rita och skriva, samt kombinera grafik och text, som jag menar har potential att lyfta hela vårt område. För om vi kan göra tydligare, skarpare och mer informativa modeller så kan vi bli mycket mer relevanta för våra organisationer.

Det betyder inte att jag vet och kan allt. Du kanske också har något att bidra med. Du har kanske andra insikter. Det är värdefullt om du då delar med dig. Så att vi tillsammans kan utveckla hela vårt område.

Exempel från ett helt annat område

Som en liten inledning vill jag visa ett mycket enkelt och vardagligt exempel från en helt annan bransch. Det är det elektriska kopplingsschemat till elsystemet på en bil, en Nash Ambassador från 1957. Det kanske inte är något märkvärdigt, det är så kopplingsscheman brukar ritas. Men ändå. Jag tycker att det finns så mycket klokskap och skicklighet i den grafiska gestaltningen som man kan begrunda och bara måste beundra. 

Lägg till exempel märke till följande:

  • Begränsningar: Tänk först på de begränsningar man hade: inget färgtryck samt begränsat utrymme.
  • Geografin i schemat: Titta sedan på hur man ordnat geografin i schemat. Längst upp har vi framlyktorna, sedan motorutrymmet med tändspole, fördelardosa och batteri. instrumentpanelen hittar vi långt ner på ritningen med alla strömbrytare och instrument. Baklyktorna ser vi längst ner. Hela ritningen är alltså utlagd schematiskt efter var i bilen respektive komponent sitter. Komponenterna är ordnade i grupper som är tydligt avgränsade från varandra. Man kan naturligt och utan ansträngning orientera sig i ritningen i förhållande till bilen i verkligheten.
  • Symboler: De olika komponenterna har symboler som är lätta att känna igen eftersom de avbildar komponenten ifråga symboliskt. Så länge man vet något om bil-el kan man mer eller mindre automatiskt känna igen komponenterna och behöver ingen symbolförklaring. Eller i varje fall, när man har stött på dem en gång är det lätt att erinra sig vad de står för nästa gång.
  • Linjer: Alla ledningar ritas som linjer, men de som går mellan batteri, laddningsrelä och generator är kraftigare. De representerar kraftigare kabel som ska klara starkare ström. Kabeln till startmotorn är på liknande sätt lite mittemellan i grovlek. Grovleken på linjen symboliserar hur grov kabeln är.  Linjerna är dragna med räta vinklar och ”hopp” där de korsar varandra. Linjer som ska till samma ställen är dragna tillsammans som grupp.
  • Ordning: Symboler, linjer och texter är placerade med raka marginaler. Hela diagrammet bildar en rektangel med raka marginaler.

Jag har försökt tänka hur man ska kunna förbättra kopplingsschemat ovan, men har inte hittat något sätt. Det är helt enkelt perfekt. Idag har vi förstås färgtryck, vilket skulle vara en fördel. Men i övrigt?

När jag ser vad man gjort inom detta och andra områden med grafik och gestaltning blir jag lycksalig, imponerad och ödmjuk. Det finns så mycket kunskap om hur man gestaltar ritningar och modeller inom olika yrkesområden. Det finns så mycket att lära sig av.

Varför har vi inte lärt oss?

Men varför är det så bristfälligt inom vårt område? Det vill säga allt som har med it- och verksamhet att göra. Varför har vi inte lärt oss?
Du som läser detta, tror du inte att vi inom vårt område skulle kunna bli lika bra på att gestalta med grafik och text som i andra branscher? Eller är det så att just vårt område är så omöjligt, att vi har en omöjlig uppgift? Vi kan i varje fall inte skylla på att vi är i en ung bransch. Verksamhets- och it-arkitekter har funnits i någon form i minst ett halvsekel. För mig är det en gåta. Hur har vi kunnat undgå att inte lära oss med tiden? Vad har hållit oss tillbaka? Jag vet inte, men jag tycker att vi nu har ett ansvar att bli bättre.

Hur blir vi bättre?

Vad kan vi då göra för att bli bättre? Jag vill i varje fall dra mitt strå till stacken. Jag kommer i en rad av artiklar framöver stegvis gå igenom det jag kommit fram till, med exempel och motiveringar. Några saker är kanske självklara för läsaren, några är kanske nya. Några är kanske kontroversiella i det att de motsäger sådant som annars brukar läras ut. Men jag tror verkligen att du, om du läser, begrundar och provar det som sägs kommer att utvecklas som modellerare och arkitekt.

Du behöver inte ens hålla med om allt, och det är ok. Men du kommer att bli tvungen att reflektera över hur du gör och varför.

Jag hoppas också att du vågar och vill kritisera mina råd. Det kan ju inte vara så att det bara är jag som har kunskap inom området. Eller att det jag säger är den slutgiltiga visdomen inom området. Min önskan är att fler vill bidra.

Det mesta jag kommer att skriva om framöver är mer eller mindre tillämpligt på alla slags modeller, och ibland till och med på alla slags grafiska representationer. Men en del konkreta råd gäller specifikt för informationsmodeller.

Mitt hopp är att det finns läsare som blir nyfikna på att utvecklas, som blir inspirerade till att experimentera och förbättra sina modeller i detta avseende. Det är det jag vill, så ett frö till en renässans inom området.

Vad jag kommer att beröra

Följande är en preliminär och grov plan över vilka ämnen jag kommer att ta upp i artikelserien.

  • Disposition:
    Hur vi placerar elementen i förhållande till varandra på diagrammet så att vi förmedlar vilken relation företeelserna har till varandra.
  • Struktur:
    Hur vi ger diagramytan en struktur som förmedlar hur vi ser på relationen mellan företeelserna.
  • Övergripande struktur:
    Hur vi kan ge hela modellen en meningsfull övergripande struktur.
  • Fokus:
    Hur vi lyfter fram centrala element.
  • Linjer:
    Hur vi drar relationslinjer så de blir tydliga och inte stör.
  • Namn:
    Hur vi benämner företeelserna och placerar namn.
  • Definitioner:
    Hur vi skriver definitioner och använder definitioner i diagrammet.
  • Verksamhetsregler:
    Hur verksamhetsregler har sin naturliga plats i informationsmodellen.
  • Färg:
    Hur vi använder färg.
  • Gråskalor:
    Hur vi använder gråskalor.
  • Samverkan tex och grafik:
    Hur vi får grafik och text att samverka.
  • Informationstäthet:
    Hur vi får våra modeller att förmedla allt vi behöver förmedla.
  • Diagramtyper:
    Hur vi kan utöka vår verktygslåda med fler diagramtyper.
  • Rika informationsmodeller:
    Hur vi kan få informationsmodeller att bära mycket mer kunskap och spela en mer central roll i en verksamhet.

Nästa artikel blir en rivstart.
Hoppas du vill hänga med! Om du har tankar kring detta – mejla mig: peter.tallungs@irm.se

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 3 mars. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Är du verksamhetsarkitekt och har konsulterfarenhet? Sök jobb hos oss!

Trivs du i gränslandet mellan verksamhet och it? Triggas ditt engagemang av komplexa verksamheter? Har du några års konsulterfarenhet som verksamhetsarkitekt? Gillar du dessutom att dela med dig av din kunskap? Perfekt!! Då vill vi att du söker tjänsten som verksamhetsarkitekt hos oss på IRM.

Efterfrågan på IRM:s tjänster och kompetens inom verksamhetsarkitektur är stor. Och så långt vi kan se kommer den fortsätta öka. Därför behöver vi nu bli fler som kan stötta våra kunder i samspelet mellan verksamhet och it.

Om oss

IRM gör sina kunder framgångsrika genom att guida dem och skapa stabil framdrift i deras verksamhetsutveckling. Vi arbetar modelldrivet med verksamhetsarkitektur, verksamhetsanalys, process-och verksamhetsutveckling, kravspecifikation, kvalitetssäkring och utbildning.

Vår ambition är att alltid leverera långsiktiga värden för våra kunder och att skapa goda relationer. I grunden är vi problemlösare. Med nyfiken omtanke och öppenhet för nya idéer finner vi de bästa lösningarna för kunden. Som individer har vi stor frihet samtidigit som vi även tar ansvar för framdrift, resultat och utveckling. Tillsammans odlar vi kreativitet, mångfald och nytänkande.

Om dig

Vår bild av dig är att du har jobbat en tid som konsult och är trygg i din roll som verksamhetsarkitekt. Och att du gärna delar med dig av din erfarenhet och kompetens såväl till nyfikna kollegor i lunchrummet som till kunskapstörstande elever i klassrummet.

Du är en självgående person som söker ett sammanhang där det råder frihet under ansvar, i en miljö där det finns utrymme att utveckla nya idéer och metoder. Du drivs av utmaningen att ge dina kunder hållbara lösningar och är bra på att skapa goda relationer.

Vi tror också att du, som många av oss, är något av en problemlösare som triggas av de utmaningar som finns i komplexa organisationer och verksamheter.

Har du dessutom erfarenhet av verksamhetsmodellen och metoden Vintergatan är vi en ”perfect match”.

Ansök genom att skicka ett mail och ditt cv till info@irm.se

Varmt välkommen med din ansökan senast 12 mars 2022.

Frågor besvaras av Henrik Friberg

E-post: Henrik.friberg@irm.se

Telefon: 0730-51 11 22

Hur kan informationsmodellering gå till? Del 2

Förra artikeln ”Hur kan informationsmodellering gå till? Del 1” beskrev vilka arbetsformer som kan finnas för informationsmodellering. Det gav en bild av själva verktygslådan som står oss till buds. Denna artikel ger exempel på hur man kan kombinera arbetsformerna i ett uppdrag. Jag tror att det är värdefullt att reflektera över och diskutera hur vi jobbar. Gör du likadant, eller på annat sätt?

Min erfarenhet är att informationsarkitekter gör ganska olika. Det är inte alla som omfamnar alla arbetsformerna. Man har kanske inte tagit möjligheten att utöka verktygslådan.

Jag har funderat på hur jag gör egentligen. Det vanliga är att jag löpande kombinerar och växlar mellan arbetsformer efter behov och läge. Jag kan skönja ett någorlunda återkommande mönster i vilken ordning och på vilket sätt jag växlar de olika arbetssätten. Jag ska nu försöka beskriva detta. Föreställ dig att uppgiften är en av de vanliga, att modellera de centrala delarna av en verksamhet. Alternativt kan det vara en avgränsad del av en verksamhet, som till exempel en större verksamhetsfunktion.

Steg 1: Skapar en karta

Det första jag gör är alltid detsamma. Jag börjar inte med att informationsmodellera, utan först behöver jag skapa något som kan ge överblick och fungera som en kontextkarta. Det vill säga en karta där jag sedan kan ge förankring, det vill säga sammanhang och avgränsning för de olika informationsmodeller jag tar fram. Det blir en karta över vilka verksamhetsfunktioner (eller om man vill kalla det för verksamhetsförmågor) det finns, och hur de relaterar till varandra. Där ritar jag in alla it-applikationer liksom hur de är integrerade med varandra och omvärlden.

Hur man tar fram en sådan förmågekarta har jag ännu inte beskrivit i denna artikelserie, men det är lätt och snabbt att göra, och blir en mångsidigt användbar karta, som visar vilka delar den består av och hur dessa samverkar. Det bli ofta första gången verksamhet och it får en gemensam karta där båda sidorna kan känna sig hemma.

Det intressanta är att det mest effektiva sättet att få fram en sådan karta är att re-engineera applikationsportföljen. Ty informationssystemen är idag en så integrerad del av en verksamhet att it-landskapet, om man tolkar det rätt, faktiskt ger den mest tydliga och sanna bilden av hur verksamhetens olika funktioner samverkar operativt.

Det går till så här: Jag workshoppar med it-arkitekterna och tar hjälp av deras kartor över vilka applikationer som finns. Ty finns det en applikation så finns det en verksamhetsfunktion som applikationen stödjer. Eller som jag vill se det: En applikation är alltid, per definition, en integrerad del av en viss verksamhetsfunktion. Hur dessa sedan är integrerade och används ger nycklar till beroendet mellan verksamhetsfunktionerna.

Att det fungerar går tillbaka på Conways law: “Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.

Fast då behöver man först göra klart för sig vad som egentligen utgör en it-applikation och vad som inte utgör en it-applikation. En it-applikation är, per definition, ett informationssystem som stödjer en viss verksamhetsförmåga. Det kan således vara ”Pelles månadsrapport”, ett Excel-ark, så länge det har en återkommande och operativ roll i verksamheten. Ett affärssystem däremot är sällan en applikation, utan en plattform för flera separata applikationer. Huvudboken är en applikation, leverantörsreskontra en annan, och så vidare. En integrationsplattform är heller aldrig en applikation, utan en kommunikationsinfrastruktur. Finns det någon verksamhetslogik som körs på en sådan plattform så är denna verksamhetslogik en egen applikation. En applikation som ägs av en verksamhetsfunktion och bara driftas på integrationsplattformen. För en verksamhetslogik måste per definition alltid ägas av en verksamhetsfunktion, och utgör då en applikation som ingår som en integrerad del i den verksamhetsfunktionen.  

Andra sätt att nysta ut hur verksamheten hänger ihop utgår ofta från saker som organisationsschemat eller processerna. Men det ger inte fakta på samma sätt som om man utgår från hur verksamheten verkligen fungerar och hänger ihop operativt, enligt ovan. Den bild man får fram när man gör en förmågekarta på det sätt jag beskrivit visar hur verksamheten fungerar på riktigt. Det blir sedan mycket intressant att lägga organisationsschema och processmodeller ovanpå detta.

Ännu mer intressant blir det att lägga på tjänsteperspektivet. Men då är vi kommit långt från informationsmodellering.

Vad beträffar informationsmodelleringen så blir en sådan förmågekarta användbar för att ge kontext åt de olika informationsmodellerna. Allt annat man kan göra med en sådan karta får det bli andra artiklar om.

Steg 2: Identifiera och få tillgång till scheman för de mest centrala databaserna, eller datakällorna

Jag behöver nu snabbt få ett första grepp om de centrala informationsstrukturerna. Det enkla och effektiva sättet är att ”reverse-engineera” databasschema för de mest centrala databaserna. Jag intervjuar it-arkitekter och förvaltningsansvariga för att få reda på vilka de centrala databaserna är. De förser mig med scheman, samt med upplysning om vem som är mest kunnig om respektive databas och som jag kan få störa med frågor allteftersom.

Steg 3: Tolka scheman

Jag går sedan igenom olika scheman, ofta databasscheman, tabell för tabell, kolumn för kolumn, och försöker tolka och rita början till en informationsmodell. Ofta får jag fråga den som vet vad som döljer sig i databasen och jag försöker med dennes hjälp ge bra konceptuella namn och definitioner till entiteter, attribut och relationer. Fast jag noterar också de fysiska namnen för att hela tiden behålla kopplingen till det fysiska.

Snabbt har jag nu ett första utkast till en informationsmodell som jag visar för kunniga it-personer. De ger mig feedback, korrigerar mina missförstånd och snabbt har vi en modell som representerar vår gemensamma förståelse så här långt.

Det här är ett lätt och roligt arbete i verksamheter som har egenutvecklade system. Även om det är gamla system är de nästan alltid relativt välstrukturerade vad gäller informationsstruktur och begriplighet. Det är min erfarenhet. Jag håller inte med om det som ofta sägs, att de gamla systemen är den stora bromsklossen.

Men med standardsystem är det en helt annan sak. Dels har de ofta tusentals tabeller varav nästan alla är så generella att de kan innehålla lite av varje. Ofta är också strukturerna misshandlade, både av företagen som utvecklar systemen och av den senare anpassningen när man har försökt få systemen att åtminstone hjälpligt stödja det som verksamheten behöver. Och vad värre är; ingen i organisationen har någon vidare kunskap om vilka data som faktiskt finns i systemen eller hur den är strukturerad. Om jag då vänder mig till leverantören så är det också där svårt att få vägledning. Dels har de inte så mycket grepp om vilka anpassningar som gjorts och hur olika strukturer har använts hos just denna verksamhet. Dels är de sällan så värst pigga på att hjälpa till om det inte handlar om merförsäljning. Ofta skäms de för att visa sina trassliga datastrukturer.

Arbetet att bringa ordning blir då betydligt knepigare, och långsammare. Men det finns ändå inget annat sätt än det jag beskrivit. Organisationen behöver ta tillbaka kontrollen över sina data och hur det hanteras.

Steg 4: Tolka data

Därigenom går jag igenom data i databaser och filer. Vanligen börjar jag med de mest centrala databaserna. Jag går igenom datainnehållet kolumn för kolumn. För varje kolumn kollar jag saker som följande:

  • För alla kolumner: Finns det tomma förekomster (vilket inkluderar innehåll som på något sätt kan tolkas som tomt)?
  • För textkolumner (utom de med ett litet och bestämt antal möjliga värden): Vad är de längsta textsträngarna? Är de klippta? Finns det konstiga värden?
  • För numeriska kolumner (utom de med ett litet och bestämt antal möjliga värden): Vad är minimi- och maxvärde? Finns det negativa värden? Finns det orimliga värden?
  • För kolumner med ett litet och bestämt antal möjliga värden: Vilka är värdena, och vilka antal har varje förekomst?

Tillsammans med någon kunnig går jag igenom hur man ska tolka innehållet, och bokför alla resultat. Jag listar särskilt de anomalier jag upptäcker, det vill säga de misstänkta bristerna i datakvalitet, så här långt.

Sedan går jag vidare på liknande sätt. Fast med den lite djupare förståelse jag nu har kan jag göra analyser med databasfrågor där jag kombinerar värden i olika kolumner, detta för att hitta mönster i data som kan förklara saker och ting.

Vid det här laget har jag fått en djupare kunskap om befintliga data och vad de betyder. Ofta får vi justera definitioner och ibland även namn på entiteter och attribut. Vi kan till exempel upptäcka att bland det vi trodde var kunder finns även leverantörer eller partners.

Så syftet är dels att få en djupare och mera rättvisande förståelse för vilka företeelser som hanteras av verksamheten och hur, det vill säga en mer korrekt informationsmodell och mera korrekta definitioner och beskrivningar än vad vi annars skulle ha. Dels får vi också en lista på brister till exempel saknad, motsägelsefull eller på annat sätt uppenbart felaktiga data. Detta kan bli input till data management-åtgärder, vilka kan vara att korrigera bristerna men också att utforma åtgärder för att den typen av fel inte ska uppstå igen.

Ibland får jag till och med tillsammans med en programmerare tolka någon algoritm i programkod som bestämmer värde på någon output, baserat på olika kombinationer av input-parametrar.  

Också detta är vanligen ett rättfram, roligt och enkelt arbete. Men även här blir det oerhört mycket knepigare när det är frågan om standardsystem.

Steg 5: Fördjupat arbete

I detta läge har vi kommit så långt man kan komma med dessa enkla och rättframma arbetsformer. Det har mest handlat om ett rakt och enkelt arbete. I en del fall räcker detta och vi kan mer gå över i en mer lugn takt, att fortsätta stödja utvecklingsarbetet i organisationen.

Men i många verksamheter finns det områden som har trasslat ihop sig ordentligt. Det kan vara en produktstruktur där man tappat greppet fullständigt. Eller att man har olika strukturer och begrepp i olika system och där ingen egentligen vet hur det hänger ihop. Då är det tidigare kartläggandet bara själva initierandet. Nu börjar det riktigt roliga! Ett detektivarbete med att lägga pussel och hitta mönster i oredan. De mest framträdande metoderna i detta arbete blir att varva dataanalys (för att hitta mönster och mening i oredan) med riktade eller spontana workshoppar med de tyngsta kunniga inom området, ofta analytiker av olika slag. Vi tar oss an ett område efter ett annat. Min erfarenhet är att det kan ta lite tid, men det går alltid att bringa ordning. Bara man har envishet. Man jobbar på, men forcerar ändå inte, saker och ting måste få mogna fram.

Detta är en förenkling

Denna beskrivning är naturligtvis förenklad. I verkligheten blir det mer att man växlar och blandar arbetsformer ännu mer. Men det ger ändå en bild av det typiska, hur tyngdpunkten stegvis flyttas från vissa arbetsformer till andra.

Hur jobbar du som informationsarkitekt? Liknar det mitt sätt eller är det helt annorlunda?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 24 februari. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Hur kan informationsmodellering gå till? Del 1

Modellering kan ske i olika arbetsformer. Varje arbetsform har sina speciella styrkor och svagheter. De behöver kombineras på olika sätt, över tid och också lite grand beroende på vad uppgiften är. Inte någonstans har jag sett en genomgång av och jämförelse mellan de olika arbetsformerna, vilket jag tror skulle vara värdefullt. I denna artikel försöker jag mig på att kategorisera och jämföra de olika arbetsformerna.

Det finns mer än ett sätt att fånga kunskap om begrepp och information i en verksamhet. Det är som en verktygslåda där ett antal olika arbetsformer är de verktyg man har till sitt förfogande. Verktyg som man i sitt löpande arbete behöver växla mellan och kombinera, alltefter uppgiftens karaktär och var man befinner sig i processen.

Jag har inte någonstans sett en genomgång av och jämförelse mellan de olika arbetsformerna, vilket jag tror skulle vara värdefullt. Då kan vi sedan gå igenom och reflektera över hur vi jobbar och varför. Och kanske kan någon också få inspiration till att komplettera sin verktygslåda eller bättre utnyttja något verktyg man redan har i sin repertoar.

Därför vill jag här och nu göra ett försök. Mina kollegor har hjälpt mig med indelning, namnsättning och beskrivning av arbetsformerna. Se det som ett försök. Saknar du någon arbetsform? Har vi missat något? Gör något åt det! Du är välkommen att hjälpa till.

Arbetsform 1: Seminarium

Modellering i seminarieform går till så att man samlar ett antal personer från olika delar av en verksamhet i ett eller flera längre seminarietillfällen. Man skapar tillsammans en informationsmodell som spänner över en hel verksamhet, eller en (vanligen större) del av en verksamhet.

Den stora styrkan med det stora modelleringsseminariet är det breda deltagandet. Folk från olika delar av organisationen får vara med och framföra sin syn på de företeelser som hanteras. Det man tar fram får därmed automatiskt en bred förankring

Det är kanske enda gången man på allvar får tillfälle att mötas runt verksamhetens centrala begrepp. Det ger ofta en insikt om var problemområdena finns, och vilka olika behov och synsätt det finns i organisationens olika delar. En skicklig faciliterare kan se till att det blir en bra dialog, där vägen kanske blir lika viktig som målet. Ingen annan arbetsform kan få till just detta.

Begränsningen med arbetsformen är dock tydlig:

  • Ett seminarium kräver stora resurser, det vill säga många personers tid som måste tas i anspråk och reserveras långt i förväg.
  • Det finns inte under själva seminariet tid och möjlighet till den fördjupning inom olika områden, som andra arbetsformer kan ge. Resultatet kan endast bli ytligt och därmed inte så användbart, annat än som en första översikt.

Det här är ett sätt att modellera som ofta var allenarådande, under 80- och 90-talet. Många konsultbolag erbjöd facilitering av modelleringsseminarier som en paketerad tjänst. Man bokade ett par heldagar med någon vecka emellan. Konsultbolaget tillhandahöll vanligen två seminarieledare, eller faciliterare. En som ledde och den andre som ofta hade en mer observerande roll. Resultatet levererades som en rapport med en modell dokumenterad i diagram och text.

Arbetet blev gärna ett ”one-shot”. Resultatet blev vad det råkade bli och togs sällan vidare. Man följde sällan upp arbetet med andra arbetsformer. Det kanske mest berodde på att arbetet vanligen leddes av någon extern part som hade en paketerad tjänst med ett paketerat resultat.

Jag tycker att jag har fog för att påstå att resultatet av detta arbetssätt sällan eller aldrig blev särskilt hållbart. Många gånger har jag kommit till ett företag för att utveckla något system eller verksamhetsfunktion och då fått en rapport från en sådan seminarieserie stucken i händerna på mig. Modellen har egentligen aldrig varit till hjälp, för den har utan undantag visat sig för ytlig och bristfällig när man trängt lite djupare. Ingen har jobbat vidare med modellen och ingen har egentligen använt resultatet. Och ingen modellerare finns kvar för att ta hand om den nya input och den fördjupade kunskap som alltid, utan undantag, kommer då man använder en modell.

Det enda påtagliga resultatet är en hyllvärmare i it-chefens bokhylla. Dock ska vi inte förringa värdet av att folk från olika delar av verksamheten fått tillfälle att tänka och diskutera tillsammans. Synd bara att det blir ett engångstillfälle.

På de modelleringskurser som fanns på 80- och 90-talen så nämndes inga andra arbetssätt än seminarier av detta slag. Det förutsattes att det var så informationsmodellering skulle gå till, punkt slut. Och kanske är det så på en del håll även idag.

Jag tror att vi numera kan vara överens om motsatsen. Att informationsmodellering är något som måste ske mer eller mindre kontinuerligt för att vara hållbart. Arbetet behöver kombinera olika arbetssätt och modellen (eller modellerna) blir egentligen aldrig ”klara”. Modellen avspeglar i varje läge vår nuvarande gemensamma förståelse, vilken alltid utvecklas med tiden.

Somliga kollegor hävdar att seminarieformen kan ha sitt berättigande ibland. Fast då som en start på ett kontinuerligt arbete, och inte för att ge ett avslutat resultat. En förutsättning är då att man planerar för en kontinuitet, att de mest centrala deltagarna i seminariet fortsätter arbetet under andra arbetsformer.

Arbetsform 2: Riktad workshop

Ofta behöver man samla några experter inom ett visst område som behöver redas ut. Ibland sakkunniga från ett par närliggande områden som behöver enas om gemensamma begrepp. En riktad workshop skiljer sig därmed från det stora seminariet genom att workshopen är avgränsad och koncentrerad till ett smalare och djupare område eller till och med till en specifik frågeställning. Workshopen är, till skillnad mot seminariet, lätt att upprepa vid behov.

Det här är en naturlig del av det kontinuerliga arbetet som informationsarkitekt ute i verksamheter. En sådan liten workshop är lätt att organisera, har ett tydligt syfte och är effektiv. Eftersom endast de som är kunniga inom området är med så kan man snabbt gå djupt i området. Ingen behöver vara med som ”gisslan”.

Ofta har man en serie av sådana möten med samma grupp. Deltagarna behöver kanske tid att tänka och undersöka saker innan man träffas igen. Och jag som informationsmodellerare behöver rita och skriva på modellen, och inte minst reflektera över den vunna kunskapen, som jag sedan kan presentera som ett delresultat för att fördjupa diskussionen. På så sätt börjar man sällan från noll, vare sig med själva förståelsen eller kommunikationen, eller för den delen hur man jobbar tillsammans. Man hittar alltid sätt att effektivt tränga djupare i den gemensamma förståelsen, och att lösa upp knutar.

Arbetsform 3: Spontan workshop

En variant på workshop är att man tar ett mer eller mindre spontant och kortare arbetsmöte med en eller ett par experter inom något område. Jag har kanske stött på en frågeställning som jag behöver reda ut eller få perspektiv på. Eller så vill jag förankra det jag tycker mig ha förstått. Eller bara bolla någon idé.

Det här är mer eller mindre ett dagligt inslag av arbetet för en informationsarkitekt i en verksamhet.
Ofta består hela min tid av att jag sitter bredvid en expert av något slag, och kan störa hen vid behov, för att ställa frågor och bolla idéer spontant utan att behöva boka ett möte.

Jag brukar beskriva mitt arbete som att jag under en tid sitter bredvid en mycket kunnig person, en expert. Hen har sitt ordinarie arbete men jag får tillåtelse att störa. Jag ställer frågor och ritar. Experten tittar på modellen och avfärdar den ofta. Jag justerar, provar något annat, visar på nytt och det hela upprepas. Ända tills personen blir nöjd med vad som visas och vi båda är nöjda med att det är det bästa sättet att representera kunskapen för tillfället. Då vet jag att vi nått någonstans. Tillsammans. Mitt jobb är sålunda att göra expertens kunskap kommunicerbar. Det hela är på sätt och vis en ständigt pågående workshop. Fast med långa uppehåll av reflexion och ingen press att komma framåt med en gång, utan saker och ting får mogna fram i den takt det tar. Med tid att sova på saken, göra omtag, forska, läsa på, experimentera, involvera någon annan. På detta sätt har vi ofta snabbt enkelt och effektivt kunnat nysta ut mycket trassliga strukturer i verksamheter. Härvor som alla sagt vara omöjliga.

Kunskap finns hos personer i verksamheten men den är aldrig jämnt fördelad.
Nästan alla verksamheter har någon person som har mycket djup kunskap, som vet det mesta. Om inte annat så vet denne vem man ska fråga och har kunskap om sammanhanget för att rätt tolka svaret. Men personen kan inte alltid kommunicera det den vet. Det är just det som är mitt jobb, att hjälpa till med det.

Det märkliga är det som ofta händer när man jobbat med ett problem utan att komma fram till något som känns tillfredställande. Man har problemet i huvudet dygnet runt, det ligger där och gnager. Inte på ett obehagligt sätt, men som en retsam irritation. Då kan man plötsligt känna att man snart kommer att komma på något. Man har ännu ingen aning om vad det är, bara att det kommer att komma. Och plötsligt får man ett genombrott. Det kan vara i duschen, på promenaden, ofta mitt i natten. Ett Heureka moment (en aha-upplevelse). Det är kanske inte det slutliga svaret, men det är ett genombrott, ett sätt att se på problemet som öppnar för ett mer fruktbart synsätt.

Det är just det som är mest fascinerande med modellering tycker jag. Det viktiga är att arbetssättet måste ge utrymme för att insikterna måste få mogna fram. Det är ett misstag att tro att det därmed tar längre tid. Det gör det inte. Bara att resultatet inte kan kommenderas fram. Därför är det här arbetssättet centralt, det som sker mer eller mindre löpande.

Arbetsform 4: Studie av dokumentation

Jag letar nästan alltid reda på olika slags dokumentation, beskrivningar och definitioner av de företeelserna jag behöver modellera, både internt och externt, och studerar dessa för att få en djupare förståelse.

När jag ska förstå ett område behöver jag alltid börja med att studera det. Det här är något jag alltid gör, något jag börjar med och som jag återkommer till parallellt med övrigt arbete. Det kan handla om att förstå hela området. Jag har till exempel under min tid i försäkringsbranschen köpt otaliga böcker om försäkring för att verkligen förstå kunskapsområdet på djupet. Eller så kan det handla om att på djupet förstå specifika företeelser eller begrepp. Jag googlar för att få definitioner och beskrivningar av olika saker. Jag söker på internt intranät och filservrar för att hitta beskrivningar dokument och exempel.

Arbetsform 5: Analys av datastrukturer

Jag studerar de datastrukturer som förekommer i verksamheten. Det är ofta databasscheman men kan också vara filbeskrivningar, formulär, scheman, tjänstebeskrivningar med mera.

Att förstå vilka datastrukturer som används idag är mer eller mindre oundgängligt för att både bredare och djupare analysera en verksamhets informationsförsörjning.

Det här är något jag gör tidigt i arbetet, så snart jag fått klart för mig vilka de centrala databaserna och filerna är. Genom att studera och tolka de centrala datastrukturerna i en verksamhet får jag snabbt och effektivt fram huvuddragen av vilken information som hanteras. Samt att jag kan jag koppla informationen till var och hur den lagras och hanteras.

Det fanns förr en föreställning om att man ska hålla sig på avstånd från befintliga lösningar. För att inte riskera att i tanken fastna i befintliga lösningar, ”asfaltera kostigar” som man sa. Den farhågan anser jag var kraftigt överdriven. Så överdriven att den närmast var en felföreställning. Jag tror att den föreställningen snarare har fungerat som ursäkt för att slippa fördjupa sig i något jobbigt grävande.

Man har då avfärdat det som att det är tekniska detaljer och utan intresse. Jag menar tvärtom. Att vi, om vi vill göra ett bra jobb, måste intressera oss för strukturen hos informationen i dag, även om den har sina brister.

Det betyder inte att man direkt får fram en informationsmodell genom att re-engineera en fysisk datamodell. Till det behövs det en tolkning, vilken de andra arbetssätten ger mig.

Arbetsform 6: Analys av data

Jag analyserar innehållet av data i olika former av datalagring och dataöverföringar som används av verksamheten. Det kan vara databaser, filer, ifyllda formulär etcetera.

Data ger fakta som ingen annan metod kan ge. Finns det en post i en databas så har det hänt något i verksamheten. Det är fakta. Allt annat är egentligen hörsägen eller indirekt kunskap. Sedan gäller det förstås att rätt tolka vad posten betyder. Det har jag alla de andra metoderna till.

Jag kallar det ”data-arkeologi”. Liknelsen är med historievetenskap, där man kan ställa metoden arkeologi mot metoden historisk antropologi. Inom arkeologin får man fram fakta. Om man hittar någon artefakt i marken så har det otvetydigt hänt något där. Sen behöver det tolkas förstås. Historie-antropologer å andra sidan intervjuar naturfolk för att bättre förstå hur man kan ha levt i äldre tider med liknande förhållanden. Lite tillspetsat kan man säga att arkeologer ”gräver i ruiner” och antropologer ”pratar med infödingar”. På samma sätt är det med analys av data. Hittar jag en post i en databas så har det hänt något i verksamheten. Det är fakta. Sedan behöver jag ju alltid tillsammans med folk från it och verksamhet reda ut vad som hänt.

Jag menar att denna ”data-arkeologi” ger mig en fast grund av fakta att stå på. Mer fast än någon annan metod. Därför är det synd att det är en nästan okänd och outnyttjad arbetsmetod inom informationsmodellering. En orsak kan vara att metoden kräver lite mer tålamod och att man inte är rädd för att gräva i databaser, sortera och analysera data och att lära sig de verktyg som behövs för detta.

Hur kombinerar man arbetsformerna?

Jag tror att informationsarkitekter gör ganska olika. Det är inte alla som omfamnar alla arbetsformer. Man kanske mest kopierar det andra gör och har inte hittat till hela verktygslådan. Men när jag diskuterar med kollegor är vi ändå i hög grad ense om de olika arbetsformernas styrkor och svagheter.

Observera att denna artikel är strikt avgränsad till arbetsformer där det mer direkt sker en modellering. Jag måste ha fler sätt att skaffa mig förståelse av verksamhetens förmågor och sammanhang. Till exempel gör jag förmågekartor, intervjuer, deltagande observationer med mera. Det är minst lika viktigt som själva modelleringen. Men jag väljer här att se det som en annan del av verktygslådan, även om gränsen kan vara lite suddig.

I nästa artikel ger jag exempel på hur det kan gå till att kombinera arbetsformerna i ett uppdrag.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 17 februari. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se

Hur kan vi organisera arkitektarbetet?

Hur kan vi organisera arbetet med informationsarkitekturen i en större organisation? Vad är viktigt för att få samverkan med de olika parterna att fungera? Något vi kan vi skippa på en gång är den traditionella toppstyrande arkitektfunktionen.

Men hur kan vi då göra? I denna artikel går jag igenom tänkbara organisationsmodeller samt ger grundläggande förhållningssätt för den samverkan vi behöver få till i våra organisationer.

De finns en traditionell organisationsmodell för arkitekturarbete i en organisation. Man tänker sig att en centralt placerad grupp av arkitekter tar fram en målarkitektur för olika områden och att denna grundritning sedan ska följas av de olika projektteamen. Denna toppstyrning fungerar inte alls. För att ett arkitekturarbete skall fungerar måste det drivas som en organisk och kontinuerlig samverkan med och mellan organisationens olika funktioner och utvecklingsinitiativ.

Så den traditionella toppstyrande arkitektfunktionen är ett alternativ vi kan skippa på en gång. Vilka andra organisationsmodeller kan då fungera? Låt oss gå igenom och jämföra några alternativ.

Organisationsmodell 1: Självorganiserande team

Team som är skickliga på att samverka och kommunicera kan operera utan central auktoritet. Oftast har en eller några få personer i teamet en viss grad av översiktligt ansvar för den övergripande strukturen. Det är viktigt att en sådan person är arkitekt/utvecklare och kommunikatör i samma person. Den personen ska inte ta designbesluten ensam utan behöver kontinuerligt samverka och kommunicera med berörda parter både inom och utanför teamet.

Ofta uppstår en sådan roll spontant. Teamet måste i så fall ha en kärna av ett fåtal personer med tillräcklig kompetens för att ta de större designbesluten. Detta kan fungera, åtminstone i en mindre organisation. Men det kräver som sagt en hel del av teamet.

Organisationsmodell 2: Informell samverkan mellan självorganiserande team

När en övergripande struktur spänner över flera områden börjar team som har beroende till varandra att samarbeta på ett informellt sätt. Varje team gör upptäckter som leder till idéer för den övergripande strukturen. De olika möjligheterna diskuteras av en informell kommitté med representanter från de olika teamen. Teamen rör sig framåt tillsammans som en lös sammanslutning.

Denna ordning kan fungera när det är få team som skall koordineras, när de alla är motiverade att koordinera sig, när deras designförmågor är jämförbara och deras behov av struktur tillräckligt lika för att tillgodoses av en gemensam övergripande struktur.

Det som effektivt saboterar ett sådant samarbete är när incitament att bli klar i tid och på budget övertrumfar nytta och långsiktighet. Vilket tyvärr är vanligt i många organisationer. Då tvingas teamen att var och en köra sitt eget race.

Organisationsmodell 3: Ett centralt arkitektteam

När en strategi skall spänna över många team behöver vissa beslut tas centralt. Då behövs ett centralt arkitektteam.

Ett centralt arkitektteam bör arbeta på ett kollegialt sätt tillsammans med de olika teamen. Man behöver ha inställningen att man stödjer teamen med att koordinera och harmonisera övergripande strukturer och andra frågeställningar mellan teamen.

På ett organisationsschema ser detta ut som det traditionella toppstyrande arkitektteamet, det ökända ”elfenbenstornet”, men det får inte förväxlas med detta. Det är i själva verket ett helt annat sätt att styra, i varje aktivitet. De centralt placerade arkitekterna arbetar tillsammans med projektarkitekterna och utvecklarna i teamen, vilka experimenterar tillsammans med olika team för att få fram bästa övergripande strukturen.
Kort sagt, de centralt placerade arkitekterna gömmer sig inte bakom sina PowerPoint. De är inte rädda för att smutsa ner händerna med riktigt arbete tillsammans med utvecklarna i teamen.

Grundläggande förhållningssätt för samverkan

I det följande listas några grundläggande förhållningssätt för den samverkan som behövs i arkitekturarbetet i en organisation.

1. Arkitekturen för ett visst utvecklingsinitiativ måste ägas av projektteamet självt, inte av ett separat arkitektteam

Centrala arkitektteam har vanligen en officiell auktoritet. Men de ignoreras ofta eller kringgås. Orsaken är följande: När det som arkitektteamet tar fram skall tillämpas i projekten fungerar det inte så bra. Arkitektteamet är då vanligen inte så mottagligt för återkoppling. De är avskärmade från den praktiska verkligheten och har sällan de praktiska kunskaperna som skulle behövas för att kunna engagera sig. Fenomenet är så vanligt att det fått ett namn: ”Ivory Tower Architects”. Därmed har utvecklare ofta inget annat val än att ignorera eller kringgå det centrala arkitektteamet.

Om den strategiska designen i stället växer fram inom projektteamet når den ut mycket mera effektivt, förutsatt att teamet kommunicerar och samverkar med sin omgivning på ett bra sätt. Designen blir då relevant för projektet och får den naturliga auktoritet som följer med ett genomtänkt community-beslut. De centrala arkitekterna är mindre av poliser och mera av facilitatorer, kommunikatörer och coacher för att stödja projektet. De hjälper teamen med att se och beakta de bredare och långsiktiga perspektiven i verksamheten.  

För att skapa en övergripande struktur måste man ha en djup förståelse för projektet och för domänen. De enda som kan nå det djupet av förståelse är medlemmarna i teamet. Det förklarar varför en projektarkitektur skapad och ägt av ett separat arkitektteam sällan fungerar.

2. Arkitekturen måste tillåta ständig utveckling

Om arkitekturen är låst i onödan så får inte teamet den flexibilitet de behöver för att lösa det problem det har ansvar för. En överordnad harmoniseringsprincip kan behövas, men arkitekturen måste kunna utvecklas och förändras i takt med att projektet lever sitt liv.

3. Arkitektteamet måste undvika att suga upp alla de bästa och smartaste utvecklarna

Ledningen brukar vilja överföra de skickligaste utvecklarna till arkitektteamet. De vill få en hävstångseffekt på deras talang. Utvecklaren själv är tilltalad av möjligheten att få ett bredare inflytande och/eller arbeta med ”mera intressanta” problem. Det är också prestigefyllt att vara medlem i det som upplevs som ett elitteam.

Problemet blir då att bara de mest oerfarna utvecklarna blir kvar för att bygga och vidareutveckla applikationerna. Men att bygga och förvalta en bra applikation kräver erfarenhet.
Ett annat problem är att utvecklare med mest kunskap om domänen sällan blir medlemmar av arkitektteamet.

Båda teamen, både det centrala arkitektteamet och utvecklingsteamet, kräver utvecklare med designförmåga och domänkunskap.

4. Strategisk design kräver minimalism och ödmjukhet

Destillering och minimalism är viktig för all design, men mest av allt för den strategiska designen. Det är en kärna i arkitekturarbetet. Men allra viktigast är ödmjukheten, att inte låsa fast sig, utan lyssna, ompröva och fördjupa designen kontinuerligt.

Akta dig för masterplanen!

Till sist vill jag citera Christopher Alexander, byggnadsarkitekten och designteoretikern, fadern till idén om mönster inom design:

The master plan attempts to set down enough guidelines to provide for coherence in the environment as a whole – and still leave freedom for individual buildings and open spaces to adapt to local needs.

…in practice master plans fail—because they create totalitarian order, not organic order. They are too rigid; they cannot easily adapt to the natural and unpredictable changes that inevitably arise in the life of a community.

… The attempt to steer such a course is rather like filling in the colors in a child’s coloring book…. At best, the order which results from such a process is banal.

…Thus, as a source of organic order, a master plan is both too precise, and not precise enough. The totality is too precise: the details are not precise enough.

… the existence of a master plan alienates the users [because, by definition] the members of the community can have little impact on the future shape of their community because most important decisions have already been made.

Från: The Oregon Experiment (Alexander et al. 1975) 

                                      

Alexander och hans kollegor förespråkar i stället en uppsättning principer som alla medlemmar av en community ska tillämpa för varje steg i den gradvisa framväxten av det man utvecklar.
Då växer det fram något av en organisk ordning, som är väl anpassad till omständigheterna.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 10 februari. Vill du prenumerera på denna artikelserie? Registrera din mailadress här.

PS Vi har tyvärr varit tvungna att ta bort möjligheten att kommentera på artiklarna för en tid. Har du tankar om innehållet i artikeln som du vill dela? Välkommen att kommentera på vår linkedin där lägger vi ut en post vid varje publiceringstilfälle. Eller skicka ett mail till Peter Tallungs: peter.tallungs(at)irm.se