De laatste tijd krijg ik relatief veel vragen over het onderscheid tussen architectuurprincipes en eisen. In het boek over architectuurprincipes schrijven we dat zowel architectuurprincipes als eisen gewenste ontwerpeigenschappen beschrijven. Eisen zijn gewenste eigenschappen van een artefact. Architectuurprincipes zijn specifieker van aard. Het zijn declaratieve uitspraken die de ontwerpvrijheid beperken door essentiële eigenschappen te beschrijven die nodig zijn om aan de doelstellingen te voldoen.

Een andere manier om naar principes te kijken is dat zij in tegenstelling tot eisen die het "wat" beschrijven, een oplossingsrichting aangeven en daarmee het "hoe" beschrijven. Een eis is bijvoorbeeld dat systemen ook toegankelijk moeten zijn voor mensen met een functiebeperking. Een bijpassend architectuurprincipe is bijvoorbeeld dat voldaan moet worden aan de webrichtlijnen voor toegankelijkheid. Dit leidt overigens dan wel weer tot specifiekere (systeem)eisen, zoals "bij door het systeem gegenereerde foutmeldingen moet de gebruiker mogelijkheden krijgen om verder te gaan".

Interessant om te zien in het beschreven voorbeeld is dat architectuurprincipes gebaseerd zijn op (high-level) eisen, maar ook leiden tot meer specifieke eisen. In het boek stellen we dat allerlei drivers voor architectuurprincipes zoals doelstellingen, kernwaarden, knelpunten, risico's en beperkingen leiden tot architecturele eisen. Dit in tegenstelling tot bijvoorbeeld de ArchiMate 2.0 (draft) waarin eisen alleen kunnen voortvloeien uit architectuurprincipes.

Een andere constatering is dat architectuurprincipes kunnen worden beschouwd als gegeneraliseerde eisen. Niet alleen zijn ze van meer algemene aard (ze hebben typisch betrekking op meerdere systemen), je kunt ze potentieel ook echt afleiden van specifieke eisen. Zo zou je bestaande programma's van eisen kunnen bestuderen en je afvragen of eisen ook in meer algemene zin gelden. Overigens moet je dan wel goed kijken naar de formulering van het architectuurprincipe. Deze is typisch in stellende vorm ("het is zo dat..."), terwijl systeemeisen typisch geformuleerd worden in de vorm "het systeem zal...".

Een ander interessant perspectief dat ik zie is dat zowel eisen als architectuurprincipes afgeleid zijn van doelstellingen, maar dat de laatste een minder directe route afleggen. De meest directe route is van doelstelling naar functionele eis, naar oplossing (of zelfs direct naar oplossing). Dit is de route die typisch gevolgd wordt vanuit de business. Architectuurprincipes komen "langszij"; zij bieden een alternatieve vertaling van de doelstellingen die beperkingen oplegt aan de oplossing.

Architectuurprincipes bevinden zich in de niet-functionele ruimte. Ze beschrijven niet zozeer een functionaliteit, maar beschrijven randvoorwaarden/kwaliteitseisen waaraan een oplossing moet voldoen los van de specifieke functionaliteiten. Architectuurprincipes zullen dan ook met name leiden tot kwaliteitseisen, alhoewel ze ook kunnen aangegeven dat bepaalde functionaliteiten randvoorwaardelijk. Dit past goed bij mijn eigen gevoel dat we als architecten primair bezig zijn met kwaliteitsverbetering en professionalisering. Ons werk lijkt erg op dat van een kwaliteitsmanager. Deze laatste is echter primair met het proces bezig, terwijl wij ons primair met het product bemoeien.

Een aantal van bovenstaande constateringen kwamen mooi bij elkaar bij in een aantal al wat meer gedateerde stukken over eisen die ik vond van de hand van Karl Wiegers, die ook een boek over het onderwerp heeft geschreven. Wiegers beschrijft een model voor eisen, waarbij hij een onderscheid maakt in de functionele ruimte en de niet-functionele ruimte. Beiden komen bij elkaar in de Software Requirements Specification. In de functionele ruimte schetst hij eisen op drie verschillende niveau's. Business requirements bevinden zich het dichtst bij de doelstellingen en gaan nog niet over IT ondersteuning. User requirements redeneren vanuit de taken van de gebruiker van een systeem en worden typisch beschreven in de vorm van use-cases. Functionele eisen zijn de meest specifieke eisen die beschrijven wat het systeem precies moet doen. Het zijn de business requirements die ten grondslag liggen aan de architectuurprincipes en die daarmee goed passen in het eerder beschreven beeld.

