ARTIKEL | Odysseus

Homeros ska inte behöva lösa våra integrationsproblem.

Vad Odysséen inte kan lära oss om skalbara organisationer, och varför en bra metafor måste veta var den ska sluta.

KÄRNIDÉ

En bra berättelse kan göra ett problem begripligt. Den kan inte ersätta arkitektur, datamodell, governance, testning eller operativt ansvar.

Jag har använt Odysséen för att prata om mål, omvägar, AI, ledarskap, beteendedesign, mätning och lärande.

Det fungerar förvånansvärt bra.

Vilket också är exakt när man bör bli lite misstänksam.

För om en metafor verkar kunna förklara allt är risken stor att den snart inte förklarar någonting särskilt bra.

En metafor ska veta när den ska sluta

Odysséen är stark när den hjälper oss att se mänskliga frågor: riktning, osäkerhet, handlingskraft, frestelse, stöd, omdöme och förändring.

Men den kan inte avgöra vilket system som äger kunddata när två system ger olika svar.

Den löser inte hur behörigheter ska fungera eller vad som händer när ett API ligger nere.

Och den bygger inte säkerhet, drift eller governance åt oss.

Om jag börjar använda Skylla och Karybdis för att förklara microservices har någon rätt att ta ifrån mig tangentbordet.

Där har metaforen slutat hjälpa.

Och det är precis som det ska vara.

Data har ägare även när berättelsen inte har det

I verkliga organisationer behöver vi veta var information kommer ifrån.

Vilket system är den auktoritativa källan?

Vem äger definitionen?

Vilken kvalitet kan vi lita på?

Vilka personuppgifter får användas?

Vad händer när två system beskriver samma person eller objekt på olika sätt?

Data Management at Scale betonar bland annat domäner, golden sources, data contracts, metadata och governance.

Det är inte särskilt poetiskt.

Det är däremot avgörande om AI, dashboards och automation ska kunna lita på datan.

Integration är inte bara att koppla två API:er

Det är lätt att göra integration till en teknisk checkbox.

'Har ni API?'

'Ja.'

'Toppen.'

Problemet är att system inte bara har olika endpoints. De har olika modeller av verkligheten.

Ett 'program' kan betyda en sak i ett LMS och något helt annat i ett CRM.

En 'aktiv användare' kan ha tre olika definitioner.

Domain-Driven Design ger ett användbart språk för detta genom bounded contexts och context maps.

Poängen är att tydliggöra var modeller gäller, vem som äger dem och hur de översätts när system möts.

All friktion är inte dålig

UX-språk gör ibland 'friktion' till något som alltid ska bort.

Det är för enkelt.

Dålig friktion är väntan, dubbelarbete, onödiga klick, otydliga regler och information som måste anges flera gånger.

Bra friktion kan skydda kvalitet, samtycke, säkerhet, reflektion och viktiga beslut.

Det kan vara bra att ett ekonomiskt godkännande kräver en extra kontroll.

Det kan vara bra att en användare måste formulera ett eget svar i stället för att bara klicka Nästa.

Det kan vara bra att en AI-rekommendation med stor konsekvens kräver mänsklig bekräftelse.

Odysseus gör det oönskade beteendet svårare med flit.

Det är inte dålig UX. Det är poängen.

Skalbarhet är mer än att servern orkar

Designing Data-Intensive Applications skiljer mellan bland annat reliability, scalability och maintainability.

Det är en bra påminnelse om att 'skalbar' är ett väldigt lätt ord att säga och ett mycket svårare ord att bevisa.

En lösning kan tekniskt hantera fler användare och samtidigt bli organisatoriskt omöjlig att förvalta.

Den kan ha snabb frontend och en datamodell som gör varje ny rapport dyr.

Den kan automatisera hundra uppgifter och göra felsökning nästan omöjlig.

Den kan integrera allt med allt och skapa ett systemlandskap där ingen längre vet vad som händer när en källa ändras.

Automation behöver ett ansvarssystem

Automation är inte värdefull bara för att en människa slipper klicka.

Frågan är vad som händer när den automatiserade vägen fungerar, och när den inte gör det.

Vem ser felet?

Kan händelsen spåras?

Kan processen pausas?

Vem får ändra regeln?

Vad händer om datan är fel?

Vilka steg kräver mänskligt godkännande?

Det är governance, inte bara workflow.

Säkerhet och integritet är inte sidospår

När system knyter ihop roller, data, AI och externa integrationer blir förtroende en del av själva produkten.

Behörighet, loggning, dataminimering, retention, threat modeling och incidenthantering är inte saker som läggs till när den intressanta delen är färdig.

De avgör vilka flöden som överhuvudtaget är rimliga att bygga.

Det är en annan typ av kunskap än den Odysséen hjälper oss med.

Och det är precis därför avgränsningen är viktig.

Så vad är berättelsen bra för?

Berättelsen hjälper oss att ställa bättre frågor.

Vad är Ithaka?

Vad händer när vägen blockeras?

Vilket stöd ökar människans förmåga?

Har teamet den information det behöver?

Vilken friktion är skyddande och vilken är bara dålig?

Mäter vi verkliga framsteg?

Har resan gjort människan mer kapabel?

Sedan behöver verkliga system svara på en helt annan uppsättning frågor:

• Vilka objekt och relationer finns i datamodellen?
• Vilket system äger vilken data?
• Hur ser integrationskontrakten ut?
• Vilka roller och behörigheter gäller?
• Vilka regler automatiseras och hur loggas de?
• Vilka felmoder finns och hur återhämtar vi oss?
• Hur mäter vi prestanda, kvalitet och effekt?
• Vilken människa äger beslutet när systemet är osäkert?

Hur vi tänker på det i Bizpart

Det här är också en viktig del av hur jag ser på Bizpart.

Det synliga för användaren ska kunna vara enkelt: rätt nästa steg, rätt information, rätt stöd.

Men den enkelheten behöver vila på en betydligt mer avancerad grund av roller, data, regler, integrationer, uppföljning, säkerhet, drift och vidareutveckling.

Bra teknik ska inte göra användaren imponerad av komplexiteten.

Den ska göra att användaren slipper bära den.

Det är där Odysséen slutar som metafor och det verkliga byggandet börjar.

Metaforer hjälper oss att förstå vad vi försöker åstadkomma. Arkitektur avgör om det faktiskt går att göra pålitligt, säkert och i skala.

Underlag och avgränsning

Detta är en medveten motvikt till metaforen, inte ett komplett arkitekturramverk. Relevanta principer beror på kundens risk, storlek, data, systemlandskap och kravbild.

Källor

• Evans, E. (2003). Domain-Driven Design. Addison-Wesley.
• Kleppmann, M. (2017). Designing Data-Intensive Applications. O'Reilly Media.
• Strengholt, P. (2020). Data Management at Scale. O'Reilly Media.
• Bizparts modell- och teoribank: data governance, threat modeling, arkitektur, integration, reliability och maintainability.