REVIEW VERSIE. Dragon1 Open Standaard Architectuurprincipes. Dragon1 Open Standard Architecture Design Principles. D1-APRS-2010rev0.9.7

1 2 3 4

REVIEW VERSIE

5 6 7 8

Dragon1 Open Standaard

9

Architectuurprincipes

10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

Dragon1 Open Standard – Architecture Design Principles D1-APRS-2010rev0.9.7

Colofon Auteur:

The Dragon1 Company

Datum:

19 november 2010

Versie:

0.9.7c

Status:

Concept

© Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

1

Inhoudsopgave

2 3

1

4 5 6 7

DOCUMENTHISTORIE .................................................................................................. 4 1.1 1.2 1.3 1.4

PUBLICATIEHISTORIE.................................................................................................. 4 WIJZIGINGENHISTORIE ............................................................................................... 4 REVIEWERS .............................................................................................................. 4 AMBASSADEURS ........................................................................................................ 4

8

2

MANAGEMENTSAMENVATTING ................................................................................. 5

9

3

INLEIDING ..................................................................................................................... 9

10 11 12 13 14 15 16 17

3.1 3.2 3.3 3.4 3.5 3.6 3.7 4

18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

5

43 44 45 46 47 48 49

HET CONCEPT ‘PRINCIPE’ ........................................................................................ 13 4.1 4.2 4.3

DEFINITIE ............................................................................................................... 13 FUNCTIE ................................................................................................................. 14 VORM ..................................................................................................................... 15

4.4 4.5

SOORTEN PRINCIPES ............................................................................................... 18 PRINCIPES NAAR SOORT ENTITEIT .............................................................................. 20

4.6

PRINCIPES NAAR GEBRUIKSDOEL ............................................................................... 21

4.7

PRINCIPES OP THEMA OF DOMEIN .............................................................................. 25

4.3.1 4.3.2

Beschrijving ....................................................................................................................... 15 Visualisatie ........................................................................................................................ 17

4.5.1 4.5.2 4.5.3 4.5.4 4.5.5

Systeemprincipes.............................................................................................................. 20 Bouwwerkprincipes ........................................................................................................... 20 Conceptprincipes .............................................................................................................. 20 Fenomeenprincipe ............................................................................................................ 20 Realiteitsprincipe............................................................................................................... 21

4.6.1 4.6.2 4.6.3 4.6.4 4.6.5

Analyseprincipes ............................................................................................................... 21 Ontwerpprincipe ................................................................................................................ 21 Realisatieprincipes ............................................................................................................ 22 Beheerprincipes ................................................................................................................ 22 Architectuurprincipes ........................................................................................................ 22

4.7.1 4.7.2 4.7.3 4.7.4 4.7.5

Enterprise principes .......................................................................................................... 25 Bedrijfsprincipes ................................................................................................................ 25 Informatie principes........................................................................................................... 26 Technische principes ........................................................................................................ 26 Security principes.............................................................................................................. 26

ATTRIBUTEN VAN PRINCIPES .................................................................................. 27 5.1 5.2 5.3

6

AANLEIDING .............................................................................................................. 9 DOEL & DOELGROEP ................................................................................................. 9 BEHEER EN DOORONTWIKKELEN VAN DE OPEN STANDAARD ............................................ 9 GEBRUIKSLICENTIE VOOR HET TOEPASSEN VAN DEZE OPEN STANDAARD ........................ 10 DOORONTWIKKELING VAN DEZE OPEN STANDAARD ...................................................... 11 MEER INFORMATIE OVER DEZE OPEN STANDAARD........................................................ 11 OVERZICHT VAN OPEN STANDAARDEN VAN DRAGON1 .................................................. 11

FUNCTIES VAN ATTRIBUTEN ...................................................................................... 27 OVERZICHT VAN ATTRIBUTEN .................................................................................... 28 AFHANKELIJKHEID TUSSEN PRINCIPE-ATTRIBUTEN ....................................................... 36

STAPPENPLAN VOOR HET WERKEN MET PRINCIPES.......................................... 37 6.1 6.2 6.3

STAPPENPLAN 1 - HET ZIEN, FORMULEREN EN DOCUMENTEREN VAN EEN PRINCIPE ......... 37 STAPPENPLAN 2 - HET SELECTEREN VAN EEN PRINCIPE ............................................... 40 STAPPENPLAN 3 - HET GEBRUIKEN OF TOEPASSEN VAN EEN PRINCIPE ........................... 40 D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

2 / 62

1

7

2 3

NORMALISEREN / HERFORMULEREN VAN PRINCIPES ........................................ 41 7.1 7.2

DE HUIDIGE PRAKTIJK ............................................................................................... 41 STAPPENPLAN VOOR HERFORMULEREN VAN UITSPRAKEN NAAR PRINCIPES .................... 42

4

8

5

BIJLAGE A: SJABLOON VOOR HET BESCHRIJVEN VAN HET PRINCIPE .................... 48

6

BIJLAGE B: BEGRIPPENKADER ...................................................................................... 49

7

BIJLAGE C: VOORBEELDEN VAN SOORTEN PRINCIPES ............................................. 58

LITERATUURVERWIJZING ........................................................................................ 47

8

D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

3 / 62

1

1 Documenthistorie

2

1.1 Publicatiehistorie Wanneer

Wat

Wie

Waarom

19 nov

Review versie

Dragon1 Company

Openbare Review

3 4

1.2 Wijzigingenhistorie Wanneer

Wat

Wie

Waarom

23 september 2010

Initiële opzet van het document en afstemming met glossary of terms Afronding v 0.7

Mark Paauwe

Voor initiële review

Mark Paauwe

Afronding v 0.9

Mark Paauwe

Voor 2e review en publicatie Voor openbare review

30 september 2010 10 november 2010 5 6

1.3 Reviewers Wie

Organisatie

Rol

Talitha Paauwe Jan Verwoerd

Paauwe Group Dragon1 Architecture Foundation Dragon1 Architecture Foundation Gebruikersvereniging

Redacteur

Jacques Honkoop Alfred Dijkstra NNtb NNtb 7 8 9 10

Reviewers zijn personen die hun deskundigheid hebben ingezet om deze open standaard op een hoger kwaliteitsniveau te krijgen.

11

1.4 Ambassadeurs Wie

Organisatie

Rol

NNtb NNtb 12 13 14 15 16

Ambassadeurs zijn personen die het gebruik van deze open standaard hun steun geven.


4 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

2 Managementsamenvatting Binnen het enterprise architectuur vakgebied wordt veel waarde gehecht aan het (architectuur)principe als instrument om richting te geven aan het ontwerp van de (toekomstige) onderneming of delen daarvan. Dit document beschrijft hoe vanuit de methode Dragon1 naar principes gekeken wordt en hoe men effectief gebruik kan maken van dit instrument in bijvoorbeeld projecten en bij het maken van ontwerpen van systemen en het realiseren van systemen. Wanneer iemand op een uitspraak het etiket principe plakt, dan geeft hij daarmee richting zichzelf en anderen een lading aan die uitspraak dat deze voor alles, altijd en overal in een bepaalde context geldig is. Hierop kan iedereen die beschikt over deze kennis, namelijk de wijze waarop iets werkt, verder bouwen en vertrouwen. Een principe is daarmee altijd een gehandhaafde werking met een geproduceerd resultaat tot gevolg, voordelig dan wel nadelig. Echter, wanneer iemand op een uitspraak het etiket principe plakt terwijl deze uitspraak eigenlijk niet voor alles, overal en altijd in de context geld, dan komt iemand die bouwt en vertrouwd op het principe in die context heel bedrogen uit. Immers het beloofde resultaat van de werking van het principe zal niet altijd optreden. Dragon1 Open Standaard Architectuurprincipes Dit document is de open standaard van Dragon1 voor architectuurprincipes. In dit document treft u onder andere de volgende onderwerpen aan: • Definitie van het begrip principe • Functie van principes • Syntax en communicatievorm (beschrijven en visualiseren) van principes • Generieke en standaard classificatie en soortindeling voor principes • Attributen van principes • Stappenplan voor het opstellen en formuleren van principes • Stappenplan voor het herformuleren van principes • Belangrijke gerelateerde begrippen of concepten en hun onderlinge relaties (volgt in de volgende versie van het document) • Reviewen van principes (volgt in de volgende versie van het document) Uitwisselbaarheid en herbruikbaarheid Deze open standaard kan door iedereen worden gebruikt voor het op een hoog kwaliteitsniveau werken met principes. U kunt door naar deze standaard te verwijzen anderen duidelijk maken welke achterliggende praktijkgerichte theorie u heeft gebruikt voor het werken met principes in uw architectuur. Met deze standaard is het voor zelfstandig werkende groepen en individuen eenvoudiger om op een gelijke wijze met principes in de architectuur om te gaan. Het vergoot de uitwisselbaarheid, herbruikbaarheid en voorspelbaarheid van de opgestelde en geselecteerde principes in de architectuur. D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

5 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

Definitie en functie van principe Er is een groot verschil tussen het letterlijke begrip principe en het figuurlijke begrip principe. In de spreektaal hanteren we vaak principe als een begrip om hiermee duidelijk te maken wie we zijn en hoe we graag willen overkomen. In principe doe ik altijd ….dit… of uit principe doe ik ….dit ….niet. In principe is veelal een synoniem voor 'normaal gesproken'. Uit principe is veelal een synoniem voor op basis van mijn overtuiging. Voorbeelden van de spreektaal principes zijn: In principe ben ik vanavond, als er niets tussen komt, op tijd thuis. Uit principe doe ik niet mee aan kansspelen. In Dragon1 is een principe letterlijk gedefinieerd als 'de gehandhaafde wijze waarop een entiteit, zoals een systeem, concept of fenomeen, deels of in zijn totaliteit, werkt, gebeurt of plaatsvindt met een bepaald geproduceerd effect of resultaat tot gevolg in een gegeven context'. Een voorbeeld van een principe is: jong geleerd is oud gedaan. Een ander voorbeeld is kennis geeft macht. Weer een ander voorbeeld is optimale inzet van informatie in het businessmodel zorgt voor een hoger concurrerend vermogen van de organisatie. Het (veelal positieve) effect van het principe (de werking) is de reden om het betreffende systeem, concept of fenomeen (dat die werking bevat) ergens voor in te zetten of de werking ervan (deels) te hergebruiken in dezelfde of ander context, zodat het effect tot zijn recht komt in bepaalde situatie. Niet alle principes hebben overigens positieve effecten of een voordelige werking. Het is echter van belang om ook met deze principes (die we ook anti-principes noemen) rekening te houden en hun effect op de onderneming in kaart of beeld te brengen. Een architect kijkt naar verschillende soorten principes, zoals conceptprincipes, om te analyseren of een concept bepaalde prestatie- of kwaliteitsvoordelen oplevert en als onderdeel van het totaalconcept wordt gekozen in het architectuurontwerp omdat het invulling geeft aan de gestelde eisen. Visualiseren van principes Een architect maakt gebruik van principedetailtekeningen om aan bouwers op een juiste manier over te dragen hoe een concept dient te worden ontworpen en gerealiseerd. Een architect maakt gebruik van principetekeningen om aan opdrachtgevers (owner / client) op een duidelijke manier over te dragen hoe bruikbaar of noodzakelijk een concept is in het licht van strategische uitgangspunten en bedrijfsdoelen van de onderneming of uitdagingen en randvoorwaarden betreffende een bouwwerk, project of programma.


6 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

Taalverschillen: uitgangspunt versus principe In de Nederlandse taal en de Engelse taal heeft het begrip principe vaak een verschillende betekenis. Daar waar in het Nederlands vaak uitgangspunt wordt gehanteerd, hanteert men in het Engels daar vaak het begrip ‘principle’ voor of ‘values’. Dit maakt het lastig voor architecten in het Nederlands taalgebied om goed verschil te maken tussen wat er bedoeld wordt aan de hand van labels van begrippen. Een lijst ‘principles’ in een Engels architectuur document, zou in het Nederlands zo maar een lijst met uitgangspunten kunnen zijn. Voorbeelden hiervan zijn: Our principle is that we strive to deliver top quality with our employees for our customers. Doing that, we manage risks well and professionally. Een dergelijk ‘principle’ drukt uit wat een organisatie belangrijk vindt en waar ze aan vast willen houden. Ze gaan er vanuit dat dit waar is, terwijl er vaak toch allerlei momenten en omstandigheden zijn waarin dit niet waar is. Maar een principe is juist is dat nooit weerlegbaar mag zijn. Anders is het geen principe! Volgens Dragon1 is een principe niet iets dat je kunt wensen of willen. Een principe is synoniem voor het mechanisme zoals iets altijd werkt binnen een benoemde context. Een principe is iets geheel anders dan een uitgangspunt, regel of een eis (en. requirement). Een principe is bij gebruik een richtinggevende uitspraak. Het principe zelf is geen richtinggevende uitspraak, maar een uitleg of beschrijving van hoe iets altijd werkt, in elkaar steekt of plaatsvindt. Bijvoorbeeld: als het principe van zwaartekracht geldt, dan gaat alles daar onder gebukt, en moet je daar altijd rekening mee houden. Er is geen ontkomen aan. Dus bij het bouwen van gebouwen op de aarde, moet er altijd met het principe van zwaartekracht rekening worden gehouden. Als we het label principe op een normatieve uitspraak plakken (zoals een uitgangspunt), dan willen we daarmee zeggen dat deze normatieve uitspraak in een bepaalde context, altijd en overal op dezelfde wijze werkt, plaatsvindt of in elkaar steekt, of dat dat zou moeten. Hier zou iemand anders dan voor de volle 100% vanuit moeten kunnen gaan en verder op moeten kunnen bouwen. Alleen wat is het geval: de normatieve uitspraak is niet altijd waar, omdat het geen gehandhaafde werking beschrijft. Normatieve uitspraken voorzien van het label principe levert daarom altijd problemen op. Een voorbeeld van een normatieve uitspraak waar vaak het label principe op staat: ‘ Wij slaan in onze organisatie gegevens altijd eenmalig op’. Deze uitspraak doelt weliswaar op een principe, maar is zelf een uitgangspunt, doel, eis, wens of randvoorwaarde. De uitspraak is namelijk al gauw in bepaalde omstandigheden binnen de context niet waar. Zonder een vorm van handhaving uit drukken in de uitspraak kun je dit namelijk niet hardmaken. De formulering In Dragon1 wordt voor het principe-attribuut shortstatement een voorkeur schrijfwijze aan gedragen ter bevordering van kwaliteit, documentatie en hergebruik van principes. Dit heet de door-formulering. Deze luidt: Door [actieregel] op/in/binnen [context] vanuit [handhavingmechanisme] zorgt [entiteit] ervoor dat [gebruiksregel] zodat [effectregel - 1e resultaat] waarmee [effectregel 2e resultaat] etc… D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

