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.

/Peter Tallungs, IRM, 2022-01-27

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

Taggar: #Informationsarkitektur, #StrukturmönsterFörInformationsarkitekter