From good to great #2: Fail or prevail.

Som jag nämnde i första delen i artikelserien är jag övertygad om att den agila ansatsen till mjukvaruutveckling är en av de bästa sakerna som någonsin hänt vår bransch. Med det sagt tycker jag att det fortsatt finns stort utrymme för förbättringar i de agila metoder vi använder och dess underliggande principer.

Är agilt agilt?

Dagens affärsklimat är mer präglat av konkurrens än någonsin. Globaliseringen har medfört att världen har krympt avsevärt och det finns alltid konkurrenter som jagar dig och hotar att göra saker lika bra som, eller kanske till och med bättre än du. Konkurrensen kommer att bli ännu hårdare i framtiden eftersom alla företag nu effektiviserar sin verksamhet och försöker att hitta möjligheter som innebär fördelar jämfört med sina konkurrenter. Ingen beskriver den utvecklingen bättre än den kanadensiske premiärministern Justin Trudeau;

The pace of change has never been this fast, yet it will never be this slow again.

För att kunna behålla en ledarposition, eller åtminstone hålla jämna steg med sina konkurrenter, måste dagens företag vara både proaktiva och snabbrörliga. Det innebär att det blir extremt viktigt att ha en agil och flexibel verksamhet. Företag som inte lyckas förnya sig och hantera förändringar snabbt kommer att bli utkonkurrerade.

Hur berör det här oss som mjukvaruutvecklare? Vi kan väl knappast vara ansvariga för våra kunders affär, eller kan vi det? Jag säger att vi faktiskt är det. I princip alla delar av dagens företagande stöds av programvara. Om ett företags verksamhet förändras är det mycket troligt att mjukvarusystemen också måste förändras och att de dessutom måste förändras snabbt för att inte skapa en flaskhals i företagets affärsutveckling. Mjukvarulösningar måste därför utformas på ett sådant sätt att dess struktur och arkitektur överensstämmer med den verksamhet de stöder. Det måste vara möjligt att identifiera, implementera och driftsätta nödvändiga mjukvaruförändringar på ett effektivt sätt som är både långsiktigt hållbart och inte adderar teknisk skuld.

Agil mjukvaruutveckling riskerar att påverka företags verksamhetsagilitet negativt

Nu till en viktig fråga. Betyder det faktum att vi utvecklar programvara baserat på agila metoder att resultatet per automatik gör det möjligt för verksamheten att bli mer agil? Jag vill hävda att så inte är fallet. Agila metoder och verksamhetsagilitet är inte samma sak. Tvärtom kan agil mjukvaruutveckling till och med ha en negativ inverkan på företagens agilitet. Agila metoder har ett starkt fokus på att leverera programvara snabbt i korta iterationer. Att leverera programvara snabbt är naturligtvis i sig bra för affärsflexibiliteten, åtminstone på kort sikt. Problemet är att en prioritering av snabb leverans i korta, timeboxade iterationer riskerar att leda till att vi, troligtvis omedvetet, offrar långsiktig kvalitet, genomtänkt struktur och stabil lösningsarkitektur på vägen. Därför finns det en betydande risk för att den mjukvarulösning som utvecklas blir rörig och allt svårare att underhålla och utveckla över tid.

När vi pratar om kvalitet i detta sammanhang handlar det om mycket mer än att bara skriva buggfri kod. Naturligtvis bör koden vara så felfri som möjligt, men kvalitet i det sammanhang som har att göra med mjukvarulösningar som stödjer verksamhetsagilitet  handlar om struktur, struktur och åter struktur. Förresten, nämnde jag att strukturen verkligen är viktig?

De viktiga grejerna

Nu kanske du frågar dig varför strukturen är så viktig och vad det egentligen innebär. Struktur handlar om hur mjukvarulösningar och system delas in i mindre och större komponenter och hur de är beroende av - och interagerar - med varandra. Det handlar om allt från hur mjukvaran är sammankopplad internt på detaljnivå till hur större komponenter, såsom system och tjänster, är anslutna till och kommunicerar med varandra.

