Jag är mycket intresserad av arkitektur. Hur koden struktureras, vart den placeras, vad som anropar vad, vilka domänobjekten är, hur datan flödar genom systemet. Arkitektur representerar för mig de val som görs i utvecklingen av systemet som är svårast att ändra kostnadseffektivt senare. Dessa val kan vara tekniska. Som val av databas och språk etc. Men det är inte de jag främst tänker på. Tekniska val spelar roll, men används de vanligaste språken finns förmodligen förutsättningarna att utveckla det som önskas oavsett.
Big design up front is dumb. Doing no design up front is even dumber.
Dave Thomas
Jag tänker snarare på de val som görs i designen av systemets komponenter. Det är inte längre spännande att se om man lyckas koda det där mejlet som skall gå iväg till den där personen när någon viss sak händer. Det behovet kommer lösa sig. Något kommer bli levererat som utför detta. Det som är intressant att fråga sig är: skrapar denna efterfrågan på ett större organisatoriskt behov som snart kommer uppdaga sig måne? Kan då systemet byggas på ett sådant sätt att det blir enkelt att koppla på mera personer till samma lösning?
Finns det någon grupp av funktioner som behöver utvecklas eller ändras ständigt? Optimera då med extra tajta ramar för leverans av denna kärnfunktionalitet i systemet. Snabbt exempel: en grym basklass andra komponenter kan ärva från.
Försök också skapa en plats i periferin av systemet där slit och släng funktionalitet kan skapas och tas bort. Kanske blir moduler i denna arm av systemet inte lika snyggt integrerad för användaren men visar det sig att någon funktion är extra omtyckt kan den få en bättre plats vid bordet i framtiden.
En god arkitektur skapar en trivsam DX som leder till att behov kan förstås, utvecklas och levereras smidigt och utan regressioner.
Arkitekturen bjuder in till ett gemensamt språk där kodare inte längre pratar om enskilda klasser, utan större koncept och hur de kopplas samman med andra delar av systemet.
Arkitekturen kan skapa möjligheten för flera att göra mer utan omprogrammering. Systemet skall vara tillräckligt datadrivet och gränssnitt för konfigurering exponeras till användaren. Skapa framtida förutsättningar som motverkar ”lusten” att hårdkoda värden som bör vara dynamiska.
Strive to leave the world less complex than you found it! You’re not done when you’ve ”solved the problem”. You’re only done when you’ve cleaned up the inevitable mess.
Brian Goetz
Arkitektur etablerar också en gemensam samsyn kring teknikvalen i systemet och hur olika typer av funktioner brukar designas. Vissa delar kanske körs som återkommande bakgrundsjobb. Andra funktioner kickas igång av någon händelse.
Arkitekturen påverkar hur systemet körs i produktion. Vilka förutsättningar som finns att felsöka OLIKA typer av problem och hur systemet kan observeras under last.
Personen eller personerna som driver arbetet med arkitekturen kanske kallar sig arkitekter men de är också alltid mycket kompetenta programmerare.
Arkitekterna är de som slutligen frågar sig ”Behöver vi verkligen detta?”. Behövs ett externt loggningssystem? Inte nu men senare? Behövs AI sättas in här? Bör systemet göras om till microservices? Varför?
Designing how a modification is best incorporated into an established program depends on the perception of the similarity of the new demand with the operational facilities already built into the program. The kind of similarity that has to be perceived is one between aspects of the world. It only makes sense to the agent who has knowledge of the world, that is to the programmer.
Arkitekterna försöker se hur behoven kan komma att ändra sig i framtiden. Behöver systemet orka med mer användare inom 5 år så påverkar det valen som görs idag. Skall systemet säljas i andra länder i framtiden så påverkar det valen som görs idag. Hur smidigt det är att få igång nya utvecklare att skapa nya funktioner i framtiden påverkas av valen som görs idag.
Vikten i många av dessa frågor kommer från affärsmålen och användaren. En arkitekt behöver därför förstå affärsprocessen och varför kunderna vill ge sina pengar i utbyte mot systemet. De är en form av tekniskt ledarskap.
En mjukvaruarkitekt arbetar med att strukturera och designa mjukvaror så att de uppfyller både funktionella krav och de olika arkitekturella kvalitetsegenskaperna som ställs på systemen. Mjukvaruarkitekten deltar ofta aktivt i programutvecklingen. Mjukvaruarkitekten arbetar vanligen på en mer detaljerad nivå än lösnings- arkitekten, varvid rollen kan ses som en specialisering av lösningsarkitektens.
Då ”arkitekt” tenderar att bli en något diffus titel gillar jag starkt definitionen ovan Iasa Sweden skapat för den specifika roll jag tänker på. Notera också att de anser att mjukvaruarkitekten är en form av lösningsarkitekt och alltså kan verksamheten. Kompletta listan för typer av arkitekter enligt Iasa Sweden är:
Enterprisearkitekt
Sammanhållande och övergripande roll för arkitekturarbetet inom organisationen med fokus på helhetssyn
Verksamhetsarkitekt
I organisationens huvudsakliga verksamhet nära utveckling av produkter, processer och informationshantering
Lösningsarkitekt
Mellan verksamheten och det teknikstöd som stöttar verksamheten
Mjukvaruarkitekt
Nära det teknikstöd som används av verksamheten
Infrastrukturarkitekt
Säkerställer att organisationen har rätt infrastruktur för verksamhetens behov av applikationsstöd, nätverks- kommunikation, datalagring och säkerhet
Gamers brukar prata om ”End game”. Den sista delen av dataspelet när inte så mycket nytt finns att upptäcka utan spelet blir mer av en loop av återkommande saker som skall utföras. Hur ser ditt systems ”End game” ut? Sett till systemets hela livslängd, vart kommer den största delen av tiden spenderas? Vad kan göras så den största delen blir så kul som möjligt?
När ett system föds vid klicket på ”File”->”New project” så finns ingen arkitektur, bara en tom textfil utan kod. Här är allt möjligt men valen är också förlamande. Arkitekturen sätter upp ramarna vi håller oss inom så antal val görs mindre men arbetet görs effektivare på sikt.
Även i system som byggts utan någon uttryckt arkitektur tror jag ändå att det alltid finns en där. Någon kultur kring vad som ligger vart eller hur olika behov implementeras. Tänk till inför varje ändring och lämna koden i lite bättre skick varje gång kommer ge avkastning.
Mera läsning
Introduktion till ett mycket intressant nytt ramverk till Spring som kan säkerställa att systemets moduler beror på varandra på rätt sätt. Kan bland annat skapa diagram över arkitekturen i PlantUML format automatiskt ❤️
