Landelijk Architectuur Congres 2005 ‘Procesmodel voor het projectmatig opstellen van een applicatiearchitectuur voor een universiteit’ Michel Houben, Hans Janssen en Daan Rijsenbrij
0. Managementsamenvatting Heden ten dage zijn de prestaties van bedrijfsprocessen steeds meer afhankelijk van de wijze waarop de informatievoorziening functioneert. Onze hele samenleving wordt in snel tempo gedigitaliseerd. Op allerlei gebieden worden handmatige werkzaamheden ondersteund of zelfs vervangen door geautomatiseerde informatiesystemen. De digitale wereld wordt in snel tempo complexer, het wordt steeds moeilijker om op afdoende wijze beveiliging te borgen en de wirwar van reeds bestaande applicaties is verstikkend. [RIJS5] Er ontstaan steeds meer koppelingen en afhankelijkheden tussen applicaties en een toenemend aantal faculteiten op de Radboud Universiteit heeft – al dan niet direct – belang bij een bepaalde applicatie. Om het applicatielandschap beheer(s)baar te houden, dient structuur te worden aangebracht in dat applicatielandschap. Een structuur die orde en discipline afdwingt bij de totstandkoming van de digitale wereld. Deze structuur, die zorgt voor het ordentelijke verloop van een bouwproces, is al eeuwenlang onderdeel van ‘architectuur’ in de fysieke wereld. [RIJS5], [ORDINA1] Applicatiearchitectuur1 is een besturingsinstrument: een atlas voor de boardroom om besluiten te kunnen plaatsen en de gevolgen te kunnen overzien; een hulpmiddel voor complexiteitsbeheersing; een raamwerk voor uitvoering; een communicatiemiddel voor alle betrokken stakeholders, zowel tijdens als na de realisatie. [RIJS2] Werken onder ‘digitale architectuur’ zorgt dus onder andere voor transparantie en structuur. Deze aspecten zijn nog niet doorgedrongen bij de verschillende reeds aanwezige methoden, aanpakken of processen die digitale architecten gebruiken bij de concipiëring van een architectuur. Dit artikel beschrijft een procesmodel, waarin stapsgewijs activiteiten worden weergegeven, die opdrachtgever, eigenaar, architect en stakeholders moeten ondernemen voor het concipiëren van een applicatiearchitectuur.
1
Dit geldt op een hoger beschrijvingsniveau natuurlijk ook voor enterprise architectuur. © Michel Houben, Nijmegen, 2005
1
1. Inleiding De huidige manier van een Universiteit om de geautomatiseerde informatievoorziening te vernieuwen, leidt vaak niet tot het gewenste resultaat. Medewerkers komen met talloze initiatieven om tot verbetering te komen. Deze oplossingen hebben echter vaak een hoog ‘hype’-gehalte. Beslissers weten niet wat ze moeten besluiten, iedereen probeert zijn eigen particuliere problemen op te lossen, zonder rekening te houden met de onderlinge samenhang en toekomst. Voor de Universiteit is de applicatiearchitectuur een instrument dat borgt, dat grootscheepse transformaties in het applicatielandschap ordelijk verlopen. De applicatiearchitectuur wordt als middel gebruikt bij het transformatiepad naar het nieuwe studentinformatiesysteem. Een aantal doelstellingen van applicatiearchitectuur: 1. In één oogopslag moet duidelijk zijn welke principes gelden op applicatieniveau. Met architectuur kan het overzicht bewaard blijven en de samenhang wordt bewaakt. 2. Door architectuur worden keuzes beperkt, daardoor is dit een goed wapen om de complexiteit te reduceren. 3. De aanwezigheid van een gemeenschappelijk architectuurraamwerk is bij het ontwikkelen onder applicatiearchitectuur belangrijk. 4. Primair is de architectuur een communicatiemiddel. 5. Applicatiearchitectuur levert meerwaarde voor een organisatie, zoals lagere ontwikkelkosten in de toekomst, integratie tussen (bestaande) systemen en toegenomen bruikbaarheid van het systeem.
Er zijn tegenwoordig veel stakeholders betrokken bij zaken in de digitale wereld met de meest tegenstrijdige eisen en wensen. Het is aan de architect om een architectuur te concipiëren waar de belangrijkste stakeholders zich in voldoende mate in kunnen vinden. Een architect leidt een proces waarbij de stakeholders met elkaar één set van principes overeenkomen en deze met elkaar delen2. [RIJS7] Door een complex systeem niet als geheel te presenteren, maar vanuit verschillende viewpoints voor specifieke stakeholders, kunnen belangrijke aspecten veel duidelijker worden. Dit maakt een architectuurbeschrijving beter leesbaar.
2. Architectuurdefinitie Applicatiearchitectuur3 is een besturingsinstrument: een atlas voor de boardroom om besluiten te kunnen plaatsen en de gevolgen te kunnen overzien; een hulpmiddel voor complexiteitsbeheersing; een raamwerk voor uitvoering; een communicatiemiddel voor alle betrokken stakeholders, zowel tijdens als na de
2
Het teambuilding effect onder de stakeholders is zeer belangrijk. Dit geldt op een hoger beschrijvingsniveau natuurlijk ook voor enterprise architectuur. 3
© Michel Houben, Nijmegen, 2005
2
realisatie. Voor een Universiteit is de applicatiearchitectuur een borginstrument dat ervoor zorgt, dat grootscheepse transformaties in het applicatielandschap ordelijk verlopen. [RIJS2]
3. Principes Een architectuur, zeker in de digitale wereld, is principegeoriënteerd. Principes zijn richtinggevende uitspraken ten behoeve van essentiële beslissingen, een fundamenteel idee bedoeld om een algemene eis te vervullen. Principes beïnvloeden direct de wijze waarop de IT zal worden ingezet op informatiesysteemniveau. [RIJS4] Vanuit de principes worden regels, richtlijnen en standaarden gedestilleerd, deze zorgen voor meer verduidelijking van de principes. Principes zijn erg belangrijk om meer helderheid te scheppen voor de stakeholders van de toekomstige applicatie(s). Een principe vloeit voort vanuit een concern die de organisatie heeft. Het zijn de concerns die aanleiding geven tot het formuleren van principes. Het is belangrijk om de architectuur niet te gedetailleerd uit te werken, dus voor een bruikbare architectuurbeschrijving moet gelden: ‘just-enough’ en ‘just-in-time’. Dat beleving van gebruikers een essentieel aspect hoort te zijn bij het concipiëren van een applicatiearchitectuur is een open deur. Daarom zullen er belevingsprincipes moeten worden opgesteld, zoals bijvoorbeeld een dynamische user-interface met zelfverklarende functionaliteiten.
FIGUUR 1: DE USER-INTERFACE ALS BEMIDDELAAR TUSSEN GEBRUIKER EN SYSTEEM Desalniettemin is de spreekwoordelijke ‘achterkant’ van het systeem ook belangrijk voor de gebruiker, hiermee worden de structuur en constructieprincipes bedoeld. [RIJS4] Voorbeelden van principes zijn: • Belevingsprincipe: o De user-interface van de applicatie kan worden aangepast aan de individuele wensen van de gebruiker. • Constructieprincipe: o XML voor dataflexibiliteit. • Structuurprincipe: o De informatie is overal beschikbaar voor de student, any place, any where with any device
© Michel Houben, Nijmegen, 2005
3
4. Stuurmogelijkheden en nut architectuur De verschillende stuurmogelijkheden [PAAUWE] die architectuur kan bieden: •
•
•
•
•
•
•
•
Architectuur faciliteert beeldvorming, oordeelsvorming en besluitvorming. o Voorbeeld: Een algemene impliciete standaard voor het ontwikkelen van databases, bijvoorbeeld de Oracle omgeving. De besluitvorming voor de Universiteit zou op dit vlak erg gemakkelijk kunnen zijn. Architectuur kan issues en beslissingen plaatsen in hun context. Architectuur kan afhankelijkheden en tegenstrijdigheden van issues en beslissingen inzichtelijk maken. o Voorbeeld: De verschillende faculteiten op de Universiteit zullen verschillende principes, regels, richtlijnen en standaarden hebben. Het is aan de architect om de conflicterende principes tot een algemeen geaccepteerd principe te destilleren. Architectuur kan gebruikt worden bij leverancierskeuze of investeringsbeslissing. o Voorbeeld: Formuleren welke standaarden toegestaan zijn en welke niet a.d.h.v. deze beschrijving kan er een keuze gemaakt worden. Architectuur kan gebruikt worden bij visie-ontwikkeling o Voorbeeld: Principes zijn een ordenend instrument en afgeleid uit o.a. de visie van de Universiteit. De principes geven een heldere beeldvorming van de visie en kunnen indien nodig worden bijgewerkt. Architectuur kan gebruikt worden bij audit en review-trajecten o Voorbeeld: Als reviewer moet men vaak documenten beoordelen op hun kwaliteit waarbij men controleert of het proces tot het komen tot dit document volgens de afgesproken principes is verlopen. Het onder architectuur realiseren van een (deel van een) organisatie of van een systeem is een vorm van risicomanagement o Voorbeeld: Een architectuur voor de Universiteit leidt tot inzicht, structuur en overzicht. Daarmee ondersteunt architectuur de besluitvorming en beperkt risico’s. [RIJS5] Het beheren van architectuurdossiers laat investeringen in architectuur beter renderen en houdt ontwikkelde architecturen langer bruikbaar, toegankelijk, beheersbaar en onderhoudbaar. o Voorbeeld: Door bepaalde marktontwikkelingen zoals bijvoorbeeld ‘het draadloos internet’, kan het zijn dat bepaalde standaarden bij een architectuurschets zullen veranderen. Architectuur inzetten volgens een bepaalde methode maakt het werk van architecten en het te verwachten resultaat voorspelbaar. o Voorbeeld: Een procesmodel voor het concipiëren van een architectuur is relevant aangezien het management een duidelijk overzicht heeft over projectvorderingen, status, problemen en planning.
Het nut van de architectuur is niet in geld uit te drukken, de architect moet in staat zijn om de voordelen van architectuur boven water te halen. Wat heeft architectuur op lange termijn voor baten? Architectuur vergt op korte termijn investeringen. Architectuur levert pas op lange termijn een kostenbesparing op.
© Michel Houben, Nijmegen, 2005
4
In het architectuurteam moet een duidelijke leider zitten; iemand die de architectuur en het nut van de architectuur kan verkopen aan alle belangrijke stakeholders binnen de onderneming. De juiste persoon is de Corporate Architectural Officer (CAO), een enterprise-architect op het hoogste niveau, hij hoort in feite de ‘slimme’ denker te zijn die het overzicht over de onderneming bewaakt.[RIJS7]
5. De architect als succesfactor [SOG1] Het kweken van awareness voor architectuur in de gehele organisatie is een van de belangrijkste uitdagingen waar een architect voor staat. De architect staat boven de verschillende partijen in de organisatie bij het uitbalanceren van hun vaak tegenstrijdige belangen. Een architect is ten eerste kaderstellend en moet ook over de volgende skills beschikken: • Analyseren van eisen en wensen, regisseren in adviesprocessen en coachend adviseren. Een architect moet in staat zijn om zuiver te communiceren en te structureren. Aangezien een architect in staat moet zijn om een compromis te vinden bij conflicterende principes van verschillende stakeholders, is het zeer belangrijk dat een architect goed kan luisteren en communiceren. Bij architecten die dat niet kunnen, leidt dit alleen maar tot ‘autistische’ IT-systemen. [RIJS9] • Documenteren en visualiseren Een architect moet eenvoudig kunnen visualiseren op management niveau.[RIJS9] • Managen van relaties in complexe situaties en faciliteren van workshops Een architect moet zich kunnen inleven in de stakeholders. Er zijn verschillende soorten architecten in de digitale wereld4: enterprise-architect, domeinarchitect, applicatiearchitect en werkruimtearchitect. Een applicatiearchitect is meer oplossingsgericht, terwijl een enterprise en domeinarchitect kaderstellend zijn. Door de inperking van dit onderzoek, zal alleen de applicatiearchitect besproken worden. Profiel van een applicatiearchitect gebaseerd op Rijsenbrij [RIJS7]: •
Zakelijk gevoel voor de business en IT behoeften en nuchtere visie op technologie (ongevoelig voor hypes). Kunnen luisteren en presenteren, communicatieve vaardigheden zijn zeer belangrijk. Valkuil 1: Een architect die gaat handelen naar de inzichten die hij heeft. [PAAUWE] Een architect neemt geen beslissingen, hij creëert alleen een beeld. Valkuil 2: Een architect die teveel gaat plannen en te weinig bezig is met beïnvloeden, opleiden en motiveren. [PAAUWE]
4
De digitale wereld bestaat uit netwerken, servers, storage, applicaties, informatieverkeer, communicatieruimtes, kennishuishouding en digitale businessdiensten. © Michel Houben, Nijmegen, 2005
5
•
•
• •
Hoog abstractie vermogen, het gaat om het juiste samenspel tussen de geschikte representatie of weergave van informatie en efficiënte berekening met die gegevens. Valkuil: Een architect die eerst gaat beslissen en daarna pas bedenken. [BENTHEM] Subtiel gevoel voor organisatiecultuur Valkuil: Een architect die niet weet hoe een organisatiecultuur in elkaar zit, waardoor de communicatie tussen de architect en de organisatie kan worden bemoeilijkt. [PAAUWE] Flinke portie ICT-kennis is vereist, veel ervaring op het gebied van de systeemontwikkeling en liefst ook op beheer (ITIL etc.) Valkuil: Ontwerpen en toepassen van architectuur verwarren en niet splitsen. Gevoel voor menselijke maat. Valkuil: Ervaren ontwerpers of constructeurs die als architect worden ingeschakeld. Deze personen hebben meestal minder gevoel voor de menselijke maat. [PAAUWE]
De architect is als het ware de regisseur in het beeldvormingsproces [VERMEUL] [RIJS8], een proces dat leidt tot maakbare artefacten in de digitale wereld. [RIJS7] Uit de bovenstaande profilering blijkt dat de houding van de architect van grote invloed is op de mate waarin hij z’n boodschap tussen de oren krijgt bij het college van bestuur van de Universiteit. Hij moet zorgen voor een goede Business-IT alignment. Veel architecten concentreren zich op de inhoud, dat is correct. De inhoud moet wel een duidelijk doel dienen en er moet draagvlak en acceptatie voor komen.
6. Procesmodel 6.1 Rolindeling en fasen In het procesmodel worden vier verschillende rollen onderscheiden: • Opdrachtgever / projectleider: Degene die verantwoordelijk is voor de voortgang van het project. Dit is een manager, projectleider, bestuurder of iemand van de directie. Om een project tot een succes te maken, is het niet voldoende een goede architect aan te stellen. Ook de rol van de opdrachtgever/ projectleider zelf kan het verschil uitmaken tussen succes en falen. [PRINCE2] De opdrachtgever is mede verantwoordelijk voor een heldere formulering van de opdracht. • De opdrachtgever stelt het budget beschikbaar en zorgt voor liquide middelen. Tijdens het proces zal er een continue gedachtewisseling plaatsvinden tussen de opdrachtgever en de architect. Deze persoon ziet er ook op toe dat wat ontwikkeld wordt, ook op de juiste wijze ontwikkeld wordt. Hij controleert de werkzaamheden, voortgang en resultaten van het project. • Eigenaar: De toekomstige eigenaar van de applicatiearchitectuur is verantwoordelijk voor het in balans houden van alle ontwikkelingen waar de universiteit mee te maken heeft. Hij is dan ook de meest aangewezen persoon voor de ‘accountability’ van applicatiearchitectuur. Dit doet hij in nauw overleg met het management en de opdrachtgever. [RIJS1] © Michel Houben, Nijmegen, 2005
6
• •
Architect: Dit is de uitvoerder van het project, een specialist met domein- en probleemkennis. Stakeholders: Werken onder applicatiearchitectuur geldt voor de gehele organisatie, het is daarom van essentieel belang dat verscheidene personen hun gedachtes kunnen uiten. Kennisdeling, samenwerking en hergebruik zijn aspecten waar men aan moet denken.
In het model onderscheidt men zes fasen (initiatie, definitie, selectie, concipiëren, inbedding en onderhoud): Initiatie
Definitie
Selectie
Concipieren
Inbedding
Onderhoud
Opdrachtgever / Projectleider Eigenaar Architect Stakeholders
FIGUUR 2: SCHEMATISCHE WEERGAVE PROCESMODEL(HORIZONTAAL DE ROLLEN; VERTICAAL DE FASEN)
6.2 Gebruikte symbolen In het procesmodel wordt een onderscheid gemaakt tussen drie soorten producten: • Checklist: een lijst om te controleren of een bepaald document aan de gewenste eisen en inhoud voldoet. • Organisatiedocument: dit is een document dat binnen de Universiteit reeds aanwezig is. Het dient als bron voor een activiteit en is essentieel om een bepaalde activiteit uit te voeren of om een architectuurdeliverable op te leveren. • Architectuurdeliverable: een document dat een resultaat is van een bepaalde activiteit. Deze productsoorten worden schematisch weergegeven: Checklist
Organisatie document
Architectuur deliverable
FIGUUR 3: OVERZICHT VERSCHILLENDE PRODUCTSOORTEN BIJ HET PROCESMODEL
© Michel Houben, Nijmegen, 2005
7
6.3 Voorbeeld representatie procesmodel Hieronder enkele voorbeelden / fragmenten uit het opgestelde procesmodel. Voor het totale procesmodel zij verwezen naar de academische scriptie van Michel Houben (http://www.digital-architecture.net/scripties.htm).
De activiteiten van de opdrachtgever in de initiatiefase Strategisch plan
Beginpunt
Jaarplan 1.1.1.Opstellen business case Informatieplan Business Case
Opdrachtaanvraag
1.1.2.Verstrekking opdracht
FIGUUR 4: OVERZICHT OPDRACHTGEVER IN DE INITIATIEFASE Activiteiten: 1.1.1. ‘Opstellen business case’ Naar aanleiding van gesprekken, strategisch plan, jaarplan en informatieplan zal de opdrachtgever een business case opstellen. In de business case is het bestaansrecht van het project verwoord, de redenen om het project uit te voeren en van de te verwachten kosten en baten. [PRINCE1] Tijdens het project wordt er een projectstatus bijgehouden. In de projectstatus worden de projectvorderingen, besluiten en knelpunten beschreven. De status wordt continu besproken met de opdrachtgever en eigenaar. De uitvoer van deze activiteit is de business case. Samenvattend kan men stellen dat de business case een rechtvaardiging is voor het opstarten, uitvoeren, vervolgen en eventueel vroegtijdig, afsluiten van een project. 1.1.2. ‘Verstrekking opdracht’ Naar aanleiding van de business case, wordt er een formele opdracht voor het ontwerp van een applicatiearchitectuur opgesteld. De opdrachtaanvraag wordt in nauw overleg met de eigenaar opgesteld en overhandigd aan de architect. Architectuurdeliverable: •
Business case: het bestaansrecht van het project, waarom het project moeten worden uitgevoerd.
© Michel Houben, Nijmegen, 2005
8
•
Opdrachtaanvraag: de beschrijving van de opdracht aan de architect. De architect krijgt hierdoor een beter beeld van het doel van de applicatiearchitectuur.
Organisatieproducten: •
• •
Strategisch plan: een verantwoord plan is gebaseerd op de vijf P's: product, plaats, prijs, promotie en personeel. Een bedrijf heeft meer kans van slagen als de bedrijfsvoering is onderbouwd met een gedegen plan. Hierdoor wordt een beter beeld verkregen van de missie, visie en strategie van de Universiteit. Jaarplan: hierin wordt vastgesteld hoe de uitvoering van de taken op de te verwachten ontwikkelingen in de toekomst zal worden afgestemd. Informatieplan: dit is een plan waarin de Universiteit de volgende aspecten in kaart brengt: o Welke automatiseringsprojecten zijn gewenst of nodig? o Wat is de samenhang tussen de verschillende projecten? o Welk belang wordt gehecht aan elk van die projecten? o In welke volgorde worden deze projecten uitgevoerd? o Waarop moet men letten om eventueel de plannen bij te kunnen stellen?
7. Fysieke architectuur Achter de fysieke wereld van producten, diensten, productieprocessen, medewerkers en productiemiddelen als grondstoffen, halffabrikaten, gebouwen, apparaten en transportmiddelen, is een digitale wereld ontstaan. Een wereld waarin een digitaal alternatief bestaat voor veel van deze zaken, maar die tevens ondersteuning biedt voor het geordend functioneren van de processen in de fysieke wereld. [RIJS4] De fysieke wereld kan niet zonder de digitale wereld en andersom. Digitale architectuur kan worden beschouwd als de volgende evolutiestap in het denken over architectuur: een nieuw supplement op de fysieke architectuur, de architectuur van steden, gebouwen, landschappen en het interieur. In beide gevallen gaat het om artefacten. De term ‘architectuur’ duidt op de beheersing van complexiteit door middel van vorm. Het is wat aanmatigend dat sommige fysieke architecten die term hebben geannexeerd voor hun eigen vakgebied dat van de fysieke bouwkunde, temeer daar zij deze term op hun beurt weer ontleend hebben aan de Griekse scheepsbouw. [RIJS4] Tijdens een interview met een fysieke architect werd gesuggereerd dat de term architectuur in de digitale wereld niet bestaat, hij benoemde het als een structuur. Structuur heeft inderdaad te maken met architectuur, maar aspecten zoals beleving, constructie en gebruikerswaarde kan men niet in deze term omvatten. De definitie van fysieke architectuur volgens de architecten van de fysieke wereld [CLEVIS]: Fysieke architectuur is een ruimtelijke conceptvertaling van een programma van eisen rekening houdend met de drie vitrivius aspecten. Het concept en de functie bepalen het gebouw. © Michel Houben, Nijmegen, 2005
9
De architectonische kwaliteit van een gebouw in zijn gebouwde omgeving wordt bepaald door zijn gebruikswaarde, technische en esthetische kwaliteit en toekomstwaarde. Bouwen is samenwerken, samenwerken is meedenken, meedenken vraagt inzicht. Bij de vormgeving van een bouwwerk voert de fysieke architect een gevecht tegen de zwaartekracht. [RIJS7] Daarentegen ‘vecht’ de digitale architect enerzijds tegen complexiteit, anderzijds tracht hij een 'bewoonbare' digitale wereld te scheppen. [RIJS3] De bovenstaande filosofie en definitie hebben veel raakvlakken met de digitale wereld.
Gebruikswaarde
Digitale architectuur: Dynamische userinterface van een systeem Back-up systemen
Technische en esthetische kwaliteit Toekomstwaarde Géén autistische ICTsystemen, maar dynamische systemen
Fysieke architectuur: Klimaat eigenschappen in een ruimte Fundering van een gebouw Mogelijkheid tot uitbreiding van een gebouw
FIGUUR 5: VERGELIJKING DIGITALE EN FYSIEKE ARCHITECTUUR De bovenstaande indeling (figuur 5) is zowel in de fysieke als digitale wereld volledig bruikbaar. In de fysieke wereld zien we dat de uitvinding van het gewapend beton de mogelijkheid gaf dat wij grotere overspanningen konden toepassen. In onze wereld heeft het internet gezorgd dat we webservices kunnen gaan toepassen, de ultieme mogelijkheid om gedistribueerd systemen te ontwerpen. [RIJS6]
8. Stellingen Stelling 1: Architectuur moet gezien worden als bindmiddel, niet als investering. In een volatiele wereld komt er nog meer nadruk te liggen op de functie van architectuur als bindmiddel van de visie tijdens het ontwikkelen van oplossingen. Bij de Universiteit is het onzeker welke systemen in welke volgorde en samenhang zijn geïmplementeerd en kan de onderlinge cohesie alleen worden geborgd door het leggen van architectonische fundamenten. Door 'onder architectuur' te ontwikkelen klopt de samenhang, ondanks het gebrek aan zekerheid vooraf. [RIJS3] Stelling 2: Architectuur bevordert de samenwerking tussen de verschillende faculteiten van een universiteit. We zien steeds vaker dat er sprake is van wisselende patronen van universiteiten die nu eens samenwerken en dan weer met elkaar concurreren. Een interessant schaakspel, maar hoogst vermoeiend voor ouderwetse managers die opgroeiden in het industriële tijdperk. © Michel Houben, Nijmegen, 2005
10
De werkelijke waarde van een Universiteit ligt in de mogelijkheden die ze heeft om met partners, studenten, docenten en leveranciers samen te werken; kortom in haar positie in een ‘connected world’. Vaak is de student de belangrijkste partner voor een universiteit. Om te beoordelen of samenwerking echt mogelijk en haalbaar is, zal de Universiteit steeds meer gebruikmaken van architectuur, een architectuurbeschouwing die zich voortzet tot ver buiten de muren van de traditionele instelling. Stelling 3: Het procesmodel ‘concipiëren van een applicatiearchitectuur’ is één op één gelijk met het procesmodel ‘concipiëren van een fysieke architectuur’. Bij fysieke architectuur heeft men te maken met dezelfde fasen en rollen. De eigenaar van een gebouw, opdrachtgever (= overheid of gemeente), de architect en de stakeholders (bijvoorbeeld de patiënten van een ziekenhuis) komen overeen. De fasen van het procesmodel hebben dezelfde doelen zowel bij fysieke als digitale architectuur. Stelling 4: Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. [Albert Einstein] Het is belangrijker dat men zich iets bij het procesmodel kan voorstellen, dan de denkwijze van het procesmodel. Er zijn veel wegen die naar Rome leiden, de denkwijze achter het model is belangrijker dan de detaillering. In het procesmodel ligt het zwaartepunt bij de rol van architect, hij is de sleutelfiguur. Het is aan deze functionaris om er iets van te maken. Het doorlopen van de verschillende fasen moet zo praktisch, zichtbaar en transparant mogelijk worden gehouden. Stelling 5: De digitale architect moet net zoals de fysieke architect goed kunnen visualiseren en communiceren. Visualisatie is bij fysieke en digitale architectuur ontzettend belangrijk (bij de fysieke architectuur in de vorm van maquettes, bij de digitale architectuur in de vorm van A0 poster). Op deze manier krijgen de stakeholders een duidelijk beeld van de huidige en toekomstige situatie. Ten tweede is men in staat om met de stakeholders te brainstormen over aspecten als ontwerp, knelpunten en oplossingen. Goede visualisaties van de architectuur en ook het aanbieden van meerdere alternatieven, scenario’s genoemd, lokken een enthousiaste discussie uit bij de stakeholders, waardoor de betrokkenheid bij het architectuurtraject sterk wordt vergroot en men ook zelf creatief gaat meewerken. [RIJS6]
© Michel Houben, Nijmegen, 2005
11
Over de auteurs ing. M.T.M.G (Michel) Houben M.Sc. is momenteel werkzaam als consultant bij Accenture. Hij studeerde Hogere Informatica aan de Fontys Hogescholen Eindhoven en Informatiekunde aan de Radboud Universiteit Nijmegen. Drs. Hans Janssen is hoofd van de afdeling Concerninformatie van de Radboud Universiteit Nijmegen. Deze afdeling voert het functioneel beheer van alle universiteitsbrede informatiesystemen en is daarmee belast met het bewaken van de onderlinge samenhang van de systemen en het leveren van bestuurlijke informatie op basis van de in die systemen vastgelegde gegevens. Prof. dr. Daan Rijsenbrij behoort tot de ontwikkelaars van het architectuurgedachtegoed binnen Capgemini. Hij was initiatiefnemer en voorzitter van de Landelijke Architectuurcongressen 1999 – 2003. Sinds 1 september 2003 bekleedt hij een leerstoel aan de Radboud Universiteit Nijmegen op het gebied van de architectuur in de digitale wereld.
Literatuurlijst [BENTHEM]
Benthem J.F.A.K. van, Logica voor informatici, Addison Wesley, Amsterdam, 1991. ISBN 90 678 9484 2.
[CLEVIS]
Interview woensdag 15 juni 2005 met Ton Clevis-Kleinjans van Clevis Kleinjans Architecten. http://www.clevis-kleinjans.nl/
[ORDINA1]
Applicatieontwikkeling onder architectuur, 2002 ten Hagen & Sam Uitgevers, Den Haag, ISBN 90 440 0667 3, 2002.
[PAAUWE]
Paauwe & Partners, Enterprise Architectenbureau. Uitspraken en documenten van Mark Paauwe, website http://www.paauwe-enpartners.nl Het procesmodel is afgeleid van Dragon1, met als copyright Paauwe & Partners, Enterprise Architectenbureau (2005).
[PRINCE1]
De kleine Prince 2, gids voor projectmanagement. Derde herziene druk / eerste oplage, september 2002, ISBN 90-4400384-4.
[PRINCE2]
Hoe haal ik het beste uit mijn project? Prince2 voor opdrachtgevers. Auteur: Michiel van der Molen, 2004, ISBN 90 5931 183 3.
© Michel Houben, Nijmegen, 2005
12
[RIJS1]
Daan Rijsenbrij, Jaap Schekkerman, Harry Hendrickx (2004), Architectuur, besturingsinstrument voor adaptieve organisaties (de rol van architectuur in het besluitvormingsproces en de vormgeving van de informatievoorziening), Lemma; tweede druk, ISBN: 90 5931 281 3.
[RIJS2]
D.B.B. Rijsenbrij (2004), Architectuur in de digitale wereld (versie nulpuntdrie). Inaugurale rede uitgesproken bij de aanvaarding van het bijzonder hoogleraarschap (2004) in de informatiekunde aan de Radboud Universiteit. http://www.digital-architecture.net/oratie/inaugurele%20rede.doc
[RIJS3]
Stellingen Daan Rijsenbrij op website, 2005. www.digitale-architecture.net
[RIJS4]
Rijsenbrij, Daan, ‘Inleiding’, 2004, hoofdstuk 1 van het collegedictaat: http://www.digitalarchitecture.net/dictaat/hoofdstuk%201%20inleiding.doc
[RIJS5]
Rijsenbrij, Daan, ‘Digitale architectuur’, 2004, hoofdstuk 2 van het collegedictaat: http://www.digitalarchitecture.net/dictaat/hoofdstuk%202%20digit ale%20architectuur.doc
[RIJS6]
Rijsenbrij, Daan, ‘Architecting’, 2004, hoofdstuk 3 van het collegedictaat: http://www.digitalarchitecture.net/dictaat/hoofdstuk%203%20architecting.doc
[RIJS7]
Rijsenbrij, Daan, ‘De architect van de digitale wereld’, 2004, hoofdstuk 4 van het collegedictaat: http://www.digitalarchitecture.net/dictaat/hoofdstuk%204%20architect.doc
[RIJS8]
Rijsenbrij, Daan, Jaap Schekkerman, Harry Hendrickx, Hans Goedvolk en Jack van ’t Wout, ‘De Architect’, 2001, Derde Landelijk Architectuur Congres, Zeist. http://www.serc.nl/lac/LAC-2001/3skills/papers/De%20architect.pdf
[RIJS9]
Rijsenbrij, Daan, deze notitie is gepubliceerd in tiem (tijdschrift voor informatie en management), nr. 7, maart / april 2005, pp 28 – 32, getiteld ‘Architect in de Digitale Wereld (vechten tegen complexiteit)’. http://www.tiem.biz/
© Michel Houben, Nijmegen, 2005
13
[SOG1]
Martin van den Berg en Marlies van Steenbergen, DYA Stap voor stap naar professionele enterprise-architectuur, 2004, ISBN 9044011219.
[VERMEUL]
Vermeulen, Erik en Daan Rijsenbrij, De architect als informatieplanner of als informatieregisseur; wie levert welke architect?, Tweede Landelijk Architectuurcongres, Amsterdam, 2000.
© Michel Houben, Nijmegen, 2005
14