Vastleggen van architectuurprincipes

Ben Binnendijk, Joost Lommersen Eric Roovers, donderdag 10 juni 2010

Naar een metamodel voor de vastlegging van principes en andere afspraken

Er is momenteel geen open standaard voor de vastlegging van architectuurprincipes. TOGAF 9 beschrijft een sjabloon voor vastlegging van individuele principes, maar biedt geen structuur voor het vastleggen van een verzameling principes in relatie tot elkaar en in relatie tot andere architectuurproducten. ArchiMate kent, als taal voor het vastleggen van architectuurproducten, momenteel geen architectuurprincipes in haar metamodel. Dit artikel beschrijft een manier om architectuurprincipes gestructureerd vast te leggen. Deze structuur kan in architectuurrepository’s gebruikt worden als aanvulling op het TOGAF Architecture Content Model of het ArchiMate metamodel.

Wat zijn architectuurprincipes?

Architectuurprincipes zijn “...general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission” [TOGAF]. Architectuurprincipes zijn een onderdeel van een architectuur(beschrijving), zoals verwoord in de [IEC/ISO 42010:2007]: “fundamental conception of a system in its environment embodied in its elements, their relationships to each other and to its environment, and the principles guiding its design and evolution”. In onze praktijk zijn architectuurprincipes richtinggevende uitspraken, die je idealiter als eerste in kaart brengt. Verdere detaillering vind vervolgens plaats via het ontwerpen van concrete richtlijnen en modellen die invulling geven aan de principes. De DYA-methode [Wagter] kent bijvoorbeeld een getrapte indeling in algemene principes, concrete beleidslijnen en specifieke modellen, waarbij deze onderwerpen verdiepingsslagen van elkaar zijn.

Beheersing en sturing via architectuurprincipes bestaat al lang, en over de toepassing van er van is regelmatig gepubliceerd (zie bijvoorbeeld [Davenport], [Greefhorst] of [Buitenhuis]). Deze artikelen richten zich vooral op het definiëren van de principes. Waar wij in de praktijk tegenaan liepen, waren problemen bij de vastlegging van principes.

Vastleggen van principes volgens open standaarden

TOGAF geeft architectuurprincipes een plek in haar Architecture Content Framework en biedt een sjabloon voor vastlegging. De mogelijke relaties tussen principes en andere metamodel elementen worden echter niet expliciet beschreven. Ook het sjabloon biedt geen uitkomst; hierin worden attributen van één principe beschreven, zoals “Category”, “Statement” en “Rationale”, maar geen relaties met andere metamodel elementen.

Een andere open standaard, ArchiMate (zie [ArchiMate] en [Lankhorst]), beschrijft een metamodel voor het modelleren van architectuurproducten. ArchiMate kent een opdeling in een bedrijfs-, applicatie- en technologielaag. Iedere laag bevat een aantal concepten die in relatie tot elkaar te modelleren zijn. Ook laagoverstijgende relaties zijn mogelijk. Het betreft hier echter inhoudelijke concepten als services, producten, bedrijfsprocessen, applicaties, dataobjecten en infrastructuuronderdelen. Architectuurprincipes kunnen niet gemodelleerd worden.

Eisen aan de vastlegging van principes

Om architectuurprincipes handig te kunnen vastleggen, stellen we de volgende minimale eisen aan deze vastlegging:

  • Van ieder principe wordt informatie vastgelegd over het principe zelf;

  • Van ieder principe wordt vastgelegd van welk(e) ander(e) principe(s) het een verbijzondering is;

  • Van ieder principe wordt vastgelegd op welk architectuurproduct het van toepassing is.

We kunnen gebruik maken van TOGAF 9 [TOGAF, hoofdstuk 23 en paragraaf 34.6] voor de informatie die we van ieder principe willen vastleggen (zie Tabel 1). We breiden dit uit met attribuut “Nalevingsniveau” dat de volgende waarden kent: “Verplicht”, “Volg op of leg uit” en “Advies”.

Attribuut

Omschrijving

ID

Unique identifier for the architecture principle

Name

Brief name of the architecture principle

Statement

Statement of what the principle is

Rationale

Statement of why the principle is required and the outcome to be reached

Implications

Statement of what the principle means in practical terms

Category

The following categories of principle apply: Guiding Principle, Business Principle, Data Principle, Application Principle, Integration Principle, Technology Principle.

Description

Textual description of the architecture object

Priority

Priority of this principle relative to other principles

Metric

Identifies mechanisms that will be used to measure whether the principle has been met or not

