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

Om den storskaliga skiktningen av en modell

Föregående artikel, Strategimönster för informationsarkitekter del 5 – Den storskaliga strukturen, handlade om själva processen att få till en bra storskalig struktur för sin informationsmodell. Ett av strategimönstren i artikeln hette ”Skiktning av modellen efter ansvar”.

Frågan blir då: Hur ska då en sådan skiktning se ut? Det finns inte ett svar på den frågan som fungerar för alla modeller, men det finns vissa mönster som ofta framträder då man betraktar domäner lite djupare, det vill säga då man modellerar. Låt mig beskriva några av dessa.

Inom arkitektur och ingenjörskonst, av vad slag det månne vara, finns det några verkligt grundläggande mönster som utgör själva basen i hur en arkitekt eller ingenjör kan tänka. Det handlar om hur man på ett logiskt sätt kan strukturera sin värld. Man behöver skapa någon slags ordning, hitta en struktur för att hantera den komplexitet som finns där. En ordning som hjälper oss att förstå och förklara. Ett sådant grundläggande mönster är hur saker och ting är ordnade i komponenter som är någon form av företeelser som var och en är tydligt avgränsade från varandra. Ett annat grundläggande mönster, det som vi här ska beröra, är att dessa komponenter på något sätt kan ordnas i skilda skikt, eller lager, som tänkes placerade över varandra. Vi kan kalla det för en skiktad arkitektur.

Vi har alltså två mycket grundläggande mönster. Dels hur man ordnar det man ska analysera eller designa i komponenter av något slag. Dels hur man sedan kan ordna dessa komponenter i skikt.  Man skulle kunna kalla dessa för supermönster eftersom de är så grundläggande för vår förståelse och överallt förekommande och användbara.

Vi kommer här att gå igenom vad en skiktad arkitektur innebär, först med exempel från helt andra områden än informationsmodellering, sedan vad det kan betyda för en informationsmodell.

Vad är en skiktad arkitektur?

Som sagt tänker man sig att komponenterna är ordnade i två eller flera skikt. Ett skikt längre ner förutsätts vara mer stabilt än det skikt som är över, det vill säga ha en långsammare förändringshastighet. Alla komponenter i ett visst skikt utgör tillsammans ett ”språk” och en bakgrund som komponenterna i det skikt som är över detta får mening av. Komponenterna i ett visst skikt har ett beroende till komponenter i det skikt som är direkt under sig, samt kan ha beroenden till andra komponenter i det egna skiktet. Däremot får de inte vara beroende av komponenterna i något skikt över sitt eget. Det är själva kärnan i tänkandet, att beroendena inte går hur som helst utan strikt i ena riktningen.

Det finns sedan två varianter av skikt; ”Strict layering” där komponenterna bara känner till och använder komponenter i skiktet direkt under sig (vid sidan av komponenter i det egna skiktet), samt ”relaxed layering” där komponenter även kan använda komponenter i skikt längre ner än det skikt som är direkt under.

Skiktning på detta sätt, ibland strikt, ibland mindre strikt, har tillämpats så gott som överallt där människor tänkt ut eller konstruerat saker. Det är detta som gör det till något av ett supermönster. För att ge en känsla för vad en sådan skiktning innebär, generellt sett, ger jag här några exempel från helt andra områden än informationsarkitektur.

Exempel 1 på skiktad arkitektur: Byggnadsarkitektur

En byggnad kan ses som att den har flera skikt som kan placeras längs en skala efter förändringshastighet:

  • Platsen där byggnaden är placerad (ca 100–1000 år).
  • Grund och stomme (ca 100–300 år).
  • Ytter- och innerpanel samt takbeklädnad
    (ca 50–100 år).
  • Installationer, dvs värme, vatten, avlopp, elektricitet (ca 40–60 år).
  • Ytskikt: Färg, tapeter (ca 10–30 år).
  • Inredning: Möbler, tavlor (ca 5–25 år).
  • Dekoration: Blomvaser, dukar (ca 1–30 dagar).

Här är det tydligare att prata om ett inre och yttre skikt, än ett undre och övre. De innersta lagren är det som sitter djupast i väggar, golv och tak och de yttersta det som sitter utanpå väggarna, på insidan eller utsidan. Vi ser att de olika lagren har mycket olika förväntad förändringshastighet. Därmed är det naturligt och mycket lämpligt att de som är mer snabbrörliga har ett beroende till de som är trögare, och inte vice versa. Samt att lagren hålls strikt åtskilda så beroendet är enkelt och lättförändrat.

Annars blir det problem. Till exempel om man gör möblerna väggfasta. Jag lade en gång ner en stor möda på att göra en mysig väggfast säng till min dotter, perfekt för den 10-åring hon var då. Men när hon blev femton och rummet blev till ett hang out för tjejgänget blev sängen pinsam, så jag fick riva.

Där bröt jag mot regeln att något (i detta fall en säng) som tillhör ett ganska snabbrörligt skikt inte bör ha för komplicerade beroendet till ett mera trögrörligt skikt (väggen).

För att inte tala om när våra hantverkare gjöt in elkablarna i betongen i källarväggarna!

Exempel 2 på skiktad arkitektur: Programvaruarkitektur

It-arkitekturer är nästan alltid skiktade på liknande sätt, vare sig det är arkitekturen i en specifik programvara eller det är den övergripande uppbyggnaden av applikationer eller tjänster i en verksamhet.

Men jag upplever att man inte så ofta har tänkt på varför man gör så, att det ytterst handlar om förväntad förändringshastighet och – sammankopplat med detta – var förändringskrav emanerar från.

Exempel 3 på skiktad arkitektur: Kommunikationsprotokoll

Kommunikationsprotokoll, det vill säga standarder för hur vi kommunicerar i olika sammanhang är alltid skiktade på liknande sätt.

Hur kan vi skikta en informationsmodell?

När vi tar fram en större informationsmodell behöver vi ge den någon slags övergripande struktur så att den blir begriplig och hanterbar. Först och främst behöver vi dela in den i sammanhängande ämnesområden. Det blir det vi kan se som våra komponenter i detta sammanhang. Sedan behöver på något sätt organisera dessa ämnesområden. Då kan det vara en idé att använda supermönstret ”Skiktad arkitektur”.

Men vad ska denna skiktning baseras på? Det är just detta den här artikeln vill hjälpa till med. Jag tror inte att det finns ett enda universellt svar som fungerar i alla verksamheter, men det finns vissa mönster för detta som ofta framträder då vi betraktar olika verksamheter. Låt mig beskriva några av dessa.

Strukturmönster 1: Skiktning i Tillgångar och Operationer

En del verksamheter är baserade på att exploatera fasta tillgångar som till exempel maskiner, fastigheter, fordon eller fartyg. Då kan man organisera informationsmodellen i följande två skikt:

  • Tillgångsskiktet (Capability layer eller Potential layer)

Tillgångsskiktet uttrycker vilka tillgångar och resurser som finns och vad som kan göras med dessa. Även personal och hur den är organiserad hör hit, likaså kontrakt med leverantörer, i de fall de kan betraktas som stabila.

Detta skikt kan man hitta i nästan varje verksamhetsområde, men det är mer framträdande i verksamheter som transport och tillverkning som har stora fasta kapitalinvesteringar (anläggningstillgångar) som möjliggör affären.

Skiktet innefattar också omsättningstillgångar (tillgångar avsedda för omsättning eller förbrukning), men verksamheter som drivs främst genom omsättningstillgångar bör i stället välja skikt som tydliggör detta.

  • Operationsskiktet (Operation layer)

Uttrycker vad som verkligen görs. Vilka aktiviteter som gjorts och vad som sålts.

Operationsobjekt refererar typiskt tillgångsobjekt, men ett tillgångsobjekt kan aldrig referera ett operationsobjekt. Vi får därmed en skiktning där tillgångsskiktet är ett undre skikt och operationsskiktet ett övre.

I de flesta fall i denna typ av verksamheter kan det räcka med ett tillgångs- och operationsskikt för att täcka allt på ett bra sätt. De rymmer både en beskrivning av den nuvarande situationen och aktiva operativa planer liksom händelserapportering.

Men ibland kan det finnas behov av ett till skikt, vilket presenteras i det följande.

Strukturmönster 2: Beslutstödsskikt (Descision Support layer):

Att bara spåra och rapportera vad som händer räcker inte för alla verksamheter. När modellen ska stödja beslutsfattande på ett mer genomarbetat sätt kan man tala om ett ytterligare skikt ovanför operationsskiktet; beslutstödsskiktet

Skiktet är till för analys av verksamheten och beslutstöd. Det baserar sin analys de lägre skikten, det vill säga tillgångs- och operationsskikten. Beslutsstödsystem använder historisk information för att aktivt söka möjligheter för nuvarande och framtida operationer.

Sammanställande beskrivning av de olika skikten så här långt

Här kommer en sammanställning av de tre möjliga skikt vi hittills tagit upp.
Observera att det som skiljer skikten inte bara är förändringshastigheten hos strukturerna i sig utan även, och kanske främst, tillståndsförändringar hos företeelserna i skiktet, vilket avspeglas i volatiliteten hos data.

Utöver de skikt vi nu har gått igenom kan det kanske i vissa speciella fall finnas fog för ett par mer udda skikt. De nämns i det följande.

Strukturmönster 3: Policyskikt (Policy layer)

Ett skikt skulle kunna vara för att hantera övergripande mål och regler. Det vanliga och mer lämpliga är att man lägger de regler som beskriver ett visst objekt i samma del av modellen som objektet självt. Men i vissa fall skulle man kanske kunna tänka sig regler som spänner tvärs över hela modellen. I så fall kan man behöva ett policyskikt.