7 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

De soorten principes Principes zijn op verschillende wijzen in te delen. Bijvoorbeeld naar aard of entiteit, naar gebruiksdoel en naar thema of domein. Een indeling van principes naar aard (of soort entiteit) is bijvoorbeeld: • Systeemprincipes • Bouwwerkprincipes • Conceptprincipes • Realiteitsprincipes • Fenomeenprincipes Een indeling naar gebruiksdoel is bijvoorbeeld • Architectuurprincipes • Analyseprincipes • Ontwerpprincipes • Realisatieprincipes • Beheerprincipes Een indeling naar thema is bijvoorbeeld: • Enterprise principes (in de onderneming) • Bedrijfsprincipes (in het bedrijf) • Informatieprincipes (in de informatievoorziening) • Technische principes (in de ICT-infrastructuur) • Security principes (informatiebeveiliging) Let wel: dezelfde principes kun je dus op verschillende wijze indelen! In de praktijk hanteren we combinaties van deze indelingen: AS-IS Bedrijfssysteemontwerp-principes en TO-BE Security-fenomeen-analyseprincipes. Deze principes worden vaak kortweg AS-IS bedrijfsprincipes of TO-BE securityprincipes genoemd. Het is echter in het belang van een succesvolle realisatie van een bouwwerk, systeem of oplossing, om te zien welk type principes daadwerkelijk bedoeld wordt of gehanteerd wordt. Het is ook hier weer schrijftaal versus spreektaal. Deze Dragon1 Open standaard helpt u in het correct en daarmee succesvol formuleren, selecteren en toepassen van principes in de Enterprise Architectuur.


8 / 62

1

3 Inleiding

2

3.1 Aanleiding

3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

Binnen het enterprise architectuur vakgebied wordt veel waarde gehecht aan het (architectuur)principe als instrument om richting te geven aan het ontwerp van de (toekomstige) onderneming. Er vindt echter nog veel discussie plaats over wat een (architectuur)principe nu precies is, welke functie het heeft en op welke wijze het beschreven dient te worden. Ook in de diverse architectuurmethoden die het vakgebied rijk is wordt op verschillende wijzen met dit instrument omgegaan. In de praktijk leidt dit echter tot verwarrende situaties. Binnen veel ondernemingen is de status en functie van het principe ten opzichte van andere ‘proposities’ (zoals eisen, wensen, regels, richtlijnen etc.) onduidelijk en is de wijze waarop principes geformuleerd worden zeer divers. Hierdoor wordt er op een minder efficiënte en minder krachtige wijze omgegaan met het (architectuur)principe. Deze open standaard dient als hulpmiddel om bij het werken onder enterprise architectuur op een krachtigere manier te werken met architectuurprincipes. Dragon1 kent een duidelijke functie toe aan het architectuurprincipe en ook wordt veel aandacht besteed aan de wijze waarop een architectuurprincipe geformuleerd en beschreven dient te worden in Dragon1. De, voor het architectuurvakgebied, vernieuwde definities van principe en van architectuurprincipe heeft als doel principes en architectuurprincipes effectiever te kunnen communiceren, visualiseren en toe te passen. De nieuwe, op bouwkundige architectuur gebaseerde, definitie heeft nu al in de praktijk hierin meer toegevoegde waarde laten zien dan de huidige meer gangbare 'richtinggevende' definitie of 'ontwerpruimte-beperkende'-definitie.

28

3.2 Doel & Doelgroep

29 30 31

De doelgroep van deze open standaard is iedereen die conform Dragon1 principes wil gebruiken in architectuur en ontwerp.

32

3.3 Beheer en doorontwikkelen van de open standaard

33 34 35 36 37 38 39 40 41 42 43

Deze standaard wordt beheerd door de Dragon1 Architecture Foundation. Dit houdt in dat wijzigingsaanvragen (RFC’s) vanuit de Dragon1 User Group door de stichting in behandeling worden genomen. Iedereen die lid is van de gebruikersvereniging kan input leveren via een werkgroep ter verbetering van de open standaard. Op basis van de ervaringen in de praktijk en de open standaard zijn er ook best practices op het gebied van architectuurprincipes beschikbaar. Het Whitepaper Dragon1 Architectuurprincipes en het promotieonderzoek van Mark Paauwe naar architectuurprincipes vormen onder andere de onderliggende theoretische verkenning en praktijkstudie waarop deze open standaard is gebaseerd. D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

9 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

Het beheer van de open standaard door de stichting houdt ook in dat verkeerd of oneigenlijk gebruik van de open standaard wordt gemonitord en zoveel mogelijk wordt voorkomen, en dat inbreuk wordt tegengegaan of gesanctioneerd.

3.4 Gebruikslicentie voor het toepassen van deze open standaard De gebruikslicentie van deze open standaard geeft de volgende rechten en plichten: Artikel 1. Dit document en de inhoud ervan kan door iedereen voor interne nietcommerciële toepassing worden aangewend. Artikel 2. Er is geen licentie of accreditatie betreffende Dragon1 nodig om deze open standaard te mogen toepassen. Het gebruik van deze open standaard is 'free of charge'. Artikel 3. Het is toegestaan om voor het opstellen en formuleren van principes tekst uit dit document over te nemen. Het is toegestaan om informatief, nietcommercieel, te publiceren over deze open standaard in bijvoorbeeld een artikel, whitepaper of onderzoeksrapport. Artikel 4. Het is niet toegestaan deze open standaard aan te passen en deze open standaard aangepast of niet aangepast zich geheel of deels op enigerlei wijze toe te eigenen. Artikel 5. Het is niet toegestaan deze open standaard deels of geheel te (her)gebruiken en/of deels of geheel te veranderen zonder duidelijk naar deze open standaard te verwijzen. Artikel 6. Het doel van deze open standaard is om het niveau van het opstellen en formuleren van principes bij architectuur en ontwerp te verhogen. Hiertoe dient deze open standaard open te blijven. Artikel 7. Het is niet toegestaan deze open standaard onderdeel te maken van een andere methode of aanpak of anderszins of op enigerlei andere wijze deze open standaard zich geheel of gedeeltelijk (onder een andere naam) en/of deel gewijzigd toe te eigenen. Artikel 8. Het incorrecte of oneigenlijk gebruik van deze open standaard dient te worden gemeld bij de stichting. Het oogluikend toestaan of niet melden van misstanden wordt gezien als het medeplegen van een inbreuk op de open standaard, zulks ter beoordeling van de stichting. Artikel 9. De Dragon1 Architecture Foundation is nooit verantwoordelijk te houden voor eventuele druk- of zetfouten en/of gevolgschade door het (verkeerd) gebruik van deze open standaard.


10 / 62

1 2 3 4 5 6 7 8 9 10 11

Artikel 10. Het is niet toegestaan deze open standaard op te nemen in een workshop, training of opleiding of iets dergelijks zonder schriftelijke toestemming van de stichting. Voor het lesgeven in de Dragon1 open standaard is een accreditatie of licentie vereist. Artikel 11. Voor het aanbieden en of uitvoeren van consultancy volgens of met Dragon1 is een accreditatie of licentie vereist. Artikel 12. Voor het gebruiken van deze open standaard in tools zoals software, is vooraf schriftelijk toestemming nodig van de stichting.

12

3.5 Doorontwikkeling van deze open standaard

13 14 15 16

De definities, indelingen, classificaties en voorbeelden van principes in deze open standaard worden jaarlijks herzien en indien nodig bijgewerkt aan de laatste trends en ontwikkelingen.

17

3.6 Meer informatie over deze open standaard

18 19 20 21 22

Indien u meer informatie wilt over de open standaard kunt u hiervoor contact opnemen met de stichting (betreffende het gebruik en de toepassing van de open standaard) of met Paauwe Research (betreffende de inhoud van de open standaard of het werken met architectuurprincipes).

23

3.7 Overzicht van open standaarden van Dragon1

24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

De volgende Dragon1 Open Standaarden zijn momenteel (of komen op termijn) beschikbaar: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19.

Visual Language Standard Architecture Visualization Standard Architecture Enterprise Design Standard Architecture Quality Standard Architecture Stakeholder Management Standard Architecture Communication Standard Architecture Implementation Standard Architecture Service Management Standard Architecture Start-Up & Initiation Standard Architecture Application Standard Architecture Framework Standard Architecture Documentation Standard Architecture Design Principles Standard Architecture Maturity Standard Architecture Enterprise Innovation Standard Architecture Requirements Management Standard Architecture Rules for Architects Standard Architecture Solution Design Standard Architecture in Projects Standard D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

11 / 62

1 2


12 / 62

1

4 Het concept ‘principe’

2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

In Dragon1 is het herkennen en onderkennen van principes die in entiteiten aanwezig zijn belangrijk voor de architect. Hoe beter hij hier toe in staat is, des te hoger van kwaliteit zijn de bouwwerken (complexe systemen) die hij onder architectuur ontwerpt en laat realiseren.

32

4.1 Definitie

33 34

De Dragon1 definitie voor principe is:

Principes beschrijven of geven uitleg aan de wijze waarop iets, een entiteit, werkt. In het engels wordt wel eens gezegd: ‘Principles are about the way things work’. Omdat een entiteit als het ware het huis is van een principe, gaan we eerst even verder in op het begrip entiteit. Een entiteit is iets dat bestaat, wordt herkend of wordt onderkend. Er zijn verschillende soorten entiteiten te onderkennen, die voor een architect van belang zijn. Dit zijn soorten entiteiten zoals systemen, concepten en fenomenen. Een systeem is een samenwerkend geheel van entiteiten, bijvoorbeeld een informatiesysteem. Een concept is een conceptueel systeem zoals een aanpak, werkwijze of patroon. Bijvoorbeeld het selfservice-concept. Een fenomeen is een gebeurtenis gedreven systeem zoals storm, onweer en de loyale klant. Door de principes te zien die in soorten entiteiten zoals systemen, fenomenen en concepten schuilgaan, kan de architect juiste keuzes maken. Bijvoorbeeld de juiste keuzes voor een aanpassing aan bestaande systemen in de organisatie. Het onderkennen en volgen van de juiste fenomenen in de klantomgeving. Het selecteren en toepassen van de juiste concepten in een ontwerp waarmee bouwwerk wordt gerealiseerd. Omdat er verschillende soorten entiteiten zijn, zijn er ook verschillende soorten principes te onderkennen. Dit zijn principes, zoals systeemprincipes, fenomeenprincipes, conceptprincipes, architectuurprincipes en ontwerpprincipes die de architect dient te leren herkennen.

Een principe is de gehandhaafde wijze waarop een entiteit werkt, in elkaar of plaatsvindt met een bepaald geproduceerd effect of resultaat tot gevolg in een gegeven context. 35 36 37 38 39 40

Een principe beschrijft de gehandhaafde werking van de gehele entiteit of van een gedeelte van de entiteit. Een principe beschrijft één of meer oorzaak-gevolg relaties (door … [dit] gebeurt … [dat]). Een principe dat de gehele werking van een entiteit beschrijft noemt Dragon1 het 'first principle'. Een architect dient zoveel mogelijk op zoek te gaan naar het 'first principle', omdat hiermee de essentie van D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

13 / 62

1 2 3

de werking van de entiteit en het geproduceerde resultaat door die werking snel is te begrijpen en is over te brengen (te communiceren).

4

4.2 Functie

5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

Een te ontwerpen en te realiseren bouwwerk moet uiteindelijk de voordelige werking van (bedrijfskundige en informatiekundige) concepten gaan bevatten. Samen vormen de concepten namelijk die zijn gebruikt in een bouwwerk de architectuur van het bouwwerk. Architectuur is het samenhangend geheel van concepten dat is toegepast op een bouwwerk. Dus de architect moet heel goed in de gaten hebben wat de werking, de gevolgen of de impact is van het resultaat dat door de concepten wordt geproduceerd. Deze werking en het geproduceerde resultaat van een entiteit, zoals een concept wordt in Dragon1 gezien als een principe. Architecten hebben als taak om de juiste concepten te selecteren die vanwege hun werking bepaalde voordelen opleveren die daarmee passen bij het invulling geven aan de gestelde eisen van de opdrachtgever. Architecten hebben ook als taak door de juiste implementatie van de concepten, de voordelen van de concepten te laten gelden in het bouwwerk dat ze ontwerpen. Daarom moet de architect dus goed weten wat de principes (de werking en voordelen) zijn van de concepten die ze gebruiken in hun architectuur. Het is belangrijk dat de architecten weten waar een goede werking van een concept van afhangt. Namelijk van het handhavingmechanisme en de goede samenwerking van elementen, componenten en objecten in het concept. De samenwerking van deze aspecten komen tot uitdrukking in een principe. Als een concept namelijk niet goed of onvolledig wordt geïmplementeerd, doet dat afbreuk aan het produceren van de voordelen die door het principe van het concept worden beloofd. Vier belangrijke functies van principes onderscheiden we hier voor de manager, architect en de architectuur: 1. Met principes zijn managers en architecten is staat de voordelige werking van oplossingsrichtingen (of concepten) helder en objectief inzichtelijk te maken en daardoor beter het concept te kunnen matchen met gestelde eisen, om vervolgens een concept te kiezen als onderdeel voor het architectuurontwerp van een bouwwerk. 2. Met principes zijn managers en architecten in staat te begrijpen waarom bepaalde bouwwerken in meer of mindere mate goed functioneren en door het principe van een systeem goed inzichtelijk te maken, zijn ze beter in staat zijn het principe dat elders is gebruikt succesvol als referentie in een nieuw bouwwerk toe te passen. 3. Met principes zijn managers en architecten beter in staat correct het verschil te analyseren tussen de theoretische werking van een oplossingsrichting (het concept) en de daadwerkelijke praktijktoepassing D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

