Ik zie in de inleidende opmerkingen van Danny een aantal zaken waar ik het niet geheel en al mee eens ben, maar die niet alleen gelden voor de NORA:
1. In tegenstelling tot Danny vind ik het essentieel een onderscheid te maken tussen functionele eisen en principes.
Hoewel hij wel terecht opmerkt: Het belangrijkste verschil tussen principes en eisen zijn dan ook mijns inziens dat eisen gelden voor een specifiek systeem en principes gelden voor meer dan een systeem (een klasse van systemen).
2. De classificatie in business principes, architectuurprincipes, bouwprincipes en transformatieprincipes is absoluut niet vaag en erg essentieel voor een goed architectuurdocument.
3. Zijn opmerking over decompositieniveaus is uitermate essentieel, maar als hij spreekt over de specifieke aspectgebieden 'business, applicatie en infrastructuur', hebben wij toch een verschil van benadering. Dit zijn geen aspecten, maar subsystemen.

Ad 1: Net zoals Vitruvius ben ik van mening dat architectuur dient om artefacten professioneler te ontwerpen. Vitruvius onderscheidde daarbij de kwaliteitskenmerken: schoonheid, bruikbaarheid en duurzaamheid (de verschillende vertalingen van de Latijnse termen die in de tekstboeken staan hebben zo af en toe wat andere bewoordingen, maar komen toch ongeveer hiermee overeen). Voor de digitale wereld (sommigen van jullie noemen dat de IT-wereld, anderen weer de e-wereld), zouden dat de kwaliteitskenmerken zijn: beleving, structurering en constructie. Zoals ik in de update van mijn oratie (http://www.digital-architecture.net/oratie/ update.doc) reeds aangaf, zou ik dit drieluik willen uitbreiden met twee extra kwaliteitskenmerken: het duo security & privacy en het duo governance & compliancy. Omdat de wereld van Vitruvius nog niet zo onveilig en hectisch was als de onze heeft Vitruvius deze kwaliteitskenmerken niet onderkend, naar ik aanneem. Deze vijf superkwaliteitskenmerken duid ik vaak aan met Vitruvius++.
Wat opvalt in mijn tekst hierboven is dat ik principes zie als de bron van veel kwaliteitskenmerken, daarom noem ik de Vitruvius++ kenmerken soms superkwaliteitskenmerken.
In een functioneel ontwerp onderscheidden wij vroeger functionele eisen en kwaliteitseisen (ik meen mij te herinneren dat Theo Bemelmans die laatste categorie in het begin prestatie-indicatoren noemde). Functionele eisen gaan over 'wat' het systeem moet gaan doen, bijvoorbeeld het afhandelen van hypotheekaanvragen. De kwaliteitseisen geven aan met welke snelheid (afhankelijk van het communicatiekanaal), welke gebruiksvriendelijkheid en welke betrouwbaarheid om maar een paar kwaliteitskenmerken te noemen. Dat onderscheid tussen functionele eisen en kwaliteitseisen is zeer essentieel op het niveau van de functionele specificatie, maar is ook op de hogere niveaus te onderkennen. Zo is het mogelijk twee systemen die totaal verschillende zaken afhandelen, bijvoorbeeld een factureersysteem en een betaling van zorgtoeslag, onder dezelfde architectuur te ontwerpen en bouwen. Dat is ook wat Danny bedoelt in zijn toelichtende zin over een klasse van systemen.

Ad 2: Principes zijn richtinggevende uitspraken die de vormgeving of het functioneren van een systeem voorschrijven (pre_script_ieve architectuur).
Het businessgebeuren heeft dergelijke principes. Bijvoorbeeld het business principe op de Radboud Universiteit dat als slechts een van de studenten van een Mastervak aangeeft geen Nederlands te spreken, de docent verplicht is in het Engels te doceren. Dat is een belangrijk en verstrekkend business principe. Doch dit business principe is absoluut geen architectuurprincipe, het beperkt de ontwerpruimte van de digitale artefacten op geen enkele wijze. Een business principe als de een loketgedachte, dat onderdeel is van het derde fundamentele principe in NORA 2.0, leidt wel tot een architectuurprincipe, namelijk de splitsing in front office en back offices, met mogelijke mid offices. In mijn architectuurwerk kom ik vaak deze twee soorten business principes tegen: zij die leiden tot architectuurprincipes en zij die dat niet doen. Vele van de business principes die ik zie bij NORA 2.0 leiden absoluut niet tot architectuurprincipes.

Ad 3: Met decompositieniveaus bedoelt Danny dat principes, subprincipes, subsubprincipes, etc, etc worden geordend als boomstructuren. De wortels van die bomen zijn mijn Vitruvius++ aspecten en de bladeren van die bomen zijn regels, standaarden en richtlijnen waaraan de ontwerper zich dient te houden. Deze boomstructuren werken op de digitale artefacten waaruit het systeem bestaat. Zeg maar de componenten en hun onderlinge relaties die worden genoemd in de architectuurdefinitie 1471 van IEEE, waarvan de NORA uitgaat. Deze artefacten kunnen worden geordend naar hun scope (enterprise, domein, informatiesysteem en digitale werkruimte, zie de bovengenoemde update op mijn oratie) en de subsystemen (business, informatie, applicatie en technische infrastructuur).
Omdat de uiteindelijke regels die voortkomen uit verschillende wortels met elkaar in conflict kunnen zijn (bijvoorbeeld regels aangaande gebruiksvriendelijkheid die voortkomen uit de beleving en regels aangaande passwoorden die voortkomen uit de security), dienen deze conflicten op het juiste niveau in de boomstructuren te worden onderkend. Dit kan alleen met goede decompositieniveaus.

Nu de zaken waar Danny en ik volledig op de zelfde golflengte zitten.

a. Danny's persoonlijke constateringen, toegespitst op hoofdstuk 6, dat de principes veel gedetailleerder dienen te worden geformuleerd om de bruikbaarheid van de NORA te vergroten.
Het zou goed zijn dat als huiswerk te zien voor het team dat NORA 3.0 gaat formuleren. Dit geldt ook voor het SMART maken van de principes waar Danny mij in bijvalt.

b. Zijn pleidooi om te komen tot een algemene catalogus van zaken die te maken hebben met het professioneel formuleren van een architectuur en het daarop volgend ontwerp. Dit zou een mooie uitdaging zijn voor het onderhavige E-Magazine 'Via Nova Architectura'.

c. Ook zijn opmerkingen over de constructie, het gebruik en het beheer van services zijn mij uit het hart gegrepen. Een beschouwing over services-management hoort in de NORA beslist niet thuis, maar in een notitie over hoe je zakelijk en professioneel met het hele bouwwerk van services hoort om te gaan. Hier geldt hetzelfde als bij punt b: een uitdaging voor dit E-Magazine.