Arkitekturblogg del 4: Att arbeta med taktiker inom mjukvaruarkitektur

25 November 2016 // Patrik Gustavsson

I föregående blogginlägg såg vi att krav på kvalitetsegenskaper driver på arkitektens arbete och själva arkitekturen. Att förstå definitionen för vad en kvalitetsegenskap är för något, är därför viktigt både för dig som arkitekt och för dig som arbetar i andra roller relaterade till arkitektens arbete.

”A quality attribute (QA) is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its stakeholders. You can think of a quality attribute as measuring the “goodness” of a product along some dimension of interest to a stakeholder.” (Software Architecture In Practice, sid 63).

Vikten av att kunna mäta och testa ett krav (”measurable or testable”)

“Systemet ska vara säkert” eller ”Systemet ska vara användbart” är inga krav eftersom de inte går att mäta eller testa. ”Lösenord i databasen ska vara krypterade med en MD5 algoritm” och ”85% av användarna ska inom 2 minuter förstå bokningssidan så tydligt att de klarar av att boka en resa själv” är däremot krav på säkerhet och användbarhet.

Kravet på att förstå bokningssidan (användbarhet) visar att en del kvalitetsegenskaper inte är så enkla att mäta. Jämför med att ta tid med en klocka för att mäta prestanda, eller att kontrollera att systemet är igång för att mäta tillgänglighet. För att mäta användbarhet för bokningsfunktionen krävs det att användare som inte tidigare sett bokningssidan får sätta sig framför datorn och försöka boka en resa. Ett annat exempel där man behöver mäta på ett lite mer sofistikerat sätt är krav på modifierbarhet. Modifierbarhet mäts i hur lång tid det tar för ett utvecklingsteam att göra en förändring av en viss storlek i applikationen. Det är värt att reflektera över att modifierbarhet är en egenskap som du som arkitekt kan vara med och påverka och som har effekt långt efter det att projektet är färdigt.

Vikten av att kraven verkligen har efterfrågats (”interest to a stakeholder”)

En arkitekt som kommer till ett projekt och tänker ”jag ska göra systemet så säkert och så användbart som det bara är möjligt”, utan att känna till kraven eller verksamheten, har inte förstått sin roll. Kraven på säkerhet eller användbarhet kanske inte är så höga för ett visst system. Arkitektens uppgift är att systemet ska leva upp till de ställda kraven, inte att maximera kvaliteten ur alla aspekter. Inte minst för att det lätt leder till att kostnaden och tiden för projektet då riskerar att överstiga det som det faktiskt finns behov av. Det finns nog ingen som skulle vilja betala materialkostnader för att en bro ska klara fordon på 100 ton när det bara finns behov av att klara fordon på 20 ton. Samma synsätt bör gälla inom mjukvaruarkitekturen.

Noggrannhet i värden för krav på kvalitet

Hur noggrant ska man då mäta krav på kvalitet? Svaret på den frågan är inte helt enkel men det man bör ha i åtanke är att det inte bara är du som arkitekt som är mottagare av krav på kvalitet. Andra mottagare av kraven kan ha behov av högre grad av noggrannhet än vad du som arkitekt har.

Som illustration kan vi titta på skillnaden mellan kraven på 99,2% tillgänglighet under kontorstid och 99,4% tillgänglighet under kontorstid. Vad innebär de kraven för dig som arkitekt? Siffran 99,2% har säkert redan fått dig att ha två servrar igång samtidigt så att om en av dem går ned så är ändå själva applikationen fortfarande igång. Skillnaden att gå till 99,4% har troligen ingen praktisk betydelse för dig som arkitekt. Men för den driftsorganisation som har skrivit på ett serviceavtal (SLA) innebär ändringen i kravet en direkt påverkan på inställelsetid vid problem.

Mitt råd är att aldrig försöka få fram noggrannare värden från kravställaren än vad du behöver för att motivera ett beslut som du behöver göra. Annars slösar du både med kravställarens tid och din egen tid. Men det är som sagt viktigt att du faktiskt får värden och inte bara uttryck som ”säkert” och ”användbart”.

Taktiker

Nu har vi kommit fram till ett läge där det är lämpligt att beskriva vad en taktik är och återigen tar vi en definition från Software Architecture In Practice.

”The quality attribute requirements specify the responses of the system that, with a bit of luck and a dose of good planning, realize the goals of the business. We now turn to the techniques an architect can use to achieve the required quality attributes. We call these techniques architectural tactics. A tactic is a design decision that influences the achievement of a quality attribute response to some stimulus. Tactics impart portability to one design, high performance to another, and Integrability to a third”. (Software Archiecture In Practice, sid 70).

Varje kvalitetsegenskap har en uppsättning av taktiker som går att använda. Taktikerna är i sin tur grupperade beroende på angreppssätt för det som de vill åstadkomma. Det är ofta möjligt att använda mer än en taktik åt gången för att få arkitekturen att leva upp till de krav som finns på kvalitet. Nu ska vi titta närmare på ett par exempel på hur man använder taktiker för att uppnå hög grad av tillgänglighet.

