Share via

När är en arkitektur rätt/fel?

  • Article

Jag hade idag ett ganska långt telefonsamtal med en arkitekt på en av Sveriges större produktbolag. De har idag en produkt som är baserad på både gamla versioner av VB och även en del .NET. För stunden står de i ett läge där de ska skriva om en hel del kod och han ville därför diskutera lite kring arkitektur och rätt eller fel.

Jag tänker inte gå in på detaljer i konversationen utan tänkte redogöra för min grundsyn när det gäller arkitektur och systemdesign.

Jag är väldigt långt från religös eller puristisk i min syn utan mer pragmatisk om vi ska använda en massa krångliga ord för att beskriva grundsynen. Det finns ett problem som man vill lösa och då finns det olika variabler som påverkar de val man gör för att uppnå detta.

Den enda gången som en arkitektur eller systemdesign är fel är när den inte uppfyller de funktionella kraven anser jag, och det är ju rätt självklart. Bygger man ett system som ska klara 1 000 000 användare och inte gör det så är något fel, i alla andra fall så är det rätt gjort.

Och rätt gjort är det oavsett om det är baserat på ett ramverk från oss på Microsoft eller ett snabbhack. Däremot visar det sig ofta att alla de ramverk, riktlinjer och referensapplikationer som finns faktiskt innehåller en massa bra information (visst är det otroligt... :-)), men jag anser inte att man måste följa eller använda dem slaviskt. Det gäller istället att plocka ut godbitarna och kombinera dem för att lösa ett problem.

För mig är ordet "enkelhet" absolut viktigast när det gäller arkitektur och systemdesign och det gäller saker som:

  • enkelhet att förstå arkitekturen
  • enkelhet att implementera arkitekturen
  • enkelhet att förvalta systemet/applikationen

Detta innebär att alla "bra-att-ha"-lösningar bör tas bort, "ju renare desstu bättre" och man ska absolut inte anamma "buzz-words" bara för att. Ler lite lätt åt den absolut bästa IBM-reklamen "-We've got to be on the Internet! -Why? -It doesn't say...".

Sitter man med en fet klient idag som ska skrivas om och inte ser framför sig att den ska distribueras ut i ett kluster eller tjänsteorienteras, varför ens fundera på SOA?

Tror man att en applikation kommer att ha 1000 användare, varför designa den för 1 000 000? Får man det högre antalet användare så finns garanterat pengar att bygga en sådan lösning vid en senare tidpunkt...

Vet man att processen eller de funktioner som ska vara med inte är slutgiltiga, lös problemet och bygg om när det behövs.

Ska vi använda DataSet eller egna klasser i vår applikation? Ta det som utvecklarna tycker är bekvämast, prestandamässigt så spelar det ingen roll i 99% av fallen. Fundera dock över interoperabiliteten...

Vad jag försöker säga är att du kan aldrig ta höjd för allt som kommer i framtiden, oavsett teknik eller hur verksamheten förändras så varför ens försöka. Spara pengarna för stunden och använd dem när de behövs, eller rättare sagt när du vet hur de ska användas.

För att återgå till produktbolaget och telefonsamtalet, skulle de i den kod som fortfarande används från 80-talet i dagens applikation ha tagit höjd för webben, SOA och .NET hade de haft problem...

Efter denna postning så lär pursiterna hoppa på mig, rätt eller fel?

