Architectuurprincipes

Dragon1 Open Standaard Architectuurprincipes

Architectuurprincipes Dragon1 Open Standaard Evaluatieversie

Mark Paauwe Talitha Paauwe-Wijnands (red.)

Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

1

Dragon1 Open Standaard Architecture Principles

www.dragon1.org

Website: www.dragon1.org Bij dit boek hoort de ondersteunende website van Dragon1. Op deze website treft u de andere open standaarden, checklisten en documentsjablonen aan om met Dragon1 in de praktijk aan de slag te gaan. © 2011 Paauwe Group BV Het woordmerk Dragon1 en het beeldmerk van Dragon1 zijn voor alle publicaties van Uitgeverij Paauwe Group BV als woordmerk en beeldmerk beschermd. Alle rechten voorbehouden. Behoudens de in of krachtens de Auteurswet van 1912 gestelde uitzonderingen mag niets uit deze uitgave worden verveelvoudigd, opgeslagen in een geautomatiseerd gegevensbestand, of openbaar gemaakt, in enige vorm of op enige wijze, hetzij elektronisch, mechanisch, door fotokopieën, opnamen of enige andere manier, zonder voorafgaande schriftelijke toestemming van de uitgever. Voor zover het maken van reprografische verveelvoudigingen uit deze uitgave is toegestaan op grond van artikel 16h Auteurswet 1912 dient men de daarvoor wettelijk verschuldigde vergoedingen te voldoen aan de Stichting Reprorecht (Postbus 3051, 2130 KB Hoofddorp, www.reprorecht.nl). Voor het overnemen van gedeelte(n) uit deze uitgave in bloemlezingen, readers en andere compilatiewerken (artikel 16 Auteurswet 1912) dient men zich tot de uitgever te wenden. Dragon1 Open Standaard - Architectuurprincipes Eerste druk 2011-12-01, v1.0d Uitgeverij Paauwe Group BV Postbus 239, 6700 AE, Wageningen [email protected], www.paauwe.info Noot van de uitgever Wij hebben alle moeite gedaan om rechthebbenden van copyright te achterhalen. Personen of instanties die aanspraak willen maken op bepaalde rechten, wordt vriendelijk verzocht contact op te nemen met de uitgever. ISBN

978-94-90873-05-9

2



Voorwoord Wat is een open standaard? Dragon1 bestaat als methode uit een twintigtal open standaarden. Dit zijn de belangrijkste pijlers van de methode rondom de belangrijkste concepten in Dragon1. De open standaarden staan onder beheer van de Dragon1 Architecture Foundation, waarbij gebruikers van de Dragon1 methode invloed kunnen uitoefenen op de inhoud, verbetering en doorontwikkeling van een Dragon1 Open Standaard. Een ‘Dragon1 Open Standaard’ is een volledige detailuiteenzetting van de theorie en toepassingsmogelijkheden van een Dragon1-concept. Een open standaard wordt gepubliceerd door middel van een open standaard specificatiedocument. Zo is er bijvoorbeeld voor het werken met architectuurprincipes een aparte open standaard en is er ook één voor het maken van architectuurvisualisaties. Het gebruik van een open standaard Een reden om open standaarden te onderkennen in Dragon1, of anders gezegd de methode op te delen in open standaarden, is dat het gebruik van de methode hierdoor laagdrempelig wordt gemaakt voor organisaties. Men hoeft niet gelijk een hele nieuwe methode te adopteren, maar kan nu de huidige wijze van werken gericht verbeteren met een vernieuwing. Dragon1 biedt voor iedereen die met architectuur bezig is voordelen. Door te kijken welke open standaard het beste helpt voor het aanpakken van organisatiespecifieke vraagstukken is Dragon1 zeer gericht en effectief in te zetten. Aan het gebruik van een Dragon1 Open Standaard zijn voorwaarden verbonden. Dit om onder andere ervoor te zorgen dat de kennis en informatie in de Dragon1 Open Standaarden open blijft en niet door derden in niet-open vorm wordt aangeboden. Wat staat er in deze open standaard? In deze open standaard voor architectuurprincipes wordt tot in detail het werken met architectuurprincipes uiteengezet. En tevens de verschillen tussen principes en architectuurprincipes. Dragon1 biedt een brug om van ‘zachte’ principes (richtinggevende uitspraken) over te stappen naar ‘harde’ principes (gehandhaafde


3


www.dragon1.org

werkingsmechanismen) waardoor principes meer implementeerbaar, meetbaar en voorspelbaar worden.

Dragon1 Open Standaard Architectuurprincipes Gebruik architectuurprincipes om de gehandhaafde werking van business- en ICTconcepten in de onderneming op strategisch niveau te sturen en te borgen. Binnen het enterprise architectuurvakgebied wordt veel waarde gehecht aan ‘architectuurprincipe’ als instrument om richting te geven aan het ontwerp en de realisatie van een integrale bedrijfs-/ICT-oplossing, een onderneming of delen daarvan. Deze open standaard beschrijft hoe vanuit Dragon1 naar principes gekeken wordt en hoe men effectief gebruik kan maken van dit instrument in bijvoorbeeld projecten bij het ontwerpen en realiseren van systemen of bouwwerken. In de Engelse taal wordt significant iets anders verstaan onder het begrip principe waar het de betekenis heeft van ‘richting geven’, dan in de Nederlandse of Italiaanse taal waar het ‘werkingsmechanisme’ betekent. De afgelopen decennia heeft dit ervoor gezorgd dat internationaal de betekenis van ‘richting geven’ is aangeleerd. Helaas betekent dit dat met deze interpretatie van principe, architectuurprincipes veel aan kracht verliezen, omdat ze in het gebruik optioneel worden. In het huidige enterprise architectuurvakgebied wordt een principe dan ook gezien als ’een richtinggevende uitspraak die zelden of nooit wijzigt’. Bijvoorbeeld: ‘Gegevens worden in de organisatie altijd enkelvoudig opgeslagen en alleen in de daarvoor bestemde brondatabase.’ Om een meer zuivere theorie over krachtige enterprise architectuurprincipes te kunnen vormen, is daarom gekeken naar andere en oudere vakgebieden zoals bouwkundige architectuur, natuurkunde, wiskunde en industrieel ontwerp. Deze inzichten hebben geleid tot het radicaal vernieuwen van de bestaande theorie omtrent architectuurprincipes in het enterprise architectuurvakgebied. Dit heeft als gevolg dat in Dragon1 fundamenteel nieuw tegen principes wordt aan gekeken. In Dragon1 wordt een principe gezien als ‘de gehandhaafde wijze waarop iets werkt met een bepaald resultaat tot gevolg’. Bijvoorbeeld: ‘Door gegevens enkelvoudig in een brondatabase op te slaan, wordt ervoor gezorgd dat er geen inconsistente versies van gegevens kunnen ontstaan waarmee de organisatie eerder beschikt over deze gegevens en sneller gebruik kan maken van een hogere kwaliteit van deze gegevens.’ 4



Door deze nieuwe benadering van principe in Dragon1 wordt ervoor gezorgd dat het vakgebied schudt op zijn grondvesten waarmee het mogelijkheden geeft voor de verdere ontwikkeling van het vakgebied en met name voor het duurzaam en toekomstvast innoveren van ondernemingen. Mark Paauwe, Founder of Dragon1, November 2011


5


www.dragon1.org

Inhoudsopgave ARCHITECTUURPRINCIPES DRAGON1 OPEN STANDAARD ............................ 1 VOORWOORD .................................................................................................................. 3 INHOUDSOPGAVE .......................................................................................................... 6 DOCUMENTHISTORIE .................................................................................................... 9 PUBLICATIEHISTORIE .................................................................................................... 9 WIJZIGINGENHISTORIE ................................................................................................. 9 REVIEWERS .................................................................................................................... 9 AMBASSADEURS .......................................................................................................... 10 MANAGEMENTSAMENVATTING........................................................................... 11 INLEIDING .................................................................................................................... 12 OVERZICHT VAN DE INHOUD ........................................................................................ 12 UITWISSELBAARHEID EN HERBRUIKBAARHEID ............................................................. 13 DEFINITIE EN FUNCTIE VAN PRINCIPE ........................................................................... 13 VISUALISEREN VAN PRINCIPES ...................................................................................... 14 TAALVERSCHILLEN: PRINCIPE VERSUS UITGANGSPUNT ................................................ 14 DE FORMULERING........................................................................................................ 16 DE SOORTEN PRINCIPES ............................................................................................... 16 INLEIDING ............................................................................................................... 19 1.1 1.2 1.3 1.4 1.5 1.6 1.7

AANLEIDING ....................................................................................................20 DOEL & DOELGROEP ........................................................................................20 BEHEER EN DOORONTWIKKELING VAN DE OPEN STANDAARD ............................ 21 GEBRUIKSLICENTIE VOOR HET TOEPASSEN VAN DEZE OPEN STANDAARD .......... 21 DOORONTWIKKELING VAN DEZE OPEN STANDAARD ......................................... 22 MEER INFORMATIE OVER DEZE OPEN STANDAARD ............................................23 OVERZICHT VAN OPEN STANDAARDEN VAN DRAGON1 ......................................23

NORMATIEVE UITSPRAKEN ................................................................................. 25 2.1 2.2

WAT IS EEN NORMATIEVE UITSPRAAK? ............................................................ 26 HET LABELEN VAN UITSPRAKEN ....................................................................... 26

HET CONCEPT ‘PRINCIPE’ ................................................................................... 29 3.1 3.2 6

INLEIDING........................................................................................................ 30 DEFINITIE ........................................................................................................ 30 Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.


3.3 3.4

FUNCTIE............................................................................................................ 31 VORM ................................................................................................................33

3.4.1 Beschrijving .................................................................................................33 3.4.2 Visualisatie ............................................................................................. 36 DE SOORTEN PRINCIPES ..................................................................................... 40 4.1 4.2

SOORTEN PRINCIPES ........................................................................................ 41 PRINCIPES NAAR SOORT ENTITEIT ....................................................................44

4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.3

Systeemprincipes ...................................................................................44 Bouwwerkprincipes................................................................................ 45 Conceptprincipes .................................................................................. 46 Fenomeenprincipes ............................................................................... 47 Realiteitsprincipes ..................................................................................48

PRINCIPES NAAR GEBRUIKSDOEL..................................................................... 49

4.3.1 Analyseprincipes ....................................................................................... 49 4.3.2 Ontwerpprincipes.................................................................................. 49 4.3.3 Realisatieprincipes .................................................................................50 4.3.4 Beheerprincipes ...................................................................................... 51 4.3.5 Architectuurprincipes ............................................................................. 51 4.4

PRINCIPES OP THEMA OF DOMEIN .................................................................... 57

4.4.1 4.4.2 4.4.3 4.4.4 4.4.5 4.5

Enterprise principes ............................................................................... 57 Bedrijfsprincipes .................................................................................... 58 Informatie principes ............................................................................. 60 Technische principes ............................................................................. 61 Security principes .................................................................................. 62

PRINCIPESRAAMWERK ..................................................................................... 62

DE ATTRIBUTEN VAN EEN PRINCIPE ................................................................. 64 5.1 5.2

FUNCTIES VAN ATTRIBUTEN ............................................................................. 65 OVERZICHT VAN ATTRIBUTEN ......................................................................... 66

RELATIES VAN PRINCIPES ................................................................................... 77 6.1 6.2 6.3

RELATIES VAN PRINCIPES MET ENTITEITEN ....................................................... 78 RELATIES TUSSEN MANAGEMENTCONCEPTEN................................................... 78 PRINCIPES: DE LIJM TUSSEN STRATEGIE EN BELEID .......................................... 80

STAPPENPLAN VOOR HET WERKEN MET PRINCIPES ....................................... 81 7.1

INLEIDING ........................................................................................................ 82


7


www.dragon1.org

7.1.1

Stappenplan 1 - Het zien, formuleren en documenteren van een principe 82 Stappenplan 2 - Het selecteren van een principe ................................................ 86 Stappenplan 3 - Het gebruiken of toepassen van een principe ........................... 86 7.2 7.3 7.4

NORMALISEREN / HERFORMULEREN VAN PRINCIPES........................................ 87 STAPPENPLAN VOOR HERFORMULEREN VAN UITSPRAKEN NAAR PRINCIPES ..... 89 HET DOCUMENTEREN VAN EEN PRINCIPE......................................................... 93

LITERATUURVERWIJZING ................................................................................... 96 BIJLAGE A: VERKORT SJABLOON VOOR HET BESCHRIJVEN VAN HET PRINCIPE ............................................................................................................... 101 BIJLAGE B: BEGRIPPENKADER ........................................................................... 103

8



Documenthistorie Publicatiehistorie Wanneer

Wat

Wie

Waarom

19 nov. 2010

Preview versie

Openbare Preview

20 dec. 2010

Preview versie

Openbare Review

Wijzigingenhistorie Wanneer 23 september 2010

Wat Initiële opzet van het

Wie

Waarom

Mark Paauwe

Voor initiële review

Mark Paauwe

Voor 2e review en

document en afstemming met glossary of terms 30 september 2010

Afronding v 0.7

publicatie

Reviewers Wie

Organisatie

Rol

Talitha Paauwe

Paauwe Group

Redacteur

Jan Verwoerd

Dragon1 Architecture

Reviewer


9


www.dragon1.org

Foundation Alfred Dijkstra

Dragon1

Reviewer

Gebruikersvereniging Harm Verschuren

IT Eye

Reviewer

Jacques Janssen

Dragon1 Competence Center

Reviewer