14 / 62

1 2 3 4 5 6 7 8 9

van een oplossing (die veel minder dan verwacht presteert) in een bouwwerk (het systeem). Met behulp van principes is een oplossing effectief en meer rendabel in te zetten. 4. Met principes zijn managers en architecten beter in staat te begrijpen welke fenomenen (machten en krachten) in de omgeving van het bouwwerk aanwezig zijn waar sowieso qua werking niet onderuit kan worden gekomen of waar zonder pardon rekening mee gehouden moet worden.

4.3 Vorm

10 11 12 13

In deze paragraaf komt naar voren welke vormen van formulering er zijn. Een principe kan zowel op tekstuele wijze worden verwoord als via een visualisatie. Ook de mate van detail waarmee het principe beschreven of gevisualiseerd wordt kan verschillen.

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

4.3.1 Beschrijving De kern van een principe wordt geformuleerd in het Short Statement. De eerder gegeven syntax structuur hiervoor is richtinggevend en dient in de praktijk daar waar nodig of mogelijk te worden aangescherpt. Naast het Short Statement kent de beschrijving van het principe nog tal van andere attributen. Deze worden in dit document nog nader toegelicht. Het Short Statement bestaat grofweg uit een actieregel (inclusief handhavingsmechanisme), effect-regel en gebruiksregel. Het statement van een principe bestaat dus uit de volgende delen: • • • • • •

Deel 1 - actieregel Deel 1.1 - handhavingmechanisme Deel 2 - effectregel Deel 3 - gebruiksregel Deel 5 - context Deel 6 - houder

In zijn totaliteit beschrijft het Short Statement dus een werkingsmechanisme. In Dragon1 wordt voor het principe-attribuut shortstatement een voorkeur schrijfwijze aan gedragen te bevordering van kwaliteit, documentatie en hergebruik van principes. Dit heet de door-formulering. Deze luidt: Door [actieregel] op/in/binnen [context] vanuit [handhavingmechanisme] zorgt [entiteit] ervoor dat [gebruiksregel] zodat [effectregel - 1e resultaat] waarmee [effectregel - 2e resultaat] etc… De delen van een principe worden nu toegelicht aan de hand van een voorbeeld principe.


15 / 62

1 Het voorbeeld van een vraagprincipe geformuleerd conform de Dragon1 syntax: Door als dienstenaanbieder, in geval van klantcontact op de markt, altijd eerst vragen te stellen aan klanten, vanuit streng toezicht op het klantcontact en de gemaakte afspraken, zorg je er als aanbieder voor dat je beter weet wat er speelt bij de klant zodat je je handelen of aanbod beter kunt afstemmen op de situatie waarmee je handelen en aanbod meer positieve gevolgen heeft of beter aansluit bij de vraag. Dit in tegenstelling tot gelijk te gaan handelen in geval van een bepaalde vraag, omdat dat het aanbod en handelen ergens anders ook werkte. 2 3 4 5 6 7 8

4.3.1.1 Actieregel De actieregel beschrijft hoe een bepaald effect of gevolg wordt bereikt. Het beschrijft een bepaalde oplossing, aanpak of werkwijze dat iets anders in gang zet. In een oorzaak-gevolg relatie beschrijft dit gedeelte dus de ‘oorzaak’. Bij het voorbeeld van het vraagprincipe is vragen stellen de actieregel.

9 10 11 12 13 14 15 16

4.3.1.2 Effectregel De effectregel beschrijft welk gevolg een oorzaak uit de actieregel heeft. De effectregel beschrijft welke vereiste of gewenste situatie bereikt wordt of welk probleem wordt opgelost.

17 18 19 20 21 22 23

4.3.1.3 Gebruiksregel De gebruiksregel beschrijft waar het voordelige effect voor wordt gebruikt of waar het nadelige effect zijn impact op heeft. Wat wordt er mogelijk of onmogelijk gemaakt door de werking beschreven in de actieregel en effectregel.

24 25 26 27 28 29 30

je weet beter wat er speelt is de eerste effectregel in het vraagprincipe. je kun je handelen beter afstemmen op de situatie is de tweede effectregel.

je handelen heeft meer positieve gevolgen is de gebruiksregel in het vraagprincipe. 4.3.1.4 Context De context is het afgebakende gebied of domein waarbinnen de werking van het principe altijd geldig is. De context is impliciet, waarmee wordt beweert in het vraagprincipe, dat dit principe overal en altijd op de wereld en voor de mensheid werkt voor elke dienstenaanbieder en bij elke klant.


16 / 62

1 2 3 4 5 6 7 8 9

4.3.1.5 Handhavingmechanisme Het handhavingmechanisme is het mechanisme dat ervoor zorgt dat altijd en overal binnen een context de werking van de actieregel geldig blijft. Het handhavingmechanisme werkt zo goed (met een waarschijnlijkheid van meer dan 0.9) dat je er vanuit mag gaan dat het principe altijd en overal in de context werkt, onder normale omstandigheden. Het handhavingmechanisme in dit principe zijn de afspraken en toezicht omtent klantcontact.

10 11 12 13 14 15 16 17 18 19 20 21

4.3.1.6 Houder De houder van het principe is de entiteit die zorgt draagt voor het handhavingmechanisme en die de actie regel uitvoert.

22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

4.3.2 Visualisatie

Een principe kan nooit los worden gezien van de entiteit waar ze de werking van toelicht via een beschrijving of visualisatie. De houder is de entiteit die het principe bezit. Als de entiteit niet benoemd kan worden, wordt dit deel ook wel geformuleerd als ‘wordt ervoor gezorgd dat’. Dit is vaak bij fenomenen en concepten het geval. De houder van dit principe is bij toepassing vaak een organisatie.

In Dragon1 visualiseren we principes zoveel en zo vaak als mogelijk is. Dit om de werking voor ons te zien plaatsvinden. Het visualiseren levert meer inzicht en overzicht op dan alleen het lezen van een tekstuele beschrijving van het principe. Met een visualisatie kan een complexe beschrijving van een principe sneller worden doorzien en eventueel meer kloppend worden gemaakt. Er zijn vier soorten visualisaties om principes zichtbaar mee te maken: Schetsen, tekeningen, diagrammen en fotografische beelden. Het visualiseren van een principe gebeurt veelal door een schets (conceptschets) te maken van het systeem, concept of fenomeen waar het principe de werking van beschrijft. En daarnaast van het principe in meer detail een tekening te maken (principetekening). En passent, worden ook de concepten en haar elementen en componenten, bij het visualiseren van een principe eenduidig gedefinieerd voor een sneller en beter beeld en begrip. Een schets is in Dragon1 een informele visualisatie die gedachten structureert en visies concretiseert. Een tekening is een informele visuele toelichting van een stuk tekst. De volgende items komen vaak terug in een visualisatie van een principe: • De elementen uit het concept • De regels die van toepassing zijn op de elementen • De kwaliteitsvoordelen van kwaliteitsaspecten naar aanleiding van het gedrag van de elementen en regels. • De mechanismen en werkingcycli visualiseren D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

17 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

• •

Haallijnen die toelichten wat de operationele functie, constructieve functie en decoratieve functie is van elementen Situatie, context, ruimten en locaties

Het verdient aanbeveling in de beschrijving van een principe de zelfstandige naamwoorden en werkwoorden als entiteiten en hun relaties te gebruiken als basis voor het maken van een entiteit relatie model, dat daarna informeel is te visualiseren. Gebruik archetypen (oerbeelden) voor symbolen bij de entiteiten, dit zorgt voor een snelle herkenbaarheid van wat je als architect bedoeld met een symbool. Voor meer uitleg over het visualiseren van principes kunt u de Dragon1 Open Standard Visual Language raadplegen. Bij deze open standaard is ook een powerpointpresentatie met voorbeeldvisualisaties van het vraagprincipe

17

4.4 Soorten principes

18 19 20 21 22 23 24 25

De architect kijkt in de regel naar vier soorten principes om controle te hebben over de kwaliteit van het bouwwerk of bouwsel dat hij ontwerpt. Het betreffen de principes in concepten, de principes in het te ontwerpen systeem en de principes in de huidige systemen. Ook kijkt de architect naar de principes in andere gebieden om hiervan te leren en om ze te kunnen hergebruiken. Dragon1 onderkent deze verschillende soorten principes, zodat de architect zeer doelgericht en efficiënt een bepaald soort principe kan inzetten.


18 / 62

1 2 3 4 5 6 7 8

Figuur 2: Principesoorten schema Figuur 2 toont vele voorbeelden van principes die van toepassing zijn op de belangrijke entiteiten binnen een onderneming. In deze afbeelding staan meer principes dan in dit hoofdstuk worden genoemd. Het waarom en functie van deze soorten principes kunnen eenvoudig worden afgeleid van de hierna behandelde soorten principes.


19 / 62

1

4.5 Principes naar soort entiteit

2 3 4 5 6 7

4.5.1 Systeemprincipes Wat is een systeemprincipe? Waarom onderkennen deze soort, wat is de functie?

8 9 10 11 12 13

4.5.2 Bouwwerkprincipes

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

4.5.3 Conceptprincipes

Wat is een bouwwerkprincipe? Waarom onderkennen deze soort, wat is de functie?

Wat is een conceptprincipe? Een conceptprincipe is de uitleg of de beschrijving van de gehandhaafde werking van een concept met een bepaald geproduceerd resultaat tot gevolg. Een conceptprincipe wordt ook wel het werkingsprincipe genoemd van een concept. Waarom onderkennen deze soort, wat is de functie? De reden dat naar het principe (de werking) van een concept gekeken wordt, is om het concept dan met onderbouwing te kunnen selecteren als onderdeel van het totaalconcept in het architectuurontwerp. De architect selecteert doorgaans een concept omdat het conceptprincipe dusdanige resultaten produceert die matchen met de gestelde eisen door opdrachtgever en belanghebbenden. De officiële definitie van conceptprincipe in Dragon1 is: Een conceptprincipe is een principe dat aangeeft op welke gehandhaafde wijze een concept in elkaar, werkt of dat iets gebeurt in het concept, waarbij er altijd een bepaald resultaat wordt geproduceerd of dat er een bepaald effect is.

30 31 32 33 34 35 36 37

Voorbeeld van een conceptprincipe

4.5.4 Fenomeenprincipe Waarom onderkennen deze soort, wat is de functie?


20 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

4.5.5 Realiteitsprincipe Wat is een realiteitsprincipe? Realiteitsprincipes zeggen wat geldt betreffende de werking in het gerealiseerde systeem. Bij een realiteitsprincipe moet de handhaving expliciet worden geregeld om het principe te laten gelden. Dit in tegenstelling tot ontwerpprincipes. Ontwerpprincipes zeggen wat geldt in de context van een te ontwerpen systeem. Bij ontwerpprincipes wordt de handhaving al afgedwongen in de context van het te ontwerpen systeem. Waarom onderkennen deze soort, wat is de functie? De realiteitsprincipes zeggen hoe de concepten in de onderneming zich nu gedragen. Hiermee kan de architect fundamentele weeffouten opsporen en ze voor eens en voor altijd oplossen. Een architect heeft vaak te maken met een wirwar van realiteitsprincipes die een ongewenste situatie in stand houden. Goed zicht hierop maakt het oplossen van het ontwerpvraagstuk velen malen makkelijker. Het is voor een architect van groot belang om te weten wat de huidige situatie is in een onderneming betreffende principes. Zeker als een architect een onderneming af wil helpen van hardnekkige verkeerde principes. De architect moet daarom precies weten welke principes gelden, wat en wie principes handhaaft, uit welke elementen ze bestaan en waarom het effect of gevolg van deze principes niet bijdraagt aan het realiseren van de strategie. De officiële definitie van realiteitsprincipe in Dragon1 is: Een realiteitsprincipe is een principe dat zegt wat de huidige gehandhaafde wijze van werken is van een (deel van een) gerealiseerd systeem. Een realiteitsprincipe geldt in de huidige situatie.

27 28 29

Voorbeeld van een realiteitsprincipe

30

4.6 Principes naar gebruiksdoel

31 32 33 34 35 36

4.6.1 Analyseprincipes

37 38

4.6.2 Ontwerpprincipe

Wat is een analyseprincipe? Waarom onderkennen deze soort, wat is de functie? Voorbeeld van een analyseprincipe


21 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

De architect maakt architectuurontwerpen van bouwwerken. Om een hoge kwaliteit van het bouwwerk te realiseren, maakt een architect gebruik van principes bij het ontwerpen. Deze principes noemt Dragon1 ontwerpprincipes. Een architect dient ontwerpprincipes te kiezen die helpen de kwaliteitseisen, strategische uitgangspunten en randvoorwaarden te realiseren of eraan tegemoet te komen van het beoogde bouwwerk. Hiervoor dienen wel de missie, visie, identiteit, cultuur en voorkeuren van de opdrachtgever, eigenaar of klant in de juiste eisen te zijn vertaald. Principes in fenomenen, concepten en bestaande systemen staan model voor ontwerpprincipes. Voor elk onderkende architectuur zijn vele ontwerpprincipes mogelijk. De architecten dienen ontwerpprincipes zo weinig mogelijk zelf te bedenken. Ontwerpprincipes dienen zoveel mogelijk uit de literatuur of als best practice uit de praktijk worden gehaald. Dit geeft kennis, zekerheid en voorspelbaarheid bij toepassing van de ontwerpprincipes. Ze hebben zich immers al bewezen. De officiële definitie van ontwerpprincipe in Dragon1 is: Een ontwerpprincipe is een principe dat geldig is in de omgeving van het bouwwerk en daardoor invloed heeft op het bouwwerk, en waar door benoeming bewust door de architect bij het ontwerpen en realiseren van het bouwwerk rekening mee wordt gehouden.

20 21 22 23 24 25 26

4.6.3 Realisatieprincipes

27 28 29 30 31 32 33 34

4.6.4 Beheerprincipes

35 36 37 38

