Architectuur en Design

 
02 juli 2010

De titel van deze post bevat twee termen die vaak vermengd worden. Architectuur en ‘hoog abstract ontwerp’ worden in de software engineering vaak als één en dezelfde discipline gezien.

Dat is verwarrend en dus niet handig. Een mooie zin die in één klap duidelijkheid verschaft las ik in het NAF boek Architecture: Building Strategy into Design van Jan Dietz, namelijk:

Architecture is not what you see but what shaped what you see.

Dat vind ik een handig ijkpunt. Het geeft je een handvat om bij alle activiteiten na te gaan of je nu met architectuur of met design bezig bent. Het blijkt in de praktijk dan ook dat architectuur zich meer richt op het samenstellen van een reeks principes, uitgangspunten en eventueel verzamelingen aan technologieën en/of patterns, waar je design meer creatief/constructief van aard is. Zo is UML in mijn optiek dan ook meer te plaatsen bij designactiviteiten.


Werken met ?
Kijk dan bij onze mogelijkheden voor starters en/of ervaren IT'ers.


Categorieën: Architectuur, Development


Reacties (9)

  • Matthijs schreef:

    Na wat meer leeswerk post ik mijn visie op architectuur en design.

    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.

    Geplaatst op 05 augustus 2010 om 9:09 Permalink

    • Leest een beetje als een samenvatting van wat hierboven staat, behalve dat je de functionals uit de architectuur trekt. Ik denk dat dat niet kan. non-functionals zonder funcionsls waar die betrekking op hebben zijn betekenisloos. Die twee zijn dus niet zo los te trekken, denk ik.

      Geplaatst op 05 augustus 2010 om 21:13 Permalink

      • Matthijs schreef:

        Rick je hebt gelijk, het staat hierboven een beetje beperkt beschreven.
        Wat ik bedoelde is dat architectuur een combinatie is van zowel non-functional als functional requirements maar dat niet statisch gedefinieerd kan worden waar het design behoort te beginnen aangezien dat afhangt van het feit of je een deel functionele requirements in de architectuur hebt opgenomen en zo ja welk deel.

        Geplaatst op 06 augustus 2010 om 7:08 Permalink

  • @Matthijs

    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

    Geplaatst op 04 augustus 2010 om 21:39 Permalink

    • Matthijs Mast schreef:

      Als ik het goed begrijp wordt bedoeld dat je kunt ontwerpen in termen als io module /databases en objecten die een leek ook bekend voorkomen (domeinmodel) klopt dat?
      Is het verschil tussen architectuur en design het verschil tussen het hebben over technische architectuur als databases /services en gerelateerde programmaobjecten?

      Geplaatst op 05 augustus 2010 om 7:15 Permalink

      • Laat ik even vooropstellen dat er heel veel verschillende visie zijn op wat architectuur is, dus dat ik je niet zomaar kan vertellen hoe het is. Ik kan je vertellen wat ik vind en waarom, hopelijk heb je daar ook wat aan. :)

        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.

        Geplaatst op 05 augustus 2010 om 8:49 Permalink

  • Matthijs Mast schreef:

    Dit klinkt interessant.
    Zou iemand hier nog een voorbeeld van kunnen geven omdat ik het verschil en de overeenkomst nog niet helemaal zie.

    Geplaatst op 03 augustus 2010 om 12:10 Permalink

  • Ik was laatst bij een meeting van Agile Holland over lean architecture en daar vertelde Viktor Grgic over zijn visie op architectuur.

    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?

    Geplaatst op 22 juli 2010 om 22:02 Permalink

  • Eric Jan Malotaux schreef:

    Helemaal mee eens!

    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!

    Geplaatst op 06 juli 2010 om 7:10 Permalink