– South America Jos Kapteijns

Rabobank

Reviewer

Frank Langeveld

ATOS Origin

Reviewer

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

Ambassadeurs Wie

Organisatie

Rol

Ton Eusterbrock

Sogeti

Informatie Architect

Harmen Groenwold

Capgemini

Managing Consultant

Frits de Boer

Zeppelin

Directeur

Gerben Hoogeboom

NDW

Informatie Architect

Albert Royen

Gemeente Maastricht

Beleidsadviseur I&A Concernstaf

Richard Uijen

TenneT TSO

Architect

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



Managementsamenvatting De open standaard voor architectuurprincipes: voor hogere legitimiteit, implementeerbaarheid, meetbaarheid en voorspelbaarheid van business- en ICT-concepten in de organisatie.


11


www.dragon1.org

Inleiding Binnen het enterprise architectuurvakgebied wordt veel waarde gehecht aan het architectuurprincipe als instrument om richting te geven aan het ontwerp van de (toekomstige) onderneming of delen daarvan. Deze open standaard beschrijft hoe vanuit Dragon1 naar principes gekeken wordt en hoe men effectief gebruik kan maken van dit instrument in bijvoorbeeld projecten 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 deze uitspraak: ‘dat deze voor alles, altijd en overal in een bepaalde context geldig is'. Hierop kan iedereen die beschikt over deze kennis, de wijze waarop iets werkt, verder bouwen en vertrouwen. Een principe is daarmee altijd een gehandhaafde werking met een geproduceerd resultaat tot gevolg, voordelig danwel nadelig. Echter, wanneer iemand op een uitspraak het etiket ‘principe’ plakt terwijl deze uitspraak eigenlijk niet voor alles, overal en altijd in de context geldt, dan komt iemand die bouwt en vertrouwt op het principe in die context bedrogen uit. Immers het beloofde resultaat van de werking van het principe zal niet altijd optreden.

Overzicht van de inhoud In dit document treft u onder andere de volgende onderwerpen aan:

12



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





Reviewen van principes

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 vergroot de uitwisselbaarheid, herbruikbaarheid en voorspelbaarheid van de opgestelde en geselecteerde principes in de architectuur.

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 spreektaal principes zijn: 

In principe ben ik vanavond, als er niets tussen komt, op tijd thuis.



Uit principe doe ik niet mee aan gokspelletjes.

In Dragon1 is een principe letterlijk gedefinieerd als: 'een principe is de gehandhaafde wijze waarop een entiteit, zoals een bouwwerk, concept of fenomeen in een gegeven context, deels of in zijn totaliteit, in elkaar steekt, werkt, gebeurt of plaatsvindt met een bepaald geproduceerd effect of resultaat tot gevolg. Een principe duidt daarmee conform de definitie altijd een gehandhaafde werking aan. Als de handhaving faalt, werkt het principe niet. Een kort voorbeeld van een principe waaruit duidelijk een werking naar voren komt 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’. Van belang is om vast te stellen dat niet Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

13


www.dragon1.org

alleen zogenaamde constructieprincipes een bepaalde werking uitdrukken. Ook de later uitgewerkte decoratieve en operatieve principes drukken een werkingsmechanisme uit. Het (veelal positieve) effect van het principe (een werkingsmechanisme) 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 een andere context, zodat het effect tot zijn recht komt in een 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 of tegenwerkende principes noemen) rekening te houden en hun effect op de onderneming in kaart of beeld te brengen. Een architect kijkt naar verschillende soorten principes, bijvoorbeeld conceptprincipes, om te analyseren of een concept bepaalde prestatie- of kwaliteitsvoordelen oplevert en als onderdeel van het totaalconcept kan worden gekozen in het architectuurontwerp omdat het invulling geeft aan de gestelde eisen.

Visualiseren van principes Een architect maakt gebruik van principetekeningen om aan een opdrachtgever (owner/client) op een duidelijke manier over te dragen hoe bruikbaar of noodzakelijk een (enterprise) concept is in het licht van (strategische) uitgangspunten en (bedrijfs)doelen van de onderneming of uitdagingen en randvoorwaarden betreffende een bouwwerk, project of programma. Een architect maakt gebruik van principedetailtekeningen om aan engineers (ontwikkelaars en bouwers), op een juiste manier over te dragen hoe een concept dient te worden ontworpen en gerealiseerd.

Taalverschillen: principe versus uitgangspunt Wanneer in het Nederlands het begrip uitgangspunt wordt gehanteerd, hanteert men in het Engels daar vaak het begrip ‘principle’ voor of ‘values’. Wanneer in het Nederlands het begrip ‘principe’ wordt gehanteerd, hanteert men daar in het Engels ook ‘principle’ voor. Dit maakt het lastig voor architecten in het Nederlands taalgebied om een juist verschil te kunnen maken tussen wat er nu precies bedoeld

14



wordt. Een lijst ‘principles’ in een Engels architectuurdocument zou in het Nederlands zomaar een lijst met uitgangspunten kunnen zijn. Een uitgangspunt zegt waar men vanuit gaat, maar het hoeft dus niet per se zo te zijn. Een principe zegt hoe iets werkt, en niet hoe we denken dat iets werkt, maar hoe het daadwerkelijk werkt. Voorbeelden van uitgangspunten die zijn ‘gelabeld als principes’ 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 wil houden. Men gaat er vanuit dat dit waar is, terwijl er vaak toch allerlei momenten en omstandigheden zijn waarin dit niet waar is. Volgens Dragon1 is een principe niet iets dat men kan ‘wensen’ of ‘willen’. Een principe is synoniem voor het mechanisme dat iets altijd werkt binnen een benoemde context. Een principe is ook iets anders dan een regel of een eis (Eng. requirement). Bijvoorbeeld als het principe van zwaartekracht geldt, dan is dat op alles van invloed, en moet men 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. Soms kan een principe bij gebruik in een bepaalde afgesproken context een richtinggevende of normatieve uitspraak zijn. 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 dit zou moeten. Hier zou iemand anders dan voor de volle 100% vanuit moeten kunnen gaan en verder op moeten kunnen bouwen. Echter een normatieve uitspraak is niet gelijk aan een principe, want de normatieve uitspraak is niet altijd waar, omdat het geen gehandhaafde werking beschrijft. Normatieve uitspraken voorzien van het label principe leveren daarom altijd problemen op. Een voorbeeld van een normatieve uitspraak waar vaak het label principe op staat is: ‘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 Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

15


www.dragon1.org

randvoorwaarde. De uitspraak is namelijk al gauw in bepaalde omstandigheden binnen de context niet waar. Zonder een vorm van handhaving uit te drukken in de uitspraak, kan men dit namelijk niet hardmaken.

De formulering In Dragon1 wordt voor het principe-attribuut short statement een voorkeur schrijfwijze aan gedragen ter bevordering van de kwaliteit, documentatie en hergebruik van geformuleerde principes. Dit heet de door-formulering. Deze luidt: Door [actieregel] op/in/binnen [context] vanuit [handhavingmechanisme] zorgt [entiteit] ervoor dat (alternatief: wordt ervoor gezorgd dat) [gebruiksregel] zodat e e [effectregel - 1 resultaat] waarmee [effectregel - 2 resultaat]. Een voorbeeld van een decoratief businessprincipe conform de door-formulering is het conceptprincipe van productlabeling: ‘Door een product in een bepaalde markt te voorzien van een label vanuit gedegen continu marktonderzoek dat een bepaalde doelgroep optimaal aanspreekt, wordt ervoor gezorgd dat het product meer zichtbaar is voor leden van de doelgroep, zodat het product vaker wordt gekocht door leden van de doelgroep waarmee de omzet van de organisatie wordt verhoogd.’ Een voorbeeld van een operatief businessprincipe conform de door-formulering is het conceptprincipe van selfservice: ‘Door het altijd uitsluiten van tussenkomst van een interne medewerker bij de verkoop van producten via de webshop wordt ervoor gezorgd dat tegen significant lagere kosten omzet kan worden gedraaid, waarmee de organisatie veel optimaler en efficiënter werkt. Een voorbeeld van een constructief businessprincipe conform de door-formulering is het principe van afdelingsgericht werken: ‘Door het werken in een organisatie altijd te verdelen over afdelingen wordt ervoor gezorgd dat de werkzaamheden op de ene afdeling minder de werkzaamheden op de andere afdeling storen, waarmee een afdeling gerichter, meer gefocust en sneller resultaat kan boeken van een hogere prestatie en kwaliteit.

De soorten principes Principes zijn op verschillende wijzen in te delen. Bijvoorbeeld naar aard of entiteit, gebruiksdoel, thema of domein. Een indeling van principes naar aard (of soort entiteit) is bijvoorbeeld:

16





Systeemprincipes



Bouwwerkprincipes



Conceptprincipes



Realiteitsprincipes



Fenomeenprincipes

Een indeling naar gebruiksdoel is bijvoorbeeld: 

Architectuurprincipes



Analyseprincipes



Ontwerpprincipes



Realisatieprincipes



Beheerprincipes

Een indeling naar domein/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 kunt u dus op verschillende wijze indelen.

In de praktijk hanteren we combinaties van deze indelingen: AS-IS bedrijfssysteemontwerpprincipes 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


17


www.dragon1.org

van een bouwwerk, systeem of oplossing, om te zien welk type principes daadwerkelijk bedoeld wordt of gehanteerd wordt. Deze Dragon1 Open Standaard helpt u in het correct en daarmee succesvol formuleren, selecteren en toepassen van principes in de enterprise architectuur.

18



Hoofdstuk 1

Hoofdstuk 1

Inleiding Waarom is deze open standaard voor architectuurprincipes er en hoe wordt deze beheerd?


19


www.dragon1.org

1.1 Aanleiding Binnen het enterprise architectuurvakgebied wordt veel waarde gehecht aan het architectuurprincipe als instrument om richting te geven aan het ontwerp van de (toekomstige) onderneming. Er vindt echter nog veel discussie plaats over wat een architectuurprincipe 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, worden 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 architectuurprincipe. Deze open standaard dient als hulpmiddel om bij het werken onder 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 definitie van principe en van architectuurprincipe, heeft als doel principes en architectuurprincipes effectiever te kunnen communiceren, visualiseren en toe te passen. Deze nieuwe definitie heeft nu al in de praktijk hierin meer toegevoegde waarde laten zien dan de huidige meer gangbare 'richtinggevende'-definitie of 'ontwerpruimte-beperkende'-definitie.

1.2 Doel & Doelgroep De doelgroep van deze open standaard is iedereen die conform Dragon1, principes wil gebruiken in architectuur, ontwerp en realisatie van bouwwerken. U moet hierbij denken aan doelgroepen zoals enterprise architecten, business architecten, informatie architecten, technische architecten, ICT-architecten, security architecten of project architecten, CIO’s, directieleden, managers, beleidsmedewerkers, engineers, ontwikkelaars, beheerders en consultants.

20



1.3 Beheer en standaard

doorontwikkeling

Hoofdstuk 1

van

de

open

Deze open standaard wordt beheerd door de Dragon1 Architecture Foundation. Dit houdt in dat wijzigingsaanvragen (RFC’s) vanuit de Dragon1 gebruikersvereniging door de Dragon1 Architecture Foundation 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 toepassingen van (delen uit) 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. Het beheer van de open standaard door de Dragon1 Architecture Foundation 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.

1.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 de teksten 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. Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

21


www.dragon1.org

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 Dragon1 Architecture Foundation. 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 Dragon1 Architecture Foundation. 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. 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 Dragon1 Architecture Foundation. 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 Dragon1 Architecture Foundation.

1.5 Doorontwikkeling van deze open standaard 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.

22



Hoofdstuk 1

1.6 Meer informatie over deze open standaard Indien u meer informatie wilt over de open standaard kunt u hiervoor contact opnemen met de Dragon1 Architecture Foundation (betreffende het gebruik en de toepassing van de open standaard) of met PAAUWE (betreffende de inhoud van de open standaard of het werken met architectuurprincipes).

1.7 Overzicht van open standaarden van Dragon1 De volgende Dragon1 Open Standaarden zijn momenteel (of komen op termijn) beschikbaar: 1.

Dragon1 Open Standard Architecture Principles

2. Dragon1 Open Standard Visual Language 3.

Dragon1 Open Standard Architecture Visualization

4. Dragon1 Open Standard Enterprise Architecture Design 5.

Dragon1 Open Standard Architecture Quality

6. Dragon1 Open Standard Architecture Stakeholder Management 7.

Dragon1 Open Standard Architecture Communication

8. Dragon1 Open Standard Architecture Implementation 9. Dragon1 Open Standard Architecture Service Management 10. Dragon1 Open Standard Architecture Start-Up & Initiation 11. Dragon1 Open Standard Architecture Application 12. Dragon1 Open Standard Architecture Framework 13. Dragon1 Open Standard Architecture Documentation 14. Dragon1 Open Standard Architecture Maturity 15. Dragon1 Open Standard Architecture Enterprise Innovation 16. Dragon1 Open Standard Architecture Requirements Management 17. Dragon1 Open Standard Architecture Rules for Architects Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

23


www.dragon1.org

18. Dragon1 Open Standard Solution Architecture Design 19. Dragon1 Open Standard Architecture in Projects 20. Dragon1 Open Standard Agile Architecture 21. Dragon1 Open Standard Architecture Governance & Management

24



Hoofdstuk 2

Hoofdstuk 2

Normatieve Uitspraken Hoe graag we ook iets als principe willen zien, alleen het werkingsmechanisme van een echt principe zorgt voor een bruikbaar resultaat.