In de niet-functionele ruimte beschrijft Wiegers ondermeer bedrijfsregels, kwaliteitseigenschappen, externe interfaces en beperkingen. Architectuurprincipes kunnen mijns inziens ook in deze niet-functionele ruimte worden gepositioneerd. Het zijn meer algemene uitspraken dan de andere zaken die door Wiegers in deze ruimte worden gepositioneerd. Zo bedoelt Wiegers als hij het heeft over kwaliteitseigenschappen eigenlijk meetbare kwaliteitseisen die de kwaliteitseigenschappen concretiseren. Vanuit dat perspectief leiden kunnen architectuurprincipes leiden tot dergelijke kwaliteitseisen. Daarnaast zullen architectuurprincipes leiden tot beperkingen aan het ontwerp.

Merk overigens op dat zowel kwaliteitseisen, bedrijfsregels beperkingen ook meer algemene tegenhangers hebben die op hun beurt ten grondslag kunnen liggen aan architectuurprincipes. Ik ga er even van uit dat deze op een ander abstractieniveau zitten, en conform ons boek ten grondslag liggen aan de business requirements bovenin het model. Uiteindelijk kan elke gewenste verandering worden gezien als een eis. Zo kan elk knelpunt worden geherformuleerd als doelstelling. Ook het omgekeerde is veelal waar; doelstellingen verhullen veelal knelpunten in de huidige situatie.

In de volgende figuur heb ik de originele plaat van Wiegers aangevuld met architectuurprincipes in lijn met het eerder besprokene. Dit geeft wat mij betreft een goed beeld van de algemene positionering van architectuurprincipes.

Weergaven: 1422

Reactie van Marc Lankhorst op 29 December 2011 op 9.28

Danny,

Waar je zegt: "Dit in tegenstelling tot bijvoorbeeld de ArchiMate 2.0 (draft) waarin eisen alleen kunnen voortvloeien uit architectuurprincipes" heb je die draft toch niet helemaal goed gelezen. ArchiMate 2.0 kent het "driver" concept, dat precies al die dingen wil vatten die jij ook als drivers noemt. Daarnaast is er het "goal" concept, dat over veranderdoelen gaat die volgen uit de drivers, en daaruit kunnen dan weer requirements en principes volgen.

Reactie van Danny Greefhorst op 29 December 2011 op 11.25

Hoi Marc,

Het gaat mij erom dat de term "requirement" zelf in ArchiMate 2.0 gereserveerd lijkt voor de zaken die volgen uit architectuurprincipes. Daarmee ligt de focus op user/systeem/functionele eisen en lijkt het algemene begrip "business requirement", dat ook nog helemaal niet over IT hoeft te gaan, geen duidelijke plaats te hebben gekregen.

Mvgr,
Danny

Reactie van Marc Lankhorst op 29 December 2011 op 12.50

Maar die interpretatie klopt dus niet, requirements hoeven niet per se uit architectuurprincipes te volgen, maar kunnen ook een gevolg van goals (bedrijfsdoelen) zijn. Ook een business requirement kun je in ArchiMate 2.0 dus prima met het requirementsconcept modelleren. Het is gedefinieerd als een 'statement of need' dat moet worden gerealiseerd door een 'systeem' (in brede zin, niet per se IT-systeem dus). De uitleg bij het concept zegt dat ook: 'The term “system” is used in its general meaning; i.e., as a group of (functionally) related elements, where each element may be considered as a system again.'

Reactie van Danny Greefhorst op 29 December 2011 op 20.55

Hoi Marc,

