Alle IT-kennis onder één wereldwijd dak
Werken bij de beste IT dienstverlener van Nederland?
Resultaat door passie voor IT
Start typing keywords to search the site. Press enter to submit.
Generative AI
Cloud
Testing
Artificial intelligence
Security
September 10, 2024
In de whitepaper “Principle-based approach in Enterprise Architecture practice; finding the sweet spot” wordt uitleg gegeven wat een Principle Based Architecture (PBA) is als alternatief van de Rule Based Architecture (RBA). De vraag is alleen nog hoe je dat realiseert. In deze blog geef ik daar in een paar stappen antwoord op.
Wellicht is het goed om nog even een typische regel en een typisch principe te demonstreren dat ook in de white paper als voorbeeld wordt gebruikt:
Het verschil is niet altijd scherp. Soms zijn richtlijnen meer principe dan regel, soms andersom. Kijk voor een goed voorbeeld van een Principle Based Architecture ook eens naar NORA(externe link) van de Rijksoverheid.
Om PBA succesvol te implementeren is het van belang dat de architectuur binnen de organisatie volwassen genoeg is. Van management tot ontwikkelaar moet men begrijpen waarom de Enterprise Architecture van belang is. Daarnaast moeten ze zich er ook aan houden. Tenslotte geeft Burgemeestre [1] aan dat bij PBA meer ontwerpvrijheid hoort en deze vrijheid moet op een goede manier worden gebruikt. De DYA-volwassenheidsmatrix kan hierbij een hulpmiddel zijn. Schaal 6 in deze matrix zou een goed moment kunnen zijn om aan principle based architecture te beginnen.[2]
Wanneer de organisatie er klaar voor is, kan PBA worden geïntroduceerd. Dat kan evolutionair. Je kunt er ook voor kiezen om de gehele set van bestaande regels in één keer te vervangen door een set van nieuwe principes. Gezien de benodigde voorbereidingstijd en tijd om te wennen aan de verantwoordelijkheid lijkt dit laatste niet verstandig.
Het is ook niet nodig om van strikte regels in één keer op te schuiven naar abstracte principes. Het is mogelijk, zelfs aan te raden, om strikte regels te vervangen door principiëlere maar minder strikte regels. En die vervolgens weer te vervangen door nog abstractere principes. Zo kan door ondervinding het passende niveau voor een organisatie worden gevonden. Dit niveau wordt aangeduid met de term “sweet spot”. Overgang van RBA naar PBA is een cultuurverandering en die type veranderingen kosten over het algemeen veel tijd. Die tijd kan goed gebruikt worden om de sweet spot te vinden.
Een belangrijk element in PBA is dat principes beschrijven wat de organisatie wil bereiken. Bij regels is dit niet nodig. De regel is opgesteld en er hoeft alleen maar vastgesteld te worden of aan de regel is voldaan.
Om van regels op te schuiven naar principes is het dus belangrijk om te weten waaróm de regel opgesteld is. Hierin ligt ook vaak de sleutel tot het vinden van het achterliggende principe. Als het principe is gevonden, kan vervolgens getoetst worden of dit principe bijdraagt aan de business doelstellingen van de organisatie. Als dit bevestigend beantwoord is dan is hoogstwaarschijnlijk een goed principe gevonden.
Dit kan voor alle regels uit de architectuur gedaan worden. Men mag daarbij verwachten dat een aantal verschillende regels leiden tot één principe. Dit is meestal ook een teken dat een goed principe is gevonden.
Natuurlijk kan het ook zo zijn dat één regel een antwoord is op meer principes. Elk van de principes is dan kandidaat om in de architectuur te worden opgenomen.
Uiteindelijk is het van belang om het aantal principes niet te groot te laten worden. Het is dan goed om onderscheid te maken tussen primaire principes en secundaire principes. Bijvoorbeeld een top 10 principes en een lijst van aanvullende of ondergeschikte principes. Dit vergroot het overzicht en vermindert de kans op ingewikkelde discussies.
Wat als er nu niet direct een bijbehorend businessdoel gevonden wordt? Dit betekent niet altijd dat het gevonden principe niet goed is. Het zou immers kunnen dat het principe appelleert aan één van de secundaire business doelstellingen. De kans is groot dat het principe dan ook als secundair gekwalificeerd mag worden.
Wat goede principes zijn voor de ene organisatie, zijn nog geen goede principes voor de ander. Iedere organisatie heeft tenslotte zijn eigen missie, doelstellingen en positie in de maatschappij. De architectuur-principes van de organisatie moeten daarop aansluiten. Het is daarom niet mogelijk om inhoudelijke uitspraken over goede en minder goede principes te doen.
Ik ben zelf een groot voorstander van Principle Based Architecture. De belangrijkste reden is dat de professional al zijn kennis, creativiteit en vaardigheid inzet om tot goede oplossingen te komen. Dit leidt volgens mij tot meer plezier in het werk, en daardoor tot optimale oplossingen.
Dit sluit ook erg goed aan bij wat Markowski [3] in zijn boek aangeeft met betrekking tot vrijheid in een organisatie. In dit boek wordt aangegeven dat (ontwerp)teams vrijheid nodig hebben om tot een organisatie-optimum te kunnen komen.
In tijden van disruptie is het van belang dat organisaties wendbaar en innovatief zijn. Ik ben van mening dat een PBA daarvoor beter geschikt is dan een RBA.
Er is dus alle reden om met Principle Based Architecture te experimenteren.
Geïnspireerd geraakt over deze nieuwe architectuurprincipes en technologiegedreven architectuur? Neem dan contact op met onze contactgegevens.
Referenties:1. B. Burgemeestre, J. Hulstijn, Y.H. Tan: Rule-based versus Principle-based regulatory compliance; Proceedings of the 2009 conference on Legal Knowledge and Information Systems: JURIX 2009: The Twenty-Second Annual Conference, pages 37-46.2. R. Wagter, M. van den Berg, J. Luijpers, M. van Steenbergen: DYA Snelheid en samenhang in business- en ICT-architectuur; ISBN 9072194624.3. V.A.R. Markowski, L Baris: Managen van complexiteit; ISBN 9789402225556.
