Allereerst wil ik even reageren op een aantal opmerkingen van Daan Rijsenbrij, waarna ik zal ingaan op een aantal persoonlijke constateringen.

Op een aantal plaatsen in zijn commentaar spreekt Daan Rijsenbrij over het onderscheid tussen functionele eisen en principes. Ik vraag mij sterk af in hoeverre zo'n onderscheid wel gemaakt kan worden. Mijns inziens hebben zij meer met elkaar gemeen hebben dan dat zij verschillen. Principes kun je decomponeren tot lager gelegen principes, die je op een bepaald niveau richtlijnen zou kunnen noemen. Deze richtlijnen zijn zo specifiek geworden dat ze direct in een programma van eisen kunnen worden opgenomen. De decompositie van principes leidt tot een hele keten van principes die in feite een doel-middel hierarchie vormen. Het hoger gelegen principe is daarmee een eis en het onderliggende principe de oplossing. Deze doel-middel hierarchie van principes lijkt wel verdacht veel op de doel-middel hierarchie die je ook in eisen kunt onderkennen. Het belangrijkste verschil tussen principes en eisen zijn dan ook mijns inziens dat eisen gelden voor een specifiek systeem en principes gelden voor dan een systeem (een klasse van systemen).

Daan Rijsenbrij geeft aan graag een onderscheid te willen zien in business principes, architectuurprincipes, bouwprincipes en transformatieprincipes. Mijns inziens is deze classificatie net zo vaag als het onderscheid tussen fundamentele principes en architectuurprincipes. Aansluitend bij mijn vorige opmerking zou ik liever het onderscheid zien in decompositieniveau's. Het hoogste niveau is dan wat NORA de fundamentele principes noemt. De onderliggende niveau's worden steeds gedetailleerder en gaan op een zeker moment over een specifiek aspectgebied: business, applicatie, infrastructuur. Dit aspectgebied zou je als voorvoegsel voor het principe kunnen hanteren. Overigens zie je hierin ook het onderscheid tussen verschillende stakeholders terugkomen; lager gelegen principes worden steeds specialistischer.

Ik sluit mij aan bij de opmerkingen van Daan Rijsenbrij rondom het SMART formuleren van principes. Gegeven de gelijkenis met eisen is dit ook niet verwonderlijk; daar is dit reeds een welbekende best-practice. Overigens gaat daar mijns inziens ook het belangrijkste werk inzitten bij het formuleren van princpes. Uiteindelijk gaat het erom dat principes kernachtig maar toch specifiek genoeg zijn om uitdrukking te geven aan de intentie achter het principe. Dit is een proces van verfijning waar vaak meerdere iteraties en feedback van anderen voor nodig zijn om tot het uiteindelijke resultaat te komen.

Dit brengt mij tot de opmerkingen op de NORA principes, waarbij ik met name heb gegeken naar hoofdstuk 6 aangezien dat mijn eigen expertisegebied is. Wat mij met name opvalt is de mate waarin motivatie en implicaties van principes zijn gedefinieerd. Zij worden niet expliciet onderscheiden, maar zijn simpelweg samengevat in een toelichting bij het principe. Hierdoor is het lastig te begrijpen waar het principe op ge_base_erd is (zie ook opmerking van Daan Rijsenbrij omtrent ontbreken van X-ref matrix). Daarnaast is het lastig om in te zien wat de precieze impact van principes is, terwijl het doel van architectuurprincipes nu juist is om veranderingen in kaart te brengen of te stroomlijnen.

Een ander punt wat mij opvalt is dat veel principes op algemene best-practices lijken (bijv. "Elk gegeven kent een eigenaar en een beheerder"). Enerzijds verbaast me dat niet; veel organisaties worstelen met generieke problemen. Anderzijds vraag ik me af dit soort algemeenheden nog voldoende toegevoegde waarde hebben; vrijwel iedereen zal het met je eens zijn. Ik zou ervoor willen pleiten om te komen tot een algemene catalogus van principes waarin deze principes verwoord zijn en waar anderen aan kunnen refereren. Specifieke architecturen kunnen zich dan richten op organisatie-specifieke problemen en specifieke keuzes die organisaties maken. Dit zorgt er ook voor dat architecturen beter toegankelijk worden: algemeenheden kunnen worden weggelaten.

Een andere constatering is dat een aantal principes meer op een definitie of een uitleg lijken dan op een principe. Een principe als "Complexe services mogen gebruikmaken van eenvoudige services" lijkt uiteindelijk niet meer te zijn dan de definitie van een complexe service: dat is er een die is samengesteld uit andere services. Een andere is: "Services zorgen voor een losse koppeling tussen gebruiker en leverancier"; dit is nu eenmaal een inherente eigenschap van services. Overigens vallen deze principes ook grotendeels onder mijn vorige opmerking: ze zijn algemene best-practices en definities van een service-architectuur.