Architectuurdetails

Architectuur heb ik weleens omschreven als ‘alle details die globaal belangrijk zijn’. Volgens mij moet een architect vooral die ‘globale details’ bewaken en zorgen dat ze samen het gewenste product vormen, uiteraard op tijd en binnen budget. Hij hoeft dus geen tijd te besteden aan alle zaken die vanzelf goed gaan – lees: aan dat wat het ontwikkelteam zelfstandig kan. Vaak is de praktijk anders en zijn architecten druk bezig met het schrijven van dikke documenten, soms vol trivialiteiten die wellicht al bekend zijn of in de praktijk nooit worden gelezen. En is er te weinig tijd voor de details die later wel belangrijk blijken.

Twee van die ‘globale details’ die bijna altijd aandacht verdienen, zijn beschikbaarheid en betrouwbaarheid. Het is immers een misvatting dat software deterministisch is; ook software heeft een faalkans. Een prima werkend programma kan plots falen of vooral druk zijn met iets heel anders. Elke gebruiker weet dat, in tegenstelling tot de meeste ontwikkelaars. Ook omdat die druk zijn met nieuwe features en de projectleider geen oog heeft voor elk detail. Hier ligt een taak voor mijn moderne architect: een werkend systeem is belangrijker dan correcte documentatie, geheel in de lijn van Agile.

Volgens architectuurstandaarden als Dya werkt de architect met drie aspecten: de klantbehoefte, het realisatieproces en de technologie. De klantvraag leidt vaak tot dikke documenten. Tijdens de realisatie wordt vaak vooral getest aan de rechterkant van ‘de V’. Beide zijn nodig, maar zelden efficiënt. En wat als de software meestal werkt, maar niet altijd? Vaak wordt de bug opgelost zonder te meten wat de betrouwbaarheid is – een typisch geval van ‘meten beïnvloedt het resultaat’. Ook het technologieaspect helpt slechts beperkt. Softwareteams zijn niet gewend om te denken in termen als faalkans.