Jag tror dock att det är mycket ovanligt att man vill ha med den typen av regler i en informationsmodell. Policyskiktet uttrycker regler och mål som spänner över hela verksamheten och som styr och begränsar beteendet i andra skikt. Den typen av allomspännande regler räknas inte till det man kallar verksamhetregler och hör därmed egentligen inte hemma i en informationsmodell. Jag kommer att ta upp detta med verksamhetregler i senare artiklar i denna serie.

Strukturmönster 4: Kundförbindelseskikt (Comittments layer)

Kundförbindelser uttrycker vad vi lovat. Det kan vara av mycket olika art och därmed motivera olika placering. De kan ibland vara av en art som liknar policys när de utrycker mål som styr framtida operationer. Men de kan också likna saker i operationsskiktet i det att förbindelser uppstår och förändras som en del av den pågående affärsaktiviteten. Kundförbindelser kan också i en del fall, då man har långa och varaktiga åtaganden mer eller mindre ersätta tillgångar. Det innebär att de kan finnas i ett eller flera av de andra skikten. Men ibland kan det kanske vara motiverat med ett särskilt skikt.

Var hamnar ett Policyskikt eller ett Kundförbindelseskikt i skiktningen?

Jag är mycket osäker på var dessa extra skikt hamnar i en skiktning, det vill säga om man kan säga något bestämt som alltid gäller om hur beroendena går mellan dessa och de övriga skikten. Jag tror att det beror på typen av verksamhet. I vilket fall bör man bestämma hur beroendena ska tillåtas gå. Om beroendena får gå hur som helst har man i realiteten ingen skiktning.

Skikt i en annan mening: Regelplan i modellen

Jag har i artiklarna om modellmönster tagit upp hur användbart det är att skikta en del av en modell, det vill säga ett ämnesområde, i ett operativt plan och ett regelplan. Det är en skiktning som inte får förväxlas med den storskaliga skiktningen i denna artikel. Den skiktningen verkar i en mycket mindre skala, det vill säga inom ett ämnesområde.

Inte bara för informationsmodeller

Ovanstående mönster är tillämpliga inte bara för informationsmodeller utan även i kanske ännu högre grad för förmågekartor och liknande. Det är ju i grunden ett sätt att gruppera och hantera alla förmågor i en verksamhet.

Vilka övergripande strukturer har du tillämpat?

Jag tycker att detta med strukturmönster är oerhört intressant och något jag skulle vilja utveckla än mera. Det finns nog fler mönster för hur man kan strukturera en informationsmodell. Hur har du gjort och hur har det fungerat?

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 3 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

Strategimönster för informationsarkitekter – del 5: Den storskaliga strukturen

När vi modellerar företeelserna i en verksamhet, behöver vi finna en övergripande struktur. På så sätt blir helheten mer begriplig och hanterbar.

När man tar fram en informationsmodell finns alltid risken att man beskriver alla detaljer utan att lyckas fånga en sammanhängande helhet. Vad vi behöver är att finna någon slags övergripande struktur för modellen. En struktur som bildar en helhet där varje del kan tolkas i termer av sin roll i helheten.

Om vi lyckas få till en helhet som känns naturlig så blir modellen till ett språk som låter oss förstå, resonera om och hantera modellens domän även i breda drag. Men hur lockar vi fram denna struktur? Det vill säga: Hur hittar vi en bra design för helheten? Och hur hanterar vi denna helhet framöver?

Denna artikel presenterar tre strategimönster som kan hjälpa oss med hur vi kan tänka för att få till detta.

Strategimönster 1: Framväxande struktur (Evolving Order)

En modell blir aldrig klar med en gång utan växer fram över tid. Den utvecklas i takt med att kraven från de olika intressenterna kommer fram och vår gemensamma förståelse för domänen fördjupas. I början kanske vi ordnar entiteter och ämnesområden på något sätt som känns meningsfullt för stunden. Men vi måste i det läget akta oss för att spika strukturen. Modellen är då endast ett första försök. Om vi redan då skulle frysa den struktur vi tycker oss ha funnit blir den till en tvångströja som hindrar den fortsatta utvecklingen.

Det är naturligt att vi tidigt kommer fram till en övergripande struktur. När utvecklingen sedan fortsätter upptäcker vi nästan alltid att den skaver och då finner vi snart en mer passande struktur. Det händer gång på gång, med oregelbundna mellanrum. I början innebär det ofta större förändringar. Senare går det vanligen längre tid mellan de omvälvande insikterna, men när en ny insikt kommer ska den alltid välkomnas. Att vi behöver ändra modellen gång efter annan är något bra, det är tecken på framgång, att vi vinner kunskap som vi kan skörda.

Problem: Om någon tidigt bestämmer och låser fast en övergripande struktur händer det ofta att denna anbefallna struktur hindra oss från att ta en designväg som skulle göra verksamhetsbegreppen, informationshanteringen eller applikationen mycket enklare och tydligare. Vi kanske kan använda den framtagna strukturen på något sätt om vi anstränger oss, men vi missar ändå de stora möjligheterna att göra saker och ting bättre.

Arbetet saktar ner när vi tvingas till work arounds. Utvecklare kanske kommer med propåer om att vi borde ändra arkitekturen. Projektledaren har samtidigt fått föreställningen att arkitekturen är klar och spikad. Den skulle ju göra applikationen enklare att ta fram, så varför ägnar vi oss åt arkitekturproblemen fortfarande? kanske hen tänker. Det kanske är möjligt för utvecklarna att få gehör för ändringar av strukturen men om varje ändring blir till en kamp tar det för mycket kraft.

Fast å andra sidan, om designen släpps fri och utom all kontroll, om var och en får ändra som hen vill, om arkitekturen får flyta ohämmat, så blir resultatet en struktur som ingen kan förstå som en helhet och som blir svår att underhålla och vidareutveckla.

En arkitekt kan alltså hindra ett projekt genom att ta beslut för tidigt och ta för mycket makt från utvecklarna av de specifika delarna. Snart kommer utvecklarna att med skohorn tvinga in applikationen i den anbefallna strukturen. Vilket får tråkiga konsekvenser som vi kommer att få dras med för evinnerlig tid. Eller så kommer de att tvingas kringgå den anbefallda arkitekturen, med resultat att applikationen inte får någon tydlig struktur alls.

Problemet är inte att vi har en struktur, det vill säga regler för hur vi ska ordna modellen, utan stelbentheten hos strukturen/reglerna och var strukturen/reglerna kommer ifrån.

Lösning: Låt strukturen växa fram med applikationen. Var inte rädd för att, under arbetes gång, ändra till en helt annan struktur när det visar sig behövas. Låt inte heller den framtagna strukturen begränsa detaljdesign och andra modellbeslut som måste tas med detaljkunskap, mer än nödvändigt.

Strategimönster 2: Systemmetafor (System Metaphor)

Vi har nytta av metaforer, det vill säga analogier och mentala bilder eller liknelser, för de saker vi utvecklar.

Exempel: Vi kan se de verksamhetsfunktioner som stödjer analys och rapportering som en fabrik.  Med leverantörer och transportörer som levererar råvaror (rådata) på lastbryggor på fabrikens baksida (leveransytor). Och som vi sedan via olika processer hanterar, bearbetar, kombinerar och förpackar (transform). För att distribuera (load) till olika butiker (data marts) där konsumenter (analytiker och rapportkonsumenter) kan ta del av dessa.

De olika datastrukturer vi tar fram stödjer dessa funktioner. Därför kan vi dela in informationsmodellen på liknande sätt.  

Men en metafor är alltid ett tveeggat svärd. Analogin kan aldrig bli exakt och kan därmed leda tanken både rätt och fel.

Problem: Strukturer för datahantering tenderar att vara abstrakta och svåra att greppa. Utvecklare och användare behöver sätt att få designen mera påtaglig för att kunna förstå och dela en gemensam vy.

Lösning: När en konkret metafor för domänen växer fram, fäster sig hos teamet och verkar leda tankarna i en riktning som känns fruktbar, då ska du ta analogin i bruk för systemets övergripande struktur. Organisera designen runt metaforen. Systemmetaforen skall både underlätta kommunikation runt systemet och tjäna som ledning för utvecklingen av det.

Intressant nog kan vi aldrig forcera fram en metafor, utan vi kan bara vara öppna för att en sådan kan komma.

Alla metaforer är inexakta. Se upp för överanvändning av metaforer och var beredd att släppa en metafor som hamnar i vägen för en fördjupad förståelse.

Strategimönster 3: Skiktning av modell efter ansvar (Responsibility Layers)

När vi får en djup förståelse för en domän, kommer snart djupare mer övergripande mönster att framträda. Vissa företeelser hamnar i förgrunden och tar plats mot en bakgrund av andra företeelser. Förgrunden och bakgrunden förändras oberoende av varandra, med olika cykler och av olika anledningar. Vi får då en naturlig skiktning av domänen och därmed av modellen.

Problem: Hur kan vi dra nytta av en naturlig skiktning av domänen och göra denna skiktning synlig och användbar i modellen?  

Den naturliga skiktningen av domänen leder oss till en motsvarande skiktning av modellen. Skiktning är ett av de mest framgångsrika arkitekturmönstren, oavsett arkitekturdomän. Både byggnadsarkitektur, it-arkitektur och informationsarkitektur kan skiktas.

Skiktning är en partitionering av ett system där ett element som tillhör ett visst skikt känner till och kan använda tjänsterna i ett skikt under detta skikt men är oberoende och ovetande om skikten över. På så sätt går beroendena mellan delarna inte hur som helst utan ordnat uppifrån och ner, från förgrund till bakgrund.

Den variant av skiktning som passar bäst för en modell, verksamhet eller domänmodell i ett it-system är ”Relaxed layering”, som innebär att en medlem av ett skikt får använda sig av alla skikt under, inte bara det som är närmast under. (Den andra möjliga varianten är ”Strict layering” vilket innebär att man inte får hoppa över ett skikt.)

