De tre principer jag nämnde i bloggposten:

• Enklare är bättre
• Nu är bättre än sen
• Karta funkar, men det gör inte backspegel

… har i praktiken lett till en del konkreta sätt att tillämpa de tre principerna, som jag själv alltid följt när jag ansvarat för arkitekturfrågor. Hoppas att min sammanställning kommer till nytta. Som rättesnöre för mig har de under åren sparat en hel del tid. När jag arbetat efter omfattande metoder och ramverk har punkterna nedan varit de centrala.

Enklare är bättre

Ny teknik och nya funktioner driver med automatik upp komplexiteten i en it-stack. Därför behövs ständiga förenklingar och konsolideringsinsatser. Det är en del av livscykelkostnaden.

Förenkling innebär kontinuerlig konsolidering, eliminering av överlappande funktioner och ett ständigt ifrågasättande av om man måste ta allt ansvar själv. Bara när varför är klarlagt, går det att vara säker på vilka delar som går att förenkla. Det är sammanhanget som i praktiken är avgörande. Den övergripande förståelsen för vad som vart system är på väg gör tvärfunktionella frågor som integration, regelefterlevnad och informationssäkerhet hanterbara och relevanta, istället för att bli allt svårare. Utan kontroll blir hela miljön lätt ett alltmer komplicerat lappverk.

 

”Utan varför, blir all prioritering meningslös.”

 

Dessutom är risken för att informationssäkerhet och integritet går förlorade på vägen. Tråkigt nog har jag under min karriär sett fler exempel på att så är fallet än motsatsen.

Att köpa färdiga funktionsblock som applikationskoncept, arkitekturkomponenter, publika molnkomponenter eller för den delen Basalts privata moln blir en nyckel. Det är den typen av åtgärder och förutsättningslöst tänk som gör helheten gripbar. Att se och förstå varför blir lättare.

Nu är bättre än sen

Bara för att något går fort, innebär det inte att det är rätt. För mig är fort och rätt två oberoende parametrar. Hotet utifrån gör fort mycket viktigare idag, och det ställer krav på att helheten är anpassad för det.

Det finns självklart enkla ekonomiska principer som nuvärde, som säger att tillgänglig nu är värt mer än tillgänglig senare. Det är inte det jag avser, utan snarare att sätta förutsättningarna för att kunna leverera snabbare.

 

”Cyberhotet gör det allt viktigare att kunna jobba fort. Krav på reaktionstid har minskat från veckor till timmar.”

 

Både fort och rätt behöver vara en del av basfunktionaliteten, som det är när man köper färdigt. Det är ju till exempel ett av kärnvärdena med outsourcing. Hela miljön blir någon annans ansvar. Molnet är ju också en form av outsourcing, bara mer uppdelat på komponenter, och automatiserat från grunden. Fort går knappt att göra idag utan hög grad av automatisering, och som är en inneboende egenskap i ett moln, oavsett om det är privat eller publikt.

Det är den typen av struktur och genomarbetade lösningar som gör det möjligt att leverera i bitar, så att varje leverans blir liten, mindre komplex och värde kan genereras snabbare. Att bygga system så, tvingar hela arkitekturen och arbetssätt på såväl utveckling som drift att följa i samma spår – i den mån de numera är separata.

Med små och täta releaser minska risken för att man utvecklar funktioner som inte kommer till nytta och tillfällen till att få feedback om vilka problem som är viktigast att hantera blir fler.

 

”Fort och rätt behöver vara basfunktionalitet, när man köper färdigt.”

 

Den typen av lösningar leder vidare till exempel till att huvudprinciperna för kommunikation mellan system sker asynkront och med webb-orienterade tankesätt som meddelandeströmmar istället för synkrona integrationer med handskakning. De senare tenderar att kräva att hela informationskedjan är implementerad, istället som i det asynkrona fallet, där nya funktioner införs i mindre enheter och fungerar oberoende av varandra. Lösningarna man väljer, oavsett om de köps eller byggs behöver följa samma tänk.

För att lyckas med små och separata initiativ, behövs en tydlig bild av vart man är på väg och hur det är tänkt att saker hänger samman. Återigen kommer kartan till nytta.

Karta funkar, men det gör inte backspegel

Med en karta, eller långsiktig plan, blir det också tydligt hur lång livslängd mer kortsiktiga investeringar har. Först då går det egentligen att bestämma värdet av en lösning. Kortfristiga avvikelser från målbilden lösningar behöver inte vara fel, men utan målbild saknas sätt att bedöma städkostnaden och kalkylen kommer vara baserad på fel indata. Jag brukar kalla det för backspegel-metoden. Nu är väl tyvärr backspegeln snarare normalfallet för investeringar, där att sopandet under mattan av framtida kostnader bara ökar spretigheten.