25


www.dragon1.org

2.1 Wat is een normatieve uitspraak? Voordat we het concept principe introduceren behandelen we eerst de normatieve uitspraak. Dit omdat in de praktijk vaak uitspraken onterecht worden gelabeld als principe. Onder normatief verstaan we het stellen van een norm. Dit komt in een normatieve uitspraak tot uiting in de vorm dat iets of iemand zich aan een bepaalde gekwalificeerde prestatie of kwaliteit dient te conformeren: U mag dit, we moeten dat, je kunt dat, we streven ernaar dat... . Het is van belang om goed te herkennen wanneer we met een normatieve uitspraak te maken hebben. Voorbeelden van normatieve uitspraken zijn: 

We slaan gegevens van klanten eenmaal op.



We streven ernaar de beste leverancier te zijn op de markt.



Projecten kunnen alleen worden opgestart met een goedgekeurde business case.



Klanten kunnen zelf bepalen via welk kanaal ze met onze organisatie contact opnemen.

Deze normatieve uitspraken zijn geen van allen principes, maar bijvoorbeeld strategische uitgangspunten, randvoorwaarden, beleidsmaatregelen of ontwerpregels. Ze zijn in feite delen van implementaties van principes.

2.2 Het labelen van uitspraken Waarom is het belangrijk normatieve uitspraken niet te labelen als principe? Een normatieve uitspraak is niet altijd waar. Een principe, de wijze waarop iets werkt, is daarentegen altijd waar voor de context die wordt geduid. Per normatieve uitspraak in de voorbeelden hierboven genoemd, wordt hieronder een voorbeeld gegeven van een principe wat doorgaans achter de normatieve uitspraak ligt, of het principe wat waarschijnlijk bedoeld wordt. We slaan gegevens van klanten eenmaal op.

26



Hoofdstuk 2

Ten eerste worden gegevens van klanten altijd vaker dan eenmaal opgeslagen. Dus de uitspraak is in feite nooit geldig. Ten tweede is het geen principe omdat ook al zeg men dit, anderen er niet vanuit kunnen gaan dat dit overal en altijd zo gebeurt binnen een bepaalde context. Het achterliggende principe bij deze ontwerpregel of beleidsmaatregel is: eenmalige opslag van klantgegevens in de informatievoorziening van een organisatie voorkomt het gebruik van inconsistente versies van klantgegevens. Ten derde is dit principe pas een AS-IS architectuurprincipe wanneer het ook daadwerkelijk zo werkt in de organisatie. Kortom, hoe je het ook went of keert, als je een gegeven eenmalig opslaat, kunnen er nooit inconsistente versies van dat gegeven zijn of worden opgeslagen. In feite is dat een natuurwet, een door de natuur afgedwongen wet. We streven ernaar de beste leverancier te zijn op de markt. Een streven blijft een streven als het niet geborgd wordt door een bepaalde toezicht, controle of aanpak. Deze uitspraak wordt pas een principe als het handhavingsmechanisme expliciet benoemd wordt. In deze uitspraak ontbreekt ook wat het voordeel voor de organisatie moet zijn van het streven naar de beste te zijn. Anders kan een architect niet beargumenteren waarom dit principe moet worden gekozen en wat de kosten zijn om het te implementeren (legitimiteit!). Projecten kunnen alleen worden opgestart met een goedgekeurde business case. In een organisatie is dit pas een wet van meden en perzen als het systematisch wordt afgedwongen (via bijvoorbeeld een computersysteem). Anders is het niet meer dan een loze opmerking. Klanten kunnen zelf bepalen via welk kanaal ze met onze organisatie contact opnemen. Deze uitspraak wordt pas een principe als uitleg wordt gegeven aan het feit waarom overal en altijd iedereen hiertoe in staat is of wordt gesteld. Nu is het een loze kreet die nooit bewaarheid hoeft te worden en daarmee geen kracht heeft als stuurinstrument. En dus ook geen richting geeft. Binnen organisaties wordt steeds vaker met architectuur gewerkt, en daardoor wordt het formuleren, vaststellen en implementeren van architectuurprincipes ook steeds belangrijker. Principes voormen voor bestuur en directie high-level stuurEvaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

27


www.dragon1.org

instrumenten. Ze geven aan de ene kant een duidelijk bindend kader mee en aan de andere kant veel vrijheid om het naar eigen inzicht te realiseren.

28



Hoofdstuk 3

Hoofdstuk 3

Het concept ‘Principe’ Zonder principes geen argumentatie voor de juiste oplossingsrichting.


29


3.1

www.dragon1.org

Inleiding

In Dragon1 is het herkennen en onderkennen van principes die in entiteiten aanwezig zijn belangrijk voor de architect. Hoe beter hij hiertoe in staat is, des te hoger van kwaliteit zijn de bouwwerken (complexe systemen) die hij onder architectuur ontwerpt en laat realiseren. 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 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. In het kort gezegd is een systeem 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 principes te kunnen 'zien' die in soorten entiteiten zoals systemen, fenomenen en concepten schuilgaan, kan de architect de juiste keuzes maken. Bijvoorbeeld de juiste keuze voor een aanpassing aan bestaande systemen in de organisatie. Het onderkennen en volgen van de juiste fenomenen in de klantomgeving. Of het selecteren en toepassen van de juiste concepten in een ontwerp waarmee het 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.

3.2 Definitie Het begrip principe is van zeer groot belang in architectuur. Immers, het is de controle of toets hoe en waarom een concept of een andere entiteit bepaalde voordelen biedt in het licht van doelen en eisen. Ook is een principe belangrijk om te 30



Hoofdstuk 3

kunnen analyseren of iets goed in elkaar steekt of werkt. Een definitie die helpt bij de controle, toets en analyse komt als geroepen. De definitie voor principe in Dragon1 is zo opgesteld dat deze zeer analytisch en constructief van aard is. De definitie van principe bestaat uit verschillende onderdelen die de kenmerken van een principe duiden en die in een shortstatement van een principe terug te vinden zijn. De Dragon1 definitie voor het begrip principe is: 

Een principe is de gehandhaafde wijze waarop een entiteit, zoals een bouwwerk, concept of fenomeen, werkt, in een gegeven context, in elkaar steekt, werkt of plaatsvindt met een bepaald geproduceerd effect of resultaat tot gevolg.

De Engelse definitie voor het begrip principle is: 

A principle is the enforced way an entity, such as a structure, concept or phenomenon, is assembled, works or happens producing a certain result or effect in a given context.

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 de werking van de entiteit en het geproduceerde resultaat door die werking snel is te begrijpen en is over te brengen (te communiceren).

3.3 Functie De belangrijkste functie van een principe is om te begrijpen hoe en waarom entiteit bepaalde voordelige of nadelige effecten of resultaten produceert. architect is vooral bezig met het selecteren van concepten die onderdeel van architectuur dienen te worden. Daarvoor maakt de architect gebruik conceptprincipes.

een Een een van

Een te ontwerpen en te realiseren bouwwerk moet uiteindelijk de voordelige werking van (bedrijfskundige en informatiekundige) concepten gaan bevatten. Samen vormen de concepten die zijn gebruikt/toegepast in een bouwwerk de architectuur Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

31


www.dragon1.org

van het bouwwerk. Met andere woorden 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, het gevolg 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 om invulling te 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 handhavingsmechanisme 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 in staat de voordelige werking van oplossingsrichtingen (of concepten) helder en objectief inzichtelijk te maken en daardoor beter het concept te kunnen matchen met de 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 het principe dat elders is gebruikt succesvol als referentie in een nieuw bouwwerk toe te passen. 32



3.

Hoofdstuk 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 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. Als eenmaal principes op papier staan of in de architectuurdocumentatie zijn opgenomen, dienen ze vervolgens nog wel te worden geïmplementeerd in het bouwwerk, zoals de onderneming, het bedrijfsproces of het informatiesysteem. Zowel het implementeren van een principe als het documenteren van het principe dient afzonderlijk te gebeuren. Het opschrijven dat een principe dient te gelden of dat een principe geldt, maakt nog niet dat het principe ook zo werkt in het bouwwerk dat ontworpen of gerealiseerd dient te worden. Een principe is ook door te vertalen in beleidsmaatregelen of beleidskeuzes en ontwerpbeslissingen of ontwerpregels. We nemen nogmaals het voorbeeld van het principe: ‘Door eenmalige opslag van gegevens worden inconsistente versies ervan voorkomen’. Dit is door te vertalen naar de beleidsmaatregel dat bepaalde gegevens zoals klantgegevens niet langer meer in verschillende databases mogen worden opgeslagen en dat er voor de klantgegevens een brondatabase wordt aangewezen.

3.4 Vorm Er zijn verschillende vormen van formulering voor het principe. 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.

3.4.1 Beschrijving De kern van een principe wordt geformuleerd in het Short Statement. De eerder gegeven syntaxsstructuur hiervoor is richtinggevend en dient in de praktijk daar Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

33


www.dragon1.org

waar nodig of mogelijk is 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), effectregel en gebruiksregel. Het statement van een principe bestaat dus uit de volgende delen:  Deel 1 - actieregel  Deel 1.1 - handhavingsmechanisme  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 short statement 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 [handhavingse mechanisme] zorgt [entiteit] ervoor dat [gebruiksregel] zodat [effectregel - 1 e resultaat] waarmee [effectregel - 2 resultaat] etc… De delen van een principe worden nu toegelicht aan de hand van een voorbeeld principe. 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 het handelen ergens anders ook werkte. 34



Hoofdstuk 3

 Deel 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.  Deel 1.1 - handhavingsmechanisme Het handhavingsmechanisme is het mechanisme dat ervoor zorgt dat altijd en overal binnen een context de werking van de actieregel geldig blijft. Het handhavingsmechanisme werkt zo goed (met een waarschijnlijkheid [Eng. probability] van meer dan 0.7) dat je er vanuit mag gaan dat het principe altijd en overal in de context werkt, onder normale omstandigheden. Het handhavingsmechanisme in dit principe zijn de afspraken en toezicht omtrent het klantcontact.  Deel 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. je weet beter wat er speelt is de eerste effectregel in het vraagprincipe. je kunt je handelen beter afstemmen op de situatie is de tweede effectregel.  Deel 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. je handelen heeft meer positieve gevolgen is de gebruiksregel in het vraagprincipe. Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

35


www.dragon1.org

 Deel 5 - context De context is het afgebakende gebied of domein waarbinnen de werking van het principe altijd geldig is. De context is impliciet, waarmee wordt beweerd in het vraagprincipe, dat dit principe overal en altijd op de wereld en voor de mensheid werkt voor elke dienstenaanbieder en bij elke klant.  Deel 6 - houder De houder van het principe is de entiteit die zorg draagt voor het handhavingsmechanisme en die de actieregel uitvoert. 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.

3.4.2 Visualisatie 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

36



Hoofdstuk 3

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.



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 entiteitrelatiemodel, 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. Hieronder staan twee voorbeelden van visualisaties van principes (principebeeld, principeschets en principedetailtekening). Eerst een businessconceptprincipe, dan een informatiearchitectuurprincipe en vervolgens een technisch ontwerpprincipe.


37


www.dragon1.org

My Bank Corporation Architectuurartikel: #0124A

PRINCIPLE UNIQUE IDENTIFIER

MBC

EAP001 - MBCUBL

MYBANKCORPORATION Architectuurprincipes

PRINCIPLE TITLE

Een beter en ondubbelzinnig begrip ontstaat voor ons allemaal, door het consequent gebruik van één en dezelfde taal. PRINCIPLE NAME

PRINCIPLE TYPE

Het My Bank Corporation Unified Business Language Principe

TO BE Enterprise Architecture Principle

PRINCIPLE-DRAWING

PRINCIPLE SHORT STATEMENT

My Bank Corporation Unified Business Language (My Bank Corporation Begrippenkader)

Door alle medewerkers bij de My Bank Corporation consequent een eenduidig begrippenkader te laten hanteren, waarin alle business begrippen eenduidig

?

Client

zijn gedefinieerd, vanuit verplicht gebruik en beheer van hulpmiddelen en

Klant?

toezicht en controle daarop gehandhaafd, wordt ervoor gezorgd dat de verschillende partijen binnen de My Bank Corporation elkaar goed begrijpen en

Business Manager

dat er geen verwarring meer ontstaat door verkeerde interpretaties wat weer

Business Manager

Opleiding, gebruik en vernieuwing

leidt tot betere onderlinge communicatie en het (indirect) verhogen van kwaliteit van dienstverlening, klanttevredenheid, voorkomen van imagoschade,

My Bank Corporation Unified Business Language Handboek

<< Naar overzicht

Toezicht en handhaving

kapitaalvernietiging of desinvestering.

Details en implementatie van principe

Volgend principe >>

3 ARTICLE-CONTENT-TYPE: ARCHITECTURE PRINCIPLE

Januari 2011 - Een voorbeeld van een My Bank Corporation Architectuurprincipe op basis van Dragon1 - verzorgd door Paauwe Group BV

ARTICLE-CONTENT-VIEW-TYPE: PRINCIPLE OVERVIEW DOCUMENT-VIEW-TYPE: BASIC PAGE MANAGEMENT PRESENTATION