Struktur är oerhört viktigt eftersom den avgör hur mjukvarulösningen kommer att åldras och hur länge den faktiskt kan leva. Varje komponent, från små enheter på låg nivå i kod som exempelvis klasser, metoder och funktioner till större enheter som tjänster, bör ha ett tydligt uttalat ansvar och bör vara ansvarig för en enda uppgift och ingenting annat. Relaterad affärslogik och funktionalitet bör också samlas och isoleras i en enda komponent. Låt oss ta en tjänstebaserad e-handelslösning som ett exempel. En tjänst som ansvarar för att hantera ordrar bör definitivt inte också hantera produkter. Affärslogik relaterad till ordrar bör inte heller finnas i andra komponenter utanför själva ordertjänsten.

Dessutom bör varje enskild komponent vara så fristående och oberoende av andra komponenter som möjligt. Ändringar i en komponent bör inte resultera i en kaskad av förändringar i andra komponenter. Mjukvarulösningar som är strukturerade på detta sätt kommer att stötta företags verksamhetsagilitet. Om och när (och lita på mig, det kommer att hända ganska ofta) verksamheten förändras, är de nödvändiga mjukvaruändringarna enkla och snabba att identifiera, implementera och driftsätta. Eftersom den berörda affärslogiken är isolerad i en enda komponent är det enbart nödvändigt med ändringar i just den komponenten och dessa ändringar kommer inte tvinga andra komponenter att förändras.

Att åstadkomma välstrukturerad mjukvara kräver mycket tänkande och analys och kommer definitivt inte att uppstå av sig själv. Den välrenomerade datavetenskapsprofilen Ralph Johnson sa en gång;

Software architecture is about the important stuff. Whatever that is.

Från det tidigare resonemanget i den här artikeln följer att struktur kan vara det enskilt viktigaste konceptet inom mjukvaruutveckling och bör vara en fråga för IT-arkitekter, vilket det definitivt är. Detta faktum belyser en annan, potentiellt förödande, brist när det gäller agil utvecklingsmetodik. Agila metoder, såsom scrum, säger att det inte ska finnas några uttalade roller inom ett utvecklingsteam. Dvs att det bör inte finnas någon enskild person som ansvarar för mjukvaruarkitekturen. För att vara helt ärlig och tydlig anser jag att det är fullständigt nonsens. I själva verket säger de agila principerna inte att arkitektur ska ignoreras, tvärtom. Vad de däremot säger är att ansvaret för arkitektur ska delas över hela utvecklingsteamet. I teorin är det en vacker tanke men som vi alla har lärt oss den hårda vägen betyder delat ansvar i praktiken att ingen är ansvarig. Den här lite slarviga attityden inbjuder tyvärr till ett oansvarigt synsätt på arkitektur, det vill säga på de ”viktiga sakerna”. Jag skulle till och med säga att denna princip tyvärr ofta misstolkas grovt på ett sätt som innebär att det inte anses nödvändigt att ha med några personer med arkitekturkompetens i utvecklingsteamen.

Kall spagetti

Bristande fokus på arkitektur och struktur inom ett projekt kommer utan tvekan att leda till ett fenomen som kallas accidental architecture. Det innebär att arkitekturen växer fram på ett okontrollerat sätt under projektet. Den blir vad den blir, enbart baserat på tekniska beslut från enskilda utvecklare, utan en tydlig, långsiktig plan eller ett övergripande helhetsperspektiv. Accidental architecture är troligtvis det mest förödande antimönster som kan uppstå inom mjukvaruutveckling och det oundvikliga resultatet är vad mjukvaruutvecklare brukar kalla för "spagettikod". Tyvärr pastaälskare!

 

