From good to great #2: Fail or prevail.

By — Star Republic
01.29.2021

from-good-to-great_1.original

Del 2 - "Fail or prevail"

Hej och välkommen till den andra delen i artikelserien "From good to great." som handlar om hur vi systemutvecklare kan höja oss till nästa nivå och åstadkomma stordåd i vårt hantverk för att uppfylla kundernas behov kopplat till programvara. Vi fortsätter där vi avslutade den första delen ”Be agile, not fragile.”, som fokuserade på hur agila metoder kan utvecklas ytterligare genom att bli mer affärsfokuserade. Ämnet för denna andra del är hur vi kan utveckla agila metoder ytterligare för att designa och leverera mjukvarulösningar som stöttar affären på bästa sätt.

Som jag nämnde i första delen av min artikelserie är jag verkligen övertygad om att det agila synsättet på systemutveckling är en av de bästa sakerna som någonsin hänt vår bransch. Dock tycker jag att det fortsatt finns en hel del 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. Världen har krympt avsevärt på grund av globaliseringen och det finns alltid en massa konkurrenter som jagar dig och hotar att göra saker lika bra som, eller kanske till och med ännu 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 fördelar som gör att de skiljer sig från sina konkurrenter. Ingen beskriver denna utveckling bättre än den kanadensiska 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 lyhörda. Det gör att flexibilitet kopplat till affären blir extra viktigt. Företag som inte lyckas förnya sig och hantera förändringar snabbt kommer att bli förlorare.

Hur berör detta oss som systemutvecklare? Vi kan knappast vara ansvariga för våra kunders affärer och företag, eller är vi? Jag säger att vi är det. I princip alla delar av dagens företagande stöds på något sätt av programvaror. Om verksamheten förändras är det mycket troligt att stödsystemen också måste förändras och att de måste förändras snabbt för att inte skapa en flaskhals i affärsutvecklingen. Programvarulösningar måste utformas och struktureras på ett sådant sätt att de överensstämmer med den verksamhet de stöder. Det måste vara möjligt att identifiera, implementera och släppa nödvändiga förändringar i dessa på ett effektivt sätt som både är långsiktigt hållbart och inte bygger på en teknisk skuld.

Agile software development can actually have a negative impact on business agility

Så betyder det faktum att vi utvecklar programvara baserad 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 agilitet är inte samma sak. Tvärtom kan agil mjukvaruutveckling faktiskt 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 kan leda till att vi offrar långsiktig kvalitet, en genomtänkt struktur och en arkitektonisk programvarudesign på vägen. Därmed finns det en betydande risk för att den slutgiltiga programvaran 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 felkod". Naturligtvis bör koden vara så felfri som möjligt, men kvalitet kopplat till programvaror som ska stötta en affärsfunktion 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 den egentligen betyder. Tja, 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 programvaran implementeras internt till hur huvudkomponenter, såsom system och tjänster, är anslutna till och kommunicerar med varandra.

Struktur är oerhört viktigt eftersom den avgör hur bra programvarulö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 till exempel 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 just en enskild uppgift. Relaterad affärslogik och funktionalitet bör också samlas tydligt 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 beställningar bör definitivt inte också hantera produkter. Affärslogik relaterad till beställningar bör inte heller finnas i andra komponenter utanför själva beställningstjä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 affärsflexibilitet. Om och när (och lita på mig, detta kommer att hända ganska ofta) verksamheten förändras, är de nödvändiga programvaruändringarna enkla och snabba att identifiera, implementera och distribuera. Eftersom den berörda affärslogiken är isolerad i en enda komponent är det bara nödvändigt med ändringar i den här komponenten och dessa ändringar tvingar inte andra komponenter att förändras också.

Välstrukturerad programvara kräver mycket tänkande och analys och kommer definitivt inte att skapas upp av sig själv. Den välkända programvaruvetenskapsmannen Ralph Johnson sa en gång;

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

 

 

Efter resonemanget ovan kan struktur vara det viktigaste i programvaruutveckling och bör vara en fråga för programvaruarkitekter, vilket det definitivt är. Detta faktum belyser en annan, potentiellt förödande, brist när det gäller agila programvaruutvecklingsmetoder. Agila metoder, såsom scrum, säger att det inte ska finnas några uttalade roller inom ett utvecklingsteam. Dvs det borde inte finnas någon enda person som ansvarar för programvaruarkitekturen. För att vara ärlig och tydlig tror jag starkt att det är rent och fullständigt nonsens. I själva verket anger de agila principerna inte att arkitektur ska ignoreras. Vad de säger är att ansvaret för arkitektur ska delas över hela utvecklingsteamet. I teorin är detta en vacker tanke men som vi alla har lärt oss på det hårda sättet betyder i praktiken alla att vara ansvariga att ingen är ansvarig. Denna slarviga attityd inbjuder 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 ofta tolkas grovt på ett sådant sätt att det inte alls finns några personer med arkitekturkunskap i utvecklingsgruppen.

Kall spagetti

För lite fokus på lösningsarkitektur och struktur inom ett projekt kommer utan tvekan att leda till "accidental architecture". Detta innebär att arkitekturen växer på ett okontrollerat sätt under projektet, enbart baserat på tekniska beslut från enskilda utvecklare, utan en tydlig, långsiktig plan eller en helikopterperspektiv. Detta är förmodligen det mest förödande mönster som kan skapas inom mjukvaruutveckling och det oundvikliga resultatet av detta är vad systemutvecklare kallar för "spaghettikod". Tyvärr pastaälskare!