Het is vreemd dat requirements in ArchiMate 2.0 dan geen input zijn voor architectuurprincipes. Dat lijkt ook in tegenstelling met uitspraken dat requirements ten grondslag liggen aan de architectuur (zouden dan alleen ten grondslag liggen aan de architectuurmodellen en niet de principes). Wellicht zit de mismatch in het feit dat ArchiMate requirements richt op een specifiek systeem. Dit lijkt ook in tegenstrijd met enterprise-architectuur, dat in het algemeen van toepassing is op alle systemen, of minimaal een klasse van systemen in een organisatie. Daarmee zijn requirements in ArchiMate dus toch meer systeemeisen en minder architectureel van aard.

Mvgr,
Danny

Reactie van Marc Lankhorst op 29 December 2011 op 21.42

Zoals gezegd heeft ArchiMate 2.0 ook 'goal' als concept, waar principes (en requirements) uit volgen, en gaat het uit van 'systeem' in brede zin, dus niet alleen IT-systemen. Principes volgen dus niet uit (specifieke) requirements maar uit (algemene) bedrijfsdoelen, die zelf weer uit drivers (bijv. omgevingsfactoren) volgen. Dus volgens mij is alles wat je zoekt netjes afgedekt, al heten de concepten soms anders dan in jouw terminologie.

Overigens ben ik het niet met jou/Wieger eens dat architectuurprincipes alleen over de niet-functionele zaken gaan. Maar die hele opdeling van Wieger is wat merkwaardig, bijv. met die external interfaces aan de niet-functionele kant en het idee dat 'requirements' alleen over functionele zaken gaan (waar zou je bijv. performance requirements of andere kwaliteitseisen positioneren die voortvloeien uit gebruikerswensen?)

Verder zijn de ArchiMate 2.0 concepten op dit vlak gebaseerd op KAOS en i*, twee bekende methoden voor goal-oriented requirements engineering met een lange historie. Als het je interesseert heb ik nog wel wat achtergrondmateriaal voor je. 

Reactie van Danny Greefhorst op 29 December 2011 op 22.10

Hoi Marc,

Het lijkt er inderdaad op dat er in de wereld conflicterende terminologie wordt gehanteerd. Gelukkig kan een ieder vanuit zijn eigen model de wereld verklaren (laten we dat althans hopen). De babylonische spraakverwarring zal nog wel even voortduren ben ik bang.

Over het verschil tussen functioneel en niet-functioneel kun je ook een heftige discussie over voeren. Ik ben met je eens dat de term "quality attribute" in het model van Wiegers eigenlijk "quality requirement" zou moeten zijn; dat gaf ik in mijn initiële stuk ook al aan. Requirements kunnen dus zowel functioneel als niet-functioneel van aard zijn. Architectuurprincipes zijn niet-functioneel in de zin dat ze niet gericht zijn op het specificeren van functionaliteiten. Het kan wel zo zijn dat bepaalde functionaliteiten (typisch infrastructurele functionaliteiten) randvoorwaardelijk zijn om het principe te laten werken. Overigens is het positioneren van externe interfaces niet zo heel vreemd als je bedenkt dat "interoperability" één van de kwaliteitseigenschappen is in het bekende Extended ISO 9126 model voor softwarekwaliteit (overigens onder de nogal dubieus genaamde characteristic "functionality").

Ik ben geïnteresseerd in de KAOS en i* methoden waar je naar refereert om te begrijpen hoe zij tegen de wereld aan kijken. Overigens lees ik zojuist in het paper "Goal-Oriented Requirements Engineering: An Overview of the Current... dat "Architectural design has long been recognized as having a major impact on non-functional requirements of systems".

Mvgr,
Danny

Reactie van Marc Lankhorst op 29 December 2011 op 22.32

Dit paper geeft wat achtergronden en verwijzingen: http://www.bizzdesign.com/index.php/component/docman/doc_download/1.... Overigens is de ArchiMate 2.0 motivation extension niet helemaal gelijk aan wat hier besproken wordt (dit paper is bijna twee jaar oud). Voor i*, zie http://www.cs.toronto.edu/km/istar/; voor KAOS, http://www.objectiver.com/fileadmin/download/documents/KaosTutorial...

Reactie van Erik Vermeulen op 6 Januari 2012 op 20.21