Owner

Owner of the architecture object

Source

Location from where the information was collected

Tabel 1. Attributen van een architectuurprincipe volgens TOGAF 9.

Tijdens het definiëren van principes constateerden wij dat we te maken hebben met principes die uit andere principes volgen. Zo wil je in een uitvoeringsorganisatie binnen de overheid kunnen vastleggen dat je eigen, organisatiespecifieke principes zijn afgeleid van MARIJ-principes1. De MARIJ-principes zijn vervolgens weer (deels) afgeleid van NORA-principes2. Daarnaast concludeerden we dat we onze eigen principes wilden concretiseren via deelprincipes (of richtlijnen). Deze deelprincipes moesten ook weer terugverwijzen naar het bijbehorende (hoofd)principe.

Architectuurprincipes geven richting aan oplossingsalternatieven en architectuurontwerpen voor deze oplossingen. Deze ontwerpen worden vastgelegd met “architectuurproducten”. Om te constateren dat alle principes gebruikt zijn, of om te kijken welke principes van toepassing zijn op een bepaald architectuurontwerp, dient de relatie vastgelegd te worden tussen principes en de desbetreffende architectuurproducten. Als vervolgens de architectuurproducten gekoppeld worden aan de oplossingen die onder deze architectuur zijn gerealiseerd, dan is er zelfs een relatie te leggen tussen architectuurprincipes en gerealiseerde oplossingen.

Het (initiële) metamodel (zie Figuur 1) illustreert hoe architectuurprincipes volgens de bovenstaande eisen vastgelegd kunnen worden. Door dit metamodel in te regelen in een architectuurrepository (zoals ARIS van IDS Scheer), worden de onderstaande activiteiten ondersteund:

  • uitwerken van (delen van) referentie-architecturen en projectstartarchitecturen wordt makkelijker door de gestructureerde vastlegging van principes;

  • relateren van principes aan elkaar wordt mogelijk door de “is verbijzondering van” relatie - bijvoorbeeld, hoe is een (hoofd)principe opgedeeld in deelprincipes;

  • relateren van principes aan architecturen wordt mogelijk door de relatie tussen Architectuurprincipe en Architectuurproduct - wat zowel het ontwerpen van architecturen (koppelen van principes aan architectuurproducten) als het analyseren van architecturen (uitvragen welke principes van toepassing zijn op een bepaald architectuurproduct) vergemakkelijkt;

  • onderhoud aan de architectuurprincipes en hun relaties wordt vereenvoudigd door de gestructureerde vastlegging.

Door het koppelen van architectuurproducten aan oplossingen (niet getekend in het initiële metamodel), zijn vervolgens ook nog de volgende activiteiten te ondersteunen:

  • controleren of oplossingen aan de principes voldoen wordt makkelijker te doen doordat oplossingen te koppelen zijn aan principes die van toepassing zijn;

  • verantwoording over de toepassing van principes wordt mogelijk door analyse van de relatie tussen oplossingen en de vastgelegde principes;

  • impactanalyse van de gevolgen van wijzigingen in principes op gerealiseerde oplossingen wordt eenvoudiger.


Figuur 1 Initieel metamodel voor de vastlegging van architectuurprincipes

Modelelement

Beschrijving

Architectuurprincipe

De vastlegging van een principe, via de principe-attributen uit TOGAF 9 + nalevingsniveau uit NORA.

Architectuurproduct

De vastlegging van een architectuurproduct, via een identifier, een naam en (eventueel) een korte beschrijving. Een architectuurproduct is een afgebakend onderdeel van een architectuurbeschijving, zoals een building block, artifact en/of een deliverable in TOGAF 9.

Principetoepassing

Relatieklasse tussen Architectuurprincipe en Architectuurproduct die vastlegt dat een principe van toepassing is op het gekoppelde Architectuurproduct.

Via een attribuut kan vastgelegd worden of het Architectuurproduct daadwerkelijk voldoet aan het Architectuurprincipe, of dat het Architectuurproduct niet voldoet aan het principe dat van toepassing is.

Eventueel kan ook streefdatum opgenomen worden voor het voldoen aan het principe.

Is een verbijzondering van

Relatie tussen twee Architectuurprincipes die vastlegt dat het ene Architectuurprincipe een verbijzondering is van het andere Architectuurprincipe. Bijvoorbeeld voor het vastleggen van de relatie tussen fundamentele principes en (gewone) principes in NORA, de relatie tussen MARIJ-principes en het NORA-principe waarvan ze zijn afgeleid, of de relatie tussen beleidslijnen en de algemene principes waar ze van afgeleid zijn in DYA.

