Sammanfattning
Modeller som ingen förstår gör ingen nytta. I det här avsnittet pratar vi om varför begriplighet och användarvänlighet är avgörande för att lyckas med verksamhetsarkitektur. Vi går igenom onstage och backstage, två scener med olika språk – och hur Prime Ark hjälper dig att bygga modeller som både går att visa upp och använda för analys, utan dubbelt arbete.
Transkript
Patrik:
Välkommen tillbaka till Prime Arch-podden. Jag heter Patrik Hallén, och idag ska vi prata om något som kanske är det allra viktigaste när det gäller verksamhetsarkitektur – nämligen begriplighet och användarvänlighet. För vi kan bygga hur tekniskt korrekta modeller som helst. Vi kan använda rätt objekt, rätt nivåer, och hålla oss till alla principer. Men om ingen förstår modellerna, eller om folk tycker att de är för krångliga att använda – ja, då har vi misslyckats. Modellerna är till för människor – inte tvärtom. Och det är precis det vi ska prata om idag.
Elin:
Men Patrik… varför är det så viktigt att modeller ska vara enkla och användarvänliga? Räcker det inte att de är korrekta?
Patrik:
Det är en jättebra fråga. Och det enkla svaret är: en modell som ingen använder, är helt värdelös. I Prime Arch pratar vi därför om att våra modeller ska vara både enkla och kraftfulla. Enkla, eftersom de ska fokusera på en specifik frågeställning och inte visa allt på en gång. Och kraftfulla, eftersom de faktiskt ska kunna besvara den frågeställningen. Det är där värdet ligger. En modell är inte kraftfull bara för att den är full av symboler och detaljer. Den är kraftfull när den hjälper någon att fatta ett bättre beslut, eller förstå en komplicerad situation på ett nytt sätt. För Anna, som är verksamhetsutvecklare i offentlig sektor, handlar det om att hon snabbt ska kunna förstå hur verksamhetens processer hänger ihop. Hon ska inte behöva vara utbildad arkitekt för att tolka modellerna. Johan, som är konsult, behöver modeller som är tillräckligt enkla för att imponera på kunden – men samtidigt så pass detaljerade att de går att använda som underlag för förändring. Erik, som arbetar som verksamhetsarkitekt, vill att modellerna ska vara logiska och konsekventa, så att han slipper lägga tid på att förklara symboler eller begrepp. Och Lena, som leder ett EA-team, behöver kunna ta en modell och visa upp den för ledningen – utan att folk börjar stirra ner i tabeller och fråga vad alla symboler betyder.
Elin:
Men Patrik… hur gör man då för att modellerna ska bli både enkla och kraftfulla?
Patrik:
Det är här Prime Arch gör en viktig skillnad. Vi säger att det handlar om två saker: fokus och anpassning. Fokus betyder att modellen ska svara på en specifik fråga – inte tio frågor på en gång. Anpassning betyder att du måste använda rätt språk och rätt nivå för den som ska titta på modellen. Och här kommer en annan viktig sak: Onstage och backstage handlar inte bara om detaljer. Det handlar framför allt om vilket språk vi använder och vilken publik vi riktar oss till. I Prime Arch brukar vi säga att det finns två scener, onstage. Den första är verksamhetsscenen. Där pratar vi verksamhetens språk – processer, verksamhetsbegrepp, vilka informationsobjekt som används och hur allt hänger ihop på ett sätt som människor ute i verksamheten förstår. Den andra scenen är IT-scenen. Där pratar vi fortfarande enkelt och begripligt – men på IT:s språk. Där handlar det om system, integrationer, tjänster, och ibland tekniska komponenter – men fortfarande på en nivå där även de som inte är arkitekter kan förstå. Backstage, däremot, är arkitekternas värld. Här samlar vi allt vi lärt oss från både verksamhetsscenen och IT-scenen. Vi kopplar ihop saker, berikar modeller, gör analyser och hittar mönster. Här kan vi till exempel transformera processmodeller till förmågemodeller, eller gå från verksamhetsbegrepp till informationsentiteter och bygga komplexa informationsmodeller med saker som kardinaliteter och modaliteter. Backstage får gärna vara komplex – det är ofta nödvändigt för att kunna göra djupare analyser och hitta samband som ingen ser onstage. Men både onstage och backstage kan finnas på olika detaljeringsnivåer. Onstage kan vara översiktligt eller detaljerat – det viktiga är att språket är anpassat för mottagaren. Backstage kan också vara översiktligt eller detaljerat – men det är främst till för arkitekterna själva. Det är därför Prime Arch är så kraftfullt. Det låter oss bygga modeller som både går att visa upp på onstage – och som kan användas för djupa analyser backstage – utan att behöva bygga om allt från början.
Elin:
Men Patrik… riskerar det inte att bli dubbelt arbete om man måste göra både onstage och backstage?
Patrik:
En jättebra fråga. Och ärligt talat – det är en av de största utmaningarna. Men Prime Arch är byggt för att du ska slippa bygga om allt från början. Vi bygger våra objekt en gång, och sedan kan vi visa dem på olika sätt beroende på vilken scen vi står på och vilken fråga vi vill svara på. För Anna betyder det att hon kan jobba med processflöden som är enkla och överskådliga, men veta att samma objekt också finns backstage, redo för Erik att analysera. För Johan handlar det om att kunna visa rätt nivå av detaljer för kunden utan att behöva göra två helt olika modeller. Och för Lena handlar det om att teamet kan jobba effektivt utan att trampa varandra på tårna. Det handlar alltså inte om dubbelt arbete – utan om att bygga en flexibel grund som går att använda både onstage och backstage. I nästa avsnitt ska vi prata om balansen mellan enkelhet och komplexitet i Prime Arch – alltså hur vi undviker att visa för mycket backstage, men ändå inte döljer viktig information. Tack för att du har lyssnat idag. Jag hoppas att du nu ser varför begriplighet och användarvänlighet inte är någon lyx – utan en nödvändighet för att lyckas med verksamhetsarkitektur. Välkommen tillbaka till Prime Arch-podden.
Länkar
🎧 Lyssna på Spotify
📱 Öppna i Prime Arch-appen