spaghetti

Spaghetti är faktiskt en bra metafor för att en kod är komplex, intrasslad och svår att reda ut. Detta problem förvärras med tiden när programvaran underhålls och vidareutvecklas och det görs försök att bygga på och lägga till delar i en redan rörig kod. Om du någonsin har försökt trassla ut en klibbig klump kall spagetti vet du vad jag menar. Det kommer att ta exponentiellt längre tid att skapa förändring och orsaka ett evigt flöde av oförutsedda effekter och buggar. Så småningom når vi en tidpunkt där programvaran helt enkelt inte kan underhållas och nya funktioner inte kan läggas till med en rimlig utvecklingsinsats och slutligen resulterar detta i att programvaran helt enkelt får gå ur tiden.

Any developer can create software that works for the moment but it takes real skills to create software that works in the long run.

"Accidental architecture" och dåligt strukturerad mjukvara är lömska i den meningen att allt kan se bra ut initialt. Själva projektet kan betraktas som en stor framgång eftersom programvaran 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, de kan ställa till en hel del. Programvaruprojekt som verkar mycket framgångsrika till en början kan övergå till en enda röra efter en tid av förändringar och tillägg. Just arkitektur är ett knepigt ämne för kunderna eftersom det inte är något de omedelbart kan uppfatta eller bedöma. Alla utvecklare kan skapa programvara som fungerar för tillfället, men det krävs gedigna kunskaper för att kunna skapa programvara som fungerar på lång sikt. Struktur och bra, genomtänkt arkitektonisk design blir viktigast när utvecklingsprojektet är klart och programvaran går in i förvaltningsfasen.

Den gyllene koden

Okej, jag tror att du är med på vad jag försöker att 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 är säker är att struktur och arkitektur är de saker som är svårast att ändra i ett senare skede av en programvaras livscykel. Därför bör arkitekturen baseras på något som ändras så sällan som möjligt. För att kunna utvecklas tillsammans med kundens verksamhet så friktionsfritt som möjligt bör arkitekturen likna affärsstrukturen. Detta koncept är känt som "software-to-company"-anpassning och kan vara det närmaste en gyllene kod du kan hitta inom programvaruarkitektur. 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 smidig i sin affärsutveckling.

Allt detta 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å olika perspektiv på en affärsstruktur utifrån vem, hur och vad. Frågan om vem handlar om vilka personer 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 absoluta inspirationskällor. Sten har varit lösningsarkitekt på hög nivå sedan långt innan jag ens visste vad programvara 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. Översatt till engelska lyder det:

The current organizational structure is the temporary result of the most recent struggle for power.

Detta kan ju ha sagts i en lekfull ton av Sten, men om vi tänker ett extra varv 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 chef kommer in i företaget, ganska hög. Således kan organisationsstrukturen inte vara den bästa kandidaten som underlag till en arkitektonisk grund.

Hur-perspektivet handlar om vilka flöden och metoder som används för att utföra affärsaktiviteter och hur dessa aktiviteter knyts samman för att stötta själva verksamheten. Dessa kallas normalt för affärsprocesser och eftersom de är mycket mer stabila än organisationsstrukturen utgör de en bättre grund för programvaruarkitektur. Detta även om affärsprocesser ändras då och då, särskilt när verksamheten vidtar åtgärder för att bli mer effektiva. Låt oss kika på optikerbranschen som ett illustrativt exempel. För ungefär ett decennium sedan gick vi fortfarande till en fysisk optikerbutik för att köpa glasögon eller linser. Idag kan du skicka ditt optiska kvitto till en e-handlare för att få dina synhjälpmedel levererade hem till en bråkdel av priset du betalar 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 ha som arkitektonisk grund, MEN det finns kanske ett ännu bättre alternativ....

Det tredje och mest intressanta alternativet för arkitekturgrunden är vad-perspektivet. Det handlar om vad verksamheten behöver 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 som verksamheten har för att kunna göra sällan förändras. Om det verkligen 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 arkitektoniskt perspektiv ä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 är det som kallas affärsfunktioner, dvs. funktioner som företaget måste ha. På grund av dess motståndskraft mot förändringar är affärsfunktionerna det absolut bästa alternativet för att bygga en stabil arkitektur med en bra mjukvara-till-företag-anpassning. Var uppmärksam, för jag kan inte betona detta nog! Om du lyckas skapa en mjukvarustruktur baserad på affärsmöjligheter är chansen stor att du har skapat en mycket flexibel, utdragbar och underhållbar lösning som kommer att kunna leva länge, länge. Grattis! Du har precis tagit ett stort steg mot storhet!

Att ändra våra tillvägagångssätt är aldrig lätt och att bygga programvara som är anpassad till affärsstrukturen kan 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 att den att allt inte behöver vara perfekt, inte alls. Att försöka göra ditt bästa tar dig en lång bit på vägen och är en mycket bättre inställning än att göra ingenting alls. Genom att utforma en väl genomtänkt arkitektur undviker vi framförallt att skapa en "accidental architecture" med alla de katastrofala konsekvenser den kan innebära.

Det var allt för nu, gänget. I den tredje och sista delen av serien "From good to great." kommer vi att bjuda på några tips och tricks för att uppnå en mer affärsinriktad programvarustruktur.

Håll utkik efter den sista delen, snart i en kanal nära dig!

 

Författare

Markus Bergendahl

Lösningsarkitekt

Star Republic

 

Säg hej!