Lösning: Betrakta de konceptuella beroendena i din modell och skillnaderna i hastighet och orsak till ändringar i de olika delarna av domänen. Om du kan identifiera naturliga skiktningar i domänen, formulera dem som breda abstrakta ansvarsområden. Dessa ansvarsområden bör berätta en historia om syfte på hög nivå. Refaktorera modellen så att ansvaret hos varje domänobjekt passar in snyggt inom ansvarsområdet för skiktet.

Att hitta en bra skiktning i modellen handlar om att förstå domänen och att experimentera.
Man byter ut, slår ihop, splittar och definierar om skikt efter hand och ger akt på och försöker bevara några egenskaper hos skikten:

  • Historieberättande: Skikten skall kommunicera de grundläggande realiteterna eller prioriteterna i domänen. Att välja en övergripande struktur är inte ett tekniskt beslut utan en viktig verksamhetsmodellering.
  • Logiskt beroende: Företeelserna i ett skikt skall få sin mening av hur de framträder mot bakgrunden av företeelserna i underliggande skikt.
  • Logiska gränser: Om skikten har olika förändringshastigheter eller olika orsakskällor till förändring ska detta tydliggöras.

Nästa artikel i serien kommer att gå närmare in på hur man kan skikta modeller på detta sätt.

/Peter Tallungs, IRM

Nästa artikel i serien publicerar vi torsdag 27 januari. 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

Strategimönster för informationsarkitekter – del 4: Destillering av kunskap

Destillering är processen för att separera essensen från en blandning, och få den i en form som gör den mer värdefull och användbar. Informationsmodellering kan vi se som destillering av kunskap. Kunskap om de företeelser som verksamheten hanterar och hur de hanteras. Men vi kan behöva destillera vidare, ytterligare lyfta fram det som är viktigast i domänen. I följande artikel presenterar jag strategimönster som kan hjälpa oss med detta.

När man modellerar en domän, till exempel en verksamhetsfunktion eller ett it-system, så finns det saker i modellen som utgör själva essensen, det som är mest centralt och som är själva nyckeln till förståelsen av domänen. Denna essens, denna nyckelförståelse är, skulle jag vilja påstå, det som egentligen är verksamhetens viktigaste tillgång.

Men när man modellerar finns det alltid många olika saker som behöver hanteras. Därmed är det lätt att essensen kommer ur fokus, inte får den framträdande roll som den borde ha, och försummas.

Det finns flera orsaker till att det sker, bland andra de två följande.

  1. Behovet av specialisering
    En orsak är de specialiserade roller vi ofta måste ha i utvecklingsarbete. När en it-utvecklare rör sig utanför den del av systemet denne är välbekant med går hen lätt vilse i begreppen. Detta tvingar utvecklare att specialisera sig. När så var och en begränsar sitt arbete till specifika funktioner stryps kunskapsöverföringen mellan dem ytterligare. Isoleringen ökar därmed, vilket blir en ond spiral.
  2. Tendens till dragning mot teknik
    Det finns en tendens att erfarna it-utvecklare drar sig från kärnan av domänmodellen och mot den mer tekniska infrastrukturen, eller mot något tydligt avgränsat problem som kan förstås utan specialiserad domänkunskap. Ty detta är vanligen ett mer intressant område för en tekniskt intresserad och uppfattas också som att det ger färdigheter som är användbara i andra projekt och ser bra ut i ett cv.

Vi bör prioritera domänkärnan

Allt detta gör att domänkärnan ofta inte får den uppmärksamhet som den skulle behöva. I praktiken kan kanske inte alla delar av modellen hållas lika snygga. Vi måste då prioritera. För att göra domänmodellen till en tillgång måste vi framför allt se till att den kritiska kärnan i modellen bibehåller sin elegans och användbarhet.

I det följande presenterar jag fyra strategimönster som kan hjälpa oss att lyfta fram och förtydliga essensen i en modell.

Mönster 1: Domänkärnan (Core Domain)

Problem: Den specialiserade kärnan i domänmodellen, den viktigaste delen av modellen, det som verkligen gör modellen till en affärstillgång hanteras ofta styvmoderligt. Bland it-utvecklare är det vanligt att ny teknik och avancerade algoritmer ses som det viktiga. Datastrukturerna och begrepp ses som tråkiga och oviktiga och överlåts vanligen på en junior utvecklare, som får jobba tillsammans med en databasadministratör för att skapa ett databasschema.

Dålig design eller implementation av denna del av programvaran leder till att applikationen aldrig klarar av att göra viktiga saker för användaren. Och då spelar det ingen roll hur elegant infrastrukturen är.

Lösning: Koka ner modellen. Hitta domänens kärna och separera den från massan av modellen. Lyft fram de mest värdefulla och speciella begreppen. Håll kärnan liten. Domänkärnan är den del av modellen som särskilt tydligt representerar verksamhetsdomänen och som på bästa sätt löser de uppgifter som systemet ska lösa.

Sätt de skickligaste teammedlemmarna på kärnan och rekrytera enligt denna princip. Lägg kraften på kärnan för att hitta en djup modell. Utveckla en smidig design för denna – tillräcklig för att tillgodose visionen med systemet. Motivera investeringar i övriga delar av modellen efter hur de stödjer den destillerade kärnan.

Vem gör jobbet?

De utvecklare som är de skickligaste rent tekniskt är ofta inte så intresserade av den specifika verksamheten. Det begränsar dem i detta sammanhang och förstärker deras dragning till infrastruktur. De kan då inte bygga domänkunskap, och vi får en ond cirkel.

Vi behöver sätta samman teamet på följande sätt:

  • Utvecklare som är beredda till långvarigt engagemang och är beredda på att vara bärare av domänkunskap
  • En eller flera domänexperter som har djup kunskap om sin verksamhet
  • Informationsarkitekt, som faciliterar samverkan mellan dessa och aktivt arbetar med att förfina modellen.

En väldestillerad domänkärna är en tillgång som ger snabbhet, lättrörlighet och precision.
Första iterationen av ett utvecklingsprojekt bör alltid baseras på någon del av domänkärnan.

Men det här verkar jobbigt, säger kanske någon. Kan vi inte köpa ett standardsystem i stället, eller åtminstone en standardmodell? Reality check: Domänkärnan kan förmodligen inte köpas. Industrispecifika modellramverk har hitintills alltid misslyckats.

Mönster 2: Generiska subdomäner (Generic Subdomains)

Problem:Det finns alltid delar av en modell som ökar komplexiteten i modellen utan att egentligen fånga eller kommunicera någon specialiserad kunskap. Allt sådant sidoordnat i modellen drar uppmärksamheten från domänkärnan, vilket gör det svårare att uppfatta och förstå det som är centralt.

Modellen slammar igen av allmänna principer som alla känner till ändå, eller detaljer som bara har en stödjande roll. Men de kan ändå inte tas bort eftersom de behövs.

Lösning: Identifiera sammanhängande subdomäner som behövs men som inte är de som utgör motiveringen för projektet. Faktorera ut dessa till andra generiska modeller. Gör dessa så allmänna så att inga spår är kvar av den speciella situationen i dem. De blir kandidater till återanvändbara tillgångar.

En generisk subdomän kan bli en återanvändbar tillgång på två sätt:

  1. Återanvändning av programvaran
    Ni kan göra en egen programvarukomponent som kan återanvändas av andra. Detta skall dock inte vara din prioritering eftersom du skall rikta så mycket kraft åt kärndomänen som möjligt, inte bli en leverantör av generiska komponenter. Det är ju kärndomänen som är viktig.
  2. Återanvändning av modellen
    En viktig form av återanvändning som ofta har hamnat i skymundan, både internt i våra organisationer och i branschen/samhället i stort, är återanvändning av modellen. Här finns mycket att göra för oss. Ett sätt är att vi publicerar och diskutera modellmönster inom vår Community. Ett annat sätt är att vi publicera hela modeller, som exempel på hur man har gjort, med kommentarer.

Mönster 3: Domänens vision (Domain Vision Statement)

Problem: Vi behöver skapa och förmedla en gemensam bild av den centrala idén med domänen.

Lösning: Skriv en kort beskrivning (ungefär en sida) av domänkärnan och det värde den kommer att bidra med. Ta endast med sådant som utskiljer denna domänmodell från andra. Visa hur domänmodellen tjänar och balanserar skilda intressen. Skriv visionen tidigt och revidera den när du vinner ny insikt. Det är ungefär detta du skulle säga när du ska beskriva vad som är det speciella med verksamhetsfunktionen eller applikationen som modellen beskriver.

Exempel: Vision för Flygbokningssystemet

  • Passagerarnas prioriteringar ska balanseras mot flygbolagets bokningsstrategier
    Systemet ska kunna representera passagerarnas prioriteringar och bokningsstrategier och balansera dessa mot varandra baserat på flexibla regler.
  • Modellen av en passagerare skall avspegla den relation som flygbolaget strävar efter att utveckla med återkommande kunder.
    Därför skall modellen representera passagerarens historik i en användbar kondenserad form, deltagande i speciella program, anknytning till strategiska företagskunder och så vidare.
  • Användarroller
    Användarnas olika roller (som passagerare, agent, ledningsperson) tillhandahålls för att kunna föda säkerhetssystemet med nödvändig information.
  • Modellen skall stödja effektiv rutt/sittplats-sökning
  • Modellen ska möjliggöra integration med andra etablerade flygbokningssystem.

Mönster 4: Framhävd kärna (Highlighted Core)

Problem: Vi behöver skapa och förmedla en gemensam förståelse av domänkärnan, det vill säga de viktigaste strukturerna i modellen.

Lösning: Ta fram ett destillationsdokument (Distillation Document) på 3–7 sidor som beskriver och förklarar domänkärnan. Det kan innehålla följande:

  • En lista på de viktigaste entiteterna
  • Diagram som visar deras viktigaste relationer
  • En genomgång av deras viktigaste interaktionsmönster, antingen på abstrakt nivå eller med exempel.