Comments

  • Anonymous
    March 01, 2007
    Hade det inte varit för att du verkligen tryckte på enkelheten så hade jag kommit att tänka på den här artikeln: http://worsethanfailure.com/Articles/What_Could_Possibly_Be_Worse_Than_Failure_0x3f_.aspx Trevlig helg! :-)

  • Anonymous
    March 01, 2007
    Ahhh... den där bloggen har jag helt missat, och än mer postningen... Och visst har jag precis som författaren till artikeln du nämner ovan gått på en hel del minor under åren, kanske är det därför man har blivit mer pragmatisk? Minorna har hur som helst påverkat mig att älska enkelhet och användning av ramverk. På det viset så kan jag misslyckas på färre ställen... :-) Trevlig helg själv!

  • Anonymous
    March 02, 2007
    Väldigt bra inlägg. Pragmatisk ansats och framförallt enkelhet tycker jag diskuteras alldeles för lite. Tänk KISS (Keep it simple stupid).

  • Anonymous
    March 02, 2007
    Är det inte att göra det lite lätt för sig att säga att en arkitektur bara är fel "när den inte uppfyller de funktionella kraven"? Är de ickefunktionella kraven oviktiga? Är en arkitektur inte "fel" om den gör det omöjligt eller väldigt svårt att vidareutveckla lösningen? Att underhålla den? Om den är så kostsam att det är omöjligt att ens implementera den? O.s.v. Du är ju själv inne på samma spår när du i nästa andetag lyfter fram vikten av enkelhet. Problemet är att det inte är helt lätt att ge generella svar på vad som är en bra arkitektur utan att leverera floskler och klyschor. Det handlar ju som alltid om (och nu levererar jag själv en klyscha!) det specifika problemet. Faktum är att det är svårt nog att ens leverera ett vettigt svar på vad arkitektur är - vad menar du till exempel själv med begreppet i din text ovan?

  • Anonymous
    March 04, 2007
    Både ja och nej tycker jag. En arktitektur eller systemdesign är ju trots allt i de flesta fall en ögonblicksbild av de förutsättningar som finns vid själva designförfarandet. Efter denna tidpunkt så kommer yttre omständigheter i väldigt många fall påverka och förändra den ursprungliga designen. Men, precis som du skriver, har man en förutsättning som säger att designen ska vara enkel att förvalta och vidareutveckla så kommer den att bli "fel" vid en senare tidpunkt om man gör det omöjligt att genomföra detta. Nu blir ju denna fråga ganska "flummig", när man för in tidsaspekter kring rätt och fel. Det intressanta är dock att när man diskuterar arkitektur eller design så kan man aldrig hitta en optimal lösning om problembilden inte är väl avgränsad och aldrig förändras över tiden, vilket är en utopi enligt mig. Hur som helst, det jag initialt ville säga var att så länge man gör allt så enkelt som möjligt (KISS som Johan L kommenterat ovan) oavsett om det är frågor kring databärare, SOA eller förvaltningsfas så kommer man i mitt tycke alltid ligga närmare "den rätta arkitekturen" med tiden. Vad jag menar med arktitektur... Jag är väl lika skadad som alla andra som använder arkitektur/design om vartannat, sannolikt borde jag använda systemdesign för applikationer och arkitektur när andra applikationer/system ska inbegripas i en lösning, eller?  

  • Anonymous
    March 07, 2007
    Jag ville absolut inte vara någon besserwisser utan är uppriktigt förbryllad över otydligheten i arkitekturbegreppets användning i olika sammanhang. Jag har absolut ingen "korrekt" definition som jag kan hävda gentemot andras eller slå i huvudet på de som far fram oförsiktigt med begreppet. Det finns flera bra definitioner och till och med mer eller mindre officiella sådana, men även om man skulle kunna ta fram en minsta gemensamma nämnare från dessa skulle man inte kunna vara säker på att man pratade om samma sak som andra när "arkitektur" kommer på tal. Det är därför allmänt hållna diskussioner lätt blir intetsägande. Skulle det t.ex. gå att hitta någon som inte ställer upp på din beskrivning av en god arkitektur, d.v.s. finns det någon som skulle hävda att en arkitektur INTE ska vara enkel att förstå, INTE enkel att implementera och INTE enkel att förvalta? Sannolikt inte. (Jag tror alltså inte att dina farhågor/förhoppningar om att reta upp purister kommer att besannas... ;-)) Därmed inte sagt att din bloggpost är ointressant, tvärtom tycker jag det är mycket gott initiativ att diskutera den här typen av frågor. Men det är svårt. Tyvärr är jag en lika god kålsupare själv; jag har till exempel själv använt etiketten "Arkitektur" om allt möjligt på min blogg och till och med uppgivet bytt namn på den till "Arkitektur/Design" helt nyligen. Titeln, eller ännu hellre självtituleringen, "arkitekt" är det om möjligt ännu värre bevänt med, men det är en delvis annan historia. Kanske är det så att arkitekturbegreppet kommer att fortsätta vara svårfångat och att vi får nöja oss med ett elastiskt buzz word (eller anti-buzz word beroende på rådande trend och kontext) som kan appliceras lite hur som helst? Om man sänker kraven på precision skulle jag i så fall vilja framhålla Ralph Johnsons ganska träffande (men ack så vaga) definition: "Architecture is the decisions that you wish you could get right early in a project. [...] Architecture is about the important stuff. Whatever that is." Citatet kommer från Martin Fowlers "Who needs an architect" som är intressant läsning i sammanhanget. (http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf)

  • Anonymous
    March 13, 2007
    Väl talat! :-) Grundanledningen till första postningen var som sagt att välja enkelhet först ut. Alldeles för många vill (inkluderat mig själv många gånger) använda det senaste i form av tekniker, produkter, mönster, dvs allt som finns i verktygslådan. Problemet många gånger är dock att lösningen på ett problem blir komplexare än den borde vara. Allt för att man försöker ta hänsyn till eventuella omständigheter man inte har en aning om (egentligen). Här om veckan skulle jag enkelt lyfta ut information ur en sträng. Regex tänkte jag var bra för detta, efter tre timmar gav jag upp, använde "indexOf" och "substring" och på mindre än två minuter hade jag utfört det jag skulle. OK, detta är inte arkitektur, men parallellen är snarlik. Jag ville gå den lite "tuffare vägen", insåg dock mina begränsningar och gick den "enkla vägen". Lyfter vi detta några nivåer så är det inte konstigt att många projekt havererar eller aldrig når sitt mål, dvs lösa ett problem...