Figuur 1. Voorbeeld van het beschrijven en visualiseren van een principe. Nog een visualisatie voorbeeld. Het eerste principe van e-HomeCare is als volgt gedefinieerd met een short statement: ‘Door internet in te zetten als medium vanuit een gereguleerd digitaal zorgportaal voor het faciliteren van geluid en bewegend beeld, voor communicatie, uitwisseling van medische informatie en het mogelijk maken van financiële transacties wordt er voor gezorgd dat zorgaanbieders, zorgverleners en zorgconsumenten meer, vaker en beter met elkaar in contact staan, locatie- en tijdsonafhankelijk waarmee het zorgproces meer consistent, continu, beschikbaar en bestuurbaar wordt. Met andere woorden van hogere kwaliteit is.’ Dit principe is stap voor stap te visualiseren, door alle zelfstandige naamwoorden als entiteiten te voorzien van symbolen en alle werkwoorden te beschouwen als relaties tussen de entiteiten.

38



Hoofdstuk 3

Figuur 2. Voorbeeld visualisatie van een e-Health-principe met een short statement. Voor meer uitleg over het visualiseren van principes kunt u de Dragon1 Open Standard Visual Language raadplegen.


39


www.dragon1.org

Hoofdstuk 4

De soorten principes Kies de juiste soort principe en u heeft controle over het bouwwerk.

40



Hoofdstuk 4

4.1 Soorten principes 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. In de praktijk zien we combinaties van de soorten principes die genoemd staan in figuur 3. Bijvoorbeeld: 

Een bedrijfsontwerpprincipe: een principe waar rekening mee wordt gehouden bij het ontwerpen van bedrijven in een onderneming. Bijvoorbeeld: ‘Door de afhankelijkheid van bedrijfsonderdelen naar elkaar toe te verlagen en de koppeling naar elkaar toe te verhogen, wordt de beschikbaarheid, weerbaarheid en adaptiviteit van de organisatie als geheel significant hoger.’



Een informatievoorzieningrealisatie/implementatieprincipe: een principe waar rekening meer wordt gehouden bij het realiseren van de informatievoorziening in een onderneming. Bijvoorbeeld: ‘Door een systeem dat in productie is niet gelijk te vervangen door een nieuw systeem, maar altijd een periode van overgang en schaduwdraaien in te lassen, wordt ervoor gezorgd dat over het geheel gezien de beschikbaarheid van de informatievoorziening hoger is dan anders.’



Een ICT-infrastructuurconcept-analyseprincipe: een principe waar rekening mee wordt gehouden bij het analyseren van een ICT-infrastructuurconcept uit de theorie. Bijvoorbeeld: ‘Door elementen, componenten, objecten en technische producten in een concept van elkaar te scheiden wordt ervoor gezorgd dat beter duurzaam, toekomstvast en implementatieonafhankelijk naar een concept kan worden gekeken.’



Een enterprise architectuurprincipe: een principe dat veelvuldig geldt of voorkomt in de onderneming. Bijvoorbeeld het architectuurprincipe: ‘Door onder regie informatie locatieonafhankelijk beschikbaar te stellen aan


41


www.dragon1.org

entiteiten zoals computers, applicaties, medewerkers en processen wordt de productiviteit van alles hoger.’ Figuur 3 is ook een basis voor het onderkennen van eigen typen en soorten van principes.

42



Hoofdstuk 4

Principessoortenschema Onderdelen Entiteit principes

(stijl)Element principes

Component principes

Object principes

Technisch product principes

Artifact principes

Samenstellingen Bouwdeel principes

Bouwblok principes

Bouwwerk principes

Bouwproces Analyse principes

Fragmentprincipes

Architectuur Ontwerp principes

Realisatie principes

Architectuur principes

Decoratie principes

Constructie principes

Operatie principes

Afgeronde gehelen Concept principes

Fenomeen principes

Systeem principes

Configuratie / Structuur principes

Domein principes

realiteit principes

Solution principes

Systemen en domeinen in de onderneming Keten principes

Enterprise principes

Besturings principes

Bedrijfs(functie) principes

Bedrijfsprocesprincipes

Informatie(voorziening) principes

Informatie(systeem) principes

IT-Infrastructuur principes

Product principes

Formule principes

Applicatie principes

Data principes

Security principes

Figuur 3. Principesoortenschema. Figuur 3 toont vele voorbeelden van principes die van toepassing zijn op de belangrijke entiteiten binnen een onderneming. In deze afbeelding staan meer principes dan hier worden genoemd. Het waarom en functie van deze soorten Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

43


www.dragon1.org

principes kunnen eenvoudig worden afgeleid van de hierna behandelde soorten principes.

4.2

Principes naar soort entiteit

4.2.1

Systeemprincipes

Een systeemprincipe is de uitleg of de beschrijving van de gehandhaafde werking van een systeem met een bepaald geproduceerd resultaat tot gevolg. Een systeemprincipe wordt ook wel het werkingsprincipe genoemd van een systeem. Een systeem is in dit geval een geheel van samenwerkende entiteiten gericht op het verwezenlijken van een gemeenschappelijk doel. Het eerste principe (first principle) van een systeem vertelt ons hoe de entiteiten dit voor elkaar krijgen. In een systeem zitten altijd ontelbare principes die geheel of gedeeltelijk een werking van het systeem beschrijven. In een systeem kunnen daarom ook tegenstrijdige principes en elkaar tegenwerkende principes zitten. Mensen, bruggen, ondernemingen en informatiesystemen zijn systemen. Daarom zitten in mensen, bruggen, ondernemingen en informatiesystemen ontelbare principes. Waarom onderkennen we deze soort, wat is de functie ervan? Overal om ons heen zijn er systemen waarin bepaalde principes zitten. Daar dienen we rekening mee te houden, of levert het voordelen op indien wij er rekening mee houden. Hoe beter we dat doen, des beter we in staat zijn om een doel te bereiken. ‘Hoe beter je de principes van iemand (een mens) kent, des te beter kun je met hem samenleven.’ Door de systeemprincipes te beseffen, te herkennen en te erkennen leert men in feite hoe de systemen werken. Hoe beter u weet hoe iets werkt, des te beter u het voor u kunt laten werken. Hoe beter u de principes van een brug kent, des beter kunt u die brug aanpassen op en belasten met auto’s en vrachtauto's om hem daarmee in te zetten als verkeersader. Voorbeeld van een systeemprincipe 44



Hoofdstuk 4

Het basis systeemprincipe: ‘Door vanuit regels en afspraken alle entiteiten in een systeem samen te laten werken afgestemd op een zelfde doel, wordt ervoor gezorgd dat het systeem efficiënter en effectiever is in het realiseren van haar doel, waarmee het systeem van meer toegevoegde waarde zal zijn voor de organisatie.’ In elke onderneming zijn tegenwoordig wel informatiesystemen aanwezig, een specifiek soort systeem. Per bedrijfsfunctie, zoals verkoop, inkoop, productie en ontwikkeling, zijn vaak informatiesystemen aangeschaft of gemaakt en ingericht. Het eerste principe van een verkoopinformatiesysteem (VIS) zou bijvoorbeeld kunnen: Door continu mensen informatie over de verkoopactiviteiten te laten verzamelen, sorteren, analyseren, evalueren en distribueren vanuit toezicht op procedures en de specifieke inzet van hulpmiddelen, wordt ervoor gezorgd dat inspanningen en resultaten omtrent verkoop meer inzichtelijk en overzichtelijk worden zodat planning, uitvoering en controle op de verkoopactiviteiten sterk te verbeteren zijn in het licht van de verkoopdoelstellingen en capaciteiten waarmee de onderneming in staat is haar producten en diensten effectiever en efficiënter te verkopen. Als een onderneming beslist om een verkoopinformatiesysteem aan te schaffen en zichzelf hiervan afhankelijk te gaan maken, kan het principe van dit systeem worden gebruikt om te toetsen of het verkoopinformatiesysteem voldoende volledig kan worden geïmplementeerd. Later kan het principe worden gebruikt om een eventueel slecht werkend verkoopinformatiesysteem te optimaliseren of duurzaam en toekomstvast uit te breiden of beter te integreren met andere informatiesystemen. Met dit voorbeeld wordt duidelijk dat een onderneming beter kan innoveren en concurreren wanneer van de belangrijkste informatiesystemen per bedrijfsfunctie de principes helder zijn.

4.2.2

Bouwwerkprincipes

Een bouwwerkprincipe is de uitleg of de beschrijving van de gehandhaafde werking van een bouwwerk met een bepaald geproduceerd resultaat tot gevolg. Een bouwwerkprincipe wordt ook wel het werkingsprincipe genoemd van een bouwwerk.


45


www.dragon1.org

Een bouwwerk is in dit geval een geheel van samenwerkende entiteiten gericht op het verwezenlijken van een gemeenschappelijk doel. Het eerst principe van een bouwwerk vertelt ons hoe de entiteiten dit voor elkaar krijgen. Waarom onderkennen we deze soort, wat is de functie ervan? Architecten die zich richten op ondernemingen, bedrijven en informatievoorziening, dienen te weten welke principes er gelden in hun bouwwerken. Voorbeeld van een bouwwerkprincipe Stel dat het bouwwerk ‘een gemeente' is. Een bouwwerkprincipe daar zou kunnen zijn: het one-stop-shopping principe van de gemeente – ‘Door de burger al zijn overheidszaken bij één loket te kunnen laten regelen, wordt ervoor gezorgd dat de burger en de gemeente minder tijd, geld en resources kwijt is aan de zaak, dat er minder fouten worden gemaakt en dat de burger hierdoor ook eerder geneigd is gebruik te maken van de dienstverlening van de gemeente waarmee de klantentevredenheid van de burger en de kwaliteit van dienstverlening van de gemeente worden verhoogd.’ In dit bouwwerk (de gemeente) is het businessconcept (one stop shopping) toegepast.

4.2.3

Conceptprincipes

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 we deze soort, wat is de functie ervan? De reden dat naar het principe (de werking) van een concept gekeken wordt, is om het concept dan met de juiste 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 van de opdrachtgever en de belanghebbenden. De officiële definitie van conceptprincipe in Dragon1 is: 46





Hoofdstuk 4

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

Voorbeelden van conceptprincipes Het zitconcept van een stoel: ‘Door vanuit een evenwichtige constructie een altijd stabiel zitvlak te bieden, wordt ervoor gezorgd dat iemand gedurende een bepaalde tijd in zittende houding kan rusten of in een zittende positie arbeid kan verrichten waarmee iemand meer geconcentreerd of meer uitgerust bezig kan zijn.’ Het client-server-concept: ‘Door altijd vanuit een afgesproken wijze van communicatie de client opdrachten aan een server te laten geven en servers alleen in opdracht van clients opdrachten laten uitvoeren, wordt ervoor gezorgd dat clients minder zware verwerking hoeven te doen en servers optimaler gebruikt worden, waarmee het geheel aan computing efficiënter en effectiever plaatsvindt.’

4.2.4 Fenomeenprincipes Een fenomeenprincipe is de uitleg of de beschrijving van de gehandhaafde werking van een fenomeen met een bepaald geproduceerd resultaat tot gevolg. Een fenomeenprincipe wordt ook wel het werkingsprincipe genoemd van een fenomeen. Waarom onderkennen we deze soort, wat is de functie ervan? De reden dat naar het principe van een fenomeen wordt gekeken is om van het fenomeen te leren, het gedrag ervan te voorspellen, zodat men zich er bijvoorbeeld beter op kan voorbereiden of het naar de hand kan zetten. Voorbeeld van een fenomeenprincipe Het principe van de loyale klant: ‘Door klanten vanuit afspraken over klantcontact correct te behandelen, wordt ervoor gezorgd dat klanten vaker en meer terug zullen keren naar de organisatie met hun klantvragen, waarmee de organisatie een hogere omzet zal hebben.’


47


www.dragon1.org

4.2.5 Realiteitsprincipes 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 we deze soort, wat is de functie ervan? 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.

Voorbeeld van een realiteitsprincipe Het geen-business-case-principe van projecten: ‘Door in de organisatie projecten op te starten zonder business case wordt ervoor gezorgd dat veel projecten niet te relateren zijn aan een bedrijfsdoelstelling waarmee projecten wel tijd, geld en resources kosten, maar niet bijdragen aan het resultaat van de organisatie.’

48



Hoofdstuk 4

4.3 Principes naar gebruiksdoel 4.3.1 Analyseprincipes Een analyseprincipe is de uitleg of de beschrijving van de gehandhaafde werking van een analyse met een bepaald geproduceerd resultaat tot gevolg. Een analyseprincipe wordt ook wel het werkingsprincipe genoemd van een analyse. Waarom onderkennen we deze soort, wat is de functie ervan? We onderkennen deze soort om met meer controle en beheersing kwalitatief hoogwaardige analyses te kunnen uitvoeren die van grote toegevoegde waarde zijn als opmaat voor bijvoorbeeld het maken van een ontwerp of het nemen van een managementbeslissing. Voorbeeld van een analyseprincipe Het objectiviteitsprincipe: ‘Door de werkelijkheid in al haar complexiteit, disstructuur en lelijkheid in beeld te brengen zorgt men voor het beter kunnen beheersen en verbeteren van de werkelijkheid. Het negeren van complexiteit zorgt voor het tegenovergestelde.’ Het principe van waarnemen en registreren: ‘Door waargenomen feiten objectief zonder waardeoordeel / interpretatie te registreren, wordt ervoor gezorgd dat de waarnemingen voor veel verschillende analyses te gebruiken zijn waarmee de geleverde inspanning herbruikbaar en rendabel is.’