Dokumentet ger en bred vy av hur bitarna passar ihop. Dokumentet skall vara läsbart för icke-tekniska personer och vara avgränsad till det som alla inblandade behöver veta. Använd det som en gemensam vy och en guide med vilken alla nya teammedlemmar kan starta.

Destillationsdokumentet fungerar som en gemensam förankring. Det är viktigt att det står klart för teamet vilken stor betydelse en ändring av domänkärnan innebär. En ändring av domänkärnan innebär en förändring av teamets gemensamma syn på domänens centrala begrepp och beteende.

Använd destillationsdokumentet som en indikator. Om en ändring i modellen gör att destillationsdokumentet behöver uppdateras för att vara i synk med modellen behövs en överläggning. Antingen har det skett en fundamental ändring av något element i domänkärnan eller då har domänkärnans gräns flyttat på sig.

Det är då nödvändigt att sprida den förändrade bilden till hela teamet, inklusive att dela ut den nya versionen av destillationsdokumentet till alla inblandade.

Källan till dessa strategimönster

Strategimönstren i denna artikel är hämtade från Eric Evans bok ”Domain Driven Design”. Jag tycker att de är så kloka så jag vill gärna lyfta fram dem till en bredare krets än de få som kommit så långt i hans bok. Jag har här översatt och tolkat dessa. För de som vill gå till originalen har jag skrivit Eric Evans namn på mönstren inom parentes.

/Peter Tallungs, IRM

Nästa artikel i serien på temat informationsarkitektur publicerar vi torsdag 20 januari 2022. 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

Strategimönster för informationsarkitekter – del 3: Modellens avgränsade kontext

Vilka informationsmodeller ska vi ha för ett visst område? Skall det vara en enda mycket bred modell eller flera som var och en är mer avgränsade? Hur långt ska en viss modell sträcka sig? Var ska vi låta gränsen till omvärlden gå? Låt oss se hur man kan resonera. Denna artikel handlar om hur man kan tänka för att bestämma vilken avgränsning en modell ska ha.

Först går jag igenom ett par allmänna principer om hur man kan tänka när man avgränsar kontext för en modell. Sedan går jag igenom fyra typiska fall och ger några praktiska råd. Råden är liksom i de tidigare artiklarna om modelleringsstrategi delvis baserad på Eric Evans tankar om strategi ur boken ”Domain Driven Design”.

Allmänna principer: Hur smal eller bred ska en modells kontext vara?

En modell har alltid en viss kontext. Den kan vara bred eller smal. Men hur ska vi avgöra om vi ska göra en bred modell som täcker mycket, eller flera smala som var och en är avgränsad till ett delområde?

Observera att jag här menar modell och inte modelldiagram. Det är viktigt att vi inte blandar ihop detta. En modell kan ofta behöva delas upp i flera diagram, men det är likafullt samma modell, så länge den har samma avgränsade kontext och är konsistent inom detta.

Hur omfattande en modell ska vara är en bedömningsfråga som till stor del handlar om intuition, det vill säga kunskap som vi har men som vi inte riktigt kan utrycka på annat sätt än som vad som känns rätt. Men vi kan i varje fall peka ut några faktorer som talar för en bredare kontext, och andra som talar för en smalare.

Det som talar för en bredare kontext:

  • En verksamhetsprocess går smidigare att implementera när den hamnar inom en enhetlig modell. Det är lättare att greppa en modell än två olika, samt att vi då även måste hantera mappningen däremellan.
  • Översättningen mellan de olika modellerna kan bli svår (och ibland till och med omöjlig).
  • Ett gemensamt språk ger tydlig kommunikation.

Det som talar för en smalare kontext:

  • Modellen blir enklare, vilket medför att kommunikationen mellan personer blir enklare, så länge man håller sig inom modellens kontext.
  • Enklare modellering, ty bredare modeller behöver vanligen bli mer abstrakta för att täcka fler alternativ.
  • Den kontinuerliga integreringen blir enklare. En smalare kontext betyder färre direkta intressenter med mer likartade behov som man behöver täcka.
  • Med separata modeller för olika intressenter kan man bättre tillgodose specifika behov och även specifika jargonger hos specialiserade grupper.

Allmänna principer: Var dra gränsen mellan flera avgränsade kontexter?

Då man delar en domän till två separata modeller, det vill säga två olika avgränsade kontexter, är det viktigt var man placerar gränsen mellan modellerna. Målet är att beroendet mellan modellerna blir så litet, enkelt och tydligt som möjligt. Då behöver vissa modellelement hamna på samma sida om gränsen.

Det som talar för att två modellelement bör hamna i samma avgränsade kontext, det vill säga i samma modell är följande:

  • Elementen hör samman på ett naturligt sätt.
  • Elementen brukar ofta refereras tillsammans.
  • Elementen har många och djupa kopplingar till varandra. Särskilt om sambanden är dubbelriktade.
  • Informationen i de två elementen ägs av samma verksamhetsfunktion.

Observera att det här egentligen går tillbaka på mycket generella principer för hur vi ordnar saker i största allmänhet. De gäller för alla typer av avgränsningar vi gör och kan göra. Till exempel när vi placerar saker i olika byrålådor, eller hur vi sorterar dokument i olika mappar. Eller då vi delar en modell i olika ämnesområden, men det fortfarande ändå ser det som samma modell.

Ett sammanhang där jag som informationsarkitekt deltar är i systemutvecklingsprojekt. Då behöver vi i projektet bestämma vilka kontexter vårt projekt och därmed våra modeller ska ha. Varje avgränsad kontext blir normalt ett eget system eller delsystem.
Nedan går jag igenom fyra olika typiska fall.

Fall 1: Vi bygger ett nytt it-system som ska integrera mot ett äldre system

Den information som finns i ett äldre system måste ses som sin egen kontext eftersom systemet inte kan stöpas om bara sådär. Det vill säga att vi måste acceptera det äldre systemet som det är, med sina begrepp och strukturer, vare sig det passar vår egen kontext eller inte.

Men se upp med att äldre system ibland, i praktiken, kan inrymma fler än en avgränsad kontext. Ty en avgränsad kontext bestäms av att det hos de som utvecklar och förvaltar systemet finns en avsikt att hålla ihop modellen för systemet inom dess gränser. Om förvaltningsteamet för det äldre systemet inte kontinuerligt har integrerat sina olika uppdateringar av kodbasen, eller databasen, kan det finnas svåra semantiska motsägelser inom systemet. Då går det inte att hantera det äldre systemet som en enda väldefinierad och avgränsad kontext, utan måste kanske hanteras som flera.

Fall 2: Du ska designa ett nytt it-system

När ett helt nytt it-system ska utvecklas behöver du definiera ett eller flera avgränsade kontexter för domänen, och sedan tillämpa kontinuerlig integration inom dessa. Men vilka kontexter ska du ha, hur många ska det vara, och vilka relationer skall de ha till varandra?

Om kraven på funktionaliteten håller ihop väl, och projektet inte är för stort, räcker det med en enda avgränsad kontext för hela systemet.

Om projektet växer och det blir svårt att kontinuerligt integrera allt, bör du dela modellen i två. Du bryter då isär på så sätt att beroendet mellan delarna blir så litet och tydligt som möjligt. Vi får då två delsystem som kan (men strikt inte behöver) utvecklas och förvaltas av olika team.

Beroendet behöver helst också gå endast i ena riktningen, så att vi kan upprätta ett kund-leverantörsförhållande mellan delarna. Om vi inte kan undvika ett beroende som går i båda riktningarna behöver vi upprätta en delad kärna.

Du har nu två team med varsin avgränsad kontext. Då kan det hända att de två teamen tänker så olika att det ständigt blir problem med det som måste hanteras gemensamt. Det kan bero på att de verkligen behöver helt olika saker från modellen eller att de har så pass olika bakgrund att de ser olika på företeelserna. Det kan också bero på att teamen arbetar på olika sätt.

Om detta är något du inte kan eller vill göra något åt kan du välja att låta delsystemen och därmed modellerna att gå skilda vägar. Du kan då skapa ett översättningslager (translation layer) mellan de olika delsystemen. Detta kan då underhållas gemensamt av de båda grupperna.

Det måste alltid finnas ett uttalat team, och inte flera, som är ansvarigt för en avgränsad kontext. Ett team kan hantera fler än en avgränsad kontext, men det är svårt för flera team att dela på en och samma avgränsade kontext.

Fall 3: Du behöver ta hand om speciella behov med en särskild modell

Olika grupper inom samma verksamhet har ofta egna specialiserade terminologier som skiljer sig från varandra. Det kan bero på att de har olika bakgrunder eller behöver hantera olika specialiteter. Dessa lokala jargonger kan vara mycket precisa och skräddarsydda för just deras arbete. Om man vill införa en standardiserad terminologi som ska ersätta de lokala är det mycket krävande. Det kräver en djup förståelse som man kan få först efter lång tids arbete inom domänen, och dessutom diplomati och samverkan under lång tid. Även om man lyckas finns det risk att den nya terminologin inte fungerar lika bra som den egna exakt anpassade terminologin.

Ett alternativ är att i stället tillgodose det speciella behovet av en egen terminologi i en separat avgränsad kontext. Men det finns en risk att denna möjlighet kan bli ett argument mot förändring, och bidra till att behålla ett dåligt fungerande och inskränkt terminologi och synsätt. Hur värdefull är egentligen den egna jargongen för gruppen? Och hur kan jag veta vad som är värt att behålla och vad som kan förändras? Jag behöver vara ödmjuk, och försiktig med det som faktiskt fungerar.