4.6.5 Architectuurprincipes

Wat is een realisatieprincipe? Waarom onderkennen deze soort, wat is de functie? Voorbeeld van een realisatieprincipe

Wat is een beheerprincipe? Waarom onderkennen deze soort, wat is de functie? Voorbeeld van een beheerprincipe

Deze categorie van principe is de allerbelangrijkste categorie van principes. Je geeft namelijk hiermee aan waar in essentie een bouwwerk op stoelt. Gaat een van deze architectuurprincipes onderuit, valt het hele bouwwerk in duigen.


22 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Door architectuurprincipes te onderkennen kan de architect conceptprincipes en ontwerpprincipes uit het ene bouwwerk of uit een bepaald vakgebied ontdoen van de context, zodat de principes in een ander bouwwerk of vakgebied zijn te hergebruiken. Zo kan een architect bijvoorbeeld aan elk strategisch uitgangspunt van een onderneming verschillende architectuurprincipes koppelen. Op deze manier zorgt de architect ervoor dat de strategie de basis vormt voor de architectuur in alle haarvaten van de onderneming. Een voorbeeld van een architectuurprincipe is 'informatie leidt tot kennis, en kennis leidt tot macht'. Dit principe geldt eigenlijk overal. Dit geldt bij mensen, in softwaresystemen en in ondernemingen. Het principe zegt dat door over meer informatie dan anderen te beschikken betreffende een onderwerp, men betere beslissingen kan nemen aangaande het onderwerp. En hoe beter men beslissingen kan nemen aangaande een onderwerp hoe meer verantwoordelijkheid iemand zal krijgen. Architecten gebruiken architectuurprincipes voornamelijk om ontwerpprincipes te groeperen en te clusteren op een hoger abstractieniveau. De officiële definitie van architectuurprincipe in Dragon1 is: Een architectuurprincipe is een van context ontdaan conceptprincipe of ontwerpprincipe dat overal en altijd bij alles in een systeem kan gelden. Een architectuurprincipe is een universeel principe dat holistisch is toegepast in de onderneming en daarom integraal een uitspraak doet over de ‘bouwwijze’ van de onderneming.

20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43

Stel dat de architectuur van de voorbeeldonderneming BetereZorg, dus de enterprise architectuur van BetereZorg, onder andere de volgende concepten bevat: 1. Klantgericht werken (met oa. klant als deelconcept) 2. Productgericht werken (met oa. product deelconcept) 3. Dienstgericht werken (etc..) 4. Procesmatig werken 5. Corporate Governance 6. Zaakgericht werken 7. Projectmatig werken 8. Domtica 9. Zelfstandig wonen 10. E-zorg 11. Thuishulp 12. Thuiszorg 13. Thuiswonerdossier beheer 14. Begeleid wonen 15. Declaraties 16. Zorgmeldkamer 17. Dag-en-nacht-begeleiding 18. Telecommunicatie 19. Internet en intranet en extranet D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

23 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.

Inkoop en Assemblage Locatie onafhankelijk werken Systeemonafhankelijk Integraal Klantbeeld Verkoop en Marketing Platform onafhankelijke informatieuitwisseling Cloud Computing Risicobeheer Zorgdienstverlening Portfolio Management Virtualisatie eProcurement Webbased ERP Enterprise Portals CRM Self Service IT Service Management Client Server Computing Server Based Computing IP Networking Officegerichte informatievoorziening Service oriented applicaties

Deze concepten werken allemaal verschillend en hebben daarom ook verschillende principes. Echter zijn er wel leidende principes er uit te halen. Niet elke concept is namelijk is belangrijk of krijgt voorrang. Ook zijn er principes die geheel of gedeeltelijk of in generieke zin in meer dan een concept voorkomen. Deze principes zouden we dan de enterprise architectuurprincipes kunnen noemen van deze onderneming. Deze principes komen namelijk overal in het bouwwerk, de onderneming, voor. Ook kunnen we alle principes van alle concepten die onderdeel zijn van de architectuur architectuurprincipes noemen, alleen krijgen we dan al gauw een overload van honderden of duizenden principes, terwijl de belangrijkste architectuurprincipes onderbelicht blijven. Bij bijvoorbeeld ondernemingsbouwwerken zoals gemeenten, ministeries, banken en verzekeraars zijn er zo generieke architectuurprincipes te onderkennen die bij bepaalde soort gemeenten, ministeries, banken en verzekeraar vaak voorkomen. Door op zoek te gaan naar de deelconcepten in de genoemde concepten of door de concepten generieker te maken (van welke soort is dit concept?) komen we achter de architectuurprincipes. Zo zien we bij BetereZorg verschillende concepten die zich op een bepaalde soort werken richten. Deze soorten werk-concepten rusten op het generieke concept werken. Een voorbeeld van de pure enterprise architectuurprincipes bij bovengenoemde enterprise architectuur van BetereZorg zou dan kunnen zijn (we geven hier de namen van de principes, gebaseerd op het concept waar ze de werking van beschrijven): 1. Het principe van zorgverlening 2. Het principe van handel drijven 3. Het principe van werken D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

24 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

4. Het principe van uitbesteden 5. Het principe informatisering 6. Het principe van automatisering Al deze architectuurprincipes komen per stuk in meer dan 1 concept terug. Het hangt echter van de kennis en ervaring van de architect af welke architectuurprincipe hij kent of herkent in de architectuur van een bouwwerk. De gegeven voorbeeld lijst is niet limitatief en slechts een voorbeeld. Het lijstje met zes architectuurprincipe is wel herkenbaar. De onderneming van BetereZorg leunt op de concepten zoals zorgverlening, werken, informatisering en automatisering. Ze zijn verankerd en komen overal in terug en naar voren. Alles en iedereen heeft wetenschap of gaat uit van de aanwezigheid van deze concept: er moet gewerkt (kunnen) worden, er daarom moet er geïnformatiseerd (kunnen) worden en daarom moet er geautomatiseerd (kunnen) worden. Het interessante is hier ook om te zien dat met een lijst van minder dan 100 architectuurprincipes de gehanteerde fundamenten (bedrijfskundige en informatiekundige concepten) al veel onderneming vergelijkbaar zijn te beschrijven. Unieke architectuurprincipes komen wat dat betreft nog niet vaak voor. Ondernemingen zonder klanten, diensten, kantoor, werk, communicatiemiddelen, medewerkers of werkplekken komen bijna niet voor bijvoorbeeld.

24

4.7 Principes op thema of domein

25 26 27

4.7.1 Enterprise principes

28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

4.7.2 Bedrijfsprincipes Bedrijfsprincipes betekenen in Dragon1 de wijze waarop bedrijfskundige concepten werken. Als bepaalde bedrijfskundige concepten zijn gekozen voor een onderneming, dan beschrijven de principes van deze bedrijfskundige concepten (de bedrijfsprincipes) de wijze waarop de business van een onderneming werkt. Bedrijfsprincipe, of het Engelse ‘Business principle’ is vaak een term dat synoniem gebruikt wordt voor strategisch bedrijfsuitgangspunt. Het is vaak onderdeel van imagebuilding van een organisatie op websites. ‘Business principles’ beschrijven vaak de wijze waarop ondernemingen graag willen overkomen of presenteren in de wereld. Strategische bedrijfsuitgangspunten zijn een hoger doel, een streven naar een bepaald toestand en een uiting van bepaalde cultuur, identiteit, operating model, missie, visie en filosofie. Maar vaak wordt het niet letterlijk meetbaar gerealiseerd. ‘Business principles’ moeten een gevoel overbrengen. Dragon1 beveelt het aan om bedrijfsprincipes strikt te gebruiken in hun betekenis.


25 / 62

1 2 3 4

4.7.3 Informatie principes

5 6 7 8

4.7.4 Technische principes

9 10 11 12

4.7.5 Security principes


26 / 62

1

5 Attributen van principes

2 3 4 5 6 7

De beschrijving van een principe kent diverse attributen. De attributen hebben verschillende soorten functies die ervoor zorgen dat het principe eenvoudiger is te begrijpen en vollediger is te formuleren. Een attribuut kan overigens meerdere functies kennen. In dit hoofdstuk wordt een overzicht gegeven van de attributen van een principe.

8

5.1 Functies van attributen Functie soort

Omschrijving

Communicatie

Attributen die behoren tot de functiesoort Communicatie dienen het communicatieve aspect van het principe te bevorderen.

Motivatie

Attributen die behoren tot de functiesoort Motivatie bevatten informatie waarom men het principe wil toepassen.

Bedreiging

Attributen die behoren tot de functiesoort Bedreiging beschrijven de valkuilen, risico's, bedreigingen etc. die het willen toepassen of het succesvol toepassen van een principe in de weg kunnen staan.

Werking

Attributen die behoren tot de functiesoort Werking beschrijven het werkingsmechanisme van het principe en wat er gedaan dient te worden om het principe te laten werken.

Handhaving

Attributen die behoren tot de functiesoort Handhaving beschrijven de maatregelen die genomen dienen te worden om de bedreigingen te minimaliseren en het succesvol toepassen van een principe mogelijk maken.

Context

Attributen die behoren tot de functiesoort Context dragen bij aan het afbakenen van de context waarop het principe betrekking heeft en de mate van detail die de beschrijving van het principe heeft.

Verwijzing

Attributen die behoren tot de functiesoort Verwijzing bevatten achtergrond- informatie, verwijzingen en referenties of gaan specifieker in op bepaalde aspecten die eerder zijn beschreven in andere attributen van het principe.


27 / 62

Attributen die behoren tot de functiesoort Beheer bevatten informatie die noodzakelijk is voor het beheer en onderhoud van het principe.

Beheer

1 2

5.2 Overzicht van attributen Nr.

Naam

Omschrijving

Functie

1

Exploitatie en veranderdoelen

Welke hoger liggende doelen en uitgangspunten liggen ten grondslag aan de keuze van het concept en het opstellen van het principe?

Motivatie

Door invulling te geven aan dit attribuut wordt de relatie tussen het principe en de hoger liggende doelen van het bouwwerk (lees: de onderneming) vastgelegd waardoor het belang van het hanteren van het principe en de keuze hiervoor onderstreept wordt. Benoem niet alleen deze doelen en uitgangspunten, maar beschrijf ook op een heldere wijze de relatie met het principe. Indien deze strategische uitgangspunten of doelen niet voorhanden zijn kunnen hier ook algemene kerndoelen beschreven worden zoals kostenreductie, verlagen complexiteit, snelle service etc. 2

Short Statement

De formulering van het short statement (de korte omschrijving van een principe) komt nogal nauw.

Werking / Communicatie

Omdat een principe een waarheid betreft, zijn woorden zoals mogen, willen, kunnen, zouden en moeten niet gewenst in deze omschrijving. De formulering van een principe dient stellend te zijn, maar ook een werking te beschrijven. De formulering dient uiteindelijk altijd een oorzaak-gevolg relatie te beschrijven, maar dient minimaal een D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

28 / 62

