28-12-2011

De relatie tussen architectuurprincipes en eisen

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 eisen 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. 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.