Ibland växer det fram en djupare modell som kan ena de olika språken och tillgodose de olika grupperna. Haken är att en djup modell alltid uppstår sent i livscykeln, efter mycket utveckling och tänkande, om den uppstår alls. Du kan inte planera för en djup modell. Du kan bara vara öppen för att det kan hända, acceptera möjligheten när den dyker upp, och då ändra strategi och refaktorera.

Fall 4: Du kommer in i ett projekt som pågår

Ibland kommer du som informationsarkitekt in i ett projekt som har pågått ett tag. Då kan du inte bara ge dig på att ändra allting efter eget skön. Men du behöver ändå ta kontroll över situationen. Du kan lämpligen göra så här:

  1. Definiera avgränsade kontexter Det första du då bör göra är att identifiera och definiera avgränsade kontexter, som det förhåller sig nu, det vill säga hur teamet är organiserat idag. Detta är avgörande. Kontextkartan måste avspegla verkligheten som den är just nu, inte den ideala ordningen som du ser den. Förändringar måste alltid utgå från nuläget.
  2. Tajta upp teamets arbetssätt baserat på den befintliga organisationen. Försök inte ändra allt, utan utgå även här från hur det fungerar idag. Förändringar måste alltid ske i små steg, och man måste ha människorna med sig.
  3. Se över och förändra så småningom, vilka olika kontexter som systemet omfattar och hur de är avgränsade från varandra. Det vill säga om det behövs, vilket inte alltid är fallet.

/Peter Tallungs, IRM

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

Strategimönster för informationsarkitekter – del 2: Bevarande av konsistens

Hur kan vi hantera att olika delar av vår verksamhet har olika informationsmodeller som behöver samverka? Och ändå att varje modell bevarar sin konsistens, det vill säga inte rymmer motsägelser. Peter Tallungs presenterar ett antal mönster för detta.

Följande strategimönster har sina ursprung i Eric Evans bok Domain Driven Design, som egentligen handlar om hur man kan strukturera en domänmodell i programkod. Det är inte precis samma som informationsmodellering, men närapå. Framförallt kan sammanhanget vara olika, vi informationsarkitekter fokuserar vanligen lite mer på verksamhetsfunktioner än it-system. Det gör att Eric Evans mönster kan behöva omtolkas lite grand. Fast om vi zoomar ut lite så är en verksamhetsfunktion och it-applikation mer eller mindre kommunicerande begrepp i detta sammanhang. En applikation är en integrerad och ofta central del av en viss verksamhetsfunktion.

Jag har med hjälp av mina kollegor gjort en viss omtolkning när jag tyckt det behövts, men för att läsaren själv ska kunna gå till källan har jag för varje mönster angivit Eric Evans motsvarighet inom parentes.

Mönster 1: Avgränsad kontext (Bounded Context)

Problem: Ofta finns det i en verksamhet flera modeller som helt eller delvis täcker samma domän. Då är det lätt att det blir oklart vilken modell som gäller och vilken som inte gäller för ett visst sammanhang. Kommunikationen mellan människor blir förvirrad, vilket hindrar utvecklingen.

Lösning:

  • Definiera för varje modell explicit det sammanhang för vilket modellen gäller.
  • Sätt tydliga gränser för varje modell; vilken organisation eller organisationsdel, vilket område (det vill säga tillämpningsdomän), vilket eller vilka it-system med mera gäller.
  • Håll modellen strikt konsistent inom dessa gränser, och bli inte distraherad av saker och ting utanför avgränsningen.

Kontext är ett viktigt begrepp då det gäller modeller och det är kanske på sin plats att här definiera vad som menas. Kontexten för en modell är samma som hela det sammanhang för vilket modellen gäller, till exempel ett visst informationssystem, en viss verksamhetsfunktion eller del därav, en viss process, ett visst informationsutbyte, en viss organisation, ett visst ämnesområde med mera.
(Även statusaspekten är en del av kontexten för en modell, det vill säga om modellen gäller nu, eller är det bara Peters vilda teori, eller Lenas förslag för framtiden, med mera, med mera. Med andra ord är modellens kontext hela den uppsättning villkor som måste vara uppfyllda för att man ska kunna säga att modellen gäller.)

Genom att dra en tydlig gräns för modellen kan du hålla modellen ren och därmed kraftfull inom det område där den är applicerbar. På samma gång undviker du förvirring när du flyttar blicken till en annan kontext. Men förr eller senare behöver vi integrera tvärs över en sådan gräns. Men den frågan tar vi hand om separat, och kan då ta hjälp av strategimönster i senare artiklar i denna serie.

Vad gör vi när en modell håller på att fragmenteras?

När vi utvecklar en modell får vi förr eller senare en tendens till fragmentering av modellen, det vill säga motsägelser och oklarheter. Speciellt om vi är flera som modellerar, och inte alltid tillsammans.

Tidiga tecken på fragmentering är följande:

  • Duplicerade begrepp. Två olika modellelement visar sig representera samma företeelse.
  • ”Falska vänner”. Två personer använder samma term, men menar olika saker.
  • Motsägelser. Man märker kanske att när vi ska använda modellen för en it-lösning, en datastruktur eller en rapport så finns det saker som säger emot varandra i modellen. Ofta handlar det om subtila skillnader.

Då måste vi ta ett beslut, och det finns då två vägar att gå:

Alternativ 1: Konsolidera modellen

Lös konflikterna. Vi kanske också behöver förfina arbetsprocessen för att hålla ihop modellen bättre i fortsättningen.

Alternativ 2: Splittra modellen

Fragmenteringen kanske beror på att vi är två grupper av människor som vill dra modellen åt olika håll, och att vi har goda skäl för detta. Det kan grunda sig på att olika intressenter verkligen har olika behov eller olika prioriteringar som är svåra att förena utan att modellen förlorar i användbar. Då behöver vi dela modellen till två separata modeller.

Mönster 2: Kontinuerlig integrering (Continuous Integration)

Problem: När ett antal människor jobbar inom samma modell, finns det alltid en tendens till fragmentering. Ju större team desto större tendens, men även ett litet team kan få problem.

Att alltid i dessa lägen splittra modellen i flera, är inte realistiskt. Då skulle vi förlora i samverkan och sammanhang. Därför måste vi kontinuerlig motverka tendenser till splittring. Vi behöver arbetssätt som ökar kommunikationen mellan människorna och hindrar att det uppstår onödig komplexitet i våra modeller. Ett sådant arbetssätt motverkar till exempel tendensen att man lägger till ett nytt modellelement för att man inte vågar ändra ett befintligt modellelement.

Lösning: Kontinuerlig integrering, innebär att allt som görs inom modellen förenas till en helhet och görs konsistent med täta mellanrum. Mellanrummen måste vara så täta att fragmenteringar fångas och korrigeras snabbt och enkelt. Om man låter tiden gå blir det snabbt svårare. Kontinuerlig integrering av en modell sker på detta sätt genom ständig kommunikation mellan teammedlemmarna. Teamet måste ta vård om den gemensamma förståelsen av modellen allt eftersom den förändras.

Mönster 3: Delad kärna (Shared Kernel)

Problem: Kontinuerlig integrering mellan två delar av ett team kan ibland bli för besvärlig att upprätthålla över tid. Det kan vara så att man egentligen inte har så mycket gemensam funktionalitet, eller att teamet är för stort för det nära samarbete som krävs för att hålla ihop en modell. Det kan också finnas organisatoriska hinder som gör att man inte kan jobba tätt ihop.

Lösning: Dela teamet till två team. Välj ut en del av modellen som de två teamen kan komma överens om att dela. Denna del ges en speciell status och skall inte gå att ändra utan att man överlägger med det andra teamet. Övriga delar blir i praktiken separata modeller som tillåts att mer eller mindre leva sina egna liv.

Mönster 4: Kund-/leverantörs-förhållande mellan team
(Customer Supplier Development Teams)

När två olika verksamhetsfunktioner har ett beroende mellan sig går beroendet mellan dem nästan alltid i ena riktningen. Den ena verksamhetsfunktionen befinner sig ”nedströms” i förhållande till den andra, det vill säga har ett beroende till den andra. De gör olika jobb och har därmed ofta varsin modell med sina egna begrepp och sätt att strukturera och hantera sin information.

Problem: Det kan uppstå problem i integrationen mellan funktionerna på grund av det politiska förhållandet mellan dessa. Uppströmsteamet kan känna sig låst av nedströmsteamet om de inte kan ändra saker och ting fritt. Nedströmsteamet kan känna sig utlämnade till uppströmsteamets godtycke.

Lösning: Etablera ett tydligt kund-/leverantörsförhållande mellan teamen. Det innebär att uppströmsteamet behöver se nedströmsteamet som en kund vars intressen de ska tillgodose.

Mönster 5: Konformist (Conformist)

Problem: När två team med ett uppströms-/nedströmsförhållande till varandra inte styrs av samma ledning händer det ofta att ett samarbetsmönster som ”kund-/leverantörsförhållande” inte fungerar.

Uppströmsteamet har inget tydligt ansvar att tillgodose nedströmsteamets intressen.

Om medlemmarna i nedströmsteamet då är naiva och inte inser att de är utlämnade till sig själva kommer de att få problem.

Lösning: När två team har ett uppströms-/nedströmsförhållande och där uppströmsteamet inte har någon motivering att tillgodose nedströmsteamets behov, måste nedströmsteamet inse realiteten och agera utifrån detta.

Uppströmsteamet kanske ger löften, men de kommer troligen inte att infrias. Nedströmsteamet måste lära sig att leva med det som redan finns. Ett gränssnitt anpassat till nedströmsteamets behov kommer inte att göras.

Det finns då tre vägar att gå för nedströmsteamet:

  1. Överge idén om att använda sig av uppströmsteamets tjänster
  2. Isolera sig från uppströmsmodellen med ett antikorruptionslager
  3. Bli konformist. Anpassa sig slaviskt till uppströms-teamets modell. Detta beslut ökar beroendet till uppströms-teamet. Det är ibland det rätta. Men vi bör då se det som ett aktivt val vi gör, och hantera de konsekvenser som kan uppstå.


Mönster 6: Antikorruptionslager (Anticorruption Layer)

Problem: När man bygger ett nytt informationssystem med ett stort gränssnitt mot ett befintligt system, kan det visa sig svårt att relatera företeelserna i de två systemens modeller till varandra.

I värsta fall kan det andra systemets modell korrumpera den egna modellens syften helt och hållet. Man anpassar då den egna modellen till den andra på ett ad-hoc-sätt för att få ihop det hela. Problemet är då ofta att modellen aldrig kan blir anpassad till de egna behoven så bra som den skulle kunna bli.

Lösning: Skapa ett isolationslager (antikorruptionslager) som tillhandahåller det andra systemets företeelser i termer av den egna domänmodellen. Detta lager kommunicerar med det andra systemet genom dess befintliga gränssnitt. Lagret översätter internt mellan de båda modellerna i båda riktningarna. På så sätt behöver endast antikorruptionslagret befatta sig med det andra systemets begrepp och strukturer och resten av vårt system kan ha sin egen modell mer lämplig för vårt syfte.

Mönster 7: Skilda vägar (Separate Ways)

Problem: När vi bygger ett it-system (eller en verksamhetsfunktion) behöver vi alltid avgränsa kraven. Vi kan aldrig lösa alla problem inom samma system.

Om vi har två uppsättningar krav som inte har täta band till varandra kan de delas upp till två system (eller delsystem) med olika modeller. Integration är alltid dyrt. Ibland är fördelarna små.

Lösning: Skapa en modell med en avgränsad kontext, som inte har någon knytning alls till den andra domänen. Den smala avgränsningen tillåter att man kan finna en enkel specialiserad lösning. Det här är ett val vi kanske är lite för obenägna att göra men som vi nog bör göra lite oftare.

/Peter Tallungs, IRM

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

Strategimönster för informationsarkitekter – del 1: Introduktion

Föregående artikel (Den omöjliga drömmen om den allomspännande informationsmodellen) handlade om att vi i en större verksamhet inte kan komma ifrån att olika delar av verksamheten har olika modeller som lever sina egna liv, mer eller mindre. Som informationsarkitekter måste vi därmed hantera att vi har olika modeller som ofta säger olika saker. Denna artikel är starten på en serie artiklar som handlar om de situationer som kan uppstå i dessa sammanhang och hur vi kan agera.

Utmaningen med flera modeller

Är det detta vi har att välja på? En monolitisk jättemodell eller flera mindre modeller som inte hänger ihop riktigt. Den monolitiska modellen är ohanterlig och trögrörlig, full av subtila dupliceringar och motsägelser. Flera mindre modeller kan inte användas för att lösa problem som spänner över hela verksamheten. De har konsistensproblem i varje integrationspunkt och hänger vanligen ihop endast med snabbt hopsydda ad-hoc-kopplingar mellan sig.

Det känns kanske som att välja mellan pest och kolera.
Låt mig inskjuta något om detta med pest eller kolera: Enligt vår kära professor Agnes Wold är valet självklart. Om du någon gång skulle få det valet ska du välja kolera. Pest är en förfärlig sak, med ganska säker snabb död. Kolera är däremot hanterbar. Du behöver inte ens läkarhjälp. Bara någon som ser till att du kontinuerligt får i dig vatten med salt och socker i. På samma sätt är det med valet mellan en monolitisk jättemodell och flera mindre. Du bör alltid välja flera mindre. De problem som uppstår går att hantera ganska enkelt.

Om du är med på det som föregående artikeln hävdade, att drömmen om den allomspännande informationsmodellen är omöjlig, så finns det inget val. Vi kan inte komma ifrån att vi behöver hantera flera olika modeller. I varje fall inte i en lite större verksamhet. Och att varje sådan modell behöver leva sitt eget liv, mer eller mindre.

Utmaningen blir då att modellerna behöver kunna samverka tillräckligt bra för att stödja gemensamma processer. Det handlar mest om förhandling och beslut mellan olika team. Vi befinner oss då i skärningen mellan design och politik.

Hur ska vi bryta ner domänen i flera modeller och hur ska vi hålla ihop den?

Vi behöver låta olika modeller leva parallellt med varandra i olika delar av organisationen. Men det betyder inte att vi kan släppa allt vind för våg. Vi behöver ha någon form av gemensam styrning. Vi behöver göra genomtänkta val av följande:

  1. Vilka ska de olika modellerna vara?
    En modell representerar en del av domänen som tillåts leva sitt eget liv och därmed divergera från helheten. Det är beslut vi måste ta gemensamt och även ompröva över tid, när så behövs.
  2. Hur ska modellerna relatera till varandra?
    Vi behöver fortfarande hantera en helhet. Det kan vi inte komma ifrån. Vi behöver hålla två saker i huvudet samtidigt. Vi behöver ta proaktiva beslut om vad som behöver vara gemensamt och enhetligt tvärs över hela domänen. Och vi behöver vara pragmatiska med vår förståelse för vad som inte behöver vara eller inte kan vara enhetligt.

Vi behöver skapa en tydlig gemensam bild av hela situationen. Sen gäller det att löpande se till att de gemensamma delarna fortsätter att vara gemensamma och att de delar som inte är enade hålls isär och inte skapar förvirring. Och det kommer att behöva omförhandlas över tid vad som ska vara gemensamt och vad som inte ska vara gemensamt.

Strategimönster för informationsarkitektur

Att på detta sätt balansera gemensamma behov med lokala är själva kärnan i informationsarkitektens arbete. Det är något som lyfter hela kunskapsområdet från det som bara är informationsmodellering, att få koll på en avgränsad och sammanhållen domän, till informationsarkitektur, att hantera flera domäner länkade till varandra.

Till det behövs strategitänkande. Hur ska vi lösa de situationer som uppkommer? Vilka möjligheter finns det? Jag vet inte att det någonstans i vår bransch har diskuterats hur vi kan tänka där. Tvärtom är det som om problemet inte existerade, som om det vore självklart att alla verksamheter ska enas om en modell, nu genast och för alltid.

Strategi kräver kunskap och omdöme. Så låt oss samtala om detta, för att utveckla vår förståelse. Det är just så vi utvecklar vårt omdöme.

Jag tror att det bästa sättet att angripa detta, som individ, som team och som profession är att diskutera och tillämpa olika strategimönster. Strategimönster är mönster som beskriver olika strategier man kan tillämpa i situationer i arbetet. Rent allmänt beskriver ett mönster ett generellt problem och en generell möjlig lösning med sina styrkor och svagheter. Jag har i tidigare artiklar beskrivit ett antal modellmönster, hur man kan angripa enskilda modelleringsproblem. Nu är turen kommen för strategimönster för informationsarkitektur, det vill säga mönsterför hur man kan hantera olika situationer för samverkan mellan ett antal informationsmodeller inom en verksamhet, eller mellan olika verksamheter. Om vi tar del av strategimönster inom vårt område blir vi bättre på att se vilka val vi har i olika situationer och vad de kan innebära.

Var hittar vi strategimönster för informationsarkitektur?

Var hittar vi då strategimönster för informationsarkitektur? Jag har hittat några mönster i boken Domain-Driven Design av Eric Evans. Det är en bok som är tämligen okänd bland informationsarkitekter. Denna bok riktar sig egentligen till programmerare, och handlar om hur man designar den del av programkoden som är en modell av den domän som programkoden handlar om.

Inom objektorienterad programmering har man ju klasser som representerar företeelser i domänen och försöker avbilda beteendet hos dessa. På så sätt är hela det kunskapsområdet i stort sett analogt med vårt som informationsmodellerare och informationsarkitekter. Våra modeller är ju på liknande sätt avbildningar av företeelser i domänen. Eric Evans skrev ovan nämnda bok 2003. Det är först i fjärde och sista delen, av den 530 sidor tjocka boken, som han kommer in på dessa strategimönster. Han har sagt att det egentligen är den viktiga delen av hans bok och att han önskar att han hade lagt den delen först i boken, då programmerare inte brukar läsa ända dit.

Kan vi använda strategier för programkod för informationsmodellering?

Boken gav upphov till en rörelse bland programmerare med namnet Domain-Driven Design eller DDD. När jag läste boken tänkte jag genast att detta är mer eller mindre tillämpligt även för informationsmodellering. Jag vill påstå att bokens sätt att se på samverkan mellan det som finns i verkligheten (det vill säga domänen i fråga) och det sätt som detta representeras i informationsstrukturer (i Eric Evans fall programkoden) har gjorde mer för min utveckling som informationsmodellerare än något annat. Jag är djupt tacksam till Eric Evans för detta.

Trots min iver att dela mina tankar med folk i DDD-rörelsen, gav jag snart upp. På den tiden fanns det en vanlig inställning hos programmerare att programkoden och dess utformning var det enda intressanta. Databasens struktur var ointressant för dem. Databasens uppgift sågs som rent mekanisk, att persistera objekt i koden. Och att göra informationsmodeller sågs av många programmerare som ett verktyg för att avbilda verksamhetsobjekt i en databas, vilket var fel enligt dem, det skulle man göra i den objektorienterade programkoden. De ansåg att jag var en gammaldags figur, en kvarleva som inte hade fattat grejen, när jag ville prata informationsmodellering. Det var något omodernt, överspelat.

Ett väl övervägt svar från Eric Evans

Inte för att jag behövde någon välsignelse från DDD-rörelsen, men en händelse år 2004 gjorde ändå att jag kände mig mindre udda. Jag hade tagit en Greyhound-buss från Chicago över oändliga åkerlandskap och prärier till Denver i Colorado för att gå på konferens.

Det var den legendariska årliga OOPSLA-konferensen, ”Object-oriented Programming, Systems, Language and Design”. Ett återkommande evenemang där mycket av det nya inom systemutveckling introducerades, det som vi nu tar som självklart. Inte bara objektorientering utan även designmönster (ursprungligen av Kent Beck och Ward Cunningham, inspirerad av byggnadsarkitekten Christopher Alexander) och Kent Becks Extreme Programming och senare Agila manifestet. Det var ett ställe där historia skapades, och jag ville vara där och se det hända.

Men konferensen och hela det samhälle som var representerat där var mer eller mindre avvisande till allt som inte andades och levde objektorientering. Som till exempel XML och allt det som kom med internet som motsade att man skulle skicka hela objekt över nätet. Och inte minst detta att data i databaser kunde vara något annat än rent mekaniskt persisterade objekt från programkoden.

Jag hade läst Eric Evans bok och hade under första konferensdagen deltagit på hans workshop. Jag var övertygad om att Eric Evans idéer om domändriven design var tillämpliga utanför den objektorienterade programkoden, inte minst inom databasdesign och informationsmodellering.
Fast det var nästan inte möjligt att nämna där och då, det skulle vara som att svära i kyrkan.

Det var heller ingenting som Eric Evans hade berört, vare sig i hans bok eller i andra sammanhang. Hans värld var i mina ögon helt begränsad till programkod. Jag bodde på konferenshotellet och på konferensens tredje dag råkade jag hamna vid samma lilla frukostbord som Eric Evans. Jag var starstrucked! Men dristade mig så småningom att presentera min syn på saken för honom. Jag berättade att jag ofta designade system där tabellerna i databasen mer eller mindre avbildade domänen i fråga. Och jag frågade honom om han inte trodde att hans idéer var tillämpliga för detta. Jag väntade på hans svar med en viss bävan, för jag tänkte att han kanske skulle dissa hela idén om att databasen skulle kunna avbilda verksamheten direkt.

Nu hör det till saken att Eric Evans är känd för att vara en person som inte tar lätt på frågeställningar. Det sägs att när man ställer en fråga till honom så sitter han tyst i tio minuter och sedan så kommer det ett mycket övervägt och klokt svar. Och det var precis vad som hände nu. Vi hann avsluta mellanvästernfrukosten med bacon, ägg och hasch browns, och satt kvar med det blaskiga kaffet när hans svar kom. ”Yes Peter, as long as you get your database designers to really understand that when they change the database they change the model of the enterprise”. Jag blev så glad! Jag var förvisso redan tidigare övertygad om att jag var på rätt väg i mina tankebanor, men det kändes ändå skönt att jag nu hade fått någon slags välsignelse av självaste gurun på området, och inte måste kämpa i total motvind.   

Eric Evans strategimönster tillämpade på informationsmodellering

Eftersom Eric Evans sätt att tänka runt modeller är av en klass som jag inte mött någon annanstans, och att i stort sett inga informationsarkitekter hittar till hans bok, så vill jag gärna se till att fler får ta del av hans tänkande. Jag kommer därmed att publicera fyra artiklar som presenterar och diskuterar hans strategimönster.

Jag har översatt till svenska samt försökt att efter bästa förmåga tolka varje mönster i kontexten informationsmodellering. Vilket jag inte tycker har varit speciellt svårt, men ändå vill jag reservera mig för att det är min tolkning. Jag kommer därför att för varje mönster jag presenterar bifoga Eric Evans ursprungliga namn på mönstret. Då kan den som är intresserad och vill höra det hela från hästens mun, slå upp och studera mönstret i fråga i hans bok.

/Peter Tallungs, IRM

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

Den omöjliga drömmen om den allomspännande informationsmodellen

Det är vanligt att stora organisationer startar ambitiösa modelleringssatsningar, med målet att skapa en informationsmodell som spänner över hela verksamheten och integrerar alla upptänkliga behov de olika delarna av verksamheten kan ha. Men det är ingen bra idé! Det är inte genomförbart att uppnå och kontinuerligt bevara total enighet över en större domän. Denna artikel beskriver varför.

Att uppnå och behålla total enighet över en större domän är inte genomförbart och bör inte vara ett mål

Varför fungerar det inte att ha en enda informationsmodell för en verksamhet större än den allra minsta? För att förstå detta måste vi släppa tanken på att en verksamhet är som en maskin och i stället se en verksamhet som ett organiskt ekosystem. Att ha en enda informationsmodell för en mer omfattande verksamhet skulle fungera om verksamhetens alla delar hade helt och hållet samma mål och samma prioriteringar, det vill säga att verksamheten var som en maskin där alla kugghjulen gick i takt. Men så är inte fallet, så kan en verksamhet aldrig fungera, och det vore inte heller önskvärt. En verksamhet är något helt annat, ett nätverk av olika funktioner med olika fokus och prioriteringar. Egna agendor, om man vill hårdra det (även om många skulle studsa på de orden). Och så måste det vara. Det är något bra och något vi ska bejaka.

Denna, som det kan tyckas, spretighet är inte en brist på samordning utan det är en högst ändamålsenlig organisationsform i en föränderlig värld. Så har egentligen alla organisationer fungerat i alla tider, även om många managementkurser försöker påstå något annat. Varje affärsområde, funktion, avdelning, team och individ är specialiserad på en egen aspekt av verksamheten. Det kan vara ett produktområde, ett kundsegment, en aspekt av de produkter eller tjänster man producerar, någon leverantör eller något annat i omvärlden. Många delar av en verksamhet stödjer interna kunder och är helt koncentrerade på den uppgiften. Varje del av en organisation behöver, för att kunna reagera och verka effektivt inom sitt område, ett stort mått av självständigt agerande.

Genom den mångfald som på detta sätt uppstår har organisationen förmågan att snabbt upptäcka och effektivt anpassa sig till nya möjligheter och hinder. En verksamhet är därmed inte som en maskin utan som ett ekosystem, en dynamisk och levande helhet, i ständigt omstöpande. Detta är inget nytt utan välkänt inom organisations- och managementteori, och har faktiskt varit så allt sedan den moderna organisationsteorin uppstod för ca hundra år sedan. Även om populära managementkurser och böcker har försökt tuta i oss motsatsen, att det är toppstyrning som är grejen.

I och med detta kan heller inte alla delar av verksamheten ha gemensamma begrepp och strukturer för allting. Inte ens förr, då de verksamheter vi modellerade var relativt enkla och statiska jämfört med idag, lyckades vi skapa allomspännande modell för en hel verksamhet. I varje fall om den skulle vara användbar, det vill säga ge mer än en mycket ytlig, överförenklad och ofta bedräglig bild.

En större verksamhet består av ett antal deldomäner som aldrig kan vara helt synkade

Jag brukar dra en liknelse: ”Om det vore en så bra idé att skapa en enda modell för en större verksamhet, varför har vi då inte en enda databas med en enda datastruktur som täcker alla behov i en verksamhet?”. När man hör detta tror jag att man tänker lite djupare och inser att olika delar av verksamheten har olika behov och olika prioriteringar. Och att det måste vara så om man inte ska låsa in hela verksamheten i något statiskt och extremt trögrörligt. Något som bara, i bästa fall, kan bli halvbra för de olika behoven.

Med andra ord; en större verksamhet måste ses som ett antal deldomäner som inte alltid går helt i takt och är helt synkade. Skillnaden mellan olika deldomäner beror mer på att olika delar av organisationen har olika historia, olika kulturer, ser olika saker som viktiga och har olika prioriteringar än av rena tekniska orsaker.

Förändring kräver erfarenhet och insikt

Förresten, om vi föreställer oss att vi efter långa och hårda mödor verkligen skulle lyckas ena en hel organisation runt en gemensam syn på allting av väsentlighet. Vad händer då när företaget köper upp ett annat företag, ingår ett branschsamarbete eller outsourcar några verksamhetsfunktioner? Jo, då blir vi tvungna att överge vår snygga enhetliga modell och gå tillbaka till att hantera att olika delar av verksamheten har olika modeller som vi behöver sy ihop på olika sätt.

Jag påstår inte att alla skillnader i begrepp och strukturer inom en och samma verksamhet är bra. Vissa diskrepanser mellan olika verksamhetsfunktioner är nödvändiga. Andra skillnader är kanske onödiga och till besvär, vilket kanske mest beror på att man har olika ursprung och inte har jobbat tillräckligt med att samordna och förenkla. De olikheterna behöver kanske i längden arbetas bort.

Men det är inte möjligt att utan den insikt som en längre tids arbete med modeller, data och funktioner ger oss, skilja på vad som bör få vara som det är mot vad som faktiskt bör förändras. Och för det som bör samordnas krävs det ännu mer insikt om alla olika aspekter om just denna verksamhet, för att förstå vad som krävs för att samordna och hur vi kan få det att hända. Insikt som vi får först efter ganska lång tid av praktiskt arbete inom domänen.

Det första som krävs är i vilket fall att vi verkligen förstår de olika delarna av verksamheten, hur de fungerar och hur deras data ser ut och används. Det vill säga att vi modellerar de olika delarna av verksamheten som egna avgränsade domäner. Så hur vi än vänder oss måste vi börja med att modellera de olika delarna av en verksamhet med separata modeller. Det kommer vi inte ifrån. I alla fall inte i en hyfsat stor verksamhet.

Vi kan dock behöva en översiktlig horisontell modell

Den här artikeln bör inte tolkas som att jag påstår att man inte kan skapa en gemensam ”tunn” horisontell modell för en hel verksamhet, eller en hel bransch. ”Tunn” i meningen att den inte tränger så djupt i området, inte tar med alla förekommande begrepp utan tar ett mer ytligt grepp. Det kan man, och det gör vi ofta, men då för ett avgränsat syfte, till exempel för analys och uppföljning tvärs över en eller flera verksamheter. Det är till exempel grundbulten inom rapportering och Business Intelligence. Det kräver visserligen ett envist och långvarigt arbete, men går att göra.

