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?