Sammanfattning

I detta avsnitt pratar vi om balansakten mellan enkelhet och komplexitet. Du får lära dig vad vi menar med onstage och backstage i Prime Arch – och varför båda perspektiven behövs. Vi visar hur du kan anpassa modeller och vyer efter målgruppen utan att skapa parallella sanningar. Ett måste för dig som vill bygga förståelse utan att tumma på struktur och analys.

Transkript

Välkommen tillbaka till Prime Arch-podden. Jag heter Patrik Hallén, och idag ska vi prata om något som väldigt många går vilse i när de jobbar med verksamhetsarkitektur, nämligen balansen mellan enkelhet och komplexitet. För om du är som många andra, så har du säkert någon gång hört att “allt ska vara enkelt att förstå”. Och visst, det låter klokt. Ingen vill ju sitta i ett möte och titta på diagram som ser ut som ett kretskort. Samtidigt vet du också att verkligheten inte alltid är enkel. Verksamheter är komplexa. Det finns tusen samband mellan processer, information, system och människor. Och försöker man göra allting superenkelt, så riskerar man faktiskt att missa viktiga detaljer.

Men Patrik, ska vi inte sträva efter enkelhet i allt vi gör? Det är ju det alla säger – keep it simple!

Jättebra poäng. Och det är faktiskt en av de vanligaste fällorna vi ser. Enkelhet är absolut viktigt – men inte överallt och inte hela tiden. Tänk dig en restaurang. När du sitter där som gäst vill du ha en snygg meny, god mat och en servitör som hjälper dig på ett trevligt sätt. Du vill inte veta hur många kylskåp de har i köket, eller hur diskvattnet hanteras. Allt det där sker backstage. Men någonstans måste det finnas människor som vet hur köket fungerar på riktigt. Annars faller allt ihop. Det är precis samma sak i verksamhetsarkitektur. Vissa delar måste vara enkla och snygga, så att ledning, verksamhet eller användare kan förstå och fatta beslut. Det är det vi kallar onstage. Men bakom kulisserna, backstage, finns det en annan nivå av detaljer som behövs för att allt ska fungera på riktigt. Det är där vi beskriver detaljerade samband, tekniska strukturer eller komplexa informationsmodeller. Och den backstage-bilden behöver inte alla se – men någon måste ha koll på den.

Prime Arch bygger just på det här synsättet. Vi brukar säga att man ska visa lagom mycket. Du behöver inte trycka upp hela kökets ritning på väggen i restaurangen. Det räcker att visa menyn. Men du måste ha ritningen någonstans. Annars vet ingen var spisen står. I Prime Arch handlar det därför mycket om att bestämma vilken nivå du ska jobba på – och för vem. För Anna, som verksamhetsutvecklare, räcker det ofta med en onstage-bild som visar processerna och hur de hänger ihop. Hon behöver inte se alla tekniska detaljer. För Johan, som konsult, kan det vara värdefullt att ha både en snygg onstage-bild till kunden och en backstage-bild som visar exakt hur allt hänger ihop, om någon börjar ställa svåra frågor. Erik, som verksamhetsarkitekt, jobbar ofta backstage. Han behöver kunna analysera detaljer, koppla ihop modeller och hålla ordning på komplexiteten. Men även han måste ibland zooma ut och visa onstage-bilder som folk faktiskt orkar titta på. Och Lena, som EA-teamledare, sitter ofta mitt emellan. Hon måste kunna prata med ledningen på ett enkelt språk, men också säkerställa att hennes team jobbar strukturerat backstage.

Men Patrik, är inte risken att man skapar två världar som aldrig hänger ihop? Att det onstage och det backstage blir helt olika sanningar?

Väldigt bra fråga. Och det är en helt riktig risk. Därför är Prime Arch byggt för att koppla ihop onstage och backstage. Det handlar inte om att skapa två olika sanningar. Det handlar om att visa olika vyer av samma verklighet, beroende på vem som tittar. Tänk dig en karta över en stad. För en turist räcker det kanske med en enkel turistkarta som visar sevärdheter och tunnelbanestationer. Men för en stadsplanerare behövs en detaljerad karta som visar elledningar, avloppssystem och trafikflöden. Båda kartorna handlar om samma stad – men visar olika nivåer av detaljer. På samma sätt är det i Prime Arch. Du kan zooma in eller ut, men modellerna bygger på samma objekt och samma samband. Det är så du undviker att få två olika världar som inte pratar med varandra.

I nästa avsnitt ska vi prata om grunderna i objektorientering och varför vi tror att verksamhetsutveckling inte ska bygga på dokument – utan på objekt som du kan återanvända, kombinera och förändra när verksamheten förändras. Tack för att du har lyssnat idag. Jag hoppas du börjar se att enkelhet och komplexitet inte behöver vara varandras motsatser. Det handlar bara om att visa rätt vy för rätt person. Välkommen tillbaka till Prime Arch-podden.

Länkar

🎧 Lyssna på Spotify
📱 Öppna i Prime Arch-appen