volledige entiteitenrelatie te beschrijven. De omschrijving van een principe gaat in op het mechanisme of de werking van een concept, systeem, fenomeen of stijl. De omschrijving van een principe moet zoveel mogelijk S.M.A.R.T. zijn. Het short statement beschrijft de kern van het principe en vormt tevens de basis van het principe. Dit statement dient in een later stadium nog te worden aangepast / bijgewerkt om overeen te komen met de inhoudelijke informatie die is toegekend aan de overige attributen. Het short statement kent zes generieke delen: • Deel 1 - actieregel: Beschrijft hoe het gewenste resultaat wordt bereikt. Het beschrijft een bepaald oplossing, aanpak of werkwijze. • Deel 1.1 - handhavingmechanisme: Het mechanisme dat ervoor zorgt dat altijd en overal binnen een context de werking van de entiteit geldig blijft. • Deel 2 - effectregel: Beschrijft welk resultaat bereikt dient te worden of gewenste situatie bereikt dient te worden of probleem die opgelost dient te worden. • Deel 3 - gebruiksregel: Beschrijft waarom men het resultaat wil bereiken (wat wordt hierdoor mogelijk of onmogelijk gemaakt. • Deel 5 - context: Het gebied waarbinnen het principe geldig is. • Deel 6 - houder: De entiteit die het principe bezit. Als de entiteit niet benoemd kan worden, wordt dit deel ook wel geformuleerd als ‘wordt ervoor gezorgd dat’. Dit is vaak bij fenomenen en concept het geval. In zijn totaliteit beschrijft het Short Statement dus een werkingsmechanisme. In Dragon1 wordt voor het principe-attribuut shortstatement een voorkeur schrijfwijze D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

29 / 62

aan gedragen te bevordering van kwaliteit, documentatie en hergebruik van principes. Dit heet de door-formulering. Deze luidt: Door [actieregel] vanuit [handhavingmechanisme] zorgt [houder] ervoor dat [gebruiksregel] zodat [effectregel - 1e resultaat] waarmee [effectregel - 2e resultaat] etc… 3

Rationale

De rationale dient te onderbouwen waarom een principe werkt zoals het werkt. Er dient ook uitgelegd te worden waarom dit principe in de gegeven context zal werken.

Motivatie

Zeg wat de achterliggende systemen, concepten en fenomenen zijn van het principe. Hierin ligt ook vaak en rationale besloten. 4

Kwaliteitseisen

De (kwaliteit)eisen die worden gesteld door belanghebbenden aan een bouwwerk (onderneming, systeem of oplossing) vormen de reden dat met een principe rekening gehouden moet worden of dat een principe gehanteerd dient te worden. Het is van belang om aan te geven op welke kwaliteitsaspecten van het bouwwerk het principe een positieve en / of negatieve invloed heeft.

Motivatie

Per soort bouwwerk zijn verschillende kwaliteitsstandaarden beschikbaar om hier invulling aan te geven. Indien het bouwwerk bijvoorbeeld een softwareapplicatie is, dan kan de ISO 9126 standaard hiervoor gebruikt worden: Functionality (Suitability, Accurateness, Interoperability, Compliance, Security) Reliability (Maturity, Fault tolerance, Recoverability) Usability (Understandability, Learnability, Operability) Efficiency (Time behavior, Resource behavior) Maintainability (Analyzability, Changeability, Stability, Testability) Portability (Adaptability, Installability, Conformance, Replaceability) D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

30 / 62

5

Klasse

Wat is de kernstructuur van de werking van het principe? Is het een kringgedrag principe? Is het een taak/volgorde keten principe Is het een actie-reactie keten principe?

Context

6

Soort principe

Geef aan wat voor soort principe het is. Hiervoor kan de indeling gebruik worden die eerder in dit document beschreven is.

Context

Indien binnen de onderneming andere soorten principes of andere benamingen worden gebruikt kunnen deze worden gebruikt als classificatiemiddel. 7

Soort domein, systeem, functie of proces

Is het principe dat geldig is binnen inkoop, verkoop, marketingcommunicatie, productie, financiën, ICT (IV, ICT-Infra)?

Context

Is het een principe dat geldig is binnen de consumenten-markt, back office, een winkelformule of een assortiment? Hanteer hier begrippen die binnen de onderneming onderkend worden zodat men ‘feeling’ krijgt en begrijpt waar dit principe betrekking op heeft. 8

Deelarchitectuur

In welke deelarchitecturen is het principe van toepassing?

9

Organisatie Beschouwingsniveau

Is het een principe op het niveau van de/het: • Megastructuur • Keten • Onderneming • Deelonderneming • Bedrijf • Bedrijfsonderdeel • Bedrijfsfunctie • Bedrijfsproces • Bedrijfstaak • Bedrijfshandeling

Context

10

Beschouwing-

Dit attribuut geeft aan in welke

Context


31 / 62

situatie of moment

beschouwingsituatie het principe geldig dient te zijn of gehanteerd / toegepast dient te worden. We maken onderscheid in de situatietypen principes: AS-IS principles, Plateau N principles, TO-BE principles, Envision principles en Timeless principles. Timeless principles zijn principles waar de tijd geen vat op heeft. Voor de mensheid betekend altijd een eeuwig vaak de tientallen miljarden jaren dat onze zon bestaat en dat onze aarde bestaat. • Een AS-IS principle is een principe dat zich in de huidige situatie (heden - 1 jaar) daadwerkelijk voordoet, waarmee men er verstandig aan doet er rekening mee te houden. • Een plateau N principle is een principe dat zich tijdelijk voordoet (jaar X). • Een TO-BE principle is een principe dat zich in de toekomstige situatie (3-5 jaar) zal gaan voordoen, realistisch en haalbaar is, waarmee men er verstandig aan doet er in de toekomst rekening mee te houden. • Een Envision principle is een principe dat zich in de verre toekomst zal gaan voordoen, maar voor de AS-IS, Plateau1 en TO-BE situatie onrealistisch is. • Een ‘Timeless principle’ is een principe dat altijd van toepassing is en dus tijdonafhankelijk.

11

Principeoplossingen / aanpakken

Hier dienen de gekozen principeoplossingen (aanpakken) beschreven te worden. Deze zijn al kort beschreven in het ‘Actie’-regel gedeelte van het principe. De ‘Actie’-regel wordt hier dus in meer detail uitgewerkt.

Werking / Handhaving

Per principeoplossing (aanpak) dient de naam en omschrijving vastgelegd te worden. 12

Conflicterende

Hier dient vermeld te worden met welke


Bedreiging 32 / 62

principes

andere principes het principe in conflict is of kan komen.

13

Alternatieve principes

Hier dient vermeld te worden welke alternatieve principes er zijn. Geef hier ook aan waarom juist voor dit principe / concept is gekozen en waarom dit principe ‘beter’ is dan de alternatieven.

Motivatie

14

Validiteit

Hier dient de mate waarin een principe een bewezen onderbouwing heeft, die garant staat voor het bereiken van het gewenste resultaat, inzichtelijk gemaakt te worden. Is dit principe al in het verleden succesvol toegepast of bewezen met een ‘proof-ofconcept’?

Bedreiging

15

Issues en conflicten

Dit attribuut beschrijft de interne issues en conflicten die het hanteren of toepassen van een principe met zich mee (zal gaan) brengt binnen de gegeven context (bouwwerk). Wat zijn de haken en ogen aan het principe om het in de context te hanteren? Waar conflicteert dit principe met andere principes, uitgangspunten, regels binnen de context?

Bedreiging

16

Bedrijfsvoordelen / nadelen

De voor- en nadelen van het toepassen / onderkennen van het principe dienen beschreven te worden. De voordelen die hier opgeschreven dienen te worden zijn de extra voordelen die niet direct af te leiden zijn van de invulling die is gegeven bij de attributen Exploitatie- en veranderdoelen en kwaliteitseisen. De nadelen die hier genoemd worden zijn inherent aan het onderkennen / toepassen van het principe en waar geen handhavingmechanisme tegenop kan werken.

Bedreiging / Motivatie

Een principe waaruit bijvoorbeeld voortvloeit dat men leverancierafhankelijk wordt, kan als nadeel gezien worden. 17

Extern

Hier dienen de externe


Handhaving

33 / 62

handhavingmechanisme

handhavingmechanismen beschreven te worden die noodzakelijk zijn om het principe te laten werken binnen een context. Dit is nodig om het principe binnen een bepaalde context altijd te kunnen af te dwingen. Voorbeelden van handhavingmechanismen voor principes zijn: toezicht, controle, sociale druk, beloning, bestraffing en dwingende structuren.

18

Implementatie impact

Wat dient er te worden aangepast om een principe te laten zijn werken in een context. Hoeveel tijd, geld en middelen kost het principe om (qua handhaving en structuurwijziging) te verwezenlijken? Een grove financiële inschatting kan mogelijk al gegeven worden.

Handhaving

19

Contextuele entiteiten

Beschrijf op welke contextuele entiteiten het principe betrekking heeft.

Verwijzing

Voorbeelden van onderdelen in de context waar een principe voor kan gelden zijn: systeem, systeemonderdeel, organisatie, onderneming, instelling, organisatiedomein, project, proces, product. Hier dienen niet alleen de bovenstaande begrippen vermeld te worden, maar dient men specifiek te zijn (als dit mogelijk is) en dus ook het soort onderdeel, de naam van het product etc. indien het bijvoorbeeld om een product gaat. 20

Systeem, Concept, of Stijl verwijzing

Beschrijf van welke systemen, concepten, fenomenen of stijlen het principe onderdeel is.

Verwijzing

21

Bron (vermelding)

Voorbeelden van bronnen van principes zijn: de natuur, ervaring, een door de industrie ontwikkelde technologie, een best practice, een bewezen concept.

Verwijzing

De bronvermelding voor een principe is D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

34 / 62

nooit een wens, eis, requirement of doelstelling. Het eisen van een bepaalde kwaliteit of een veranderdoel zijn wel aanleidingen om een bepaald concept (of principes) te willen of te moeten implementeren. Hier dient dus ook naast de naam van de bron ook de bronvermelding te staan. 22

First principle

Ieder systeem, stijl, fenomeen of concept heeft een kern (van waarheid, of waar het om draait) die door middel van een principe kan worden geformuleerd. Dit principle is het first principle. Van alle systemen, concepten en stijlen die in een architectuur worden gebruikt dient het first principle te worden geformuleerd.

Verwijzing

Is het principe een first principle? Ja / Nee. Indien nee: schrijf het first principle op dat de basis vormt van het principe. 23

Abstractieniveau

Is het principe beschreven op conceptueel, logisch of fysiek niveau?

Verwijzing

24

Status

We maken onderscheid in de volgende statussen van een principe:

Beheer

Voorstel (propose) - iemand heeft dit principe voorgesteld Kandidaat (candidate) – algemeen wordt erkend dat het voorgestelde principe inderdaad kandidaat is of staat In overweging (work in progress) – het kandidaat principe wordt in overweging genomen om te accepteren. Geaccepteerd (accepted) – het in overweging genomen principe is geaccepteerd. Afgewezen (Rejected) – het principe is afgekeurd. 25

Naam

Een short statement van één tot tien woorden maakt duidelijk wat de context en werking van het principe is.


Communicatie

35 / 62

Bijvoorbeeld: het zwaartekracht-principe of het gedigitaliseerde werkprocessenprincipe. 26

ID

Vanwege de vele principes in een architectuur dient een principe een unieke identificatie te hebben. Het ID betreft hier een uniek nummer of unieke code.

Beheer

27

Eigenaar en Beheerder

Wie de eigenaar en wie is de beheerder van het principe?

Beheer

28

Alternatieve representatiewijze

Hier dient de alternatieve representatiewijze beschreven of getoond te worden. Dit attribuut kan ook een verzameling van verschillende alternatieve representatiewijzen bevatten.

Communicatie

Bijvoorbeeld een ORM-model om een bepaald aspect van het principe specifieker te belichten of een visualisatie die bij een bepaalde doelgroep op een snelle manier het principe inzichtelijk maakt. 1 2 3

5.3 Afhankelijkheid tussen principe-attributen

4 5 6 7 8 9

Er is een relatie tussen de principe-attributen. De keuze of invulling van het ene attribuut heeft effect op de invulling van andere attributen van het principe. De scope voor de beschrijving wordt namelijk steeds meer afgebakend. Het stappenplan voor het formuleren van principes is op een dergelijke wijze opgebouwd zodat deze afbakening op de juiste manier plaatsvindt


36 / 62

1

6 Stappenplan voor het werken met principes

2 3 4 5 6 7 8 9 10

Hier staan drie verschillende stappenplan voor drie verschillende activiteiten aangaande principes.

11

6.1 Stappenplan 1 - Het zien, formuleren en documenteren van een principe

12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

•

Stappenplan 1 – Het formuleren van een principe

•

Stappenplan 2 – Het selecteren van een principe

•

Stappenplan 3 – het gebruiken van een principe

Stappenplan 1 gaat over het formuleren van een principe, naar aanleiding van het zien of gewaar worden van een principe. Veel architecten verkrijgen, als ze met het oplossen van vraagstukken bezig zijn, ineens inzicht of overzicht in een bepaald principe. Het is dan van belang om dit principe goed te kunnen ‘vangen’ in een formulering of omschrijving. Het formuleren van een principe is net zoiets als het even bedenken van theorie. Dat kan natuurlijk niet eventjes, en dient zorgvuldig en wel overwogen te gebeuren. In principe zou elk principe dat we formuleren al goed gedocumenteerd in literatuur dienen te staan (een bedrijfskundig of informatiekundig boek) en al voldoende vaak en succesvol te zijn toegepast (best practices) voordat we het principe als waarheid zien of beschouwen. In elke entiteit met een vaste vorm of functie huist één of meer principes. De omgeving, concepten, fenomenen, logische, fysieke en digitale systemen in de onderneming, mensen, dieren en dingen. Allemaal bevatten ze principes. Het moment dat we deze principes zien hangt echter af van hoe we kijken en wat we zoeken. Stap 1: Denk aan een vraagstuk, uitgangspunt, doelstelling of iets anders dat jij zelf of dat men voor elkaar wilt krijgen of wilt verwezenlijken in de organisatie. Bijvoorbeeld: het vraagstuk van efficiëntere inzet van informatiesystemen ter ondersteuning van bedrijfsprocessen in de organisatie. Stap 2: Schrijf het vraagstuk op en schrijf met name op waarom het een vraagstuk is en waarom en hoe het (onbedoeld) in stand gehouden wordt. Schrijf de naam op van het vraagstuk en eventueel de naam van een systeem, concept of fenomeen dat verband houdt met het vraagstuk. Realiseer je dat iets pas een probleem is als er normen zijn gesteld waar niet aan voldaan kan worden. Probeer bij de naam van een vraagstuk, systeem, concept of fenomeen een definitie / omschrijving op te schrijven. D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

37 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

Bijvoorbeeld: Vele bedrijfsprocessen in de organisatie hebben hun eigen applicatieve oplossing voor een generieke functionaliteit. Functionaliteit zoals het maken of genereren van rapportages, het batchgewijs afdrukken van documenten en het agenderen van afspraken. Als in het ene bedrijfsproces een applicatie uit een softwareproductfamilie wordt gebruikt, ligt het al snel voor de hand om extra functionaliteit uit deze productfamilie te halen. Als in elk bedrijfsproces een andere softwareproductfamilie wordt gebruikt, loopt met de jaren de applicatieve ondersteuning compleet uit de hand. De organisatie heeft van alle software die er is alle applicaties in huis, waar soms ook maatwerk op is gepleegd. Men voorziet dan op enig moment dat de informatievoorziening zo complex is geworden dat deze qua doorontwikkeling tot stilstand komt en innovatie van de business onmogelijk maakt. Stap 3: Schrijf de kwalitatieve en prestatiegerichte voordelen, nadelen en aspecten van het vraagstuk op in relatie tot gestelde normen. Bijvoorbeeld: Omdat iedereen zijn eigen applicatieve oplossing heeft, zijn er vele extra en dubbele kosten voor beheer en onderhoud die gemaakt moet worden. De verschillende applicatieve oplossingen zijn van verschillende technologieën voorzien en sluiten slecht op elkaar aan. De interfaces en koppellingen (en dan met name de kosten voor ontwikkeling, beheer en onderhoud hiervoor) voor deze in feite dubbele applicaties zouden niet nodig zijn, als iedereen voor deze generieke functionaliteit dezelfde applicaties zou gebruiken. Stap 4: Schrijf op welke concept (oplossingsrichting, werkwijze, idee, aanpak, abstractie van een implementatie) je kent waarmee je het vraagstuk kunt oplossen (geheel of gedeeltelijk). Schrijf van het concept op, op welke wijze het de voordelen of nadelen in kwaliteit of prestatie realiseert. Bijvoorbeeld:het hergebruikprincipe van open, op componenten gebaseerde, applicaties. Het hergebruikprincipe van open applicaties zegt dat wanneer alleen applicaties mogen worden aangeschaft in de organisatie, die gebruik maken van internationale open communicatiestandaarden, het vaker en beter gebeurt dat al aanwezige functionaliteit in aanwezige applicaties wordt hergebruikt. Dit omdat data en functionaliteit in een applicatie als het ware kan worden uitgebreid met een andere applicatie. Stap 5: Schrijf op wat randvoorwaardelijk is om ‘in place’ te hebben aan onderdelen van het concept, zodat het de voordelen oplevert. Welke elementen (logische en functionele onderdelen) en componenten (fysieke en digitale onderdelen) moeten er zijn. Bijvoorbeeld: het is onder andere van belang om acceptatiecriteria, inkoopafspraken en een lijst van toegestane communicatiestandaarden en applicatietechnologieën met elkaar te hebben afgesproken. Dat iemand een exotische applicatie aanschaft ter overbrugging van een periode, of dat de exoot in korte tijd wordt gestandaardiseerd kan onderdeel zijn van deze afspraken. De D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

38 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

professionalisering bij ICT mag natuurlijk niet leiden tot verstarring en blokkeren van innovatie of flexibiliteit in de business. Stap 6: Haal uit hetgeen dat je hebt beschreven de wervende titel, naam en typering en classificatie van het principe. De titel mag een deel van het principe bevatten: oorzaak of gevolg of voordeel. De naam moet vooral een oorzaak en gevolg duiden. De typering mag aangeven tot welke oplossingsdomein het principe hoort. Bijvoorbeeld: Hergebruik van applicaties leidt tot lagere beheerkosten en minder incidenten op ICT-gebied. Bijvoorbeeld: Open applicaties leiden tot beter ondersteuning met ICT van bedrijfsprocessen. Stap 7: Benoem of achterhaal uit wat je nu hebt opgeschreven de actieregel: door wat te doen gaat er iets gebeuren of in werking treden? Bijvoorbeeld: Door het aanschaffen van open component-based applicaties Stap 8:Benoem of achterhaal uit wat je nu hebt opgeschreven de effectregel: wat is het gevolg van het feit doordat er iets is gedaan of gebeurt? Bijvoorbeeld: wordt ervoor gezorgd dat applicaties sneller, vaker en beter op elkaar aansluiten en worden hergebruikt Stap 9: Benoem of achterhaal uit wat je nu hebt opgeschreven de gebruiksregel: wat is voor een entiteit in de context het voordeel dat er een bepaald systematisch oorzaak-gevolg patroon of keten optreedt? Welke prestatie of kwaliteitsresultaat produceert de oorzaak-gevolg keten of patroon? Bijvoorbeeld: wat leidt tot lagere ontwikkelkosten, beheerkosten, minder ICTincidenten en uiteindelijk betere flexibele afstemming van ICT op de bedrijfsprocessen. Stap 10: benoem de context waar de oorzaak gevolg in optreedt. Bijvoorbeeld de organisatie of in de keten. Stap 11: Benoem het handhavingmechanisme dat er voor zorgt dat de actieregel altijd leidt tot de effectregel. Bijvoorbeeld: vanuit harde procesafspraken en stringent toezicht op inkoop en acceptatie van software applicatie. Het short-statement van het principe ziet er uiteindelijk als volgt uit: Door het aanschaffen van component-based applicaties die gebruik maken van internationale open communicatiestandaarden vanuit harde procesafspraken en stringent toezicht op inkoop en acceptatie van software applicatie wordt ervoor gezorgd dat applicaties sneller, vaker en beter op elkaar aansluiten en worden D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

39 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

hergebruikt wat leidt tot lagere ontwikkelkosten, beheerkosten, minder ICTincidenten en uiteindelijk betere flexibele afstemming van ICT op de bedrijfsprocessen. Stap 12: Documenteer het principe verder aan de hand van de lijst van attributen. Zoals eigenaarschap, een treffend symbool, etc. Zie hiervoor de attributen tabel

6.2 Stappenplan 2 - Het selecteren van een principe Stappenplan 2 gaat over het selecteren van een principe als onderdeel van de architectuur. Een architect dient een onderbouwde en legitieme keuze te maken voor een principe en dit principe voor te leggen (voorzien van alternatieven) aan de opdrachtgever. Hoe dat op correcte wijze gaat, maakt dit stappenplan duidelijk. Het selecteren van een principe, is ook een organisatie afhankelijk maken van dat principe. Dat doe je niet zomaar. Een dergelijk principe dient goed te zijn getoetst op passendheid en bruikbaarheid in een bepaalde context bij een bepaald vraagstuk (een standaard, een beste practice). Hoe kun je anders onderbouwen dat je voor een principe moet kiezen als opdrachtgever. Dit stappenplan wordt uitgewerkt in de volgende versie van dit document.

6.3 Stappenplan 3 - het gebruiken of toepassen van een principe Stappenplan 3 gaat over het toepassen of gebruiken van een principe in een ontwerp. Als een architectuur eenmaal concepten met principes bevat, dient op enig moment deze architectuur invloed te hebben op het ontwerp van een bouwwerk. Hoe dat in zijn werk gaat maakt dit stappenplan duidelijk. Dit stappenplan wordt uitgewerkt in de volgende versie van dit document.


40 / 62

1

7 Normaliseren / herformuleren van principes

2 3 4 5 6 7

Veel ondernemingen hebben al (architectuur)principes opgesteld of er zijn er documenten te vinden waarin soortgelijke uitspraken zijn geformuleerd. Deze principes en uitspraken kunnen op eenvoudige wijze worden geherformuleerd conform Dragon1. In dit hoofdstuk wordt een kort stappenplan beschreven voor het normaliseren / herformuleren van principes of soortgelijke uitspraken.

8

7.1 De huidige praktijk

9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

Als je aan iemand vraagt wat principes zijn of welke principes hij ziet in de organisatie (of een willekeurig architectuurdocument raadpleegt), krijgt je antwoorden (uitspraken) zoals: 1. Elke dag heb ik hetzelfde ochtendritueel: opstaan, douchen, ontbijten, de krant lezen en naar mijn werk gaan. 2. In principe starten we een project alleen op als er een goedgekeurde businesscase aanwezig is. 3. Gegevens worden altijd gescheiden van applicaties. 4. IEEE1471 5. Inkopen is altijd slimmer, beter te beheren en goedkoper dan zelfbouw. 6. We moeten ICT-oplossingen die we kunnen kopen niet zelf gaan bouwen, omdat dat onze core business niet is. 7. Alle computersystemen hier hebben hetzelfde type operating system, namelijk Microsoft. 8. Het beleid in onze organisatie vormt onze principes. Bijvoorbeeld de internettoegang op de werkplek mag door de werknemers niet voor privédoeleinden worden gebruikt. 9. We slaan de NAW-gegevens van een klant altijd maar op één plaats op, namelijk zo dicht mogelijk bij de plaats waar deze gegevens worden ingevoerd. Zo op het eerste gezicht lijken deze uitspraken voor veel mensen allemaal principes. Maar als je nauwkeuriger naar deze uitspraken kijkt, en dan met name de formulering, dan zie je (door vanuit een bepaald perspectief te kijken) dat de uitspraken eigenlijk regels, richtlijnen, uitgangspunten, normen, standaarden en waarden zijn. Hieronder volgt een korte analyse van de bovenstaande uitspraken. Zoals we vanuit Dragon1 kijken naar deze uitspraken, zien we het volgende: •

•

Uitspraak 1 is een norm of gedragsregel. Het is bijvoorbeeld iets dat je met jezelf hebt afgesproken, waar je jezelf aan houdt. Het geeft je dag structuur en je voelt je er prettig bij en het is voor velen in Nederland heel normaal om dit te doen. Uitspraak 2 is een norm of gedragsregel. In de organisatie is bijvoorbeeld een projectmanagementmethode die dit voorschrijft. De handhaving van deze standaardregel faalt echter bij veel organisaties. Projecten worden D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

41 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

•

• • • • • •

immers al vaak opgestart zonder dat er überhaupt een businesscase aanwezig is. Uitspraak 3 is een uitgangspunt. Men streeft ernaar om dit voor elkaar te krijgen. Er is geen grote organisatie ter wereld waar dit ook echt zo is. Het nastreven van de scheiding van applicaties en gegevens is wel belangrijk aspect, gezien het echte achterliggende principe. Uitspraak 4 is een standaard. Een standaard is een alom geaccepteerde norm. Uitspraak 5 is een axioma. Het is iets waarvan iemand denkt dat het waar is gegeven de context. Dat kan ook zo zijn, maar het kan evengoed zo zijn dat het niet waar blijkt te zijn. Uitspraak 6 is een uitgangspunt. Uitspraak 7 is een interne standaard of ontwerpregel op basis van een norm. Het is de norm dat het goed is om Microsoft als operating system te gebruiken. Uitspraak 8 is een norm of gedragsregel. Uitspraak 9 is een ontwerpregel.

Deze uitspraken zijn weerlegbaar in bepaalde situaties of context. Omdat er geen context wordt geduid waarin altijd de bepaalde werking geldt, kan het niet als een ‘principe’ worden gebruikt door iemand. De uitspraken geven uiting aan wat er moet, wat we willen of wat kan, maar beschrijven vaak niet hoe iets werkt of in elkaar steekt, wat de gevolgen of resultaten hiervan zijn en waarom het goed is om het te doen. Oftewel, er ontbreekt cruciale informatie om het te kunnen handhaven binnen een systeem of te gebruiken in een ontwerp van een systeem. Neem als voorbeeld de normatieve uitspraak: ‘We slaan de NAW-gegevens van een klant altijd maar op één plaats op, namelijk zo dicht mogelijk bij de plaats waar deze gegevens worden ingevoerd.’ Hier wordt vooral beschreven wat er gedaan wordt. Waar dit uiteindelijk toe leidt en wat de achterliggende motivatie hiervan is wordt niet duidelijk uit deze uitspraak. Tevens is niet vast te stellen of dit daadwerkelijk zo gebeurt. Het beschrijft in zijn totaliteit geen werkingsmechanisme. Zoals we eerder geconcludeerd hebben is dit geen principe, maar een ontwerpregel.

7.2 Stappenplan voor herformuleren van uitspraken naar principes Achter de uitspraken uit de vorige paragraaf schuilen echter wel degelijk principes of werkingsmechanismen. Dit stappenplan helpt om de daadwerkelijke principes op te schrijven en om uitspraken die nu gelabeld zijn als principes te herformuleren conform Dragon1.

Stap 1: Selecteren van uitspraak


42 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

Selecteer een (deel van een) (samengestelde) uitspraak uit een lijst met uitspraken of uit een document, waarvan men zegt dat het principes zijn of zouden moeten worden. De geselecteerde uitspraak noemen we vanaf nu het RAW-statement. Schrijf het RAW-statement op en voorzie het van een unieke ID. Voorbeeld: ID: RAW-statement:

1 Gegevens worden altijd gescheiden van applicaties.

Stap 2: Achterhalen van soort en doel van uitspraak Om de uitspraak op een juiste wijze te herformuleren naar een principe is het van belang te achterhalen wat voor soort uitspraak het huidige RAW-statement is. Hierdoor wordt het duidelijk welke noodzakelijk informatie je al hebt voor het formuleren van het principe en welke informatie nog aangevuld dient te worden. We gaan er hier van uit dat de uitspraken qua formulering echte principes moeten worden en geen regels, richtlijnen, eisen, wensen of uitgangspunten. We gaan er daarbij ook vanuit dat het geselecteerde RAW-statement een regel (veelal een ontwerpregel) of richtlijn kan zijn, een wens of eis (requirement), een uitgangspunt (veelal een strategisch uitgangspunt of een beleidsuitgangspunt), een axioma of al een echt principe. Criteria voor het herkennen van de soort normatieve uitspraak: • Een goed geformuleerd principe beschrijft de gehandhaafde werking van iets (of een deel daarvan), zoals een concept, systeem of fenomeen. Een principe beschrijft een werkingsmechanisme en het gevolg of het resultaat van deze werking en wat daar dan mee mogelijk wordt gemaakt. • Met een axioma bedoelen we voor waar aangenomen principes. Het is een als grondslag aanvaarde basisstelling. Soms worden ten onrechte (niet onderbouwde) meningen als axioma’s gebruikt. Indien de resultaten van een onderzoek of toepassing daartoe aanleiding geven, worden axioma’s soms heroverwogen. • Een goed geformuleerde regel beschrijft de afspraak (vaak een relatie tussen entiteiten) die door twee of meer partijen wordt gemaakt. Het beschrijft hoe iets zou moeten worden gestructureerd of zou moeten gedaan. Op het niet nakomen of naleven van de regel hoort een sanctie te staan. Regels hebben soms ook de vorm van een gedragsregel (norm) of het opleggen van een standaard. • Een regel waar geen sanctie op staat en waarvan het volgen optioneel of wenselijk is, noemen we een richtlijn. • Een goed geformuleerd uitgangspunt beschrijft vaak wat een organisatie(onderdeel) nastreeft. • Een eis is iets dat er beslist dient te komen. Het is een noodzakelijk kenmerk, functie of te leveren prestatie van iets. Er wordt dringend om gevraagd, dit in tegenstelling tot een wens. • Een wet is een veelal bindende of verplichte regel die door toezichthouders en wetgevers wordt uitgevaardigd waarop een zware sanctie staat van het D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

43 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48

•

niet navolgen ervan. Door middel van handhaving van een wet probeert men het niet nakomen ervan te voorkomen. Een voorschrift is een regel die door een instantie wordt uitgevaardigd, waarbij op het niet nakomen ervan een sanctie staat. Deze sanctie kan licht zijn (een aantekening in een dossier) maar ook zeer zwaar (het uitsluitend van een organisatie uit een branche).

Bepaal aan de hand van bovenstaande criteria wat voor soort uitspraak het RAWstatement nu is. Bepaal tevens in welk van de drie delen van het short statement van het te formuleren principe het mogelijk geplaatst kan worden. Dit is natuurlijk mede te bepalen door ook te kijken naar de context (in welk document of gesprek) waarin de uitspraak is opgeschreven of is gedaan. Ook kun je na deze stap tot de conclusie komen dat de uitspraak niet geherformuleerd dient te worden naar een principe, maar dat het gewoon verkeerd gelabeld is en eigenlijk in een ander document thuis hoort. (Een uitspraak die men bijvoorbeeld gelabeld heeft als principe, maar in werkelijkheid gewoon een eis is, hoort thuis in een programma van eisen en hoeft an sich niet per se geherformuleerd te worden). Voorbeeld: Het RAW-statement ‘Gegevens worden altijd gescheiden van applicaties.’ is zowel te typeren als een eis, uitgangspunt of regel. Zonder de context waarin deze uitspraak is gedaan, is het moeilijk vast te stellen wat het nu precies voor een uitspraak is. Het kan bijvoorbeeld als eis zijn opgenomen in een programma van eisen (PvE) voor een bepaalde applicatie, maar het kan ook een ontwerpregel zijn om te kunnen voldoen aan een bepaalde eis uit het PvE. Om een definitieve typering mogelijk te maken is het dus noodzakelijk om vast te stellen of de uitspraak een ‘enabler’ is of dat de uitspraak ‘enabled’ dient te worden. Is de uitspraak een ‘enabler’ dan is het een ontwerpregel of richtlijn en is de uitspraak hetgeen wat ‘enabled’ moet worden dan betreft het vaak een eis of wens. Zonder contextinformatie is dit echter lastig te bepalen. Voor het voorbeeld gaan we in dit geval er vanuit dat de uitspraak afkomstig is uit een ontwerpdocument van een applicatie en het dus een ontwerpregel is. Indien een typering van de uitspraak niet direct mogelijk is, dient dus de documentatie geraadpleegd te worden waaruit het RAW-statement afkomstig is. De context waarbinnen de uitspraak is gedaan, maakt vaak duidelijk wat het oorspronkelijke doel is van de uitspraak. Voor het formuleren van het principe is dit verschil echter zeer belangrijk. Is de uitspraak een ‘enabler’ dan dient het gevolg of resultaat van het volgen van deze uitspraak beschreven te worden (Door gegevens altijd te scheiden van applicaties wordt ervoor gezorgd dat …). Is de uitspraak hetgeen wat ‘enabled’ dient te worden dan moet er beschreven worden hoe deze uitspraak bewaarheid kan worden (Door … wordt ervoor gezorgd dat gegevens altijd gescheiden zijn van applicaties). Dit heeft voor de verdere uitwerking van het principe natuurlijk grote gevolgen.


44 / 62

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49

Stap 3: Achterhalen wat de bron is van de uitspraak of waarvan het is afgeleid Zoek de oorspronkelijke documenten of literatuur op die men heeft gebruikt om het RAW-statement op te schrijven of te bedenken. Soms heb je dit allemaal nodig om het principe beter te kunnen formuleren, omdat hier vaak de ontbrekende informatie in te vinden is. We stellen hier dat een principe eigenlijk altijd in literatuur terug te vinden moet zijn, omdat het onderzoek en testtijd vergt voordat een principe ook echt als onweerlegbaar mag worden gekwalificeerd. Vaak komen er in uitspraken fenomenen, systemen en concepten voor waarover iets wordt gezegd. Soms is het verstandig om de uitspraak helemaal opnieuw te formuleren en het is dan het eenvoudigste om het vanuit het concept, systeem of fenomeen te formuleren. Ook kan het nodig zijn om naar abstractere, hogere klassen of meer conceptuele fenomenen, concepten en systemen te kijken. Hoe algemener de uitspraak of statement, des te grote is het gebied dat het afdekt. Het is de wens om hiernaar te streven. Een organisatie kan dan met minder uitspraken uit de voeten en het zorgt ervoor om onnodige uitzonderingssituaties op te heffen, want die kosten vaak alleen maar onnodig veel tijd, geld, capaciteit, aandacht en resources. Voorbeeld: Door op zoek te gaan naar literatuur omtrent deze uitspraak blijkt dat het scheiden van gegevens en applicaties leidt tot ‘een betere beheersbaarheid en ontsluiting van informatie’. In het PvE voor de applicatie blijkt teven de eis geformuleerd ‘De informatie die wordt verwerkt in en met de applicatie dient te allen tijde overdraagbaar te zijn aan andere applicaties’. Voorlopig hebben we aan deze gegevens voldoende om het short statement van het principe te kunnen formuleren.

Stap 4: Herformuleer het RAW-statement naar een short statement Als het statement een principe moet worden, formuleer dan wat er (steeds) gebeurt, wat dat als gevolg of resultaat heeft en wat dat dan weer mogelijk of onmogelijk maakt. Als het statement een architectuurprincipe dient te worden, probeer dan ook zoveel mogelijk context, scope of kader beperkingen weg te halen of weg te laten. Een architectuurprincipe dient holistisch te zijn. Tip: Kijk of het statement een beschrijving op fysiek niveau is waarbij het wellicht beter is om het statement zoveel mogelijk op logisch niveau te formuleren (afhankelijkheid naar product, technologie of leverancier weghalen) indien nodig of gewenst. Voorbeeld: Op basis van de uitgevoerde stappen tot nu toe is het mogelijk om het short statement van het principe te formuleren. Deze zou als volgt kunnen luiden: D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

45 / 62

1 2 3 4 5 6 7 8 9 10 11 12

Door gegevens altijd te scheiden van applicaties wordt ervoor gezorgd dat gegevens beter beheerd en ontsloten kunnen worden zodat gegevens te allen tijde overdraagbaar zijn aan andere applicaties.

Stap 5: Vervolg het normale stappenplan voor het formuleren van principes Nadat de vorige stappen zijn doorlopen kan het normale stappenplan voor het formuleren van principes gevolgd worden om invulling te geven aan de overige attributen.


46 / 62

1 2 3 4 5 6 7 8 9 10

8 Literatuurverwijzing • • • • • • •

Verkenning in een promotieonderzoek - Mark Paauwe Architectuurprincipes - Koen van Boekel Whitepaper architectuurprincipes - Paauwe Research Dictionary of Architecture and Construction Universal Principles of Design, ISBN-13 978-1-59253-007-6 Principles and Theories Landscape Architecture Design Principles


47 / 62

1 2

Bijlage A: Sjabloon voor het beschrijven van het principe

3 Unieke referentie {Unique ID / Unieke ID} Wervende titel voor principe {Title / Titel}

…

Naam van principe {Name / Naam}

…

Typering van principe {Type / Type}

…

Principe van Concept / Fenomeen / Systeem {entiteittype / entiteittype}

4 5 6 7 8 9 10 11

Vul hier een uniek code in

…

Kort omschrijving {Shortstatement / Kort uitspraak}

…

Uitgebreide beschrijving {Longstatement Lange uitspraak}

…

(Uitgangspunt of eis als justificatie voor principe)

…

Beleid {policy / beleid}

…

Implementatie {implementation / implementatie}

…

Tussen { } staat de officiële attribuutnaam. Daarboven staat een voor sommige mensen meer begrijpelijke naam. Dit sjabloon helpt om meer, vaker en beter principe gedocumenteerd te krijgen. In de attributenlijst staan nog meer attributen. Deze dienen uiteindelijk allemaal gedocumenteerd te worden, maar dat kan ook altijd nog in tweede instantie.


48 / 62

1 2 3 4 5 6

Bijlage B: Begrippenkader De volgende definities van de begrippen die een rol spelen bij principes zijn overgenomen uit de Dragon1 Glossary of terms. De schrijfwijze en definities in deze glossary zijn leidend boven de hier verstrekte definities. Raadpleeg de glossary voor de meest up-to-date definities. Begrip

Definitie

Aandachtspunt (Concern)

Een aandachtspunt is een aspect of onderwerp dat iemand uit hoofde van zijn functie, rol, taak of identiteit in zijn portefeuille of aandachtsgebied heeft zitten.

Abstractieniveau (Abstraction Level)

Een abstractieniveau is het beschouwen van één of meer entiteiten waarbij bepaalde kenmerken van die entiteiten niet in beschouwing worden genomen.

Ambitie (Ambition)

Een ambitie is de wil om een bepaald doel te realiseren. De ambitie van een onderneming of die van een bestuur of directie van een onderneming is overeenkomstig aan de strategische intentie van een onderneming of van het bestuur en de directie.

Architectuur (Architecture)

Architectuur, in de betekenis van het vakgebied architectuur, is de kunst en kunde van het gepland, functiegericht en integraal ontwerpen, realiseren, innoveren en transformeren van een bouwwerk dat veelal duurzaam en toekomstvast dient te zijn. Architectuur, in de betekenis van architectuur van een bouwwerk, is het totaalconcept of samenhangend geheel aan toegepaste bouwkundige concepten die met principes, uitgedrukt in elementen, componenten, objecten, technische producten en regels, zorgen voor bepaalde prestaties en kwaliteit van de constructieve, operatieve en decoratieve functies van een bouwwerk.

Architectuurontwerp (Architecture Design)

Een architectuurontwerp is een schematisch plan of voorstelling van een oplossing voor een (ontwerp)vraagstuk. Bijvoorbeeld een bouwwerk waarmee wordt voorzien in de behoeften van belanghebbenden. In een architectuurontwerp zijn, met behulp van concepten en principes, complexe of lastige ontwerpvraagstukken opgelost, waarbij functie en vorm gescheiden van elkaar zijn ontworpen evenals constructie, decoratie en operatie van de oplossing. Dit alles maakt van een ontwerp een architectuurontwerp. Een architectuurontwerp is een ontwerp van een totaalconcept voor een bouwwerk dat bestaat uit een analyse van de huidige configuratie, ruimten, omgeving,


49 / 62

locaties en situaties van een bestaand systeem en een ontwerp van de toekomstige configuratie, ruimten, omgeving, locaties en situaties van een nieuw systeem. De configuraties, situaties, ruimten, omgeving en locaties worden met beschrijvingen en visualisaties van entiteiten op conceptueel, logische en fysiek niveau zichtbaar en hanteerbaar gemaakt. In een architectuurontwerp wordt de vertaalslag gemaakt van concepten naar elementen, van elementen naar componenten en objecten, van componenten naar technische producten. Architectuurplateau (Architecture Plateau)

Een architectuurplateau is een stabiele situatie van een systeem of domein gedurende enkele maanden. Gedurende het bestaan van het architectuurplateau gaan partijen zich afhankelijk maken van de architectuur, de concepten en de geldende principes binnen het architectuurplateau.

Architectuurprincipe (Architecture Principle)

Een architectuurprincipe is een - van context ontdaan conceptprincipe of ontwerpprincipe dat overal en altijd bij alles in een systeem kan gelden. Een architectuurprincipe is een universeel principe dat holistisch is toegepast in de onderneming en daarom integraal uitspraak doet over de bouwwijze van de onderneming.

Architectuurraamwerk (Architecture Framework)

Een architectuurraamwerk is een matrix van plaatjes bestaande uit een aantal onderkende architecturen 1) met hun relatie tot elkaar en 2) met de belangrijkste onderdelen die in deze architecturen voorkomen. Op het raamwerk staan indien mogelijk de eigenaren van de architecturen en de locatie van de architectuurdocumentatie.

