Arkitekten som facilitator i ett lean-agilt kontext – del 1

17 oktober 2019

Medvetet arbete med arkitektur har alltid varit en förutsättning för ett framgångsrikt utvecklingsarbete i större skala. Dels genom att klargöra och beskriva verksamheters riktning, däribland förväntningarna på deras produkter, samt genom att ta fram underlag för hur IT-lösningar kan realiseras. Trots det har spelplanen för hur olika typer av arkitekter bäst bidrar till verksamhets- och produktutveckling inte alltid varit självklar. Ramverket SAFe för uppskalat lean-agilt arbete tydliggör hur arkitektur passar in i sammanhanget.

I denna artikelserie om tre delar reflekterar vi kring hur man med avstamp i nio principer, som är en del av SAFe-ramverket, kan arbeta med arkitektur. Principerna är kraftigt inspirerade av Don Reinertsens reflekterande teser för produktutveckling som han beskriver i boken: Principles of product development flow. Vi resonerar även om arkitektur och arkitekters roll i allmänhet. Vi går inte in på specifika skillnader mellan olika typer av arkitektroller. Eftersom SAFe inte finns översatt till svenska är vissa begrepp i vår artikel på engelska.

 

Denna första artikel handlar om princip 1-3:

  • Princip #1 – Take an economic view

  • Princip #2 – Apply system thinking

  • Princip #3 – Assume variability, preserve options

Princip #1 – Take an economic view

Den första principen grundar sig på något som kan tyckas vara självklart; att all förändring ska vara värdeskapande. En produkt eller IT-lösning som inte tillför något värde måste betraktas som ett misslyckande. Av erfarenhet vet vi dock att i praktiken är långt ifrån all produkt- eller IT-utveckling värdeskapande. Utvecklingsprojekt vars utvecklingskostnader skenat okontrollerat är otaliga. Inte sällan är lösningarna vare sig ordentligt genomtänkta eller förankrade hos användarna.

 

Ofta saknas transparens mellan viktiga beslut på strategisk och operativ nivå. Reinertsen poängterar vikten av att förstå konsekvenserna av olika beslut som påverkar en produktutvecklingscykel. Fel beslut på strategisk eller operativ nivå kan leda till att utveckling och förvaltning produkter tar för lång tid eller kostar för mycket.

 

Många arkitekter har gjort tappra försök att klargöra den värdeskapande aspekten av ett förändringsarbete. Arkitekter ses ofta som teknikstrateger och ur det perspektivet bör de fokusera på att ta beslut och leverera strategier för IT som ger störst nytta för investerade resurser.

 

Arkitekterna förväntas dock ofta ”sätta arkitekturen” och även uppskatta lösningars omfattning redan i ett tidigt skede. Allt för att beslutsfattare ska känna sig trygga inför en större investering. Att göra det i traditionella projekt som sträcker sig över långa tids- perioder är dock en i stort sett omöjlig utmaning och inger enbart ledning, arkitekter och övriga intressenter i en falsk känsla av trygghet. SAFe-ramverket betonar att utvecklingsarbetet ska bedrivas taktat samt leverera ofta, vilket bidrar till att säkra kontinuerligt värdeskapande och synkronisera olika intressenter.

 

Ramverket betonar även vikten av att tidigt tydliggöra den ekonomiska aspekten av utvecklingsarbete, genom att tydliggöra riktlinjer för olika beslut som påverkar en produkts ekonomi. Det kan till exempel handla om förhållningssätt vid investeringar i tekniska plattformar och olika leverantörsval. Fel beslut kan driva teknisk skuld, behov av omarbetning, kvalitetsbristkostnader, missnöjda användare samt att en produkt landar helt fel på marknaden. I grunden är det naturligtvis av stor vikt att kunna påvisa kopplingar mellan ett förändringsinitiativ och verksamhetens övergripande målsättningar - något som ofta spretar i många organisationer.

 

I SAFe är alignment (hur väl saker relaterar till varandra) en nyckelterm. Enligt SAFe måste sambandet säkras mellan strategiska initiativ och prioriteringar av en programinkrements backlog (avgränsat utvecklingsinkrement som genomförs fokuserat under cirka 10 veckor). Arkitekten hjälper med fördel till att visualisera och tydliggöra just alignment för alla olika intressenter.

 

Vidare är det naturligt att arkitekten bidrar till att tydliggöra sambanden mellan olika faktorer som produkters kvalitetsegenskaper, ledtid, kostnad och risk vilket hjälper till att balansera mål och medel. Förutom att stötta verksamhetsledningen stöttar arkitekten utvecklingsteamen och ser till att systemet i vid bemärkelse hänger ihop. Arkitekten säkrar viktiga gemensamma investeringar för genomförande av ett eller flera programinkrement - de som är strategiska, behövs långsiktigt och skapar synergier. Operativa beslut ska istället kunna tas i de olika utvecklingsteamen, med arkitekten som stöd och bollplank vid behov längs vägen. Arkitekten agerar i en faciliterande roll i det utmanande utvecklingsarbetet som helhet.

 

Princip #2 – Apply system thinking