Lees ook eens het onderzoek van Nigel Cross en de rol die 'first principles' spelen in het cognitieve proces van een ontwerper (hierbij een linkje naar een presentatie van Nigel Cross met leuke illustraties: http://www-staff.it.uts.edu.au/~anton/seminars/presentations/Nigel.pdf). Het metamodel dat een en ander samenvat staat op slide 15. Merk op dat 'first principles' de brug slaan tussen de probleemruimte (met 'problem goals') en de oplossingsruimte ('met solution criteria').

Reactie van Marc Lankhorst op 7 Januari 2012 op 9.12

Die "first principles" van Cross zijn eerder een soort 'natuurwetten' (engineering principles, bijv. dat voorbeeld van die triangulatie) dan de architectuurprincipes (normative principles) die wilt opleggen als generieke eisen aan je oplossingen. In het eerste paper dat ik noemde, wordt dat onderscheid tussen engineering en normative principles ook toegelicht in sect. 8.1.

Reactie van Erik Vermeulen op 8 Januari 2012 op 13.11

Het onderzoek van Cross richt zich op het ontwerpproces en de rol van 'first principles' voor de ontwerper.

In het aangehaalde voorbeeld is de ontwerper, Victor Scheinman, bezig met een ontwerp voor een fysiek construct (een bagagedrager). Hij weet dat het first principle van de parallellogram hem niet de nodige rigiditeit gaat bieden (‘bad thing, bad thing!’). Met het gekozen principe kan Victor Scheinman de brug tussen de probleemruimte en de oplossingsruimte slaan. Het principe biedt de gewenste stabiliteit voor de fietser en tevens een product dat onderscheidend is in de markt. De bron voor het first principle lijkt, vanwege de eigenschappen van de driehoek, inderdaad in dit geval de natuurwetenschap;  maar hij had even zo goed kunnen kiezen voor een principe als ‘veiligheidsfactor’ of ‘vorm volgt functie’ (zoals beschreven in het boek: ‘Universele ontwerpprincipes’ van William Lidwell en anderen).

Een ontwerper die zich bezig houdt met organisatie- of informatieontwerp werkt in essentie niet anders dan de ontwerpers die Nigel Cross heeft bestudeerd, maar zijn bronnen zijn eerder de ‘wetten’ van de organisatie- en informatiewetenschap en minder de wetten van de natuurwetenschap. Zo weten wij bijvoorbeeld dat de matrixorganisatie breekt met het principe van ‘samenvallende verantwoordelijkheden en bevoegdheden’ en het principe van ‘enkelvoudige aansturing’. Het is dan ook niet vreemd dat de matrix binnen organisaties regelmatig op de schop gaat (weinig stabiliteit biedt). Alternatieven zijn bijvoorbeeld de hiërarchische organisatie of de netwerk organisatie. Om de parallel te schetsen met het vorige voorbeeld, de matrixorganisatie is – met de nodige inleving - de 'parallellogram' en de hiërarchische organisatie de 'driehoek’.

De essentie is dat een goed 'first principle' de brug slaat tussen de probleemruimte enerzijds en de oplossingsruimte anderzijds. Daarbij is het verstandig om eerst een of enkele ‘first principles’ te kiezen en pas daarna te werken aan de principes voor de verdere inkleuring van het ontwerp.

Een ander belangrijk aspect van een principe dat ik wil toevoegen is de overtuiging van betrokkenen dat dit principe, en niet een ander principe, inderdaad de manier is om probleemruimte en oplossingsruimte met elkaar te verbinden. Het raakt dus zowel de betrokkenen die primair belang hebben bij de probleemruimte (bv. omdat ze de oplossing gaan gebruiken) als de betrokkenen die primair belang hebben bij de oplossingsruimte (bv. omdat ze de oplossing gaan bouwen). De architect/ontwerper zal dan ook voldoende tijd moeten besteden aan het onderzoeken van deze overtuigingen en zo nodig het bijstellen van ervan (in deze context werkt 'opleggen' vaak contraproductief).

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

24 oktober: GIA/KNVI sessie theorie ontmoet praktijk meer...

Advertenties

Je kunt hier ook zelf adverteren

© 2017   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden