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

Tobias Nyberg ny vd för IRM Design

Det är inte ofta, men nu har det hänt. Ett av IRM:s dotterbolag har rekryterat en ny vd. Vid årsskiftet tillträdde Tobias Nyberg som vd för IRM:s dotterbolag IRM Design. Han tar över rollen från Annelie Wiberg som haft den i drygt 13 år. 

”Jag lämnar över vd-rollen med varm hand till Tobias. Han har djup branschkunskap och lång erfarenhet av att skapa framgångsrika it-utvecklingsteam. Vd-bytet innebär inte att jag lämnar IRM. Jag har varit vd under lång tid, det har varit spännande och utvecklande, men nu känner jag att jag får mer energi i rollen som verksamhetskonsult så jag kommer fokusera på våra kunder 100%,” säger Annelie Wiberg.

IRM:s bolag ägs av medarbetarna och drivs av stort medarbetarengagemang. Inför rekryteringen av ny vd tog IRM Designs medarbetare fram en lista på förväntningar. Stor vikt lades vid förståelse för it-konsultens utmaningar och sälj samt förmågan att utveckla framgångsrika team. Tobias Nybergs person och bakgrund matchade förväntningarna perfekt.

Det är IRM Designs värderingar, medarbetarstyrning och potential som inspirerat mig att kliva på. Med passion för ledarskap och verksamhetsutveckling känner jag stor inspiration att göra utvecklingsresan tillsammans med bolaget. Att arbeta i utvecklingsteam och inhouse produktutveckling ger oss väldigt bra momentum och förutsättningar att utvecklas vidare. 

Jag har sett ett av leveransteamen ute på uppdrag och det var synligt vilken skillnad i kundnytta ett välutvecklat team kan åstadkomma. Tidigt slogs jag av en kultur präglad av stor prestigelöshet och vilja att hjälpa kollegor för att lösa det som kommer i teamets väg. Ovanpå detta vilar tung kompetens hos seniora utvecklare  som levererar genom hela kedjan, från kvalificerad informationsmodellering till systemarkitektur, systemutveckling och förvaltning. 

Nu blickar vi framåt och vi vill gärna lyfta fram vikten av krav, UX design- och prototyping inom utvecklingsteam. Vi är nyfikna på nya kollegor inom teamets alla förmågor,” säger Tobias Nyberg.

Det syns inte ofta utåt och det känns inte så mycket på insidan heller, men IRM består av 5 olika bolag: Moderbolaget IRM AB administrerar de levererande dotterbolagen IRM Consult AB, IRM Design AB, IRM Information Architecture AB och IRM Solution AB. IRM Design gör IRM:s kunder framgångsrika genom it-nära verksamhetsutveckling och bidrar med hållbara it-lösningar. IRM Design står idag bakom en bra bit över 100 kundanpassade system. 

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

Processutveckling- inte bara processer

Processutveckling handlar inte bara om processer. Tittar man närmare på en process så innefattar den så mycket. Processen är en del av en verksamhets förmåga, den styrs av regler och är beroende av information i olika former och allt som oftast är det människor inblandade. Och syftet med processutvecklingen är ju att utveckla vår verksamhet. Så lyft blicken och se det som den verksamhetsutveckling det är när vi pratar om processutveckling.

När initiativet till utveckling är taget känns det ofta svårt att rulla ut på rätt bana. Därför har vi tagit fram en checklista som kan hjälpa oss att hålla kursen mot vårt mål med verksamhets- och processutvecklingsinitiativet.

9 checkpoints som håller oss på rätt kurs i processutvecklingen

1. Vi vet varför vi beskriver våra verksamhetsförmågor eller processer och vad vi vill uppnå med det

Vi behöver ställa oss vissa frågor inför ett utvecklingsarbete: Varför gör vi det här? Vad är det för problem vi behöver lösa eller behov som vi behöver uppfylla? Kommer de metoder och arbetssätt vi har valt verkligen att ta oss dit vi vill? De är bra frågor, som tyvärr oftast tappas bort när man väl är igång med utvecklingsarbetet.

Vi måste kontinuerligt ifrågasätta varför vi gör vi det vi gör – under hela utvecklingscykeln.

2. Vi beskriver så mycket av vår verksamhet, omfattning såväl som djup, som syftet ställer krav på. Inte mer, inte mindre

Är det en övergripande bild vi behöver? Eller är det detaljerade djupdykningar i specifika processer? Vad vi ska uppnå styr detaljgraden.

Ett tips är att börja med att snabbt få upp en helhetsbild över verksamheten, t.ex. i form av en förmågekarta/Vintergatan och efter det beskriva processflöden och informationsbehov för de mest prioriterade områdena.

3. Vi har syftet i tankarna när vi kommunicerar vårt utvecklingsarbete; vem ska förstå och varför ska hen förstå våra verksamhetsbeskrivningar? 

För att få till förändring är det viktigt att ”få med folk på tåget”. Kommunicera utvecklingen kontinuerligt med verksamheten. För att jobba med kommunikationen på ett strukturerat sätt tar vi fram en kommunikationsplan där vi beskriver vilken mottagare som ska få vilken information, på vilket sätt och hur ofta. Det är också viktigt att vi gör vår beskrivning av verksamheten i form av modeller och kartor, lätt att förstå. Det kan vi göra genom att visualisera, använda färg och form och illustrationer. Använd verksamhetens eget språk och synliggör gärna synonymer så når du ut brett.

4. Vi ser till att medarbetarna känner igen sig i verksamhetsbeskrivningarna. Detta gör vi genom att involvera människor

Att som individ få vara med och utveckla nya arbetssätt föder mycket mer engagemang jämfört med att bara ta emot en beskrivning av en ny process och bli tillsagd att utföra det nya arbetssättet. Det är också viktigt att som individ förstå processernas resultat; varför gör jag detta arbete och vad ska resultatet användas till?

