Architectuur/oud/leerboek in wordingL. Focus

Uit Werkplaats
Ga naar: navigatie, zoeken
Falling Water.jpg

Architectuur
in de IT-wereld
Hanno Wupper
David Jansen


 © comments



cursussen / courses

literatuur

In Beweren en bewijzen wordt uitgelegd dat bij het bespreken, analyseren, verifiëren en ontwerpen van systemen een duidelijke bepaling van de →focus voorkomt dat het probleem schuift en de betrokkenen langs elkaar heen praten. Men moet bepalen, waartoe men ergens over praat (het doel), waarover (een fragment van de realiteit) en onder welk gezichtspunt en zich daar vervolgens aan houden. Beweren en bewijzen gaat over correctheidsvraagstukken. Daar doet men er goed aan, zich tot een verstandig gekozen gezichtspunt te beperken waarvoor men correctheid wil bewijzen, en van de rest te abstraheren. Wat men dan bewijst is een correctheidsstelling waarin ook staat waaraan zich de omgeving van het systeem dient te houden.

Architectuurvraagstukken zijn complexer. Hier gaat het om afstemming van belangen, afweging van botsende principes en om kwaliteitsaspecten die zich niet in formules laten vatten. Bewijzen kun je hier weinig, en vaak zijn formele specificaties ver te zoeken. Het is wel altijd zo dat samen met een bouwwerk ook een stel van regels ontworpen wordt, waaraan de gebruikers en beheerders van het bouwwerk zich dienen te houden. Bouwwerk en regels samen zorgen ervoor dat aan de gewenste principes voldaan wordt. Ook bij architectuurvraagstukken is een vaste focus belangrijk, zij het dat men zich hier doorgaans niet kan beperken tot een gezichtspunt. (Verdieping in: 3. Bouwen voor principes)

focus
  • doel
  • fragment van de realiteit
  • (gezichtspunt)
Het fragment van de realiteit is in een architectuurvraagstuk doorgaans een specifiek bouwwerk samen met de daarbij horende regels, niet een klasse van bouwwerken.

Regelverwarring

Hier kan verwarring ontstaan. In de literatuur over architectuur en ook in allerlei architectonische analysen wemelt het namelijk van regels en richtlijnen, zonder dat altijd goed onderscheiden wordt, bij welk niveau deze horen:

  • Een architect houdt zich tijdens het ontwerpsproces aan bepaalde regels, vastgesteld door zijn werkgever of ingegeven door zijn visie op architectuur.
  • Elk bouwwerk in Nederland moet voldoen aan bepaalde regels, vastgesteld door de overheid. Bouw- en woningstoezicht en de brandweer zorgen voor handhaving.
  • Elk bouwwerk van een bepaalde klasse (bijv. een gevangenis) is nog eens onderworpen aan specifieke regels. Allerlei inspectiediensten zorgen voor handhaving.
  • Bij een specifiek bouwwerk moeten zich, nadat het er is, beheerders en gebruikers houden aan bepaalde regels die afhangen van dit bouwwerk. Alleen deze regels zijn onderdeel van het ontwerp van het bouwwerk, dus output van het ontwerpsproces, de overige zijn requirements, dus imput voor het ontwerpsproces.

Je kunt hier veel verwarring stichten door al deze soorten regels door elkaar te halen. Om te slagen voor deze cursussen moet je aantonen dat je ze kunt onderscheiden. Een heldere focus helpt daarbij.

Mogelijke foci in teksten over architectuur

focus het werk van de architect
Elke architect heeft zijn principes (die bijvoorbeeld bepalen of hij gaskamers gaat ontwerpen of niet, hoe zwaar de menselijke maat weegt, of al zijn bouwwerken op elkaar moeten lijken of op een bepaalde manier als van hem herkenbaar zijn). Daaruit en mogelijk uit de principes van zijn werkgever volgen regels voor zijn werkwijze. Dit staat los van specifieke bouwwerken. - Veel literatuur over architectuur in de digitale wereld heeft deze focus. In deze cursus daarentegen concentreren we ons allereerst op de bouwheer en secifieke bouwwerken.
focus een specifiek bouwwerk
  • Regels waaraan het bouwwerk moet voldoen. Voor de architect zijn ze gegeven. De verschillende belanghebbenden beperken de ontwerpruimte (moet van steen zijn, met een gevel conform de huisstijl, niet hoger dan 12,5m, voldoen aan veiligheidseisen). Als je deze regels bespreekt, geef dan aan van welke van de vier soorten belanghebbenden deze afkomstig zijn.
  • Regels die de architect ontworpen heeft. Zo als in Architectuur/1. Theorie/3. Bouwen voor principes uitgelegd horen bij elk specifiek bouwwerk specifieke regels waaraan zich beheerders en gebruikers moeten houden. Dit is in de IT chronisch onderbelicht en heeft daarom in dee cursus onze bijzondere aandacht.