Tabel 2 Legenda bij het initieel metamodel.

Praktijkeisen aan de vastlegging van principes

Bij gebruik in de praktijk bleek al snel dat de bovenstaande eisen niet voldoende zijn voor handige vastlegging en gemakkelijk gebruik van principes. We liepen als snel aan tegen de “veelheid” aan principes. Enerzijds werd het aantal principes groot, wat tot veel beheer leidde. Anderzijds bleken principes in relatie te staan tot een aantal andere concepten die nogal veel leken op principes, zoals richtlijnen, standaarden, beleid, eisen en wensen.

Door de grote hoeveelheid aan principes bleek de toewijzing van principes aan andere architectuurproducten bewerkelijk. Daarnaast bleken bepaalde principes vaak in combinatie met elkaar aan andere producten gekoppeld te worden. Deze constateringen leiden tot de volgende eisen:

  • principes kunnen geclusterd worden in principegroepen. Een principegroep is een verzameling principes, liefst met een zinvolle naam, die als één geheel aan een architectuurproduct te koppelen is;

  • individuele principes en principegroepen kunnen gekoppeld worden aan een groep van architectuurproducten, waarbij geïmpliceerd wordt dat alle architectuurproducten een relatie hebben met de desbetreffende principes.

Voorbeelden van principegroepen zijn de verzameling van TOGAF business architectuur principes, alle NORA-principes, de MARIJ-principes voor informatiearchitectuur of alle informatiebeveiligingsprincipes. Dit zijn typisch principegroepen die volgen uit een bepaalde clustering in een architectuurmethode zoals TOGAF, of een (referentie)architectuur, zoals NORA of MARIJ. Daarnaast kan de architect ook eigen groeperingen maken, zoals een groep van usability-principes of een groep van SOA-principes.

Bij het koppelen van architectuurprincipes aan architectuurproducten, bleek het vooral handig te werken om principes te koppelen aan een diagram ). Door een relatie te leggen tussen principes en het diagram, wordt automatisch een relatie gelegd met alle architectuurproducten op het diagram. Een voorbeeld hiervan is een diagram met een applicatielandschap bestaande uit applicatiecomponenten en afhankelijkheidsrelaties tussen de getoonde applicaties. Door hieraan de principegroep met SOA-principes te koppelen, modelleren we dat dit applicatielandschap voldoet aan alle principes in de gekoppelde principegroep. Wat we op deze manier ook kunnen uitdrukken, is dat alle applicatiecomponenten in het landschap voldoen aan de groep met SOA-principes. Hiervoor gaan we een attribuut toevoegen aan de relatie tussen principe(groep) en architectuurproduct(groep).

Toen we de opgebouwde principestructuur en haar inhoud gingen gebruiken bij onze werkzaamheden, kwam al snel de vraag of we naast principes ook andere kaders konden invoeren. Principes, met name concrete deelprincipes, bleken namelijk regelmatig te verplichten tot gebruik van standaarden. En vaak werden principes afgeleid uit beleidskaders. Uiteindelijk zijn we gekomen tot een classificatie van “Afspraak” in “Beleidskader”, “Principe”, “Richtlijn” en “Standaard”3 . Eisen en wensen (“Requirement”) hebben we momenteel buiten het model gehouden. Eisen en wensen vinden wij van een andere orde dan principes et cetera4. En met een beleidskoepel van zo’n 350 beleidskaders, richtlijnen en standaards was er genoeg te doen.

Als laatste hebben we ook doelen in het metamodel opgenomen. Hierdoor kunnen principes gerelateerd worden aan bedrijfsdoelstellingen, waardoor inzicht ontstaat in het “waarom?” van een principe. Voor de eenvoud nemen we doelen los van elkaar op in de repository; we modelleren geen complete doel-middelenhiërarchie in onze architectuurrepository.

Bovenstaande eisen leiden tot een uitbreiding van het eerder getoonde initiële metamodel, zie ook Figuur 2 op de volgende pagina.


Figuur 2 Metamodel voor de vastlegging van architectuurafspraken

Modelelement

Beschrijving

Architectuurafspraak

De generieke vastlegging van een soort afspraak, waarbij het niet uitmaakt of het een groep of een individuele afspraak betreft.

Architectuurafspraak vormt samen met Afspraakgroep en Individuele Architectuurafspraak een composite pattern [Gamma].

Afspraakgroep