4.3.2 Ontwerpprincipes De architect maakt architectuurontwerpen van bouwwerken. Om een hoge kwaliteit van het bouwwerk te realiseren, maakt een architect gebruik van principes, werkingen die gelden en waar hij maar beter rekening mee kan houden omdat ze altijd waar zijn, bij het ontwerpen. Deze principes noemt Dragon1 ontwerpprincipes. Waarom onderkennen we deze soort, wat is de functie ervan? Een architect dient ontwerpprincipes te kiezen die helpen de kwaliteitseisen, strategische uitgangspunten en randvoorwaarden te realiseren of eraan tegemoet te Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

49


www.dragon1.org

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 elke 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 te 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.

Voorbeeld van een ontwerpprincipe Het principe van hergebruik: ‘Door een component zodanig te ontwerpen en te realiseren dat deze herbruikbaar is in of door een ander systeem als bijvoorbeeld het eerste systeem waarin het geplaatst wordt is verouderd, wordt ervoor gezorgd dat de verbruikte energie om de component te maken niet geheel verloren is gegaan, waarmee componenten en de systemen minder onnodig energie, tijd, geld en resources gebruiken en verbruiken.’

4.3.3 Realisatieprincipes Een realisatieprincipe is de uitleg of de beschrijving van de gehandhaafde werking van het realiseren van een systeem met een bepaald geproduceerd resultaat tot gevolg. Een realisatieprincipe wordt ook wel het werkingsprincipe genoemd van een realisatie. Waarom onderkennen we deze soort, wat is de functie ervan?

50



Hoofdstuk 4

Door deze soort te onderkennen worden de aanwezige gehanteerde realisatieprincipes meer inzichtelijk en beter duidelijk gemaakt. Realisatieprincipes zijn er altijd, daarom is het maar beter er een aantal inzichtelijk te maken.

Voorbeeld van een realisatieprincipe Het principe van 80/20. 80% van een systeem realiseer je in 20% van de tijd. De grote stappen zet je snel en de fijnafstemming duurt het langst.

4.3.4 Beheerprincipes Een beheerprincipe is de uitleg of de beschrijving van de gehandhaafde werking van het beheren van een systeem met een bepaald geproduceerd resultaat tot gevolg. Een beheerprincipe wordt ook wel het werkingsprincipe genoemd van beheer. Waarom onderkennen we deze soort, wat is de functie ervan? We onderkennen deze soort van principe om zo hoog mogelijk kwaliteit van het beheren van systemen voor elkaar te krijgen Voorbeeld van een beheerprincipe Het principe van versiebeheer: ‘Door de versie van een systeem correct te administreren en inzichtelijk te hebben, wordt ervoor gezorgd dat niet met de verkeerde versie van het systeem wordt gewerkt, waarmee de organisatie minder fouten maakt.’

4.3.5 Architectuurprincipes Een architectuurprincipe is een conceptprincipe van een concept dat is toegepast op een bouwwerk. Het concept is daardoor onderdeel geworden van de architectuur, mits het concept een decoratief, operatief of constructief concept van betekenis is voor het bouwwerk. Dus niet alle concepten die worden toegepast op een bouwwerk zijn onderdeel van de architectuur. Dus ook niet alle principes in een bouwwerk zijn architectuurprincipes.


51


www.dragon1.org

Een controle of een concept of principe tot de architectuur behoort, is de volgende: als u iets aan een bouwwerk kan veranderen zonder dat daardoor het bouwwerk wezenlijk of van wezen verandert, dan verandert u nog niet de architectuur.

Waarom onderkennen we deze soort, wat is de functie ervan? Deze categorie van principe is de allerbelangrijkste categorie van principes. U geeft namelijk hiermee aan waar in essentie een bouwwerk op leunt of stoelt. U geeft de grondvesten of grondslagen aan. Gaat een van deze architectuurprincipes onderuit, dan valt het hele bouwwerk in duigen. 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 zou overal kunnen gelden in een bouwwerk. Dit zou kunnen gelden voor mensen, voor softwaresystemen en voor 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: 

52

Een architectuurprincipe is een, veelal van context ontdaan, conceptprincipe dat overal en altijd bij alles in een systeem, zoals een bouwwerk, geldig is qua werking en resultaat.



Hoofdstuk 4

Een architectuurprincipe is een veelal universeel principe dat holistisch is toegepast in een systeem zoals een bouwwerk en daarom integraal een uitspraak doet over de wijze waarop het systeem is ontworpen, gerealiseerd en werkt. Een architectuurprincipe is decoratief, operatief en/of constructief conceptprincipe dat is gekoppeld aan het invullen van een strategisch uitgangspunt of realiseren van een bedrijfsdoel, eis of randvoorwaarde betreffende een systeem zoals bouwwerk. In een onderneming zijn vele principes aanwezig, enkele daarvan zijn integraal toegepast, met andere woorden, er is haast geen uitzondering op. Op dat moment maken we in feite verschil tussen enterprise principes en enterprise architectuurprincipes. Als dit verschil niet of lastig te maken is, zijn in feite alle enterprise principes ook enterprise architectuurprincipes. Maar dan kan de hoeveelheid principes dusdanig groot worden dat er niet meer mee te sturen valt. Ook zijn enterprise principes pas mogelijk enterprise architectuurprincipes als ze te koppelen zijn aan strategische uitgangspunten, bedrijfsdoelen en kwaliteitseisen of prestatieeisen aan de functies een bouwwerk. Als dit niet mogelijk is, zijn de principes te onbelangrijk om al architectuurprincipe te worden gezien. Figuur 4 geeft een voorbeeld hoe van concepten in de buitenwereld architectuurconcepten worden gemaakt en hoe van AS-IS conceptprincipes TO-BE architectuurprincipes worden gemaakt.


53


Mobiele werkplek

Server Based Computing

Integraal Klantbeeld Conceptprincipe: Door alle informatie betreffende dienstverlening rondom een klant te bundelen en in samenhang weer te geven wordt er voor gezorgd dat klanten meer en beter gebruikmaken van producten en diensten van de organisatie en dat medewerkers klanten meer en beter bedienen.

1

Proces Server

Automatisering

Architectuur = Het samenhangend geheel van toegepaste concepten op een bouwwerk.

Conceptprincipe: Door op een server vele zware werkzaamheden voor clients uit te voeren benut je de server optimaler en kunnen de clients van lagere capaciteit zijn.

Industrie & Wetenschap Thuis werken

www.dragon1.org

Computing

Architectuurconcept

Dienstverlening Procesautomatisering Client / Server Computing

Client

Zelfbediening

MBO - Mijn Bank Onderneming

Zaakgericht Werken Internet Conceptprincipe: Verregaande automatisering van activiteiten leidt tot verhoging van capaciteit en productiviteit van resources.

Self service portaal

3 Besturing

Architect Zorg

MBO Online Bankaccount 2.0

Overheid

Bedrijfsvoering Onderwijs

Medewerker

Financieel

Klant

2 MijnOverheid / PIP

EPD

e-Portfolio

Online bankaccount

Integraal Klantbeeld

Informatie Producten

e-Health

e-Government

e-Learning

Dienstverlening

Contracten

e-Finance

Architectuurprincipe: Door alle informatie betreffende dienstverlening van MBO rondom een klant te bundelen en in samenhang weer te geven wordt er voor gezorgd dat klanten meer en beter gebruikmaken van producten en diensten van MBO en dat onze medewerkers klanten meer en beter bedienen.

Klanten

Infrastructuur

Bron: Dragon1

Figuur 4. Voorbeeld van principes van toepassing op een organisatie. Architectuurprincipes zorgen voor herhaling, hergebruik, patronen, ritme en structuur in een bouwwerk. Stel dat de architectuur van een voorbeeldonderneming BetereZorg BV, dus de enterprise architectuur van BetereZorg, onder andere de volgende concepten bevat: Klantgericht werken (met o.a. klant als deelconcept)

Begeleid wonen

Zorgdienstverlening

Productgericht werken (met o.a. product deelconcept)

Declaraties

Portfolio Management

Dienstgericht werken

Zorgmeldkamer

Virtualisatie

Productlabeling

Dag-en-nacht-

eProcurement

54



Hoofdstuk 4

begeleiding Procesmatig werken

Afdelingsgericht werken

Webbased ERP

Corporate Governance

Telecommunicatie

Enterprise Portals

Zaakgericht werken

Internet en intranet en extranet

CRM

Projectmatig werken

Inkoop en Assemblage

Selfservice

Domotica

Locatieonafhankelijk werken

IT Service Management

Zelfstandig wonen

Systeemonafhankelijk Integraal Klantbeeld

Client Server Computing

E-zorg

Verkoop en Marketing

Server Based Computing

Thuishulp

Platform onafhankelijke informatieuitwisseling

IP Networking

Thuiszorg

Cloud Computing

Officegerichte informatievoorziening

Thuiswonerdossier beheer

Risicobeheer

Service oriented applicaties

Deze concepten werken allemaal verschillend en hebben daarom ook verschillende principes. Echter, er zijn wel leidende principes uit te halen. Niet elke concept is namelijk belangrijk of krijgt voorrang. Ook zijn er principes die geheel of gedeeltelijk of in generieke zin, in meer dan een concept voorkomen. Deze principes Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

55


www.dragon1.org

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 meer generiek 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 werkconcepten 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

4. Het principe van uitbesteden 5.

Het principe van informatisering

6. Het principe van automatisering Enterprise architectuurprincipes geven inzage in de wijze waarop competitief dan wel uniek de kernactiviteiten werken. Al deze architectuurprincipes komen per stuk in meer dan een concept terug. Het hangt echter van de kennis en ervaring van de architect af welke architectuurprincipe

56



Hoofdstuk 4

hij kent of herkent in de architectuur van een bouwwerk. De gegeven voorbeeldlijst 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 concepten: er moet gewerkt (kunnen) worden, en 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.

4.4 Principes op thema of domein 4.4.1 Enterprise principes Ondernemingsprincipes betekenen in Dragon1 de wijze waarop ondernemingsbrede concepten werken. Als bepaalde ondernemingsconcepten zijn gekozen binnen de onderneming, dan beschrijven de principes van deze ondernemingsconcepten (de ondernemingsprincipes) de wijze waarop de business van een onderneming werkt.

Waarom onderkennen we deze soort principe? Deze principes geven inzage in de fundamentele grondslagen van de organisatie. Als een onderneming klantgericht, procesgericht of dienstgericht is, ziet men op business niveau, informatie niveau en technisch niveau de klant, proces of dienst als element, component of object terug komen. Een voorbeeld van een ondernemingsprincipe


57


www.dragon1.org

Het bron-vraagprincipe: ‘Door altijd eerst te vragen wat de bedoeling is en wie de bron is die het vraagt, zorgt men ervoor dat er minder vaak iets wordt gedaan zonder dat er om gevraagd wordt, of dat het verkeerde wordt gedaan voor iets of iemand.’ Dit principe kan gelden in de business, informatievoorziening en ICTinfrastructuur. Het serviceprincipe: ‘Door altijd diensten conform afspraak te verlenen, wordt ervoor gezorgd dat niet teveel geld, tijd of resources worden gebruikt, of dat een onnodige hoge kwaliteit van dienst wordt verleend, waarmee de afnemer van de dienst vaker tevreden zal zijn en de gehele operatie minder tijd, geld en resources kost.

4.4.2 Bedrijfsprincipes Bedrijfsprincipes betekenen in Dragon1 de wijze waarop bedrijfskundige concepten, bedrijfskundige elementen, bedrijfskundige componenten, bedrijfskundige objecten of technische bedrijfskundige producten werken of in elkaar steken. 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. Het woord bedrijfsprincipe laat eigenlijk in het ongewisse of we met soort entiteit als een concept, element, component, object of technisch product als onderwerp te maken hebben. Daarom is een goede context duiding, waar de entiteit zich in bevindt in een dergelijk principe extra belangrijk. 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 zich presenteren in de wereld. Strategische bedrijfsuitgangspunten zijn een hoger doel, een streven naar een bepaalde toestand en een uiting van een 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. Een onderneming bestaat vaak uit bedrijven. Voor zorginstellingen en gemeenten geldt dit bijvoorbeeld ook. Deze bedrijven (ook wel diensten of sectoren genoemd)

58



Hoofdstuk 4