Spagetti är en utmärkt metafor för kod som är är komplex, trasslig och svår att reda ut. Det är ett  problem som dessutom förvärras med tiden när mjukvaran underhålls och vidareutvecklas och man försöker att bygga vidare på och addera till redan rörig kod. Om du någonsin har försökt trassla ut en klump klibbig, kall spagetti vet du vad jag menar. Över tid kommer det bli exponentiellt mer tidskrävande att utföra förändringar och de kommer orsaka ett eländigt flöde av oförutsedda sidoeffekter och buggar. Så småningom nås ett tillstånd där mjukvaran helt enkelt inte kan underhållas och nya funktioner inte kan läggas till med en rimlig utvecklingsinsats. Slutligen resulterar det i att mjukvaran får gå ditt mjukvara går för att dö.

Alla utvecklare kan skapa mjukvara som fungerar för tillfället, men det krävs gedigna kunskaper för att kunna skapa mjukvara som fungerar på lång sikt.

Accidental architecture och dåligt strukturerad mjukvara är lömskt i den meningen att allt kan se snyggt, prydligt och skinande ut initialt. Själva projektet kan mycket väl betraktas som en stor framgång eftersom mjukvaran levererats enligt kundens behov och krav och fungerar som en väloljad maskin. Problemet är att de strukturella brister som finns under ytan inte kommer att dyka upp eller märkas initialt. Istället kommer de att bida sin tid för att sedan dyka upp och ställa till det för dig i ett senare skede. Och tro mig, det kan verkligen bli ett ordentligt slag i ansiktet. Mjukvaruprojekt som verkar mycket framgångsrika till en början kan övergå till en stinkande röra efter en tid av förändringar och tillägg. Arkitektur och struktur är knepigt för kunderna eftersom det inte är någonting de omedelbart kan uppfatta eller bedöma. Alla utvecklare kan skapa mjukvara som fungerar för tillfället, men det krävs gedigna kunskaper för att kunna skapa mjukvara som fungerar på lång sikt. Struktur och en bra, väl genomtänkt arkitektur blir som viktigast när utvecklingsprojektetet är klart och mjukvaran övergår i förvaltning.

Den magiska lösningen

Okej, jag tror att du är med på vad jag försöker säga nu. Dålig struktur är dålig, bra struktur är bra. Men vad är bra arkitektonisk struktur och hur uppnår vi den? Svaret är, som så ofta, att det beror på. Framför allt beror det på kunden och deras verksamhet. En sak som i alla fall är säker är att struktur och arkitektur är de saker som är svårast att ändra i ett senare skede av mjukvarans livscykel. Därför bör arkitekturen baseras på något som är stabilt och som ändras så sällan som möjligt. För att kunna utvecklas tillsammans med kundens verksamhet och affär så friktionsfritt som möjligt bör arkitekturen dessutom efterlikna affärsstrukturen. Detta koncept är känt som software-to-business alignment och kan vara det närmaste en magisk lösning man kommer inom mjukvaruarkitektur. Om vi ​​lyckas skapa en arkitektur som efterliknar någon enhet i kundens affärsstruktur som sällan förändras har vi bästa möjliga chans att skapa en långsiktig och hållbar mjukvarulösning av hög kvalitet. En sådan lösning kan smidigt utvecklas tillsammans med kundens verksamhet och gör det möjligt för kunden att vara snabb, innovativ, proaktiv och agil i sin affärsutveckling.

Allt kokar ner till en sista stor fråga. Vilken "gyllene enhet" i kundens verksamhet bör vi använda som grund för lösningsarkitekturen? Låt oss fokusera på vem, hur och vad som är olika perspektiv på verksamhetsstrukturen. Vem handlar om vilka personer det är som utför viktiga affärsaktiviteter. Med andra ord handlar det om organisationsstruktur. Att basera den övergripande arkitekturen på organisationsstrukturen skulle absolut kunna vara ett alternativ. Det skulle inte vara det bästa alternativet eftersom organisationsstrukturen tenderar att förändras ganska ofta. Som ett illustrativt exempel måste jag dela ett citat som ofta nämns av Sten Sundblad, en av mina största inspirationskällor. Sten har varit arkitekt på toppnivå sedan långt innan jag ens visste vad mjukvara var. Citatet härstammar från ett uttalande som uppstod i en dialog som Sten hade med chefsarkitekten för en av de svenska myndigheterna.