Exempel på taktiker för tillgänglighet

Det finns tre angreppssätt till att få hög tillgänglighet.

• Upptäck fel (detect faults)
• Återhämta efter fel (Recover from faults)
• Förhindra fel (prevent faults)

”Availability refers to a property of software that it is there and ready to carry out its task when you need it to be”. (Software Architecture In Practice, sidan 79).

Tillgänglighet - upptäck fel

Ett exempel på taktik är ”heartbeat” vilket innebär servern kontinuerligt skickar ut meddelanden för att berätta att den är igång. Dessa meddelanden kan avlyssnas för att det ska gå att slå larm om meddelandena slutar komma. Taktiken ”heartbeat” leder inte till att servern är mer stabil och inte går ner lika ofta. Men tillgängligheten påverkas positivt eftersom servern kommer att startas upp snabbare efter en krasch.

Här följer en lista på de taktiker som används inom den här kategorin.

• Ping/echo
• Monitor
• Heartbeat
• Timestamp
• Sanity checking
• Condition monitoring
• Voting
• Exception detection
• Self-test

Tillgänglighet – återhämta efter fel

Två vanliga taktiker är ”active redundancy” och ”passive redundancy” och de innebär att du har mer än en server så att tillgängligheten inte påverkas om en av dem går ned.

Här följer en lista på de taktiker som används inom den här kategorin.

• Active redundancy
• Passive redundancy
• Spare
• Exception handling
• Rollback
• Software upgrade
• Retry
• Ignore faulty behavior
• Degradation
• Reconfiguration
• Shadow
• State resynchronization
• Escalating restart
• Non-stop forwarding

Tillgänglighet – förhindra fel

En taktik är ”removal from service” vilket innebär att du kan ta ned en komponent och starta upp den igen för att förhindra minnesläckage eller någon sorts fragmentering.

Här följer en lista på de taktiker som används inom den här kategorin.

• Removal from service
• Transactions
• Predictive model
• Exception prevention
• Increase competence set

Stimulus för taktiker

Går vi tillbaks till definitionen av taktik (“A tactic is a design decision that influences the achievement of a quality attribute response to some stimulus”) så ser vi att ordet ”stimulus” behöver vi också förstå för att veta vad en taktik är för något. Stimulus är input till taktiken och en taktik levererar ett resultat. Stimulus är det som egentligen motiverar till att en taktik behövs.

För modifierbarhet är ”Change arrives” ett stimuli och för säkerhet är ”Attack” ett stimuli. Stimuli för tillgänglighet är helt enkelt ”Fault”. Resultatet av taktiker för tillgänglighet är ”Fault masked” eller ”Repair made”.

Slutord

De taktiker som vi tittat på ovan handlar enbart om tillgänglighet. Men det finns många taktiker för att uppnå andra önskvärda egenskaper som samarbetsförmåga, modifierbarhet, prestanda, säkerhet, testbarhet, användbarhet och mycket mer.

Tänk vilka bra förutsättningar du får som mjukvaruarkitekt om du är bekant med de här taktikerna. Din möjlighet att utgöra en positiv inverkan på ett projekt och få fram en bra arkitektur ökar markant om du använder taktiker. Det är skillnaden mellan att behöva ha en del ”good luck” som det står i definitionen av taktiker mot att använda väl beprövade tekniker.

Några saker som jag själv känner att kunskap om taktiker gett mig i olika sammanhang.

• Förmåga att se luckor i kravställning, förstå vad man borde ha ställt krav om
• Förstå sammanhanget i arbetsmetodiker lättare, relation mellan krav, arkitektur, design, test osv. Dvs varför man gör vissa saker och vad man missar om man inte utför dem
• Leva på beprövade erfarenheter. Taktiker är samlade erfarenheter av vad som ”brukar fungera” i arkitektursammanhang
• Bidra till ökad kvalitet i mjukvaran genom att förstå att min roll som arkitekt främst handlar om få arkitekturen att leva upp till krav på kvalitetsegenskaper
• Ta fram lösningar enligt beprövade mönster

Det finns mycket annat att nämna också men i princip tycker jag man kan säga att arbete med taktiker är skillnaden mellan att försöka ta fram en arkitektur enbart baserat på egna idéer och tankar och att ta fram en arkitektur på ett professionellt sätt baserad på yrkeskunskap.

Nästa blogginlägg i serien kommer att handla om arkitekturmönster. Efter att ha gått igenom arkitekturmönster, mekanismer och en del andra saker så kommer bloggserien att övergå till att fokusera mer på olika ämnesområden som arkitektur i molnet, arkitektur i agila projekt, validering av arkitektur, ramverk, Enterprise arkitektur och många andra spännande områden. Men ett tag till bör vi fokusera på de saker som utgör en mjukvaruarkitektur och hur man arbetar som arkitekt med dem.