organiseren de uitvoering van activiteiten in bedrijfsfuncties, zoals inkoop, verkoop, productie en ontwikkeling. Soms is een bedrijf helemaal ingericht voor het uitvoeren van een enkele functie, zoals een inkoopbedrijf of verkoopbedrijf. Bedrijfsprincipe geeft inzage in hoe iets werkt binnen een bedrijf. Een bedrijfsfunctieprincipe geeft inzage in hoe iets werkt binnen een bedrijfsfunctie. Waarom onderkennen we deze soort, wat is de functie ervan? Binnen een bedrijf worden er altijd geheel of gedeeltelijk bepaalde functionele activiteiten uitgevoerd, bijvoorbeeld inkopen, verkopen, ontwikkelen en produceren. Een bedrijf moet ervoor zorgen, afhankelijk van missie, visie, cultuur, identiteit en strategie, dat de activiteiten effectief, efficiënt en zeer competitief worden gedaan. Het verkoopbedrijfsprincipe vertelt dus hoe verkopen werkt binnen het bedrijf. Een bedrijfs(concept)principe verschilt van een bedrijfsontwerpprincipe en een bedrijfsarchitectuurprincpe. Een bedrijfsontwerpprincipe zegt welke werking is of moest worden toegepast bij het maken van het ontwerp van een bedrijf. Een bedrijfsprincipe is een werking die is of aanwezig moet zijn in een bedrijf na realisatie. Een voorbeeld van een bedrijfsconceptprincipe Het principe van kernactiviteit gericht werken (een bedrijfs concept): ‘Door alleen die activiteiten uit te voeren die onderdeel zijn van de kern van de zaak en de overige activiteiten uit te besteden, wordt ervoor gezorgd dat men in de organisatie zich kan focussen en verder kan professionaliseren in de activiteiten die de organisatie uniek maken waarmee de organisatie haar concurrentiepositie en haar voortbestaan alleen maar verder zal verstevigen.’ (als een strategisch uitgangspunt, bedrijfsdoel, eis of randvoorwaarde is die om dit principe vraagt, dan wordt het concept onderdeel van de architectuur en wordt dit conceptprincipe een architectuurprincipe. Een voorbeeld van een bedrijfsontwerpprincipe Het ontwerpprincipe van modulaire organisaties: ‘Door een organisatie bij het ontwerpen op te delen in verschillende onafhankelijk van elkaar opererende onderdelen (loosely coupled), die echter wel in nauwe samenwerking staan, wordt er voor gezorgd dat een bedrijfsonderdeel op enjig moment makkelijker met lage Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

59


www.dragon1.org

impact te vervangen is, dan wanneer de onderdelen niet loosely coupled zijn, waarmee de organisatie sneller en beter kan groeien en concurreren. Een voorbeeld van een bedrijfsarchitectuurprincipe Het principe van professionele bedrijvigheid en specialisatie (een bedrijfsconcept): ‘Door als organisatie voor bepaalde inspanning en resultaat een eerlijke vergoeding te verlangen die rechtdoet aan het verrichte aan de opdrachtgever, wordt ervoor gezorgd dat de organisatie zich legitiem steeds meer en vaker kan bekwamen in deze inspanning en resultaten waarmee de organisatie zich kan onderscheiden en meer opdrachten op dit gebied zal krijgen.’ Dit is een bedrijfsarchitectuurprincipe omdat de organisatie als doel heeft: ‘Alles wat wij doen moeten wij in het licht van het voortbestaan van de organisatie kunnen rechtvaardigen’.

4.4.3 Informatie principes Binnen een onderneming is informatie aanwezig, de betekenisvolle interpretatie van gegevens. Deze informatie wordt steeds vaker bewust en strategisch ingezet voor een beter werking van de onderneming. Hiervoor maken ondernemingen gebruik van informatievoorziening richting onder andere medewerkers, organisaties en applicaties. Deze informatievoorziening vindt plaats door middel van informatieverzorging vanuit een informatiehuishouding. Deze drie begrippen zijn concepten voor een optimale inzet van informatie in de onderneming. Een onderneming, de medewerker en applicaties binnen de bedrijven van een onderneming voeren activiteiten uit op de informatie. Dit zijn veelal activiteiten zoals inname, verzamelen, verrijken, beoordelen, behandelen, bewerken, verwerken, archiveren, doorsturen, publiceren en aanbieden. Waarom onderkennen we deze soort, wat is de functie ervan? Informatieprincipes geven inzage in de wijze waarop een onderneming dit soort activiteiten verrichten. Informatieprincipes geven ook inzage in de kwaliteit en prestaties van bepaalde soort informatie en activiteiten op informatie. Bijvoorbeeld hoe medewerkers onafhankelijk van locatie, tijd of processtap de beschikking hebben of toegang kunnen verkrijgen tot juiste, tijdig en correcte informatie. 60



Hoofdstuk 4

Een voorbeeld informatieprincipe In elke onderneming is er informatie over producten, diensten, zaken, klanten en medewerkers. Een voorbeeld informatieprincipe betreffende het omgaan met zaakinformatie is: ‘Door altijd alle samenhangende informatie omtrent het werk door medewerkers in het verstrekken van producten en verlenen van diensten aan klanten te verzamelen, beheren en analyseren vanuit de inzet en het verplicht gebruik van een zakensysteem, wordt ervoor gezorgd dat voor klant en onderneming op elk gewenst moment of locatie beter inzichtelijk te maken is welke informatie wordt gebruikt en wat de status is van de productverstrekking en dienstverlening, waarmee klanten en de onderneming de mogelijkheid krijgen de kwaliteit van informatie overal, altijd en op elk punt in het dienstverleningsproces te verbeteren en te verhogen wat een goede verstrekking van producten en verlening van diensten ten goede komt. Dit zorgt weer voor een hogere klantentevredenheid. Deze paragraaf is een pleidooi voor ondernemers om met principes inzichtelijk te maken hoe nu en in de toekomst wordt omgegaan met of zou moeten worden omgegaan met informatie. Welke prestaties en welke kwaliteit in het omgaan met bepaalde soort informatie moet worden nagestreefd?

4.4.4 Technische principes Een technisch principe is de uiting of beschrijving van de werking van een technische entiteit die onderdeel is van de ICT-infrastructuur van een onderneming, zoals een client, server of netwerk.

Waarom onderkennen we deze soort, wat is de functie ervan? Elke organisatie heeft tegenwoordig een ICT-infrastructuur. Bijvoorbeeld vanwege een bedrijfsnetwerk of een website. Op het moment dat er een ICT-infrastructuur in de organisatie is, zijn er technische principes die een rol gaan spelen. Bijvoorbeeld vernieuwing of alignment van de ICT-infrastructuur mogelijk maken of juist blokkeren. Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

61


www.dragon1.org

Wat is een voorbeeld van een technisch principe? ‘Door medium en kanaal transparant/onafhankelijk informatie, communicatie en transacties aan te bieden aan klanten, wordt ervoor gezorgd dat klanten meer en vaker gebruikmaken van producten en diensten van de organisatie waarmee de omzet van de organisatie wordt vergroot.’

4.4.5 Security principes Integrale beveiliging en informatiebeveiliging zijn onderwerpen waarin de meeste ondernemingen nog veel bewustwording dienen op te doen. De mogelijkheden van internet, nieuwe media en nieuwe digitale hulpmiddelen zorgen voor een lage drempel van het publiceren en delen van informatie. Wanneer onbevoegden toegang verkrijgen tot strategische, tactische of operationele informatie kan dit op strategisch, tactisch en operationeel niveau de onderneming verstoren. Met securityprincipes maakt een onderneming inzichtelijk hoe voor welke entiteiten, zoals mensen, applicaties, gebouwen en ruimten, de toegang gecontroleerd wordt en is georganiseerd. Het in beeld brengen van securityprincipes in de huidige situatie (de AS-IS Security principes) geven vaak het beeld dat voor veel soort entiteiten onbedoeld en onbewust niet gecontroleerde toegang mogelijk is. Soms hebben beheerders van leveranciers van softwareoplossingen op afstand noodzakelijke toegang tot financiële gegevens van de klant, zonder dat iemand zich hier ook maar bewust van is, en dat afdoende maatregelen zijn genomen.

4.5 Principesraamwerk Wanneer in een onderneming principes worden onderkend, is het verstandig een raamwerk te maken waarin blijkt voor welke architecturen, domeinen of systemen principes worden onderkend. Ook wordt met een dergelijk raamwerk duidelijk gemaakt wie de eigenaar is van het onderdeel waar het principe geldig voor is. En dus indirect de eigenaar van het principe. Het principesraamwerk maakt de scope 62



Hoofdstuk 4

duidelijk van het principe. Bijvoorbeeld ook waar in de organisatie verschillende principes gelden voor dezelfde onderdelen. In het ene bedrijf van een onderneming kunnen andere bedrijfsprocesprincipes gelden dan in het andere bedrijf. Zie hieronder het figuur 5, een generiek enterprise architectuurraamwerk, waar concepten in zijn geplaatst.

Market architecture Doelgroep marketing

Open markt

Enterprise architecture

Business architecture Procesmatig werken

Het nieuwe werkplek

Projectmatig werken

Cross-selling

Service orientatie

Eenmalige gegevensopslag

Door virtualisatie een sterk schaalbare omgeving

IT-architecture Server-virtualisatie

Flex-werkplekken

Thin clients

Self service

Competentie management

Information architecture Integraal klantbeeld

7 x 24 globaal zaken doen

Door eenmalige opslag altijd consistentie in gegevens

Outsourcing Open source

Single signon

Security Architecture

Virtual Marketplace

Figuur 5. Enterprise architectuurraamwerk met concepten erin geplaatst. In deze figuur staan verschillende concepten geplaatst in het enterprise architectuurraamwerk van een organisatie. Door deze concepten te plaatsen in het raamwerk wordt daarmee in feite gezegd dat het principe van deze concepten van toepassing is in deze organisatie, voor de beschouwingsperiode van dit raamwerk, bijvoorbeeld AS-IS of TO-BE. Met kleur en lijnstijl kan nu bijvoorbeeld worden aangegeven wat de status en typering is van deze concepten en hun principes. In deze figuur staat bijvoorbeeld dat het concept van eenmalige opslag nog niet leidt tot consistentie in gegevens. Met andere woorden: het principe van het concept werkt nog niet goed.


63


www.dragon1.org

Hoofdstuk 5

De attributen van een principe Hoe meer attributen van het principe te benoemen zijn; hoe eenvoudiger en begrijpelijker het principe wordt.

64



Hoofdstuk 5

5.1 Functies van attributen 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. 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.


65


Verwijzing

www.dragon1.org

Attributen die behoren tot de functiesoort Verwijzing bevatten achtergrondinformatie,

verwijzingen

en

referenties

of

gaan

specifieker in op bepaalde aspecten die eerder zijn beschreven in andere attributen van het principe.

Beheer

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

5.2 Overzicht van attributen Nr., Naam

Omschrijving

Functie

1. Exploitatie en

Welke hoger liggende doelen en uitgangspunten

Motivatie

veranderdoelen

liggen ten grondslag aan de keuze van het concept en het opstellen van het principe? 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.

66



2. Short Statement

Hoofdstuk 5

De formulering van het short statement (de korte

Werking /

omschrijving van een principe) luistert nogal

Communicatie

nauw. 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 oorzaakgevolg relatie te beschrijven, maar dient minimaal een 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 bepaalde oplossing, aanpak of werkwijze. • Deel

1.1

-

handhavingsmechanisme:

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 Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

67


www.dragon1.org

bereikt dient te worden, welke gewenste situatie bereikt dient te worden of probleem dat 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 principeattribuut short statement een voorkeur schrijfwijze aan gedragen ter bevordering van de kwaliteit,

documentatie

en

hergebruik

van

principes. Dit heet de door-formulering. Deze

luidt:

Door

[actieregel]

vanuit

[handhavingsmechanisme] zorgt [houder] ervoor dat [gebruiksregel], zodat [effectregel - 1e resultaat] waarmee [effectregel - 2e resultaat] etc…

3. Rationale

De rationale dient te onderbouwen waarom een

Motivatie

principe werkt zoals het werkt. Er dient ook uitgelegd te worden waarom dit principe in de gegeven context zal werken. Zeg wat de achterliggende systemen, concepten en fenomenen zijn van het principe. Hierin ligt ook vaak een rationale besloten.

68



4. Kwaliteitseisen

Hoofdstuk 5

De (kwaliteit)eisen die worden gesteld door belanghebbenden

aan

een

Motivatie

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. 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)

5. Klasse

Wat is de kernstructuur van de werking van het

Context

principe? Is het een kringgedrag principe? Is het een taak/volgorde keten principe


69


www.dragon1.org

Is het een actie-reactie keten principe?

6. Soort principe

Geef aan wat voor een soort principe het is.

Context

Hiervoor kan de indeling gebruikt worden die eerder in dit document beschreven is. Indien binnen de onderneming andere soorten principes of andere benamingen worden gebruikt kunnen deze worden gebruikt als classificatiemiddel.

7. Soort domein,

Is het principe dat geldig is binnen inkoop,

systeem, functie of

verkoop,

proces

financiën, ICT (IV, ICT-Infra)?

marketingcommunicatie,

Context

productie,

Is het een principe dat geldig is binnen de consumentenmarkt,

back office,

een

winkel-

formule of een assortiment? Hanteer

hier

begrippen

onderneming onderkend

die worden

binnen

de

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

70

Is het een principe op het niveau van de / het: 

Megastructuur



Keten



Onderneming



Deelonderneming

Context





Bedrijf



Bedrijfsonderdeel



Bedrijfsfunctie



Bedrijfsproces



Bedrijfstaak



Bedrijfshandeling

10. Beschouwings-

Dit attribuut geeft aan in welke beschouwings-

situatie of moment

situatie het principe geldig dient te zijn of

Hoofdstuk 5

Context

gehanteerd / toegepast dient te worden. We maken onderscheid in de situatietypen principes: AS-IS principes, Plateau N principes, TO-BE principes, Envision principes en Timeless principes. Timeless principes zijn principes waar de tijd geen vat op heeft. Voor de mensheid betekent ‘altijd en eeuwig’ vaak de tientallen miljarden jaren dat onze zon bestaat en dat onze aarde bestaat. 

Een AS-IS principe 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 principe is een principe dat zich tijdelijk voordoet (jaar X).



Een TO-BE principe 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.


71




www.dragon1.org

Een Envision principe 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 principe is een principe dat altijd van toepassing is en dus tijdonafhankelijk.

11. Principe-

Hier dienen de gekozen principeoplossingen

oplossingen / wijze

beschreven te worden. Deze zijn al kort beschreven

van aanpak

in het ‘Actie’-regel gedeelte van het principe. De

Werking / Handhaving

‘Actie’-regel wordt hier dus in meer detail uitgewerkt. Per principeoplossing (aanpak) dient de naam en omschrijving vastgelegd te worden.

12. Conflicterende

Hier dient vermeld te worden met welke andere

principes

principes het principe in conflict is of kan komen.

13. Alternatieve

