Naast architectuurvisualisaties zijn architectuurprincipes het centrale thema in de digitale architectuur. Er bestaan echter nog grote meningsverschillen over wat architectuurprincipes precies zijn. In de praktijk zie ik naast serieuze verzamelingen van architectuurprincipes nog te vaak vage lijstjes die meer lijken op een wensenlijst voor Sinterklaas dan een serieuze opsomming van architectuurprincipes die daadwerkelijk en aantoonbaar de ontwerpruimte inperken. ‘I have a dream’ is een prachtige slogan om achteraan te lopen, wellicht het juiste middel om een beweging op gang te brengen. Maar deze slogan beperkt niet de ontwerpruimte in de digitale wereld.
Waar komt de behoefte aan architectuurprincipes vandaan? In het begin van de automatisering krasten we regels code uit de losse pols. Toen na verloop van tijd dit aantal wel wat groot werd, kwamen we er achter dat het handig was om eerst een ontwerp te maken. Zo werd het technisch ontwerp geboren. Nog enige tijd later werden we ons bewust van het feit dat de geautomatiseerde systemen eigenlijk waren bedoeld voor de gebruikers. Hun wensen en eisen dienden, voorafgaand aan het technisch ontwerp, te worden gespecificeerd en vormgegeven. Dus werd het functioneel ontwerp bedacht. Omdat de automatisering tegenwoordig bedrijfsbreed wordt aangepakt zijn wij uiteindelijk tot de conclusie gekomen dat je zelfs ontwerpen (zowel functioneel als technisch) niet meer uit de losse pols kan doen. Daar zijn ontwerpregels en ontwerprichtlijnen voor nodig, aangevuld met een duidelijke keuze welke industriestandaarden worden gebruikt. Om enig overzicht te krijgen worden al deze voorschriften voor het ontwerp geclusterd naar architectuurprincipes. Dus zoals reeds gesteld: architectuurprincipes dienen om de ontwerpruimte in de digitale wereld in te perken.
Architectuurprincipes komen niet uit de lucht vallen. Enkele belangrijke bronnen* die aanleiding geven tot architectuurprincipes: knelpunten in de huidige situatie, wensen omtrent verbetering van het huidige functioneren, het ecosysteem (inclusief regelgevende context, de ketens en de compliancy eisen) en de strategische uitgangspunten voor een transformatie. Een strategisch uitgangspunt is een belangrijke uitspraak om je strategie richting te geven. Strategische architectuurprincipes zijn etaleerbaar naar de buitenwereld, zij bepalen mede het bedrijfsimago. Voorbeelden van strategische uitgangspunten zijn ‘no wrong door’, ‘one stop shopping’ en ‘de overheid vraagt niet naar de bekende weg’. Bij bovenstaande bronnen, zeker knelpunten en wensen, horen stakeholders die elk weer hun eigen viewpoint hebben met hun eigen belangen. Het is belangrijk om dit expliciet in kaart te brengen.
Een goed architectuurprincipe is concreet (in vakjargon ‘SMART’, althans in de uitwerking in ontwerpregels, richtlijnen en standaards), complexiteitsverlagend, voldoende toekomstvast, redelijk innovatief en consistent en coherent met de andere architectuurprincipes.
Naast de bron van het architectuurprincipe is het ook belangrijk om zijn impact weer te geven. Welk artefact, gerealiseerd onder architectuur, wordt beïnvloed door dat architectuurprincipe? Maak ook eens een lijst van de artefacten die je in beschouwing neemt als je een architectuur gaat formuleren!
Om IT ordelijk te kunnen toepassen in een onderneming zijn er naast architectuurprincipes nog vele andere soorten principes nodig. Te denken valt aan principes op het gebied van de IT-Governance, de compliancy- & risicobeheersing, de IT-strategie, de toepassing van nieuwe technologieën, de transformatie en de sourcing, de financiering, de kwaliteitsbeheersing, de security en de privacy, de samenwerkingsvormen binnen de onderneming, de keuzes van leveranciers en partners en de bemensing en training van de IT-afdeling. Dit zijn allemaal belangrijke principes, maar voor het grootste deel geen architectuurprincipes. Sommige zijn gerelateerd aan architectuurprincipes (security versus toegankelijkheid) of zijn de bron voor architectuurprincipes (sourcing).
Echte architectuurprincipes beperken de ontwerpruimte in de digitale wereld en vinden dus uiteindelijk hun impact in de software. Bovengenoemde principes zijn in feite bedoeld voor mensen. Omdat mensen minder discipline hebben dan computers, zijn er voor die principes borgingsmaatregelen nodig om de naleving van die principes te handhaven.
Het opstellen van een waardevolle collectie architectuurprincipes vergt een architect met analytische capaciteiten, een goed inzicht in businessbehoeftes en een goed gevoel voor de gewenste bedrijfscultuur. Dit is niet weggelegd voor de doorsnee ITer. Het formuleren van een goede architectuur is zeer moeilijk en kost heel veel inspanning (lees: werktijd en doorlooptijd). Ik meen te mogen stellen dat dat door velen zwaar wordt onderschat, zeer zeker door de opdrachtgever van een architectuur en de financier.
Vaak worden er frameworks** gebruikt om de architectuurprincipes te kunnen ordenen. Dat is zeer nuttig om de onderlinge consistentie en coherentie te onderzoeken. Weet echter wel dat een architectuurframework, overigens net als een architectuurmethode, slechts een hulpmiddel is en nimmer de ervaring en de vakbekwaamheid van een ervaren architect kan vervangen.
* Een andere belangrijke bron voor architectuurprincipes zijn de best practices, horende bij de bedrijfstak, horende bij de besturingsfilosofie van de onderneming en horende bij de gewenste bedrijfscultuur. Vaak hebben deze architectuurprincipes geen duidelijke stakeholder anders dan het feit dat deze architectuurprincipes te maken hebben met professioneel werken.
** Dit is een soort Lundiakast, meestal twee dimensionaal, waarin de gevonden architectuurprincipes gesorteerd kunnen worden opgeborgen.
Deze column is eerder gepubliceerd in licht verkorte vorm in de Automatisering Gids, 7 november 2008, nummer 45, pagina 18.
Comments (12)
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 12-11-2008 22:56
Zoals beloofd een korte samenvatting van mijn conclusies destijds. Voor een uitvoerige beschrijving verwijs ik graag naar mijn scriptie, onder andere te vinden op deze website.
Geconcludeerd is dat de huidige architectuurvisie op principes een duidelijk onderscheid tussen de verschillende soorten voorschriften onmogelijk maakt. Bovendien is geconstateerd dat er nogal wat aan te merken is op de huidige visie op architectuurprinci¬pes: • er ontbreekt een duidelijke positionering van het principe; • principes zijn vaan niet stellend genoeg geformuleerd; • de geldigheid van een principe wordt meestal niet afgedwongen; • het ‘richtinggevende’ aspect van een principe wordt op een verkeerde wijze gehanteerd.
In de praktijk geformuleerde principes bevatten vaak onmeetbare, ambigue en wensende formuleringen. Daarnaast worden veelal beweegredenen bij de implicaties beschreven en andersom. Dit alles maakt een principe moeilijker te interpreteren en verliest een principe zijn sturende karakter. Overigens is het schrijnend om te moeten constateren dat er nog veel principes in omloop zijn welke uit 1 of 2 regels bestaan.
-- syntaxis De syntaxis van het principe draait om de vorm van het principe. De inhoudelijke en contextuele attributen zijn te vatten in het template dat in mijn scriptie (blz II-50) te vinden is. In deze sectie zullen de verschillende inhoudelijke componenten van het principe worden benoemd. Een dergelijke strikte scheiding van componenten maakt het gehele principe direct eenduidiger en beter communiceerbaar. Dit vergroot het sturende karakter van de architectuur. Onderstaande componenten hebben elk zowel een (semi-)formeel als een natuurlijke taal versie. Daarnaast is het mogelijk dat bepaalde componenten, zoals obstakels en acties, door de tijd heen aangepast worden. De taal zou het zodoende mogelijk moeten maken om meerdere versies van hetzelfde principe bij te houden. Overigens ben ik van mening dat het noodzakelijk is om per opdrachtgever te bepalen in welke mate van detail een principe geformuleerd moet worden. Hoe volwassener de organisatie, hoe volwassener een principe uitgeschreven kan worden.
Naam / titel Vaak wordt het principe geopend met een korte zinsnede. Dit component moet de essentie bevatten en eenvoudig te onthouden zijn. Zinsneden als ‘Information; anywhere, anytime, anyhow’ en ‘We vragen de klant nooit naar de bekende weg’ zijn prima voorbeelden om als krantenkop te fungeren. Dit kan de communiceerbaarheid en memorability van het principe enorm verbeteren.
Uitspraak / Omschrijving (‘statement’) De essentie van het principe dient te worden omschreven in het principestatement. Of zoals The Open Group stelt: ‘to communicate the fundamental rule’. Unaniem wordt gesteld dat een principe uit een aantal componenten bestaat en dat deze component de kern of de essentie van het principe vormt. Een uitvoerige uitwijding is dan ook niet noodzakelijk. Vaak wordt er echter geen onderscheid gemaakt tussen de omschrijving van het principe en een naam, titel of krantenkop. Deze scriptie volgt echter de lijn om twee componenten te gebruiken en zodoende een aparte naam of titel te gebruiken. Dit biedt de kans om enerzijds een rijke taal te creëren met verschillende mogelijkheden en anderzijds om het mogelijk te maken een principe voor verschillende doelgroepen geschikt te maken. De titel kan dan gebruikt worden puur voor de communicatie (bijvoorbeeld aan het hogermanagement in een onderneming) en het statement voor de echte omschrijving.
Beweegredenen (‘rationale’) Een principe dient beweegredenen te hebben om te worden opgenomen in de architectuur. Een principe moet namelijk een keuze zijn. Daarnaast moet er veelal moeite gedaan worden om een principe uit te voeren of te hanteren in het maken van beslissingen. Er moet dan worden aangegeven waarom het van belang is om dit principe toch te gebruiken. Dit verhoogt de acceptatie en de naleving van het principe en dient op syntactisch niveau afgedwongen te worden. De rationale kan bestaan uit referenties naar andere voorschriften, concerns (issues, needs) en/of het ondernemings- of bedrijfskader (waaronder strategie, doelstellingen, drivers en goals).
Onderbouwing Daar waar anderen hierin de beweegredenen benoemen voor het principe, kan men ook onderbouwen waarom het principe in een gegeven context en gebruik gaat werken. Dit zorgt ervoor dat een principe ‘proven’ is. Vaak zijn architecten bezig nieuwe principes te formuleren terwijl het eigenlijk beter is om referentiearchitecturen te gebruiken en te onderbouwen waarom deze set principes, gegeven de concerns (issues en needs) in de nieuwe situatie zal gaan werken. Dit zal het architectuurvakgebied ook veel volwassener maken. Klanten kopen toch ook geen producten zonder de garantie dat het product ook gaat werken? Veelal mist deze onderbouwing en de bijbehorende validatie nog bij een geformuleerde architectuur. Deze component kan als onderdeel gezien worden van de oorspronkelijke rationale.
Implicatie / consequenties (‘Implications’) Naast de beweegredenen moeten ook de implicaties en consequenties (de gevolgen), die het uitvoeren van het principe met zich meebrengen, beschreven worden. Dit is wel afhankelijk van het feit of het principe een opendeur mag zijn. Het benoemen van de implicaties en consequenties zorgt ervoor dat de gevolgen van het implementeren van een principe geïdentificeerd worden. Deze identificatie moet niet tot in den treuren gedaan worden; het is toch niet mogelijk om een complete lijst aan implicaties op te leveren en dat zou tevens te veel tijd kosten. Dit staat haaks op de, vaak gehanteerde, ‘just-in-time’ en ‘just-enough’ prin¬cipes en op de eis om geen papieren tijger te creëren.
Vanuit een implicatie of consequentie dienen acties geformuleerd te worden. De implicatie is iets waar de onderneming rekening mee moet houden bij het willen hanteren van het principe; acties dienen uitgevoerd te worden om deze implicaties te bewerkstelligen.
Een principe is beter te interpreteren als de lezer weet wat voor type uitspraak hij of zij leest. Zodoende is het beter om dit expliciete onderscheid tussen implicaties en acties te maken. Tevens biedt het de architect duidelijke syntactische handvatten om een zo compleet mogelijk principe te formuleren (wanneer gewenst). Wanneer de architect dit onderscheid dus liever niet maakt (bijvoorbeeld om pragmatische redenen), dan zal de taal dit niet eisen van de architect.
Obstakels Daar waar de implicaties gaan over de gevolgen van het principe, is het ook mogelijk om te kijken naar de (fundamentele) factoren die het implementeren van het principe hinderen. Door deze belemmeringen of obstakels te identificeren wordt het ook eenvoudiger om de juiste tegenacties te nemen. Implicaties zijn dan ook zeker geen obstakels!
Assurance In een aantal publicaties wordt er een nieuwe dimensie toegevoegd welke specifiek ingaat op het kunnen volgen van principes. Dit heeft een aantal voordelen: 1) het biedt een handvat om het principe eenduidig en meetbaar te formuleren, 2) het biedt mogelijkheden om het handhaven van het principe te concretiseren en 3) de voortgang van het implementeren van het principe kan gevolgd worden.
Het operationaliseren van principes in meeteenheden is te vergelijken met het formuleren KPI’s vanuit KSF’s. Deze prestatie-indicatoren geven de bestuurder (meet-)instrumenten in handen om de strategie (van de onderneming) te besturen. Dit is een nieuwe beweging binnen het architectuurvakgebied en is, mede daarom, nog niet breed gedragen. Genoeg architecten vinden het onzinnig om bij elk principe metrics te benoemen. De waarheid zal ergens in het midden liggen. Het benoemen van metrics geeft de architect een middel in handen om principes precies te for¬muleren en om onderliggende voorschriften te achterhalen. Maar dit moet de architect niet overdrijven. Anders ontstaat er een regelmonster en een papieren tijger. Men moet niet alles dood willen regelen. Het lijkt zinvoller om alleen geclusterde, belangrijke principes te voorzien van meeteenheden. In de toekomst zal hier nog meer onderzoek naar gedaan moeten worden. Dit zou ook prima passen in theorieën over het opzetten van referentiearchitecturen.
Handhavingsmechanisme Belangrijk is om ieder principe een handhavingsmechanisme te geven. Dit mechanisme bestaat onder andere uit het benoemen van een eigenaar, uit acties en in te richten processen om vooraf, tijdens en achteraf de impact van het principe te kunnen volgen en daar waar nodig bij te sturen.
Daarnaast kunnen een hoop, ook belangrijke, logistieke attributen onderkend worden.
Ik kan mij goed voorstellen dat er van een principe meerdere versies, in de tijd gezien, kunnen bestaan aangezien de obstakels, implicaties en acties best tijdgebonden kunnen zijn. Immers, acties kunnen uitgevoerd worden waardoor de obstakels geen obstakels meer zijn. Dit zou zeker gelden wanneer een principe wordt geformuleerd als een geldig fenomeen binnen een expliciet gedefinieerd context en kader.
-- semantiek Op semantisch niveau zijn een groot aantal kwaliteitsaspecten de revue gepasseerd en geanalyseerd. Dit heeft geresulteerd in semantische formuleerrichtlijnen welke bij moeten dragen aan beter geformuleerde principes (zie II-48). Hierbij moet men denken aan ‘formuleer een principe technologie- en leverancieronafhankelijk’ bij het kwaliteitsaspect ‘fundamenteel’. Een aantal behandelde kwaliteitsaspecten: consistentie, coherentie, eenduidigheid, holistisch, robuustheid, relevantie, realisme, afdwingbaarheid, stellend en dwingend, traceerbaarheid, actiegeoriënteerd, etc.
Een aantal richtlijnen: • Formuleer een principe zo tijdloos mogelijk (een zo ruim mogelijke tijdspanne). • Streef ernaar om een principe dusdanig te formuleren dat zoveel mogelijk aspecten van een artefact of domein ingeperkt worden. • Formuleer een titel welke simpel en beknopt is. • Formuleer een principe altijd zo eenduidig mogelijk (binnen de grenzen van de natuurlijke taal). • Definieer ambigue begrippen en relaties expliciet. • Streef naar een helder en beknopt geformuleerd principe (beweegredenen, statement en implicaties). • Spits de formulering toe op de doelgroep; hanteer de taal van de doelgroep. • Formuleer een principe welke een overtuiging uitspreekt. • Formuleer herkenbare en/of acceptabele beweegredenen. • Zorg voor een handhavingsmechanisme. • Zorg dat de eigenaar een gezag of mandaat heeft. • Formuleer in de tegenwoordige tijd. • Formuleer precies en eenduidig zonder te stranden in onnodige details (beknoptheid). • Specificeer de beweegredenen. • Vermijd zoveel mogelijk het gebruik van woorden die opties openhouden (bijvoorbeeld ‘kan’, ‘eventueel’, ‘optioneel’, etc) en zwakke uitdrukkingen als ‘zo minimaal mogelijk’, ‘makkelijk’, ‘effectief’, ‘normaal’, ‘tijdig’, etc). • Concretiseer zwakke uitdrukkingen als ‘zo minimaal / maximaal mogelijk’ naar meet¬bare uitdrukkingen. • Vermijd zoveel mogelijk het gebruik van kretologieën . • Vermijd het gebruik van constructies als ‘wij willen’ en ‘wij moeten’. • Neem ‘opendeur’ principes mee in een bijlage, zeker voor een enterprise architectuur. • Formuleer alleen eenduidige uitspraken waarvan bepaald kan worden of deze, op een gegeven moment in de tijd, geldig zijn. • Streef naar een goede verhouding tussen het abstract formuleren, de gedetailleerdheid van de context en het kunnen handhaven van het principe. • Vermijd het gebruik van ambigue woorden of zinsneden (zie in deze scriptie voor een aantal voorbeelden). • Vermijd het gebruik van kretologieën, deze zijn vaak niet eenduidig genoeg. • Gebruik zo veel mogelijk termen en definities uit de doelgroep. • Definieer expliciet termen welke meerdere betekenissen kunnen hebben.
-- noodzakelijkheid SMART
De vraag dient gesteld te worden of iedere uitspraak SMART moet zijn. De beroemde toespraak ‘I have a dream’ van Martin Luther King was niet SMART. Immers, de toespraak was niet meetbaar en niet tijdsgebonden. Maar het was wel een briljante toespraak, zeer inspirerend en activerend. Dergelijke uitingen zijn vaker te herkennen bij leiders, meer in het bijzonder bij managers van ondernemingen. Denk maar aan de marketingkreten van Nokia en Philips. Wie het onbekende wil verkennen kan niet specifiek zijn. Meetbare resultaten leiden tot calculerend gedrag. Acceptabele doelen zijn niet confronterend. Realistische doelen zijn niet ambitieus. Tijdgebonden doelen hebben een beperkte houdbaarheid. SMART-ness is dus wel nuttig om te gebruiken, maar het legt ook beperkingen op die zeer waardevolle doelstellingen uitsluiten. Zodoende is te stellen dat het SMART maken van uitspraken erg nuttig is, maar dat dit motiverende, inspirerende en activerende uitspraken niet mag uitsluiten. Een goede mix van beide soorten uitspraken, waarbij de SMART uitspraken de operationalisatie dienen te zijn van de andere uitspraken, zal pragmatisch de beste oplossing zijn. Dit geldt zeker ook voor een architectuur voor een onderneming.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 12-11-2008 23:21
It is time for the killer principle
Reagerend op de bijdrage van Pieter,
Het is goed dat je nog even jouw waardevolle scriptie samenvat als bijdrage. Veel bruikbare tips. Nu zou ik echter ook graag voorbeelden van principes willen zien en ook een onderverdeling in ontologische soorten (gericht op de functie van het principe). Dat helpt ons allemaal weer een stapje verder. Want ik denk dat het opschrijven van theorie en definities niet veel waarde heeft als we niet met een voorbeeld laten zien welke functie een principe-uitspraak in de praktijk heeft, 'anders dan richting geven'.
[Als ik het over definities heb dan bedoel ik beschrijvende definities en geen stipulatieve definities. - Zie Stanford]
Ik ben zeg maar op zoek naar de killer-app onder de principes; the killer principle
In mijn vorige bijdrage op deze column heb ik een link staan naar een architectuurprincipesschema waarin ik verschillende soorten principes onderken zoals die in de praktijk worden gebruikt, waarbij steeds 'architectuurprincipe' de bron is van alles.
In het architectuurprincipesschema staan nog geen definities voor de soorten principes en ook de relaties moeten nog hard worden gemaakt door mij. Maar eerst eens een longlist van soorten principes samenstellen.
Welke opdeling in soorten principes gebruik jij of herken jij in de praktijk en wat is een treffend voorbeeld principe voor de soort? Niet wat je theoretisch gezien zou kunnen bedenken. Het gaan om de hoofdsoorten en niet om achter alles het woord principe te plakken (zoals productprincipes, procesprincipe, etc...). Voor welke grote groepen of bepaalde onderwerpen worden nu lijsten van principes geformuleerd? En hoe kom je dan aan deze soorten of onderverdeling.
Ik stel trouwens deze vraag niet alleen aan Pieter, maar aan alle lezers.
Met vriendelijke groet,
Mark Paauwe (
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
)
Er is momenteel geen open standaard voor de vastlegging van architectuurprincipes. TOGAF 9 beschrijft een sjabloon voor vastlegging van individuele principes, maar biedt geen structuur voor het vastleggen van een verzameling principes in relatie tot elkaar en in relatie tot andere architectuurproducten. ArchiMate kent, als taal voor het vastleggen van architectuurproducten, momenteel geen architectuurprincipes in haar metamodel. Dit artikel beschrijft een manier om architectuurprincipes gestructureerd vast te leggen. Deze structuur kan in architectuurrepository’s gebruikt worden als aanvulling op het TOGAF Architecture Content Model of het ArchiMate metamodel.
Met behulp van de principegenerator kun je in enkele minuten gevoel ontwikkelen voor de werking van principes en – niet onbelangrijk – je hebt direct een handjevol principes die te gebruiken zijn als vertrekpunt voor een dialoog over principes binnen de eigen organisatie. In dit artikel wordt kort ingegaan op het idee achter de principegenerator en wordt de werking beschreven.
Het is belangrijk om een duidelijke visie te hebben als organisatie om je te onderscheiden van je concurrenten. Door deze visie te vertalen in een aantal heel fundamentele principes zorg je dat je deze ook kunt omzetten in realiteit. Dit artikel beschrijft een aantal principes die TKP Pensioen heeft gekozen bij het inrichten van haar informatievoorziening, en de wijze waarop dit heeft bijgedragen in haar onderscheidend vermogen ten opzichte van andere pensioenuitvoerders.
Op 6 juli 2009 heeft er een NAF Insight (mini-seminar) plaatsgevonden op het gebied van architectuurprincipes. Doel van dit seminar was vooral om kennis en ervaringen uit te wisselen op het gebied van architectuurprincipes en input te krijgen voor het boek dat wordt geschreven vanuit de werkgroep architectuurprincipes. In dat kader hebben zowel dienstverleners als gebruikersorganisaties hun visie en ervaringen gedeeld en heeft er een discussie plaatsgevonden.
Voor iedereen staat vandaag in de automatiseringsgids een goed verhaal te lezen over architectuurprincipes; de column van Daan Rijsenbrij. Een paar punten uit die column wil ik nu graag aanstippen en verder uitwerken. Een enkel punt dat niet in de column aan bod komt wil ook even behandelen, zoals de CIO die hoeder moet zijn van de architectuurprincipes voor de organisatie. In mijn dagelijkse praktijk als enterprise architect kom ik vaak onduidelijkheid en onmacht tegen in relatie tot architectuurprincipes. Het wordt echt tijd dat enterprise architecten samen met de CIO werk maken van dit instrument waar veel kracht en macht van uit kan gaan.
Ik was laatst zeer geboeid door een schilderij van Johannes Vermeer dat ik zag. Ik bleef er naar kijken. In verschillende boeken heb ik gelezen over het fenomeen asymmetrische balans en de schilderijen van Vermeer. Vermeer heeft, zo schrijft men, de grenzen van spiegelsymmetrie opgezocht. Hij heeft eigenlijk spiegelasymmetrie toegepast. In deze blog ga ik verder in op het principe van het fenomeen dat ik ‘spiegelasymmetrie’ noem.
The concepts of architectural principleand business rule are currently ill-defined. As a consequence, there is a lot of misunderstanding and confusion. Only by putting these concepts in an appropriate and theoretically sound conceptual framework can they become well-defined. Only well-defined concepts are useful, both in science and in practice.
Het gebied van architectuurprincipes is nog relatief ontgonnen. Er is nog geen overeenstemming over wat architectuurprincipes precies zijn, wat voor soorten architectuurprincipes worden onderkend, hoe je architectuurprincipes beschrijft en hoe je precies tot architectuurprincipes komt. Op het Landelijk Architectuur Congres 2007 is er daarom een workshop over dit onderwerp georganiseerd. Dit artikel is een verslag van die workshop.
Well considered business architecture can support an organization in becoming a place where Innovation thrives. Organizations will need to promote an environment of interaction to facilitate cross-pollination and the free flow of information. This supports the promotion of creativity and the development of ideas when seeking to exploit the full potential of innovative powers.
De prescriptieve architectuurbenadering heeft als uitgangspunt dat vrijheidsgraden van architecten en ontwerpers moeten worden beperkt door het stellen van kaders in de vorm van architectuurprincipes en richtlijnen. Er rijzen in de praktijk nog veel vragen bij het opstellen van dit soort principes en richtlijnen. Dit artikel geeft daarom een op de praktijk gebaseerd beeld en gaat in op een praktijksituatie bij een grote verzekeraar.
Voor het onderzoek is een onderzoeksplan opgesteld dat is opgenomen in het eerste hoofdstuk. Hier is gekeken wat de aanleiding van het onderzoek is en welk probleem- en doelstelling hierbij komt kijken. Een onderzoeksvraag is opgesteld met deelvragen om het onderzoek concreet te maken. Vervolgens is het onderzoek verdeeld in een aantal activiteiten en is gekeken naar het toekomstige studentinformatiesysteem van de Radboud Universiteit. ...
Guido Chorus , Yves Janse, Chris Nellen, Stijn Hoppenbrouwers, Erik Proper
Tuesday, 24 July 2007
This technical report is the result of two experiments conducted as part of an ongoing research effort to formalize architecture principles. The experiment involves a first, and modest, evaluation of the use of ORM and ORC as a means to formalize and ground architecture principles. The experiments involve the evaluation of the use of ORM and ORC to formalize the example principles provided by the TOGAF (The Open Group Architecture Framework) and principles taken from industrial practice.
In deze scriptie wordt een begin gemaakt met de theorievorming voor een prescriptieve architectuurmodelleertaal. Er wordt betoogd dat de prescriptieve modelleertaal architect- en methodeonafhankelijk ontworpen dient te worden.
Door het toepassen van digitale architectuur1 zijn ondernemingen en instellingen beter en sneller in staat om zich aan te passen bij wat medewerkers in een organisatie doen en veranderingen in het ecosysteem. Binnen de Radboud Universiteit (RU) ontbreekt het aan systematisch inzicht in de wisselwerking tussen het bedrijfsgebeuren en de informatiesystemen. In het bijzonder is er behoefte aan modellen, blauwdrukken, toekomstvisies en principes. Dit onderzoek [RVN] heeft zich beperkt tot het opstellen van principes, ook wel richtinggevende uitspraken, ten behoeve van het maken van keuzes over het studentinformatiesysteem.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-) Architectuurraamwerk beschreven. In dit eerste artikel wordt gedetailleerd ingegaan op de essentie van het ontwerpproces.
In een serie van artikelen wordt een generiek uitbreidbaar (IT-)Architectuurraamwerk beschreven. In dit tweede artikel wordt het Metamodel xAF beschreven en zal nader worden ingegaan op de Architectuur-principes.
Dit artikel beschrijft het onderzoek dat is verricht aan de Radboud Universiteit naar het opstellen van principes, ten behoeve van het maken van keuzes over het studentinformatiesysteem.