focus inrichting van het land
De overheid zorgt ervoor dat bepaalde principes landelijk overeind blijven, bijvoorbeeld veiligheid en schoonheid. Daaruit zijn regels afgeleid die voor alle bouwwerken gelden.

Architectonische analyse

In de cursus Fysieke en digitale architectuur maak je een kwaliteitsanalyse voor een fysiek en een digitaal bouwwerk met bijbehorende regels. Het fragment van de realiteit is dan een specifiek bouwwerk en zijn gebruik onder een of meer zelfgekozen gezichtspunten.

  • Leg je vast op een focus en laat die vervolgens niet schuiven: een schoolgebouw samen met de regels waaraan beheerders en gebruikers (leraren en scholieren) zich moeten houden is een ander verhaal dan het ontwerpen van een schoolgebouw binnen de Nederlandse omgeving samen met de regels waaraan architect en aannemer zich moeten houden.
  • Achterhaal de regels en richtlijnen die de architect samen met het bewuste bouwwerk heeft ontworpen om de nodige principes waarmaken. Die kun je onderverdelen in:
    • regels voor de gebruikers van het bouwwerk (sluit de ramen als je je kamer verlaat, heb altijd een sleutel op zak, heb nooit een sleutel op zak, ...),
    • regels voor onderhoud en aanpassing van het bouwwerk.

Probleemdefinitie

Een archetectonische analyse kun je beste beginnen door niet alleen de focus in kaart te brengen maar ook, wat gegeven is en in welke vorm, wat gezocht is en waar de nodige domeinkennis te vinden is.

Een problem statement form kan daarbij helpen:

Problem statement
Problem (a short name for identification)
Question Answer Explanation
→FOCUS
Goal
  • o quality assessment of an existing artefact
  • o design
  • o reconstruction of principles
  • o recostruction of rules
  • o ...
Fragment of reality
→RATIONALITY SQUARE
→properties
How are the desired →properties (not its design or structure) of the artefact under discussion defined?
  • o by explicitely stated principles and requirements?
  • o implicitely by an existing →artefact?
  • o implicitly by the needs of a surrounding artefact
  • o by a given →blueprint
  • o by a more or less vague idea of a customer
    • o together with an incomplete →artefact
    • o together with a partial blueprint
    • o together with explicitly stated principles
    • o together with users' wishes
  • ...
Can the customer be consulted? Who?
What is the problem domain?
Can a Domain expert for the problem domain be consulted? Who?
→principles and →requirements
Are the →principles of the (organisation of the) →customer known?
  • o Yes, they are stated explicitly in...
  • o No, but the customer is willing to help to make them explicit.
  • o No, and the customer cannot help to make them explicit.
Are the →reqirements (on a lower level than principles)?
  • o Yes, they are stated explicitly in...
    • o They are negotiable.
    • o They are not negotiable.
  • o No, but the customer is willing to help to make them explicit.
  • o No, and the customer cannot help to make them explicit.
If principles and requirements are not fixed: how can it be Validated?
→blueprint
Which blueprint language is (to be) used? Why?
How complete is the blueprint?
  • o non-existent
  • o decomposition in parts
  • o some parts, but not all are well-specified
    • o rules for users are specified
    • o rules for administrators ad maintenance are specified
  • o complete, including the necessary rules
Do the providers of parts or their Domain experts understand the respective →specification languages from the →blueprint?
How should it be established that the blueprint satisfies the principles and requerements?
How should it be established that the artefact is a correct realisation of the blueprint?
→artefact
How much of the artefact exists? Where?
  • o The entire artefact exists.
  • o Most of the artefact exists, but something has to be added.
    • o hardware
    • o software
    • o people following the rules
  • o All of its parts exist but are not yet assembled.
  • o Nothing exists.
If it does not (fully) exist, how and by whom will it be realised?
What are the solution domains for the missing parts?
Who are the Domain experts for the missing parts and their interfaces?
How can the artefact be Validated w.r.t. a specification?
PLAN
Step To do Comment
1
2