Hier dient vermeld te worden welke alternatieve

principes

principes er zijn. Geef hier ook aan waarom juist

Bedreiging

Motivatie

voor dit principe / concept is gekozen en waarom dit principe ‘beter’ is dan de alternatieven.

14. Validiteit

Hier dient de mate waarin een principe een

Bedreiging

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-of-concept’?

15. Issues en

Dit attribuut beschrijft de interne issues en

conflicten

conflicten die het hanteren of toepassen van een

Bedreiging

principe met zich mee (zal gaan) brengt binnen de

72



Hoofdstuk 5

gegeven context (bouwwerk). Wat zijn de haken en ogen aan het principe om het in de context te hanteren? Waar

conflicteert

principes,

dit

principe

uitgangspunten,

met

regels

andere

binnen

de

context?

16. Bedrijfs-

De voor- en nadelen van het toepassen /

voordelen / nadelen

onderkennen van het principe dienen beschreven

Bedreiging / Motivatie

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

handhavingsmechanisme

tegenop

kan

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

17. Extern

Hier dienen de externe handhavingsmechanismen

handhavings-

beschreven te worden die noodzakelijk zijn om het

mechanisme

principe te laten werken binnen een context.

Handhaving

Dit is nodig om het principe binnen een bepaalde context

altijd

te

kunnen

af

te

dwingen.

Voorbeelden van handhavingsmechanismen voor principes zijn: toezicht, controle, sociale druk, beloning, bestraffing en dwingende structuren.

18. Implementatie

Wat dient er te worden aangepast om een principe

impact

te laten zijn werken in een context. Hoeveel tijd,


Handhaving

73


www.dragon1.org

geld en middelen kost het principe om (qua handhaving en structuurwijziging) te verwezenlijken? Een grove financiële inschatting kan mogelijk al gegeven worden.

19. Contextuele

Beschrijf op welke contextuele entiteiten het

entiteiten

principe betrekking heeft.

Verwijzing

Voorbeelden van onderdelen in de context waar een principe voor kan gelden zijn: systeem, systeemonderdeel, instelling,

organisatie,

organisatiedomein,

onderneming, 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-,

Beschrijf

van

welke

systemen,

concepten,

concept- of stijl-

fenomenen of stijlen het principe onderdeel is.

Verwijzing

verwijzing

21. Bron

Voorbeelden van bronnen van principes zijn: de

(vermelding)

natuur,

ervaring,

een

door

de

Verwijzing

industrie

ontwikkelde technologie, een best practice, een bewezen concept. De bronvermelding voor een principe is 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

74



Hoofdstuk 5

de bronvermelding te staan.

22. First principle

Ieder systeem, stijl, fenomeen of concept heeft een

Verwijzing

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. 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

Verwijzing

of fysiek niveau?

24. Status

We maken onderscheid in de volgende statussen

Beheer

van een principe: 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.


75


25. Naam

www.dragon1.org

Een short statement van één tot tien woorden

Communicatie

maakt duidelijk wat de context en werking van het principe is. Bijvoorbeeld: het zwaartekrachtprincipe of het gedigitaliseerde werkprocessenprincipe.

26. ID (0)

Vanwege de vele principes in een architectuur

Beheer

dient een principe een unieke identificatie te hebben. Het ID betreft hier een uniek nummer of unieke code.

27. Eigenaar en

Wie de eigenaar en wie is de beheerder van het

Beheerder

principe?

28. Alternatieve

Hier dient de

representatiewijze

beschreven of getoond te worden. Dit attribuut kan

alternatieve

representatiewijze

Beheer

Communicatie

ook een verzameling van verschillende alternatieve representatiewijzen bevatten. 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.

76



Hoofdstuk 6

Hoofdstuk 6

Relaties van principes Zonder uitgangspunt of doel is er geen noodzaak voor principes.


77


www.dragon1.org

6.1 Relaties van principes met entiteiten Principes staan niet op zichzelf, maar hebben met vele andere soorten entiteiten relaties. Zo beschrijft een principe altijd de werking van iets, en is het geproduceerde resultaat van een principe vaak voordelig in het licht van doelstellingen of eisen.

6.2 Relaties tussen managementconcepten In figuur 6 staat een entiteitenrelatiemodel dat voor veelvoorkomende soorten entiteiten de relatie aangeeft met het principe. Principe is als begrip een managementconcept. Binnen de organisatie heeft principe een bepaalde vaste relatie met diverse andere managementconcepten. identiteit Past het principe bij of in deze organisatie?

architectuur

missie concept

uitgangspunt belanghebbende

doel

randvoorwaarde behoefte

bouwwerk

Welk resultaat boekt dit principe bij toepassing in een context

principe

eis Vraagt de strategie om het resultaat van dit principe?

beleidsuitspraak

resultaat

handhavingsmechanisme

entiteit

regels

context

werking

architect

ontwerpbeslissing

Figuur 6. Entiteitenrelatiemodel. Hieronder staan de gemodelleerde regels van het model uitgeschreven:

78



1.

Hoofdstuk 6

Belanghebbenden stellen op basis van hun behoeften uitgangspunten, doelen, eisen en randvoorwaarden aan een bouwwerk, zoals een organisatie.

2. De identiteit en missie van een bouwwerk, zoals een organisatie bepalen als kader of een principe wel of niet past in een organisatie. 3.

De architectuur van een bouwwerk bestaat uit het geheel van concepten dat is of wordt toegepast op een bouwwerk.

4. Elk concept heeft één of meer principes in zich. 5.

Een principe beschrijft de gehandhaafde werking een entiteit binnen een context met een bepaald resultaat tot gevolg.

6. Een principe bestaat onder andere uit verschillende regels. 7.

Een reden om een soort entiteit te kiezen als oplossingsrichting voor een vraagstuk ligt besloten in de voordelige werking en het voordelige geproduceerde resultaat van een principe.

8. Een beleidsuitspraak implementeert een (deel van een) principe. 9. Een ontwerpbeslissing implementeert een (deel van een) principe. 10. Een uitgangspunt legitimeert de keuze van een concept met een bepaald principe. 11. Een randvoorwaarde legitimeert de keuze van een concept met een bepaald principe. 12. Een doel legitimeert de keuze van een concept met een bepaald principe. 13. Een eis legitimeert de keuze van een concept met een bepaald principe. 14. Een architect beoordeelt of een principe een bepaald resultaat heeft in een context, of het principe noodzakelijk is vanwege de strategie en of een principe past in het bouwwerk zoals een organisatie. Pas dan stelt de architect aan de belanghebbenden voor (meestal de opdrachtgever) om het principe als architectuurprincipe te kiezen.


79


www.dragon1.org

6.3 Principes: de lijm tussen strategie en beleid Principes worden in Dragon1 gezien en gepositioneerd als de lijm tussen strategie en beleid. 1.

Ten eerste dient een organisatie een identiteit, missie en visie op thema’s te hebben, uitgangspunten en doelen te stellen en eisen en randvoorwaarden te stellen aan oplossingen en oplossingsrichting om uitvoering aan de strategie te kunnen geven.

2. Ten tweede dient de architect kennis te hebben van allerlei oplossingen en oplossingsrichtingen voor bepaalde soort vraagstukken in het algemeeen en bepaalde soort branche gerichte vraagstukken in het bijzonder. 3.

Ten derde selecteert de architect concepten als onderdeel van een oplossingsrichting of oplossing, op basis van de werking en resultaat van de werking (het principe) van een concept, waarbij de strategie om dergelijk resultaten moet vragen of verlangen.

4. Ten vierde, na keuze van de opdrachtgever voor het gebruik van het concept worden er diverse (beleids)maatregelen vastgesteld die als kaders naar projecten en afdelingen wroden gecommuniceerd.

80



Hoofdstuk 7

Hoofdstuk 7

Stappenplan voor het werken met principes En nu zelf aan de slag met het formuleren van de principes of het herformuleren van richtinggevende uitspraken.


81


www.dragon1.org

7.1 Inleiding In dit hoofdstuk staan drie verschillende stappenplannen voor drie verschillende activiteiten aangaande principes. Stappenplan 1 – Het formuleren van een principe Stappenplan 2 – Het selecteren van een principe Stappenplan 3 – Het gebruiken/implementeren van een principe (in beleid, ontwerp en realisatie). Stappenplan 1 en 3 worden in dit document uitgewerkt. Stappenplan 2 is hier buiten beschouwing gelaten.

7.1.1

Stappenplan

formuleren

en

1

-

Het

documenteren

zien,

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 bedenken van theorie. Dat kan natuurlijk niet eventjes, en dient zorgvuldig en weloverwogen te gebeuren. In feite zou elk principe dat we formuleren al goed gedocumenteerd in de 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 huizen één of meer principes in de omgeving, concepten, fenomenen, logische, fysieke en digitale systemen in de onderneming en in 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.

82



Hoofdstuk 7

Stap 1: Denk aan een vraagstuk, uitgangspunt, doelstelling of iets anders dat uzelf of dat men voor elkaar wil krijgen of wil 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. Realiseert u zich 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. 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 waarop soms ook maatwerk 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 koppelingen (en dan met name de kosten voor ontwikkeling, beheer en onderhoud) voor deze in feite dubbele applicaties, zouden niet nodig zijn indien iedereen voor deze generieke functionaliteit dezelfde applicaties zou gebruiken.


83


www.dragon1.org

Stap 4: Schrijf op welk concept (oplossingsrichting, werkwijze, idee, aanpak, abstractie van een implementatie) u kent waarmee u het vraagstuk kunt oplossen (geheel of gedeeltelijk). Schrijf van het concept op, op welke wijze het concept 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 indien alleen applicaties mogen worden aangeschaft in de organisatie die gebruikmaken van internationale open communicatiestandaarden, vaker en beter de aanwezige functionaliteit in de 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 concept ook deze 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 professionalisering bij ICT mag natuurlijk niet leiden tot verstarring en blokkering van innovatie of flexibiliteit in de business. Stap 6: Haal uit hetgeen dat u 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. Of bijvoorbeeld: Open applicaties leiden tot betere ondersteuning met ICT van bedrijfsprocessen. Stap 7: Benoem of achterhaal uit wat u nu hebt opgeschreven de actieregel: door wat te doen, gaat er iets gebeuren of in werking treden. 84



Hoofdstuk 7

Bijvoorbeeld: Door het aanschaffen van open component-based applicaties … Stap 8: Benoem of achterhaal uit wat u 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 u 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 het 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 handhavingsmechanisme dat ervoor zorgt dat de actieregel altijd leidt tot de effectregel. Bijvoorbeeld: Vanuit harde procesafspraken en stringent toezicht op inkoop en acceptatie van de softwareapplicatie. Het short statement van het principe ziet er uiteindelijk als volgt uit: "Door het aanschaffen van component-based applicaties die gebruikmaken van internationale open communicatiestandaarden vanuit harde procesafspraken en stringent toezicht op inkoop en acceptatie van de softwareapplicatie, wordt ervoor gezorgd dat applicaties sneller, vaker en beter op elkaar aansluiten en worden hergebruikt wat leidt tot lagere ontwikkelkosten, beheerkosten, minder ICT-incidenten 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 attributentabel in hoofdstuk 5.


85


Stappenplan

2

-

Het

www.dragon1.org

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 betekent direct dat een organisatie afhankelijk wordt gemaakt 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 is anders te onderbouwen dat de opdrachtgever voor een bepaald principe dient te kiezen.

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. Stel in een organisatie heeft men bepaalde principes onderdeel gemaakt van de architectuur. Door deze principes te laten leiden tot beleidsmaatregelen en ontwerpbeslissingen worden de principes toegepast. De eenvoud of het gemak waarmee een principe te vertalen is in beleidsmaatregelen en ontwerpbeslissingen hangt onder andere af van de mate waarin het legitiem wordt geacht een bepaald principe juist of correct te achten binnen de context. Veel ondernemingen hebben al architectuurprincipes opgesteld of 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. In de volgende paragraaf

86



Hoofdstuk 7

wordt aan de hand van het stappenplan een praktijkvoorbeeld van het gebruik van een principe in een context weergegeven.

7.2

Normaliseren / herformuleren van principes

Als u aan iemand vraagt wat principes zijn of welke principes degene ziet in de organisatie (of een willekeurig architectuurdocument raadpleegt), krijgt u 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 business case 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 u nauwkeuriger naar deze uitspraken kijkt, en dan met name de formulering, dan ziet u (door vanuit een bepaald perspectief te kijken) dat deze uitspraken eigenlijk regels, richtlijnen, uitgangspunten, normen, standaarden en waarden zijn.


87


www.dragon1.org

Hieronder volgt een korte analyse van de bovenstaande uitspraken. Wanneer we vanuit Dragon1 kijken naar deze uitspraken, zien we het volgende: 

Uitspraak 1 is een norm of gedragsregel. Het is bijvoorbeeld iets dat iemand met zichzelf heeft afgesproken, waar men zich dan aan houdt. Het geeft de dag structuur en degene voelt zich 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 immers al vaak opgestart zonder dat er überhaupt een business case 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 een 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 contexten. Omdat er geen context wordt geduid waarin altijd de bepaalde werking geldt, kan het niet als een ‘principe’ worden gebruikt door iemand.

88



Hoofdstuk 7

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.3

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 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:

1

RAW-statement:

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. Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

89


www.dragon1.org