5. Vi förstår vår egen verksamhets ambition

Hur processorienterade vill vi bli? Ska vi använda processer för att lösa ett specifikt problem eller utveckla ett visst verksamhetsområde? Eller vill vi gå mot en mer processorienterad organisation? Vill vi utse processägare? Etc.

Om vi vill gå mot en mer processorienterad organisation måste vi se över vår incitamentsmodell. Vad belönar vi våra medarbetare för? För att de bidrar till att våra värdeflöden utvecklas och förbättras, eller att de håller sig inom sina organisatoriska ramar? 

6. Vi förstår att införandet av nya idéer i de flesta fall handlar om att människor behöver ändra sitt arbetssätt eller beteende och vi ser till att vi har rätt kompetens för att hantera detta. 

I ett verksamhetsutvecklingsarbete har vi mycket fokus på människan och företagskulturen. Det gäller att säkra att rätt förutsättningar finns för förändringen. Vi använder gärna Kotters 8-stegsplan som stöd vid förändringsarbete. Det första viktiga steget är nästan det viktigaste: Förändringsarbetet ska kännas angeläget!

7. Vi arbetar agilt med utveckling av vår verksamhet och vi levererar nytta i tydliga mindre leveransomgångar 

Vi lever i en värld där vi kan vara säkra på är att förändring kommer att ske i snabb takt. Vi behöver också ofta lösa komplexa uppgifter för att hänga med i förändringen. Målet och vägen dit kommer att vara okänd och under ständig förändring. Detta gör att vi inte kan planera allt och veta vad som kommer att hända. Vi behöver bli mer lättrörliga när det gäller utveckling av vår verksamhet. Detta åstadkommer vi genom små, täta leveranser och feedback på det som levererats. På så sätt kan vi reagera snabbt på förändringar och fånga upp det vi lär oss under utvecklingen samtidigt skapar vi också ett kontinuerligt lärande i verksamheten.

Låt nyttan synas tidigt i förändringsarbetet, då får du fler med på tåget och slipper kostsamma överraskningar.

8. Vi lär känna kunden, på riktigt!

Kunskap om kunden (mottagaren eller den vi är till för) är ovärderlig när vi utvecklar vår verksamhet. När vi väl förstår hur kunderna/mottagarna upplever sina resor i användandet av våra tjänster och produkter, så kan vi också lättare prioritera var vi ska sätta in vår egen utvecklingsinsats. Sluta anta kundernas/mottagarnas upplevelse, ta reda på fakta istället!

9. Information is da shit!

Ja, ni har väl hört talas om datadriven verksamhetsutveckling? När vi utvecklar våra förmågor eller processer så måste vi förstå vilken information som är viktig; vilken information vi behöver, vilken information vi har, vilken information vi kan införskaffa och hur det ska gå till. Vi behöver också säkerställa att kvaliteten och tillgängligheten på vår information är tillräcklig för syftet.

Alla i verksamheten använder information i det dagliga arbetet och omvandlar den för att dra nya slutsatser och starta nya aktioner. Att jobba informationsdrivet innebär att vi tar hand om informationen som genereras i verksamheten och medvetet använder den för att optimera våra värdeflöden och skapa nya värden.

Så, att jobba med verksamhetsutveckling är lika mycket att jobba med informationsutveckling – lägg det på minnet. 😊

Kompetensutveckling

Om du vill få metoder och verktyg för att hålla utvecklingsinitiativen på banan – kolla in våra utbildningar inom process- och verksamhetsutveckling:

Certifierad verksamhetsutvecklare – en utbildning på tolv dagar uppdelade på sex tillfällen

Spela en avgörande roll och ta ett starkt grepp om verksamhetsutvecklingen. Denna utbildning är en skola med praktisk kundorientering.  För att hänga med i dagens snabba utvecklingstakt och för att kunna öka kundnöjdheten och den interna effektiviteten ställs, nu mer än tidigare, krav på en kontinuerlig och lättrörlig verksamhetsutveckling. Certifierad verksamhetsutvecklare ger dig kompetensen att utveckla processer, styra processer och att förändringsleda. 

Certifierad verksamhetsutvecklare – utbildningsbeskrivning

Processutveckling – en kurs på två dagar

Genom att kartlägga hur vi jobbar för att uppnå kundvärde, identifiera målen för varje process och sedan införa mätetal får vi en nödvändig grund för att styra verksamheten emot övergripande mål. Kursen bygger på en väl utprövad teoretisk grund i kombination med praktisk processutveckling. Du får mycket övning samt tillfälle att reflektera över konkreta exempel och ta lärdom av praktisk erfarenhet från verkliga case. Kursen ger dig förmågan att praktisera dina nya kunskaper på ett professionellt sätt, direkt i din egen verksamhet. 

Processutveckling – kursbeskrivning

Informationsmodellering – en kurs på två dagar

Lär dig att identifiera, definiera och strukturera information i modellform genom övningar. Du får lära dig teorin bakom objekt, relationer och nycklar, och vi ger även en genomgång av informationsmodellens användning och visar på samband med förmågemodellering och processutveckling. 

Informationsmodellering – kursbeskrivning

Vintergatan – en kurs på 2 +1 dag

Lär dig ta fram en översiktlig bild över hela eller delar av din egen verksamhet i en förmågekarta. Modellen har en unik syn på verksamhetsutveckling och låter dig kombinera och visualisera flera perspektiv i samma karta som processer, business capabilities, applikationssystem, kundresor, etc. Vilket leder till en oslagbar överblick.

 Vintergatan – skapa din verksamhetskarta – kursbeskrivning

Vi levererar våra utbildningar i samarbete med Dataföreningen Kompetens AB