Architectuur houdt zich bezig met strategie van de software op hoog abstract niveau in termen die voor stakeholders te begrijpen zijn. Hier overlapt het ook met DDD. Je zou kunnen zeggen dat architectuur zich bezighoudt met non-functional requirements en dat design zich spitst op het modeleren van functional requirements. Hoewel de scheidingslijn niet statisch gedefinieerd kan worden omdat dit afhangt van de architect en in hoeverre het domein al gevangen wordt op abstract niveau.

Ik denk dat elk complex systeem een visie nodig heeft. Een visie die beschreven is in termen die zowel de bouwers als de gebruikers kunnen begrijpen (ik deel ze nu even in in twee kampen, maar over het algemeen heb je natuurlijk een diverse groep stakeholders).

Naar mijn idee is het de taak van een architect om zo’n visie te vormen en te onderhouden, samen met alle stakeholders (ook de bouwers dus). Je hebt het dan dus over requirements (vanuit de gebruikszijde) en mogelijkheden (vanuit de bouwkant). Daarom is het ook, naast het beschrijven van die visie ook een spel van onderhandelen: welke requirements zijn belangrijker, als niet alles ondersteund kan worden? Wat is er tóch mogelijk, als iets heel erg wenselijk, maar niet zo makkelijk is?

Ik heb het dan over de rol van Architect en het proces van Architectuur. Dat hoeft niet noodzakelijkerwijs 1 persoon te zijn. Het is denk ik wel heel lastig om met een groep mensen een coherente visie te vormen, dan moet je elkaar goed kennen en goed kunnen communiceren. Maar niet onmogelijk. In Agile teams is het over het algemeen een Product Owner / domeinexpert(s) + een ontwikkelteam. Maar ook daar zullen onherroepelijk één of een beperkt aantal mensen de visie volledig overzien.

In ieder geval begrijp je dan denk ik wel dat je als architect niet teveel in technische details kunt spreken, aangezien het dan buiten de gezamenlijke ‘begrippen’ binnen de groep stakeholders valt. Wat wel kan, is praten over de gevolgen van een bepaalde technische keuze (in termen van snelheid, kosten, etc). Dan moet je dus een vertaalslag kunnen maken tussen die detailkeuzes en de gevolgen van die keuzes. Iets dat heel moeilijk is voor één persoon om allemaal te kennen. En je moet er rekening mee houden dat aan de kant van de gebruiker(s) zo’n zelfde ingewikkelde afweging nodig kan zijn. Kortom, hoewel er een neiging is om de architectuur bij één of een beperkt aantal personen te beleggen om een coherente visie te houden, is het iets dat die persoon vrijwel nooit in zijn/haar eentje kan doen, behalve misschien bij relatief simpele (crud) systemen.

Design of misschien nog beter gezegd, engineering, houdt zich bezig met die afweging tussen technische keuzes en hun gevolgen. Vooral aan de bouwkant wordt dat zo genoemd. Als je al het onderscheid maakt, moeten architecten en engineers dus intensief samenwerken.

Overigens zie je met bovenstaande beschrijving ook een enorme overlap met Domain Driven Design. In feite is Domain Driven Design vrijwel hetzelfde verhaal, maar dan puur toegespitst op de functionaliteit, die alleen beschreven kan worden met voldoende (formeel vastgelegde) domeinkennis. Vandaar het gebruik van één domeinmodel, die ook in software vastgelegd wordt, om de communicatie tussen stakeholders begrijpelijk te houden.

Het is denk ik lastig om hier een voorbeeld van te geven zonder dat het wat gekunsteld overkomt. Voor zover ik weet is het onderscheid namelijk wat gekunsteld.

Maar om een analogie erbij te pakken: denk aan het verschil tussen een declaratieve en een imperatieve stijl van het beschrijven van een interface / oplossing.

Men probeert zoveel mogelijk een interface alleen declaratief te beschrijven, maar zonder dat je weet wat de declaratieve termen beteken, heeft die declaratieve beschrijving ook geen nut. Het voordeel is als het goed is wel dat je de declaratieve elementen ‘kent’ als concepten en niet met een specifieke implementatie / technologie erachter.

Ik kan me voorstellen dat dit het niet duidelijker maakt, het ligt er een beetje aan of of je de gebruikte termen goed kent, kun je misschien aangeven of je hiermee geholpen bent? (dan kan ik eventueel enkele termen verduidelijken).

Groet,
Rick

Zijn letterlijke woorden herinner ik me niet meer, maar het kwam neer op het idee dat Architectuur een proces is dat over de ‘vorm’ van een applicatie / software gaat. Engineering is een proces dat gaat over de structuur van een applicatie. Het viel me op dat het aardig aansloot bij wat je hierboven beschrijft.

Het lastige eraan vind ik dat je vorm niet volledig los kunt zien van structuur, denk ik. Dat lijkt een beetje op praten in een taal met spelling en grammatica, maar zonder betekenis. Waar heb je het dan over?

Tegelijkertijd zie ik maar beperkte waarde in het scheiden van architectuur en ontwerp. Meestal wordt architectuur pas zichtbaar in een concreet ontwerp, en dan ook nog pas als het ontwerp gerealiseerd is. Natuurlijk zijn er situaties dat het gewenst of nodig is de architectuur in de vorm van principes, uitgangspunten et cetera expliciet vast te leggen. Maar die beschrijving is dan, als het goed is, zo lang houdbaar dat er voor een full time pure architect niet genoeg werk is om zijn dag te vullen.

Daarom vind ik het logisch dat architecten zich in de praktijk voornamelijk met ontwerp bezighouden. En dat dat vervolgens weer vaak architectuur genoemd wordt ook, want dat klinkt nu eenmaal duurder!