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. 

/Peter Tallungs, IRM, 2022-01-20

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 med 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

22.01.20