Architectuurstijl (Architecture Style)

Een architectuurstijl is een consistente verzameling van samenhangende concepten die bestaan uit kenmerkende of in het oogspringende principes, kwaliteitsvoordelen, regels, elementen en componenten. Een architectuurstijl wordt vanwege de bekende voordelen vaak hergebruikt. De elementen uit een architectuurstijl worden stijlelementen genoemd.

Architectuurvisualisatie (Architecture Vizualisation)

Een architectuurvisualisatie is een visualisatie die toont welke entiteiten zoals concepten, stijlelementen, componenten, objecten en producten onderdeel zijn van het totaalconcept dat is of wordt gebruikt voor het architectuurontwerp van een bouwwerk. Een architectuurvisualisatie is het resultaat van de conceptuele vertaalslag die de architect heeft gemaakt. Architectuurvisualisaties tonen welke kwalitatieve voordelen de gekozen oplossingsrichting(en) produceren door bepaalde gekozen principes, regels en handhavingsmechanisme waarbij de relatie wordt gelegd van oplossingsrichting(en) naar strategische uitgangspunten, doelen, eisen en randvoorwaarden van de


50 / 62

opdrachtgever en de belanghebbenden betreffende een bouwwerk. Behoefte (Need)

Een behoefte is een verlangen. De noodzakelijke invulling van eisen om bepaalde werkzaamheden te kunnen uitvoeren.