Att ekonomiskt motivera en konsolidering eller förenkling går normalt inte i en sådan kultur. Trettiofem år senare sitter man fortfarande kvar med samma kärn-system, som en av mina tidigare arbetsgivare gjorde. Vad det gör för kulturen är förödande. Med tiden blev förändring i sig en risk och något man gick omvägar om. Att ta bort system blir svårare och svårare. Förståelsen på detaljnivå för hur information flödade lämnade dessutom en del övrigt att önska, så verklig säkerhet var en önskedröm minst tio år in i framtiden.

Backspegel-metoden gör det därför svårt att hantera tekniksprång och nya hot. Att något inte hänt innebär inte att det inte kommer att hända, och att hantera ett tekniksprång kommer upp på agendan först när konkurrenter sprungit ifrån en och du inser vad som hänt efter en analys av hur saker gått så illa. Att istället ha en karta, eller en målbild, innebär att någon åtminstone försöker förstå vilka utmaningar man står inför och kan börja prioritera åtgärder innan resten av marknaden redan gjort det.

”… att hantera ett tekniksprång kommer upp på agendan först när konkurrenter sprungit ifrån en …”

Dessutom ignorerar backspegel-metoden i princip risk. Risker blir en separat process och hanteras utan att synka med resten av it:s agenda, vilket i praktiken resulterar i lösningar som hanterar akuta problem men lämnar hål. Ännu mer lappa och laga, alltså. Dessutom hamnar man gärna i ett läge där ansvaret för att hantera en risk blir frikopplat från hur den uppstod. Kommunikation om risker som existerar tenderar att få något av ”vargen kommer” över sig eftersom de upprepas gång på gång i möten utan att något gjorts och gröper över tid ur förmågan att prioritera faktabaserat.

Därför blir en karta en nödvändig förutsättning för att kunna hålla en stringens i det man gör på it.

Att säga nej

Sen har vi det där med att säga nej till verksamhetens initiativ. Det förtjänar ett eget litet avsnitt. När it säger nej till en verksamhet som har pengar, går verksamheten ut och köper en lösning på stan. Det är ju inget nytt. Sist jag blev överkörd själv – dessutom av ytterst seniora ledningspersoner som borde veta bättre – upptäckte man säkerhetshål som fördubblade projektets längd och all tid och pengar som icke insatta personer trodde sig spara försvann och rejält mer därtill. Dessutom blev den slutliga lösningen ett lappverk, där bara de största säkerhetshålen täpptes till. GDPR blev mer eller mindre ignorerat.

Nu fattas många beslut på det viset. Vi har väl alla sett det hända, och därtill alldeles för ofta. Vad som är förvånande, är att vi misslyckas med med att göra något åt det, att vi misslyckas med att förklara konsekvenserna så att vi kan fatta bättre beslut. Det enda sätt jag hittat att hantera problemet är svårt:

1. Lova att leverera i tid.
2. Dela upp jobbet i releaser så att första leveranser sker snabbt.
3. Håll därmed vad du lovat.

Verksamheten kanske inte får allt med en gång, men i takt med att den får det du lovat i tid, ökar förtroendet för att det blir gjort när du ber om respekt för andra prioriteringar. Så säg inte nej.

”Ta pengarna och kör så det ryker.”

Följer du principerna jag nämnt ovan, har du ju kartan och verktygen för att leverera snabbt.

Summerat i actions

Om jag extraherar actions ur det här resonemanget får jag:

• Var konsekvent – annars kommer enkelheten att misslyckas
  • Jobba med ”varför”
  • Ha koll på återbetalningstid och värde, om än bara riskreducering
  • Dela upp problemet
  • Fokusera på det du behöver, inte det som är ”bra att ha”
• Sikta på att jobba mindre, för andra kommer fylla på
  • Köp mer så att du får tid över
  • Använd molnet så ansvaret för komplexitet försvinner
  • Konsolidera – för det är det ingen annan som ansvarar för
  • Säg aldrig nej till kärnverksamheten – för då tappar du kontrollen och det som kändes som mindre blev mer att göra
• Ta med risker i prioriteringarna annars blir hela beslutsunderlaget skevt
  • Strukturera och kalibrera riskanalysen
  • Värdera risker i termer som gör dem jämförbara med andra risker. Pengar funkar alltid
  • Ha en reservplan