Ingen arkitektur er også (dårlig) arkitektur

I weekendavisen bringer en professor i etik og retsfilosofi det synspunkt til torvs, at den videnskabsmand, der ikke laver videnskabsteori, laver dårlig videnskabsteori. Nu kender jeg noget til videnskab og noget mindre til videnskabsteori. Men analogien til software-arkitektur ligger lige for: Den udvikler, der ikke laver arkitektur laver dårlig arkitektur. For som Martin Folwer skriver, så består arkitektur af summen af de tidlige beslutninger som vi ønsker vi kunne lave om. Og beslutningen om ikke at bruge en arkitektur ... resulterer også i en arkitektur.

Så en hver agil udvikler, der ikke har taget arkitekt-hatten på i begyndelsen af et projekt, laver pr. definition dårlig arkitektur. Og da dårlig arkitektur bør rives ned og erstattes af noget andet, levner det kun to muligheder for den agile udvikler: Den en er at begrænse sig til små projekter, der ikke er meget større end hundehuse eller udhuse og som ikke koster alverden at bygge op fra grunden igen eller lave en større refactoring på ? og der er stor brug for den slags bygninger og småprojekter rundt omkring, så det er bestemt en ærværdig levevej.

Den anden er at indrette sig under en arkitektur, som er holdbar. Med en parafrase over det agile manifest er valgsproget: 'Individuals and interactions supported and set free by processes and tools'.

Jeg har faktisk bidraget til i KMD-regi med at gennemføre et Scrum-projekt, hvor de væsentligste, underliggende arkitekturkomponenter var på plads fra starten og gjorde udviklerne ret produktive. Projektet blev en pæn succes, og det var baseret på .Net, må jeg hellere sige nu, hvor det er et stykke tid siden jeg har sagt noget rigtigt pænt om Microsoft (og tak for vinen, René, den var god)

Kommentarer (4)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#2 Kåre Kjelstrøm

Grady Booch skelner mellem "intentional" og "accidental" architectures hvor den første type eksplicit identificeres inden systemet bygges og den anden opstår i kølvandet på det utal af arkitekturmæssige beslutninger, der ellers må tages i udviklingsprocessen (se http://www.informit.com/articles/article.aspx?p=471929)

En "intentional architecture" opstår som reflektioner over en succesfuld "accidental architecture", hvorpå den kan genbruges. En "accidental architecture" er derfor ikke nødvendigvis af det onde, men kan være resultatet af at et system udforsker nye områder.

Jeg er meget enig i at det er afgørende for levedygtigheden og implementerbarheden af medium og store systemer at arkitekturen så vidt muligt er på plads inden koden skrives. Det er bare ikke altid muligt at klarlægge alt på forhånd og man må eksperimentere. I den situation er det så afgørende for systemets kvalitet, at andre dyder som separation of concerns og dokumentation af arkitekturmæssige beslutninger anvendes.

  • 0
  • 0
#3 Peter Nørregaard Blogger

Accidental architecture kan godt resultere i en god arkitektur men et af to væsentlige forhold skal være på plads: 1) En svineheldig eller erfaren udvikler som bare rammer rigtigt i forhold til projektet (og så er det ikke egentlig accidental men vel egentlig intentional) 2) At arkitekturen kan rulles tilbage / refaktoreres. Fowler funderer over, om den væsentligste egenskab ved "en arkitektur" mon ikke er, at den er irreversibel.

Så det er godt med refleksioner over en succesfuld accidental architecture, men det må væres målet at foretage overvejelserne så tidligt i projektforløbet som muligt. Måske helst som et Proof of Concept, hvis der er tid til det?

PS. Links blev rettet i går.

  • 0
  • 0
#4 Deleted User

Efterhånden har jeg den opfattelse, at enhver arkitektur er holdbar. Du skal bare sikre, at den ikke er komplet, således du kan bygge på. Forskellen mellem gode, og dårlige arkitekturer, er hastigheden hvormed arkitekturen vokser. En dårlig arkitektur vokser hurtigere, end en god. Den superperfekte vokser ikke, og er permanent for altid. Løsningen er fundet.

  • 0
  • 0
Log ind eller Opret konto for at kommentere