Hierdoor wordt het duidelijk welke noodzakelijk informatie er al beschikbaar is voor het formuleren van het principe en welke informatie nog aangevuld dient te worden. We gaan er hiervan 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. Soms zijn principebeschrijvingen in een document een stuk tekst met een wervende titel, subtitel en sprekende foto of model erbij. In dit stuk tekst staan dan vele vaak vele concepten, principes, uitgangspunten, randvoorwaarden, normen, problemen, standaarden, doelen en eisen genoemd. Het is dan zaak om al deze aspecten in de principebeschrijving te herkennen en te classificeren. Criteria voor het herkennen (of classificeren) van de soort normatieve uitspraak (of onderdelen daarvan):

90



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. Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.


Hoofdstuk 7



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 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 kunt u 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. Is de uitspraak Evaluatieversie – deze versie mag worden gebruikt tot 1 augstus 2012 voor alleen evaluatiedoeleiden. Daarna dient dit document van computers en uit digitale opslag te worden verwijderd.

91


www.dragon1.org

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 ervan uit dat de uitspraak afkomstig is uit een ontwerpdocument van een applicatie en het dus een ontwerpregel betreft. 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. 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 heeft u 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 de 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 het 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.

92



Hoofdstuk 7

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 kaderbeperkingen 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 shortstatement van het principe te formuleren. Deze zou als volgt kunnen luiden: 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.

7.4

Het documenteren van een principe


93


www.dragon1.org

Het verdient aanbeveling om alle belangrijke principes van een organisatie of onderneming te documenteren in een database of document. Een criterium voor de principes die belangrijk zijn is: de conceptprincipes van de top 10 enterprise concepten, business concepten, informatie concepten en technische concepten die onderdeel zijn van de enterprise architectuur. Per principe is het dan verstandig om een architectuurartikel te maken. Een architectuurartikel is een document dat in artikelvorm (met titel, subtitel, datum, intro/inleiding, body, samenvatting en conclusie) voldoende ten behoeve van het gebruik door verschillende doelgroepen uitweidt over een entiteit, in dit geval een principe. Een voorbeeld van een architectuurartikel voor een principe is het volgende: My Bank Corporation Architectuurartikel: #0124A-sub a

SUBJECT

MBC

DOCUMENTATIE VAN EXTRA ATTRIBUTEN VAN HET PRINCIPE

MYBANKCORPORATION Architectuurprincipes

PRINCIPLE UNIQUE IDENTIFIER (HERHALING)

EAP001 PRINCIPLE NAME (HERHALING)

Het My Bank Corporation Unified Business Language Principe LONGSTATEMENT VAN PRINCIPE …hier kan wat proza staan….

LITERATURE-REFERENCES OF ORIGINAL PRINCIPLE (Waaruit blijkt dat achterliggende principes waar zijn, werken, voordelen opleveren in deze context?) Het concept van begrippenkader staat in het boek xxx uitgewerkt, beschreven en gedefinieerd. ACHTERLIGGENDE PRINCIPES: -Het spreken van één taal leidt tot één versie van de waarheid -Het hanteren van een gemeenschappelijke begrippenkader leidt tot elkaar beter begrijpen en minder verwarring over interpretatie -Het definiëren van een businessbegrip leidt tot eenduidigheid over een businessbegrip DEFINITIES VAN ENTITEITEN (CONCEPTEN ELEMENTEN EN COMPONENTEN) IN LITERATUUR: De gehanteerde definitie van een gemeenschappelijk begrippenkader is… De definitie van een business begrip is… De definitie van een taal is … De definitie van partijen is… (dit zijn niet-gedefinieerde begrippen in het principe!) De definitie van goed is …

<< Naar overzicht

OWNER VAN ENTITEIT Eigenaar van het My Bank Corporation begrippenkader is…? BELANGHEBBENDEN Klanten, Directie ARCHITECT VAN DIT ARCHITECTUURPRINCIPE Naam architect ARCHITECTUURSTIJL DE E-COÖPERATIEVE BANKARCHITECTUUR? STATUS/PERIODE Kandidaat principe | Effectief voor My Bank Corporation International en My Bank Corporation Nederland vanaf 01/01/2012 ? ARCHIVE/SOURCE Dit principe staat gedocumenteerd op de MBCWIKI? Dit principe staat ook in het document MBC-Architecture-Principles.docx

Details en implementatie van principe

Volgend principe >>

5 ARTICLE-CONTENT-TYPE: ARCHITECTURE PRINCIPLE

Januari 2011 - Een voorbeeld van een My Bank Corporation Architectuurprincipe op basis van Dragon1 - verzorgd door Paauwe Group BV

ARTICLE-CONTENT-VIEW-TYPE: PRINCIPLE DETAILS DOCUMENT-VIEW-TYPE: BASIC PAGE MANAGEMENT PRESENTATION

Figuur 7. documentatie voorbeeld van de extra attributen van een principe. Figuur 7 in combinatie met figuur 1 vormen de minimale basis voor het bruikbaar documenteren van principes. 94




Hoofdstuk 7

95


www.dragon1.org

Hoofdstuk 8

Literatuurverwijzing Het wiel opnieuw uitvinden is niet moeilijk, een wiel uitvinden dat altijd en overal in alle omstandigheden zijn werk doet wel, daarom maakt de slimme architect gebruikt van goede literatuur.

96



Hoofdstuk 8

In de volgende lijst staan verwijzingen naar literatuur die is geraadpleegd. Een verwijzing naar literatuur betekent niet automatisch dat de inhoud van de literatuur ook wordt overgenomen of dat de gehanteerde theorie wordt aangenomen. De lijst geeft wel limitatief een overzicht van de literatuur die bekend was bij de auteurs voor het maken van deze open standaard. 

[BBHP07] P. van Bommel, P.G. Buitenhuis, S.J.B.A. Hoppenbrouwers, and H.A. Proper, Architecture Principles – A Regulative Perspective on Enterprise Architecture. In M. Reichert, S. Strecker, and K. Turowski, editors, Enterprise Modelling and Information Systems Architectures (EMISA2007), number 119 in Lecture Notes in Informatics, pages 47–60, Bonn, Germany, EU, Oktober 2007. Gesellschaft fur Informatik.’



[Bui07] P.G. Buitenhuis, Fundamenten van het principle (Foundations of principles). Master’s thesis, Institute for Computing and Information Sciences, Radboud University Nijmegen, Nijmegen, The Netherlands, EU, March 2007. In Dutch.



[CJN+07] G.J.N.M. Chorus, Y.H.C. Janse, C.J.P. Nellen, S.J.B.A. Hoppenbrouwers, and H.A. Proper, Formalizing Architecture Principles using Object-Role Modelling. Via Nova Architectura, February 2007.



[Dragon1/07] M.A. Paauwe, Het methodisch raamwerk voor enterprise architectuur van Paauwe, december 2007.



[Dragon1/08a] M.A. Paauwe, Dragon1 Stappenplan – Architectuurprincipes opstellen, reviewen en herformuleren v0.15.2c, september 2008.



[Dragon1/08b] M.A. Paauwe, Dragon1 Architectuurprincipesschema – versie 0.3c, november 2008.



[Dragon10] Website Dragon1, Dragon1 – http://www.dragon1.org, november 2010.



[DYA06] Bijdrage van S. Bouwens, senior informatie architect, Sogeti Nederland B.V, aan de rubriek ‘Archi-tekst’ op www.dya.info.



[DYA08] S. Bouwens, White Paper 'Architectuurprincipes', deel 1: Basics, april 2008.


97


98

www.dragon1.org



[GEA01] – Sturen op samenhang op basis van GEA, Van Haren Publishing, ISBN 978-90-8753-4066 (2009).



[IEE00] Recommended Practice for Architectural Description of Software Intensive Systems. Technical Report IEEE P1471–2000, The Architecture Working Group of the Software Engineering Committee, Standards Department, IEEE, Piscataway, New Jersey, USA, September 2000.



[Paauwe10] M.A. Paauwe, De geschiedenis van architectuurprincipes, Uitgeverij Paauwe, ISBN: 9789490873035, deels gepubliceerd op XR Magazine in oktober 2010.



[Paauwe/Rijsenbrij07] M.A. Paauwe en D.B.B. Rijsenbrij, november 2007, Digitale architectuur in beeld brengen en communiceren op basis van het Paauwe-Rijsenbrij Visualisatieschema, Versie 0.3 – een verkenning.



[SBV06] SBVR Team. Semantics of Business Vocabulary and Rules (SBVR). Technical Report dtc/06–03–02, Object Management Group, Needham, Massachusetts, USA, March 2006.



[TOGAF08] Website Open Group – TOGAF, http://www.opengroup.org /togaf, november 2008.



[Rijsenbrij04] D.B.B. Rijsenbrij (2004), Architectuur in de digitale wereld (versie nulpuntdrie). Inaugurale rede (2004).



[xAF06] xAF working group. Extensible Architecture Framework version 1.1 (formal edition). Technical report, 2006.



[Paauwe09] Understanding Architecture Principles as the way things work – http://research.paauwe.info.



De Nederlandse Corporate Governance Code 2009, www.dnb.nl.



Dictionary of Architecture 9780071351782.



A Visual Dictionary of Architecture, Francis D.K. Ching, 2005, 9780471284512.



Basic Elements of Landscape Architectural Design, 1983, 78-0-88133-478.

and

Construction,

Cyril

M.

Harris,



Hoofdstuk 8



Basic Principles of Landscape Design, Gail Hansen / Dewayne L. Ingram http://edis.ifas.ufl.edu/mg086.



Hannebaum, Leroy. Landscape Design: A Practical Approach. Reston Publishing Company, Inc.: Reston, VA.



Ingels, Jack E. Landscaping: Principles and Practices. Delmar Publishers, Inc.: Albany, NY.



Johnson, James L., McKinley, William J. Jr., and Benz, M. “Buddy.” Flowers: Creative Design. San Jacinto Publishing Co.: College Station, TX.



Nelson, Wm. R., Jr. Landscaping Your Home. University of Illinois College of Agriculture Cooperative Extension Service: Urbana-Champaign, IL.



Piercall, Gregory M. Residential Landscapes: Graphics, Planning, and Design. Reston Publishing Company,Inc.: Reston, VA.



Elements and principles of landscape design, http://imsonline.tamu.edu /courses/samples/361landscape/361docs/8912bst.pdf.



Ontwerpprincipes IJsselstein (http://www.ijsselstein.nl/index.php? mediumid=4&pagid=328&rubriek_id=1266&stukid=2197).



http://www.dmwoordenboek.nl/index.php/Hoofdpagina.



Buitenruimte voor contact 2010 – http://www.buitenruimtevoorcontact.nl /basisprincipes.html.



J. Westrik, H. Meijer en J. Heeling, Het ontwerp van de stadsplattegrond, ISBN 9789058750266.



Han Meyer, Frank de Josselin de Jong en Maarten Jan Hoekstra, Het ontwerp van de openbare ruimte, ISBN 9789058751645, 2009



H. Meyer, Stedenbouwkundige 9789085064947, 2008.



W.H. Verburg, Verdiepingbouw met staal – ontwerpboek voor architecten, ISBN 9789072830005, 2006.



Bernard Leupen, Ontwerp en analyse, ISBN 9789064505584, 2010.

regels

voor

het

bouwen,


ISBN

99


100

www.dragon1.org



Frans van Herwijnen, Leren van instortingen, ISBN 9789072830845, 2009.



Mark Paauwe, Whitepaper Architectuurprincipes, Paauwe Research – http://research.paauwe.info, 2009.



Koen van Boekel, S0552054, Master Thesis, Architectuurprincipes: functie en formulering, 2009.



Universal Principles of Design, ISBN 13 978-1-59253-007-6, 2003.



Surendra Verma, The Little Book Of Scientific Principles, Theories & Things, ISBN 9781845375270, 2006.



David Macaulay, The way things work, ISBN 9781405302388, 2004.



John H. Farrar, Corporate Governance: Theories, Principles and Practice, 9780195551457, 2008.



Vitruvius Pollo, Handboek Bouwkunde, ISBN 9789025358853, 2003.



H. Engel, Wat is architectuur?, ISBN 9789085061885, 2007.



Bijlagen

Bijlage A: Verkort Sjabloon voor het beschrijven van het principe Unieke referentie

Vul hier een uniek code in

{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}

Kort omschrijving {Short statement / Kort uitspraak}

…

…

Uitgebreide beschrijving … {Long statement / Lange uitspraak}

(Uitgangspunt of eis als justificatie voor principe)

…


101


www.dragon1.org

Implementatie(aspecten) … {Implementation / Implementatie}

Beleid(maatregelen) {Policy / Beleid}

…

Ontwerp(regels) {Design / Ontwerp}

…

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

102



Bijlagen

Bijlage B: Begrippenkader Kijk voor definities van alle Dragon1 begrippen op wiki.dragon1.org. Hieronder treft een u een korte lijst van gedefinieerde woorden aan uit deze open standaard: Aandachtspunt - 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. Architectuur - 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. Architectuurprincipe - 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. Behoefte - Een behoefte is een verlangen. De noodzakelijke invulling van eisen om bepaalde werkzaamheden te kunnen uitvoeren. Beleidsuitspraak - Een beleidsuitspraak is een richtinggevende en bindende afspraak hoe met middelen om te gaan of taken uit te voeren. Bouwwerk - 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 ware het opgebouwd uit constructieve, operatieve en decoratieve concepten en/of elementen en/of componenten en/of objecten en/of technische producten.


103


www.dragon1.org

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. Eis - 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. Principe - 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 resultaat tot gevolg in een gegeven context. Randvoorwaarde - 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. Regel - 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. Strategisch Uitgangspunt - 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.

104


Architectuurprincipes

Recommend Documents