Det finns tre hörnstenar som utgör fundamentet i SAFe - det ”agila manifestet”, vikten av att tänka lean produktutveckling (enligt Reinertsens filosofi) samt att uppmärksamma det holistiska systemtänkandet. En IT- applikation är i sig ett system, andra applikationer och komponenter som samverkar genom integration utgör ett större system, de som utvecklar lösningen representerar också ett system och verksamheten som nyttjar lösningen betraktas som ytterligare ett.

 

Därför lyfter SAFe fram att det är av vikt att förstå inte bara utvecklingsvärdeströmmar utan också operationella värdeströmmar för att lösningar inte ska bli missriktade. Systemtänkandet finns naturligt varje arkitekts DNA eftersom en produkt eller lösning ofta är en del av en helhetslösning i en organisations arkitektur. I traditionellt projektarbete är det inte ovanligt att det saknats en lyhördhet för behovet att klargöra dessa perspektiv utan man har istället fokuserat enbart på det egna projektets leverabler vad gäller tid och kostnad. Att helhetstänkande lyfts fram så tydligt i SAFe välkomnas därför varmt av arkitektskrået. Det är dock viktigt att i det här sammanhanget poängtera att modellering och dokumentation ska ske precis i den utsträckning som behövs för sammanhanget och inte mer – en förmåga till avvägning för varje arkitekt att bemästra.

 

Enligt ett agilt förhållningssätt bör arkitekten se sig som en facilitator som synliggör komplexitet och samband för verksamhetsägare och produktledning, stöttar utvecklingsteamen i att bryta ned system i mindre delar, avgör lämpliga avgränsningar samt identifierar rätt integrationspunkter. 

 

Princip #3 – Assume variability, preserve options

Förmågan att skapa system som är byggda för modifiering är avgörande i en alltmer föränderlig värld. När är det då rätt tidpunkt att fatta beslut som påverkar en produkt eller lösnings inriktning - såsom beslut om funktioner, hårdvara, mjukvaruplattformar, användargränssnitt eller integrationslösningar?

 

I SAFe-ramverket poängteras betydelsen av att inte ta lösningsbeslut för tidigt i utvecklingsarbetet. ”As late as possible, but not too late” är rådet. Det kan låta utmanande men konsten att skjuta på beslut handlar om att lära sig att hantera balansen mellan nödvändig kontroll och den för utvecklingsarbetet essentiella flexibiliteten.

 

I SAFe betonas konceptet set based design, en form av hypotesdriven utveckling. Det illustreras genom att utvecklingsteam rör sig genom en Cone of uncertainty – en avsmalnande kon där det kontinuerliga lärandet längs vägen minskar osäkerheten. Ju närmre leverans ett team befinner sig desto lättare får de att validera sina antaganden. Genom att integrera och leverera kontinuerligt säkras gemensam förståelse för en lösning. För produktutformning finns alltid olika potentiella alternativ och den tekniska utformningen av lösningen har oftast fler sätt som är ”rätt”. Detta är vad SAFe benämner som marknadens och teknikens variabilitet. Just förmågan att hantera variabilitet skiljer IT- utvecklingen från traditionell produkttillverkning som helt bygger på standardisering. Det finns ambitioner att standardisera även när det gäller IT- utveckling men det har visat sig vara en alltför komplex utmaning till följd av balansgången mellan kontroll och flexibilitet. Förmågan att hålla alternativ öppna och att ta bra beslut kring vägval blir istället central.

 

Kontinuerlig värdering av tekniska alternativ inklusive deras marknadskonsekvenser är en uppgift där arkitekterna kan erbjuda stöttning i utvecklingsarbetet. Arkitektur enligt ett agilt förhållningssätt utvecklas över tid och kan se olika ut olika skeden av utvecklingsarbetet. Regler såsom krav på kompletta lösningsbeskrivningar innan bygge får påbörjas och månatliga granskningar av lösningar i ett arkitekturråd har sällan visat sig vara ett framgångsrikt recept för att bygga förtroende mellan utvecklare och arkitekter.

 

Att frångå sådana traditionella förhållningssätt kan dock innebära ett helt nytt tankesätt för vissa arkitekter. Med utgångspunkt i ett agilt förhållningssätt kan arkitekter istället hjälpa utvecklingsteam tydliggöra teknisk vision, kontext, komponentstruktur och integrationspunkter för lösningar samt utvärdera arkitektur- design för komponenter. I en bra arkitektur har utvecklarna och arkitekten tänkt på ett sätt så att det är lagom sammanhållet och lagom distribuerat så att man just kan göra förändringar för framtida behov. Arkitekten hjälper med fördel till med uppgifter som att skapa en miljö där det är tillåtet att experimentera, fastställa viktiga systemegenskaper, skissa på scenarier, utreda konsekvenser samt sammanställa eventuella beslutsunderlag – återigen i rollen som facilitator av utvecklingsarbetet vilken rör sig mellan strategisk och operativ nivå.

 

Av: Johanna Värild, Forefront Consulting. Nästa del handlar om princip 4-6 och publiceras om en vecka. 

 

Är du intresserad av att veta mer om ämnet så håller Forefront, i samarbete med DF Kompetens, en kurs i SAFe for Architects. Några få platser finns kvar, läs mer om kursen här

 

Nästa nyhet

Forefront och Primona levererar upphandlingssystem till stor offentlig upphandlare

16 oktober 2019