Men detta är något annat än att man i grunden förändrar de olika verksamhetsfunktionernas egna begrepp och sätt att fungera. Vad vi gör när vi tar fram en modell specifikt för rapportering, analys och uppföljning är att vi skapar ett gemensamt språk ett ”lingua franca” för de aspekter av en verksamhet som man har behov att analysera och följa upp. Det kan vara mycket men långtifrån allt. Och man förändrar då inte samtidigt de olika lokala begreppen och synsätten i de olika operativa delarna av verksamheten.  

Varför vi ofta har svårt att acceptera

Vi har ofta svårt att acceptera den förbistring det innebär att olika delar av vår verksamhet har olika begrepp och olika syn på saker och ting. Det är förklarligt då det ju orsakar uppenbara problem. Olika begrepp och sätt att definiera dessa försvårar kommunikationen och är egentligen det enda som gör integration besvärlig. Det känns inte så elegant, utan mer som en fullösning. Det är detta som ligger bakom alla ambitiösa försök att ena en större domän under en gemensam modell. Men riskerna är många. Låt mig nämna några.

Risker med försök till en gemensam modell för en större domän

  • För stort grepp. Man försöker åstadkomma för mycket på en gång, till exempel då man försöker ersätta flera äldre it-system med ett gemensamt nytt system.Projektet blir nedtyngt när arbetet med att koordinera så många olika intressenter överstiger förmågan och resurserna. Vi har sett många stora och spektakulära it-haverier på grund av detta genom åren.

      Att bara öka på resurserna, det vill säga mer personal, är aldrig en lösning. Det bara ökar behovet av koordinering, och snart går all tid åt till möten. Projektet står helt stilla samtidigt som det bränner pengar och resurser i hög takt. Alla som varit med i större organisationer har nog upplevt detta. Som den kände projektledaren Fred Brooks sa redan på 70-talet: ”To add people to a late project makes it later” eller “Nine women can´t deliver a child in one month”.

      Projekt måste hållas små för att lyckas. Stora projekt har en mycket liten chans att lyckas. Små projekt har däremot en bra track record. Men vad gör man då när uppgiften är stor? Måste man inte driva ett stort projekt då. Nej, hävdar jag bestämt. Stora uppgifter går alltid att dela ner i flera mindre självständiga som var och en levererar nytta i sig självt, menar jag. Även om många inte tror det.

  • Modellen försöker få in alla behov i samma grova mall, vilket leder till att behoven tillfredsställs mycket fyrkantigt, om alls. Många kommer inte att kunna använda modellen utan tvingas ta fram egna modeller ändå.
  • Modellen försöker verkligen tillgodose alla, vilket gör att den får många alternativ och specialfall, vilket gör den mycket svår och omständlig att använda.
  • Arbetet med den stora modellen som ska lösa allt skymmer eller blockerar all annan viktig modellering. Man får då ofta höra: ”Nej, lägg inte ner något arbete på det, det kommer att lösas av den stora kommande (eller pågående) satsningen, som ska leverera om två år!”

Hur gör vi då?

Vi kan alltså inte komma ifrån att vi behöver hantera flera olika modeller i en större verksamhet, där varje modell faktiskt lever sitt eget liv, mer eller mindre.

Om vi helt lämnar tanken på en stor gemensam modell kommer vi att ha ett antal mindre omfattande modeller där var och en beskriver en del eller en aspekt av verksamheten. Utmaningen blir då att se till att de olika modeller vi har ska kunna samverka tillräckligt bra för att stödja gemensamma processer. Det handlar då mycket om förhandling och beslut mellan team.

Det är ett löpande arbete i skärningen mellan design (modellering) och politik. Med andra ord är vi inne på ett ämnesområde som är strategi vad gäller informationsarkitektur. De närmast följande artiklarna handlar om just detta. Då kommer jag att resonera om hur vi på ett mer realistiskt och hållbart sätt kan möta behovet av att få grepp om företeelser, begrepp och information i en verksamhet.

/Peter Tallungs, IRM

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

Om organisationer och personer – fyra vanliga missar

Organisationer och personer är centrala företeelser i varje verksamhet. Men vilka begrepp använder vi för dessa? I denna artikel tar jag upp några vanliga misstag, och ger råd om bra och vedertagna begrepp.

Hur det brukar se ut

I de organisationer jag verkat händer det att man delat in alla intressenter i fysiska och juridiska personer, samt haft personnummer och organisationsnummer som unikt id för respektive kategori. Jag menar att man då lyckats göra flera misstag på en och samma gång. Jag går igenom dem ett efter ett nedan.

Misstag 1: Förväxling av begreppet Organisation med begreppet Juridisk person

Det är inte alla organisationer som är juridiska personer, inte ens merparten, utan faktiskt endast cirka 40 procent av Sveriges tre miljoner registrerade organisationer. De som inte är juridiska personer utgörs främst av enskilda näringsverksamheter, de som i dagligt tal brukar kallas enskilda firmor. De är cirka 1,8 miljoner till antalet. Juridiskt och skattemässigt ingår de i den enskilda näringsidkarens person. Men de är ändå organisationer. De är ibland lite större företag, med många anställda. En och samma person kan äga flera sådana företag som till och med kan finnas på olika orter och ha olika verksamheter. Men de är inte juridiska personer.

Bland andra former av organisationer som inte är juridiska personer finns cirka 20 000 enkla bolag, 200 partrederier, 1 700 värdepappersfonder, 330 statliga enheter, 7 regionala statliga myndigheter samt cirka 6 500 verksamheter som drivs av oskiftade dödsbon. Att kategorisera alla dessa som juridiska personer blir i grunden fel.

Misstag 2: Tron att alla personer i Sverige identifieras med personnummer

Endast personer som är folkbokförda i Sverige har svenskt personnummer. Övriga som ska arbeta i landet, eller av annan anledning behöver få en registrerad identitet i Sverige, får ett så kallat samordningsnummer. Det liknar visserligen personnummer i formatet men har talet 60 tillagt till dagnumret.
(Skatteverket förklarar det så här: Samordningsnummer består liksom personnumret av tio siffror. De inledande sex siffrorna utgår från personens födelsetid med den skillnaden att man lägger till 60 till födelsedagen. För en person som är född den 23 augusti 1964 så blir de sex första siffrorna i samordningsnumret därför 640883).

Att sortera in samordningsnummer under personnummer kan synas vara en oskyldig förenkling. Men jag har varit med om att detta fått följder. Det var ett försäkringsbolag som hade företagskunder och privatkunder i samma register. De ville separera dessa genom att skapa separata register för dessa. Inte minst för att företag och privatpersoner omfattas av olika lagstiftning runt försäkring, och erbjuds olika produkter med olika skydd och olika premier. En programmerare gjorde ett sållningsfilter som baserat på om kunden hade ett giltigt personnummer blev klassad som privatperson, i annat fall som företag. Ett giltigt personnummer har, förutom en giltig checksiffra på slutet, ett giltigt datum, det vill säga de första sex siffrorna. Eftersom samordningsnummer inte klarade det testet blev alla tusentals kunder med samordningsnummer klassade som företag. Innan misstaget upptäcktes och åtgärdades blev det en hel del kostsamma och besvärliga följdfel.

Misstag 3: Tron att alla organisationer i Sverige identifieras med organisationsnummer

Eftersom en enskild näringsidkare kan driva fler än en enskild näringsverksamhet räcker det inte att använda näringsidkarens personnummer för att unikt identifiera en enskild näringsverksamhet. Enskilda näringsverksamheter identifieras därför officiellt med näringsidkarens personnummer följt av en löpsiffra, en etta för personens första näringsverksamhet, en tvåa för den andra och så vidare.

Misstag 4: Ej anpassat till kunder som inte är personer eller organisationer registrerade i Sverige

De identitetsbegrepp vi nämnt gäller endast för personer och organisationer registrerade i Sverige. Om vi har intressenter som saknar en svensk identitet behöver vi ha mer generella namn på våra id-begrepp samt kvalificera dessa med vilket land som utfärdat identiteten.

Hur ska man göra då?

Jag brukar göra så här när det handlar om verksamheter med endast svenska intressenter.

Och så här när intressenterna är internationella.

Det här kan kanske tyckas petigt, det är lättare att bara fortsätta göra som alla andra. Vi är sociala varelser så ibland tror vi att det som alla gör är korrekt bara för att alla gör så. Men det är ett farligt gruppbeteende. Om vi inte kan klara av att fixa det som är enkelt att få ordning på, hur ska vi då kunna reda ut det som verkligen är svårt? Som modellerare är vi ansvariga för begreppen. Då behövs det att vi anstränger oss att använda de termer som korrekt representerar de företeelser vi modellerar. 

Andra intressenter än organisationer och personer

Det jag inte berört här är hur man tänker när man behöver hantera andra intressenter än organisationer eller personer. Ibland vill man se delar av en och samma organisation som olika kunder. Jag har varit med om följande situation i en verksamhet. Vi hade två bröder som kunder. De hade registrerat en firma ihop men sedan gått skilda vägar. De drev separata verksamheter, men hade ändå stannat kvar i samma firma. De hade inte talat med varandra på 20 år och ville absolut inte ses som en och samma kund. Ett annat fall är hur man i försäkringsvärlden ser hushållet som kund. För privat sakförsäkring som till exempel villa-/hemförsäkring och motorfordonsförsäkring är det i de flesta situationer ointressant just vem i familjen som faktiskt står som försäkringstagare. Jag minns knappt inte ens om bilen och villan står på mig eller min partner. Därför är det vanligt att man inom privat sakförsäkring ser hushållet som kund mer än den person som råkar vara försäkringstagare. Men detta är en annan historia.

Vad tycker du?

Jag har säkert missat någon aspekt. Du får gärna komplettera eller rätta om du har en annan synvinkel.

/Peter Tallungs, IRM

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