På senare år har jag kommit i kontakt med arkitektur. Det är märkligt att man i livet ibland snubblar över ämnen man aldrig kunnat förutse att man skulle bli fascinerad av. Då menar jag inte byggnader och stadsplanering, utan det mer abstrakta och vetenskapliga begreppet arkitektur – sådant som uppstår när man försöker bygga komplexa tekniska system, som jag vågar påstå faktiskt inte riktigt är det man först tror att det är utan att närmare studera det.
Då jag i mitt arbete jobbar med system av elektronik och mjukvara är det naturligt att man stöter på begreppet systemarkitektur. Den här texten kommer inte att handla om vare sig system – som inte heller är helt trivialt att definiera – eller att djupdyka i vad arkitektur egentligen är.
Jag vill i stället titta på en text som skrevs redan 2001 av den amerikanske mjukvaruutvecklaren Joel Spolsky, om ett begrepp han kallar för ”Architecture astronauts”, i blogginlägget Don’t Let Architecture Astronauts Scare You.
Joel har en poäng: om man drar något för långt passerar det gränsen till att det blir oanvändbart. Man kan göra samma resonemang om abstrakt konst som blir konst för sakens skull, matlagning där matlagningen i sig är viktigare än hur maten upplevs, ja egentligen vad som helst. Allt som görs går att skruva in absurdum, vilket naturligtvis inte är fel för den som vill göra det för att man roas av det. Andra får väl gilla det eller inte bry sig om det.
Joels resonemang är att vissa ”arkitekter” (jag skriver detta med citationstecken av en anledning som vi snart ska se) blir ”arkitekturastronauter” och svävar ut i rymden utan syre och skapar arkitekturer (mjukvara i detta fall) som inte blir till nytta för något. Detta är säkert sant. Jag har nog själv hamnat där i något programmeringsinitiativ där jag velat tänka igenom planen för ett hemmaprojekt ett steg för mycket.
Man gör en pluginarkitektur för… en (1) plugin. Man gör en lagerarkitektur där funktionsanropen blir en rad ner i nästa lager som blir en rad ner i nästa lager. Klassisk over engineering med andra ord. Och om man är ingenjör ska man inte bara lösa problemet – man ska också faktiskt använda lösningen till något. Oftast har man dessutom ont om både tid och pengar, så over engineering är inget man vill ha.
Inom mjukvaruvärlden är arkitekturastronautens motsats kodaren som skriver utan plan och skapar något som i bästa fall går att kompilera, köra och kanske använda, men som sedan aldrig mer går att ändra eller bygga ut. Det går inte heller att felsöka och förstå – och en bug som rättas skapar tre nya oönskade beteenden eller buggar.
Det brukar gå under namnet spaghettikod eller ett anti-pattern kallat ”big ball of mud”.
(Det finns ett annat roligt begrepp som är motsvarigheten till detta, fast för själva utvecklingsmetodiken: när man utan riktig plan ändrar något, kompilerar om, kör, testar igen och ser att man måste ändra igen. Och så vidare. Det kallade en av mina äldsta programmeringskompisar för norsk programmering. Ja, jag är själv halvt norrman).
Det finns alltså ett optimalt mellanting. Och hur når man det?
Om man nu ska vara arkitekt så arbetar man med arkitektur. Och vad är arkitektur?
Ett sätt att ta reda på det är att läsa ISO-standarderna som definierar vad det är och hur man arbetar med det. Jag tycker att ISO-standarder är rätt bra saker, då man i globala kommittéer samlas och försöker skriva ner vad man anser att saker är i någon form av konsensus. Det kanske inte är perfekt, men det finns goda chanser att de ligger nära sanningen och i alla fall representerar det bästa vi har.
Den standard som berör hur man arbetar med detta heter Software, systems and enterprise — Architecture processes (ISO/IEC/IEEE 42020:2019). Där finns processen beskriven. Jag ska inte gå igenom hela, för vi behöver inte komma så långt för att få svaret på frågan.
I korthet, och något förenklad, går den ut på följande.
- Ta reda på vad det är för system du vill utveckla, vad det ska göra (funktioner) och i vilken miljö det verkar.
- Ta reda på hur bra det ska vara på att göra dessa saker och hur bra det ska vara på andra saker, till exempel hur tungt det maximalt får vara eller hur dyrt det blir att köpa delarna till det. Detta brukar vi kalla för attribut. Andra ord är egenskaper eller kvaliteter.
- Skriv krav på funktionerna – funktionella krav.
- Skriv attributkrav på systemet. (Ibland kallas dessa också för icke-funktionella krav, men jag tycker att det låter lite negativt.)
När man börjar tänka till kan attributkraven bli ganska många. Och man upptäcker en värre sak: alla attributkrav står i konflikt med ett eller flera andra attributkrav. Om man säger att något ska ha hög prestanda så drar det för mycket ström och batteritiden blir för kort. Om man ska göra det väldigt tillförlitligt så blir utvecklingstiden och därmed kostnaden för hög. Men alla ingenjörer gillar ju tillförlitlighet, och ja… just det – tid och pengar hade vi ju ont om.
Så därför måste vi ta nästa steg. - Balansera attributen mot varandra.
Beroende på vilket system man utvecklar ligger man olika långt ut på attributskalorna. En personbil får inte vara hur dyr som helst, för då går den inte att sälja, men man kan kompromissa lite med komponenttillförlitlighet eftersom man ju kan tillåta en viss garantikostnad under bilens 15-åriga livstid. En satellit måste däremot vara mycket tillförlitlig och hålla sina 15 år utan att repareras – för det finns inga serviceverkstäder i rymden. (Femton år råkar alltså vara en gemensam nämnare för dessa två system.)
Man måste alltså hitta ett optimum av kompromisser mellan alla attribut och sedan kravställa systemarkitekturen utifrån denna delikata balans. Notera: inte kravställa systemet, utan systemets arkitektur.
Därefter ska man, om man följer konstens alla regler, ta fram flera olika förslag på arkitekturer som uppfyller kraven – kanske mer eller mindre bra – och sedan välja den som passar de balanserade attributkraven bäst.
Detta har jag dock under min snart 30-åriga tid i kontakt med utveckling av inbyggda system aldrig sett göras i praktiken. Kanske faktiskt för att det sker väldigt snabbt – t.o.m. i huvudet. Arkitekterna vet att vissa typer av arkitekturer inte kommer att uppfylla kraven. Så kanske sker det ändå, fast lite undanskymt.
Och här närmar vi oss det viktiga.
Notera att jag inte skrev arkitekterna med citationstecken denna gång. För jag menar att de ”arkitekter” som inte har koll på attributbalanseringen inte är arkitekter. Om man börjar sväva ut i rymden är det något attribut som har hamnat ur balans mot ett annat attribut. Antagligen för att man inte heller har någon genomtänkt kravställning.
Poängen är alltså att Joel säkert har rätt i att det finns astronauter. Men jag tycker att de per definition (enligt ISO-standardens definition) inte håller på med arkitekturarbete.
I övrigt är jag även lite osäker på om Joel har begreppen helt rätt. Jag tycker att han i slutet av texten snarare pratar om de senaste trenderna (nåväl, bara 25 år sedan) inom produkt- och teknologiutveckling – kanske rent av om konkurrensyttringar – och inte om arkitekturer som har blivit överambitiösa.
Denna text är skriven av mig. Jag använder AI (ChatGPT) som hjälp för att kontrollera stavning och grammatik samt vissa fakta, men allt innehåll och den slutliga redigeringen står jag själv för.