Den nuvarande organisationstrukturen är det tillfälliga resultatet av den senaste maktkampen.

Uttalandet sades säkert i en skämtsam ton, men om vi tänker till lite så innehåller citatet definitivt en hel del sanning. Stannar du kvar i samma företag i några år är chansen att du upplever en eller flera organisatoriska förändringar, ofta relaterade till att en ny VD eller någon annan i ledande position kommer in i företaget, ganska hög. Därför är organisationsstrukturen inte den bästa kandidaten att basera arkitekturen på.

Hur-perspektivet handlar om de flöden och metoder som används för att utföra affärsaktiviteter och hur dessa aktiviteter knyts samman för att forma själva verksamheten. Dessa kallas vanligtvis för affärsprocesser och eftersom de är betydligt mer stabila än organisationsstrukturen utgör de en avsevärt bättre grund att bygga arkitekturen på. Däremot tenderar även affärsprocesser att ändras emellanåt, särskilt när man i verksamheten vidtar åtgärder för att bli mer effektiva. Låt oss ta optikerbranschen som ett illustrativt exempel. För bara ett decennium sedan gick de flesta av oss fortfarande till en fysisk optikerbutik för att köpa glasögon eller linser. Idag kan du enkelt och smidigt skicka ditt elektroniska optikerrecept till en e-handlare för att få dina synhjälpmedel levererade hem till ett avsevärt lägre pris än när du besöker en traditionell optiker. Denna utveckling har naturligtvis tvingat optikerna att ändra sina affärsprocesser. Således är affärsprocesser ett ganska bra alternativ att basera arkitekturen på, MEN kanske finns det ett ännu bättre alternativ....

Det tredje och mest intressanta alternativet som grund för arkitekturen är vad-perspektivet. Det handlar om vad verksamheten behöver kunna göra för att kunna uppfylla sina behov, mål och för att vara relevant och konkurrenskraftig. Den stora fördelen med detta perspektiv är att det verksamheten behöver kunna göra sällan förändras och om det förändras beror det nästan alltid på att verksamheten måste kunna göra en helt ny sak eller att den inte längre behöver kunna göra något som den brukade göra. Ur ett arkitekturperspektiv är det mycket lättare att lägga till nya saker eller ta bort gamla saker än att ändra redan befintliga saker. I affärsmässiga termer kallas detta affärsförmågor, dvs förmågor som företaget måste ha för att lyckas med sin verksamhet och sin affär. På grund av sin inbyggda motståndskraft mot förändringar är affärsförmågor det absolut bästa alternativet för att åstadkomma en stabil arkitektur med en hög grad av software-to-business alignment. Var uppmärksam, för jag kan inte betona detta nog! Om du lyckas skapa en mjukvarustruktur baserad på affärsförmågor är chansen stor att du har skapat en flexibel, utbyggbar och underhållbar lösning som kommer att kunna leva riktigt länge utan att vittra sönder. Grattis! Du har precis tagit ett stort språng mot storhet! 

Att ändra våra tillvägagångssätt är aldrig lätt och att bygga mjukvara som är anpassad till affärsstrukturen kan lätt tyckas vara nästan överväldigande svårt. Visst, det är en ny typ av tankesätt och det kommer förmodligen att kräva några försök innan du får ordning på det hela. Saken är den att allt inte behöver vara perfekt, inte alls. Att försöka enligt bästa förmåga kommer ta dig en bra bit på vägen och är väldigt mycket bättre än att inte göra någonting alls. Framförallt, genom att utforma en väl genomtänkt arkitektur, i vilken form det nu kan vara, undviker vi eländet med accidental architecture med alla sina katastrofala konsekvenser.

 

Författare

Markus Bergendahl

Lösningsarkitekt

SQLI Nordics