Beleid (Policy)

Beleid is de wijze waarop een onderneming of bedrijf wil of graag ziet dat medewerkers gebruikmaken van middelen of deze inzetten bij het uitvoeren van taken, handelingen en activiteiten teneinde de doelstellingen van een organisatie te realiseren.

Beleidsuitspraak (Policy statement)

Een beleidsuitspraak is een richtinggevende en bindende afspraak hoe met middelen om te gaan of taken uit te voeren.

Beleidslijn (Policies)

Een onderdeel van beleid. Het is een groepering van beleidsuitspraken.

Boek van architectuur & ontwerp principes (Book of architecture & design principles)

Een boek van architectuur & ontwerp principes is een document waarin in bibliotheekvorm de architectuur- en ontwerpprincipes op een juiste manier staan gedocumenteerd met literatuurverwijzingen voor een bepaalde architectuur.

Boek van concepten & principes (Book of concepts & principles)

Een boek van concepten & principes is een document dat beschrijft voor een bepaalde architectuur in bibliotheekvorm welke architectuurbouwstenen er zijn die gebruikt kunnen of mogen worden bij een architectuur.

Boek van realiteitsprincipes (Book of reality principles)

Een boek van realiteitsprincipes is een document waarin de belangrijkste principes staan die nu gelden in een bepaalde architectuur en die als ontwerpprincipe gebruikt zouden kunnen worden.

Beschouwingsniveau (Abstraction Level)

Een beschouwingsniveau is het perspectief van de onderneming dat men waarneemt, door vanuit een bepaalde managementlaag, functie of rol te kijken naar de onderneming.

Beschouwingsperiode (Consideration Period)

Een beschouwingsperiode is een bepaalde periode van tijd die men vastzet bij het in beschouwing nemen van een bepaalde situatie of configuratie betreffende een systeem.

Bouwwerk (Structure)

Een bouwwerk is elke constructie van fysiek materiaal zoals hout of digitaal materiaal zoals geautomatiseerde procesondersteuning eventueel al voorzien van operatie en decoratie die op de plaats van bestemming, hetzij direct of indirect, steun vindt in of op de grond of op een platform en is bedoeld om ter plaatse of op afstand te functioneren of diensten te leveren. Een bouwwerk is te beschouwen als