Een Architectuurafspraak die bestaat uit een groepering van andere Architectuurafspraken. De groep krijgt een eigen, unieke identificatie, een naam en een korte omschrijving.

Individuele architectuurafspraak

De vastlegging van een architectuurafspraak, bijvoorbeeld via de principe-attributen uit TOGAF 9 + het nalevingsniveau uit NORA. Architectuurafspraak is de generieke variant van Beleidskader, Principe, Richtlijn en Standaard.

Beleidskader, Principe, Richtlijn, Standaard

Verschillende soorten Individuele Architectuurafspraken

Doel

De vastlegging van een bedrijfsdoelstelling, via een unieke identificatie, een naam en een beschrijving.

Afspraaktoepassing

Relatieklasse tussen Architectuurafspraak en Architectuurproduct die vastlegt dat een afspraak van toepassing is op het gekoppelde Architectuurproduct.

Via een attribuut kan vastgelegd worden of het Architectuurproduct daadwerkelijk voldoet aan de Architectuurafspraak, of dat het Architectuurproduct niet voldoet aan de afspraak die van toepassing. Eventueel kan ook streefdatum opgenomen worden voor het voldoen aan de afspraak.

Via een attribuut kan vastgelegd worden of een afspraak alleen geldt voor het gekoppelde Architectuurproduct, of voor het gekoppelde Architectuurproduct en alle onderdelen van dit product.

Architectuurproduct

De generieke vastlegging van een soort architectuurproduct, waarbij het niet uitmaakt of het een groep of een individueel product betreft.

Architectuurproduct vormt samen met Architectuurproductgroep en Individueel Architectuurproduct een composite pattern [Gamma].

Architectuurproduct-groep

Een Architectuurproduct dat bestaat uit een groepering van andere Architectuurproducten. De groep krijgt een eigen identifier, een naam en een korte omschrijving.

Individueel Architectuurproduct

De vastlegging van een architectuurproduct, via een unieke identificatie, een naam en (eventueel) een korte beschrijving.

Een architectuurproduct is een afgebakend onderdeel van een architectuurbeschijving, zoals een building block, artifact en/of een deliverable in TOGAF 9.

Is een verbijzondering van

Relatie tussen twee Architectuurafspraken die vastlegt dat de ene Architectuurafspraak een verbijzondering is van de andere Architectuurafspraak. Bijvoorbeeld voor het vastleggen van de relatie tussen fundamentele principes en (gewone) principes in NORA, de relatie tussen MARIJ-principes en het NORA-principe waarvan ze zijn afgeleid, of de relatie tussen beleidslijnen en de algemene principes waar ze van afgeleid zijn in DYA.

Door overerving kan deze relatie ook gelegd worden tussen Afspraakgroepen en/of de diverse soorten Individuele Architectuurafspraken.

Helpt te realiseren

Relatie tussen Architectuurafspraak en Doel die vastlegt dat de afspraak het gekoppelde doel helpt te realiseren. Een afspraak is altijd gekoppeld aan minstens één doel.

Tabel 3 Legenda bij het metamodel voor architectuurafspraken

Voorbeelden uit de praktijk bij de Dienst Justitiële Inrichtingen

Als een rechter in Nederland iemand een straf of vrijheidsbenemende maatregel oplegt, is het Ministerie van Justitie verantwoordelijk voor de uitvoering daarvan. De Dienst Justitiële Inrichtingen (DJI) voert deze taak uit. Alle justitiële inrichtingen in Nederland vallen onder de verantwoordelijkheid van DJI. Dit zijn penitentiaire inrichtingen (huizen van bewaring en gevangenissen), justitiële jeugdinrichtingen, forensisch psychiatrische centra en detentie- en uitzetcentra. Daarnaast koopt DJI plaatsen in bij andere instellingen, bijvoorbeeld voor verslavingszorg. Jaarlijks verblijven tienduizenden personen voor korte of lange tijd in een justitiële inrichting, onder wie verdachten, volwassen gedetineerden, jongeren, forensische patiënten en in Nederland verblijvende vreemdelingen. Zij zitten in voorarrest, hebben een straf of maatregel opgelegd gekregen of wachten op uitzetting.

In 2008 is binnen DJI begonnen met het vernieuwen van de bestaande enterprise architectuur. Aanleidingen waren ondermeer de steeds omvangrijkere en frequentere uitwisseling van gegevens in de diverse ketens waarin DJI een rol speelt, de kwaliteit van de gegevens en het complexe applicatielandschap (circa 700 applicaties, waarvan zo’n 80 tot het centrale applicatielandschap worden gerekend). De afgelopen maanden is o.a. het baseline applicatielandschap in kaart gebracht, en zijn er diverse scenario’s ontwikkeld voor target applicatie-architecturen. Architectuurprincipes, waaronder die uit NORA en MARIJ, vormen een onderdeel van de target applicatie-architectuur. De standaardtaal voor het vastleggen van architectuurproducten is ArchiMate, en de vastlegging gebeurt in ARIS van IDS Scheer.