51 / 62

ware opgebouwd uit constructieve, operatieve en decoratieve concepten en/of elementen en/of componenten en/of objecten en/of technische producten. Component (Component)

Een component is een meer specifiek technisch fysiek (samengesteld) onderdeel van een systeem dat eigen kenmerken, eigenschappen en/of gedragingen heeft. Een component is daarmee een onderdeel van een bouwwerk, concept of fenomeen.

Concept (Concept)

Een concept is een abstractie of voorbeeld van een oplossing, een idee of aanpak. Een concept is niets anders dan een oplossingsrichting. Een concept is een relatief begrip: de elementen van een concept kunnen op hun beurt ook weer als concepten worden beschouwd. Een concept is altijd een abstractie van iets. Nooit de implementatie van iets.

Concept-principe (Concept Principle)

Een concept-principe is een principe dat aangeeft op welke gehandhaafde wijze een concept in elkaar, werkt of dat er iets gebeurt in het concept waarbij er altijd een bepaald resultaat wordt geproduceerd of dat er een bepaald effect optreedt.

Conceptueel Abstractieniveau (Conceptual Level of Abstraction)

Het analyseren of aanschouwen van een entiteit of onderwerp waarbij logische/ functionele en fysieke/digitale technische kenmerken worden weggelaten, zodat alleen de conceptuele kenmerken van een entiteit of onderwerp in beeld zijn.

Context (Context)

Een context is een afgebakend gebied rondom een onderwerp dat in beschouwing wordt genomen zodat het onderwerp meer betekenis krijgt. In een context zijn bepaalde omstandigheden en gebeurtenissen die een relatie hebben met het onderwerp dat in beschouwing wordt genomen.

Decoratie (Decoration)

Decoratie is de niet-functionele of niet-constructieve aankleding van een bouwwerk met behulp van elementen of componenten. De decoratie van een bouwwerk is het geheel van entiteiten dat geen huidige betekenisvolle constructieve of operatieve functie heeft. Decoratie zorgt voor sfeer.

Doel (Goal)

Een doel is een vereiste te realiseren situatie dat is af te leiden van de taak of missie van de acterende entiteit die het doel wil realiseren. Doelen komen op allerlei niveaus in de onderneming terug, zoals ondernemingsdoelen, bedrijfsdoelen, bedrijfsfunctiedoelen, bedrijfsprocesdoelen en afdelingsdoelen.

Doeleinde (Objective)

De achterliggende reden waarom bepaalde activiteiten worden uitgevoerd of doelen dienen te worden


52 / 62

gerealiseerd. Doelstelling (Target)

Een doelstelling is een concreet en detaillistisch geformuleerd (deel van een) doel. Een doelstelling wordt zoveel mogelijk S.M.A.R.T.-geformuleerd.

Domein (Domain)

Een domein is een afgebakend en denkbeeldig gebied van verantwoordelijkheden, taken, rollen, eigenaarschap en bevoegdheden.

Eis (Requirement)

Een eis is iets dat er beslist dient te komen. Het is een noodzakelijk kenmerk, functie of te leveren prestatie van iets. Er wordt dringend om gevraagd, dit in tegenstelling tot een wens.

Element (Element)

Een element is een meer generiek functioneel logisch (samengesteld) onderdeel van een systeem. Een element is daarmee een onderdeel van een bouwwerk, concept of fenomeen.

Entiteit (Entity)

Een entiteit is iets dat er is, wordt herkend of wordt onderkend. Een entiteit heeft een eigen identiteit en is te onderscheiden ten opzichte van andere entiteiten. Een entiteit heeft attributen die de entiteit een identiteit geven. Vaak worden de onderdelen van een systeem entiteiten genoemd om te kunnen beschouwen waaruit een systeem bestaat.

Era, Tijdperk (Era)

Een era is een tijdperk. Een periode die een beginpunt en een eindpunt heeft. Het begin en eind worden meestal door kenmerkende gebeurtenissen gemarkeerd.

Functie (Function)

Een functie is een taakvervulling van een entiteit. Een functie zegt wat een entiteit kan. Een functie is een geheel van prestaties die door een element of component worden geleverd. Een functie heeft nog geen fysieke of implementatie vorm, een vorm heeft echter altijd (een) functie(s).

Fysiek Abstractieniveau (Physical Level of Abstraction)

Het analyseren of aanschouwen van een object of onderwerp waarbij conceptuele en logische functionele kenmerken worden weggelaten, zodat alleen de fysieke digitale technische kenmerken van een object of onderwerp in beeld zijn.

Handhavingmechanisme (Enforcement machanism)

Een handhavingmechanisme is het geheel van interne en externe elementen, dat zorgt voor het altijd op dezelfde wijze werken van een concept binnen een gegeven context.

Hypothese (hypothesis)

Een nog niet bewezen, maar ook nog niet weerlegde stelling of idee


53 / 62

Klasse (Class)

Een groep entiteiten die tenminste een eigenschap of kenmerk, zoals een gedraging, gemeen hebben. Een klasse wordt gedefinieerd door de gemeenschappelijke eigenschappen of kenmerken.

Kwaliteit (Quality)

De kwaliteit van een onderneming is de mate waarin het produceren van goederen en producten, het leveren van diensten en het uitvoeren van bedrijfsprocessen voldoet aan de van te voren gestelde eisen.

Kwaliteitsaspect (Quality aspect)

Een kwaliteitsaspect is een vaardigheid van een systeem. Een kwaliteitsaspect is een niet-functionele situatie of nietfunctionele prestatie waar een doelstelling voor geformuleerd wordt.

Logisch abstractieniveau (Logical Level of Abstraction)

Het analyseren of aanschouwen van een object of onderwerp waarbij conceptuele en fysieke/digitale technische kenmerken worden weggelaten, zodat alleen de logische functionele kenmerken van een object of onderwerp in beeld zijn.

Missie (Mission)

Een missie is een taakstelling van de onderneming, het bedrijf of de bedrijfsfunctie.

Norm (Norm)

Een exact vastgelegde waarde of betekenis die geldt als een referentiepunt.

Object (Object)

Een object is een digitaal, virtueel of fysiek (samengesteld) geheel met eigen kenmerken, eigenschappen en/of gedragingen. Een object is een onderdeel van een systeem zoals een bouwwerk, concept of fenomeen. Een object is een specialisatie van component, waarbij de informatie of gegevens van het component centraal staan bij het gebruik of behandeling.

Ontwerpprincipe (Design Principle)

Een ontwerpprincipe is een principe dat geldig is in de omgeving van het bouwwerk, daardoor het invloed heeft op het bouwwerk en waarmee bewust door de architect bij het ontwerpen en realiseren rekening wordt gehouden.

Opdrachtgever, Eigenaar/Klant (Owner/client)

Een opdrachtgever is de persoon die een opdracht, veelal een architectuurontwerpopdracht, geeft aan een architect of aan een team van architecten om uiteindelijk een bouwwerk te laten realiseren op basis van het ontwerp.

Operatie (Operation)

De operatie van een bouwwerk is het geheel van entiteiten die activiteiten of werk uitvoeren. De operatie in een bouwwerk zorgt of voor of geeft een operatieve functie aan het bouwwerk.

Principe (Principle)

Een principe is de gehandhaafde wijze waarop een entiteit, zoals een systeem, concept of fenomeen werkt, gebeurt of plaatsvindt met een bepaald geproduceerd effect of


54 / 62

resultaat tot gevolg in een gegeven context. Principebeeld (Principle Image)

Een fotografische weergave van de gehandhaafde werking van een entiteit zoals een systeem, concept of fenomeen.

Principesdiagram (Principle Diagram)

Een formele schematische visualisatie van de gehandhaafde werking van een entiteit zoals een systeem, concept of fenomeen.

Principetekening (Principle Drawing)

Een principetekening is een informele visuele weergave met meer detail dan een schets, om aan belanghebbenden zoals opdrachtgevers uit te leggen op welke wijze een systeem, concept of fenomeen werkt. Deze tekening wordt gebruikt als ondersteuning voor de beslissing voor de keuze van een oplossing en om vertrouwen in de keuze te krijgen.

Principes-document (Principles Document)

Een document waarin gekoppeld aan strategische uitgangspunten, intenties en doelen de principes staan beschreven.

Programma van eisen (Program of Requirements)

Een programma van eisen (PvE) is een document waarin de eisen van belanghebbenden staan geprioriteerd en gegroepeerd op prestatie-eisen en kwaliteits-eisen.

Randvoorwaarde (Prerequisite)

Een randvoorwaarde is een bijkomstige eis of voorwaarde die noodzakelijk is voor het bereiken van een doel. Het is een externe eis van andere belanghebbenden. Een minimum eis door derden gesteld, waaraan minimaal moet worden voldaan.

Rationale (Rationale)

Een rationale is de onderbouwing van de wijze waarom een principe werkt zoals het werkt.

Realiteitsprincipe (Reality Principle)

Een realiteitsprincipe is een principe dat zegt wat de huidige gehandhaafde wijze van werken is van een (deel van een) gerealiseerd systeem. Een realiteitsprincipe geldt in de huidige situatie.

Regel (Rule)

Een regel is een afspraak over de relatie tussen twee of meer entiteiten zoals concepten, elementen, componenten, objecten of producten. Op het niet nakomen van de afspraak staat een sanctie die in zwaarte kan variëren. Deze zwaarte van de sanctie bepaalt of de regel, een richtlijn, voorschrift of wet is.

Representatie (Representation)

Een representatie is de grafische of tekstuele weergave (visualisatie) of beschrijving van iets zoals een systeem, fenomeen of concept.

Richtlijn (Guideline)

Een richtlijn is een regel waarop een lichte sanctie staat omdat het niet nakomen ervan geen grote problemen als


55 / 62

gevolg oplevert. Het niet nakomen van een richtlijn heeft daarmee weinig gevolgen voor de partijen die de richtlijn zijn overeengekomen. Specificatie (specification)

Een nauwkeurige benoeming van alle onderdelen waar iets uit bestaat.

Standaard (Standard)

Een alom geaccepteerde norm.

Strategisch stuurinstrument (Strategic Steering Instrument)

Een strategisch stuurinstrument is een hulpmiddel voor bestuur, directie en topmanagement om op basis van overzicht en de grote lijnen te sturen, via kaders, op een beheerste uitoefening van de activiteiten in de onderneming teneinde de bedrijfsdoelen te realiseren.

Strategisch uitgangspunt (Strategic Startingpoint)

Een strategisch uitgangspunt is de aanname betreffende een hoger doel dat wordt nagestreefd of een situatie die men graag ziet bewaarheid. Datgene waar men vanuit gaat, datgene dat vastligt, een veronderstelling. Basis, grondslag. Een strategisch uitgangspunt is een uitspraak die duidelijk maakt wat de onderneming wil en veronderstelt wat goed is om na te streven en welke trends, ontwikkelingen, situaties en gegevens men als feitelijk vertrek meeneemt voor het opstellen van een strategie. In een strategisch uitgangspunt weerklinkt de missie, visie, filosofie, cultuur en identiteit. Deze strategisch uitgangspunten worden als 'proposities' geformuleerd.

Strategische intentie (Strategic Intention)

De wil om een bepaalde uitdaging te realiseren.

Systeem (system)

Een systeem is een geheel van onderdelen die samenwerken, gericht op het bereiken van een gemeenschappelijk doel.

Type (Type)

Een groep van entiteiten van dezelfde klasse op basis van een gemeenschappelijke invulling van kenmerken. Een type is vaak een nummer of een code.

Uitgangspunt (Intention)

Een uitgangspunt is de aanname betreffende een hoger doel dat wordt nagestreefd of een situatie die men graag ziet bewaarheid. Datgene waar men vanuit gaat, datgene dat vastligt, een veronderstelling. Basis, grondslag.

Visie (Vision)

Een visie is een bepaalde kijk op een of meer thema’s die van belang zijn voor het kunnen uitvoeren van taken en het realiseren van missies.

Voorschrift (prescription)

Een voorschrift is een veelal niet-bindende of verplichte regel die vanuit de branche wordt uitgevaardigd. De sanctie van het niet volgen van een voorschrift is veelal het niet


56 / 62

goedkeuren van een bouwwerk voor oplevering. Wet (Law)

Een wet is een veelal bindende of verplichte regel die door toezichthouders en wetgevers wordt uitgevaardigd waarop een zware sanctie staat van het niet navolgen ervan. Door middel van handhaving van een wet probeert men het niet nakomen ervan te voorkomen.

1


57 / 62

1

Bijlage C: Voorbeelden van soorten principes

2 3 4

Ondernemingsprincipes EP1

5 6 7

Besturingsprincipes GP1

8 9 10

Bedrijfsprincipes BP1

11 12 13

Informatie(voorzienings)principes IP1

14

Applicatie principes D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

58 / 62

1 AP1

2 3 4

Dataprincipes DP1

5 6 7 8 9 10

Technische/ICT-Infrastructuurprincipes TP1

11 12 13

Informatiebeveiligingsprincipes SP1

14 15 16 D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

59 / 62

1 2

Analyseprincipes 1

3 4 5

Ontwerpprincipes 1

6 7 8

Applicatie modulariteit – Door een applicatie modulair op te bouwen wordt ervoor gezorgd dat een applicatie

Realisatieprincipes 2

9 10 11

Implementatieprincipes 3

12 13 14

Systeemprincipes D1-APRS-2010rev0.9.7- Architecture Design Principles Standard © Copyright 2010, The Dragon1 Company. Alle rechten voorbehouden.

60 / 62

1 4

2 3 4

Conceptprincipes 5

5 6 7

Bouwwerkprincipes 6

8 9 10

Fenomeenprincipes 7

11 12 13

Realiteitsprincipes (Anti-principes) 8


61 / 62

1 2 3

Consistentie door eenmalige opslag van gegevens Consistentie door enkelvoudige bron voor gegevens


62 / 62

REVIEW VERSIE. Dragon1 Open Standaard Architectuurprincipes. Dragon1 Open Standard Architecture Design Principles. D1-APRS-2010rev0.9.7

Recommend Documents