Doordat DJI een agentschap van het Ministerie van Justitie is, zijn de MARIJ en de NORA van toepassing. Door het vastleggen van zowel DJI-principes, als MARIJ en NORA principes volgens het beschreven metamodel, zijn relaties tussen deze verschillende principes visueel te maken.

Voorbeeld 1 in Figuur 3 toont een deel van de vastgelegde relaties tussen architectuurprincipes uit NORA, uit MARIJ en van DJI. Het voorbeeld in Figuur 4 toont een set van principes die samen de principesgroep “Serviceoriëntatiegroep” vormen. Deze set kan vervolgens als één geheel aan architectuurproducten gekoppeld worden.

Voorbeelden 3 en 4 laten zien hoe in ARIS de principes aan een view gekoppeld kunnen worden. In voorbeeld 3 (zie Figuur 5) wordt de Serviceoriëntatiegroep gekoppeld aan de afspraaktoepassing met de naam “Serviceoriëntatie op to-be landschap”. Deze afspraaktoepassing kan vervolgens op een diagram getoond worden. Voorbeeld 4 (zie Figure 6) toont een applicatielandschap waarop twee afspraaktoepassingen getoond worden.


Figuur 3 Voorbeeld van de relaties tussen DJI-, MARIJ- en NORA-principes.


Figuur 4 Serviceoriëntatiegroep als voorbeeld van een groep van principes.


Figuur 5 De Serviceoriëntatiegroep wordt gekoppeld aan een afspraaktoepassing “Serviceoriëntatie op to-be landschap”.


Figure 6. Geanonimiseerd applicatielandschap met twee afspraaktoepassingen.

Conclusie en aanbevelingen voor verdere verkenning

Uit onze toepassing in de praktijk blijkt het uitgebreide metamodel voor architectuurafspraken goed te werken. Het vullen van de inhoud lijkt veel werk, maar werpt bij reviews en verantwoording zijn vruchten af. Natuurlijk blijven er punten voor verbetering. Wij zien de volgende onderwerpen die verder verkend kunnen worden:

  • momenteel worden architectuurafspraken alleen gekoppeld aan architectuurproducten. De relatie met oplossingen wordt gelegd in projectstartarchitectuurdocumenten. Deze documenten bevinden zich buiten onze architectuurrepository. In hoeverre heeft het toegevoegde waarde om de koppeling van architectuurafspraken met oplossingen ook in de centrale architectuurrepository op te nemen?

  • momenteel hebben we eisen en wensen buiten scope geplaatst. In hoeverre is het nuttig om deze ook mee te gaan modelleren, en verdrinken we vervolgens niet in de hoeveelheid informatie die we moeten beheren?

  • uit de architectuurrepository worden nu enkele doelgroepspecifieke documenten geproduceerd. Een brede ontsluiting van architectuurafspraken en -producten naar architecten en diverse andere belanghebbenden moet nog worden uitgewerkt. Daarnaast hebben we nog geen overzichtelijke visualisatie gevonden die een grote hoeveelheid afspraken in samenhang kan laten zien.

1 MARIJ is de referentie-architectuur van de Rijksoverheid, zie [MARIJ].
2 NORA Is de referentie-architectuur van de Nederlandse Overheid, zie [NORA].
3 Hierbij sluiten we vooral aan op terminologie die binnen de Dienst Justitiële Inrichtingen gebruikelijk is.
4 Eisen en wensen zijn artifacten van een specifieke verandering. Ze worden dusdanig geformuleerd dat ze in een veranderproject richting geven aan het ontwerp. Principes worden niet geformuleerd als een delta, of in de context van een specifieke verandering, maar als een tijdloze waarheid. Als de werkelijkheid nog niet helemaal voldoet aan een principe, dan moet die werkelijkheid veranderd worden en dat leidt dus tot het formuleren van eisen en wensen.

[PDF]

Opmerking

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

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

29-05: KNVI sessie - kick-off ethish manifest voor architecten meer...

19-06: KNVI/PLDN sessie over semantische data integratie in de weg- en spoorinfrastructuur 

28-06: LAC summit meer...

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden