1. Architectuur: een begripsbepaling

trefwoorden: de oorsprong van architectuur, principes, het drieluik van Vitruvius, beschouwingsniveaus, digitale werkruimte.

1.1 Inleiding

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. Een digitale wereld waarin computerchips zorgen voor een razendsnelle verwerking en netwerken voor een wereldwijde verspreiding. Een digitale wereld met eigen wetten over tijd en tijdigheid, plaats en bereikbaarheid, eigendom en duplicatiemogelijkheden. Kortom een digitale wereld met een nieuw economisch model [1] , maar ook een wereld waarin wij ons persoonlijk functioneren dienen te herijken [2] . Reeds in 1996 roept de M.I.T. guru Nicholas Negroponte [1] ons op ons voor te bereiden op die digitale wereld middels zijn boek ‘being digital'.

Wij leven in één van de grootste overgangsperiodes van de cultuurgeschiedenis, een gigantische transformatie veroorzaakt door de uitvinding van de chip. Een vinding die dezelfde impact heeft als indertijd de ontdekking van het maken van vuur en de uitvinding van het wiel. Historici zullen terugkijkend uit het jaar 10.000 zich erover verbazen dat in een uiterst korte periode van krap 100 jaar, op de drempel naar het derde millennium, de totale samenleving radicaal werd getransformeerd. Tussen 1950 en 2050 zagen we een drastische overgang van lompe, onhandige, domme computers naar een samenleving, maximaal ondersteund door IT. Een samenleving waarin IT mens en onderneming [3] ondersteunt om zich maximaal te ontplooien.

Wij zitten nu midden in die overgangsperiode. Alles om ons heen wordt door IT ondersteund. Alles moet op het Internet. Nieuwe technologieën spoelen over ons heen. Zekerheden verdwijnen als sneeuw voor de zon. Alles kan en alles moet worden getransformeerd. Er komt behoefte aan orde en overzicht. De roep om architecten wordt daarom steeds luider, architecten die structuur kunnen aanbrengen. Structuur om overzicht en samenhang te bieden. Structuur als houvast. Maar structuur alleen is niet voldoende. Echte architectuur is een soort drieluik: ordening [4] , constructievoorschriften en een belevingsaspect. IT-systemen horen te appelleren aan een innerlijke beleving.

Voor het construeren van zaken in de digitale wereld is ook architectuur nodig [2], net zoals architectuur nodig is bij het construeren van zaken in de fysieke wereld van steden, gebouwen en landschappen: wij duiden dit aan met digitale architectuur [5] .

De architect Pieter van der Ree stelt dat architectuur gaat over artefacten, mensgemaakte objecten. Het dier leeft direct in de natuur. Wij mensen hebben als het ware een kunstmatige laag tussen ons en de natuur aangebracht. Architectuur ‘schuift' in tussen ons en de directe beleving van de natuur. De mens ontwikkelt zich in dat spanningsveld tussen ‘binnen' en ‘buiten'. Je zou ook kunnen stellen dat er een nieuwe werkelijkheid wordt toegevoegd. Als aanvulling daarop stel ik dat de werkelijkheid van steden, gebouwen en landschappen de eerste kunstmatige laag is die tussen ons en de natuur werd ingeschoven. Met de entree van de IT wordt er een tweede sterk interactieve laag tussen ons en de eerste kunstmatige laag geschoven. Ook deze laag vraagt om architectuur: de digitale architectuur.

Een architect in de fysieke wereld creëert een ruimte. Een ruimte om te leven, een ruimte om te werken. Een ruimte die past bij de maat van de Mens. Bij de vormgeving van het artefact dat die ruimte omsluit, voert hij een gevecht tegen de zwaartekracht. Voor digitale architecten is het de kunst om een digitale leef- en werkruimte te creëren. Een digitale ruimte waarin de mens wordt verleid zich te ontplooien, zich te ontwikkelen als werknemer maar ook als wereldburger. Hiervoor is naast veel vakmanschap ook creativiteit en durf nodig. Durf om de gebruiker als Mens centraal te stellen.

Bij het nadenken over vorm en inhoud van de digitale architectuur biedt de architectuur van de fysieke wereld een rijke bron van inspiratie. Dit geldt vooral voor de organische [6] architectuur, een wat informele stroming binnen de fysieke architectuur waarin het menselijk bewustzijn en haar ontplooiing als uitgangspunt wordt genomen. Een architectuurbenadering met bouwmeesters als Louis Henry Sullivan [7] , Frank Lloyd Wright [8] , Henry van de Velde [9] en Antoni Gaudi [10] ; voor een nadere verdieping zij verwezen naar Pieter van der Ree [4].

De digitale wereld is echter een wereld die nog te veel wordt gedomineerd door technofreaks, techneuten die artefacten creëren waarbij de technologische mogelijkheden belangrijker lijken dan de werkelijke behoefte van mens en onderneming. Overigens krijg ik dat gevoel ook wel eens in de fysieke wereld [11] als ik de werken van Santiago Calatrava aanschouw of het Centre Pompidou van Richard Rogers en Renzo Piano, hoewel dat laatste ontwerp een uit de hand gelopen grap schijnt te zijn [12] . Stelling 3a van Carel Weeber bij zijn afscheidscollege [5] in 2003 laat wat dat betreft aan duidelijkheid niets te raden over: “de faculteit Bouwkunde moet haar naam veranderen in ‘Faculty of Building Engineering', ‘Architecture' kan terug naar de kunstacademie”!

1.2 Terminologische terugblik

Digitale architectuur kan worden beschouwd als de volgende evolutiestap in het denken over architectuur: een nieuw complement [13] op de fysieke architectuur [14] , 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. Als zeevarende natie zijn de Grieken met architectuur begonnen op hun schepen, dat kan je duidelijk zien aan de vormgeving van hun eerste tempels. Die eerste tempels lijken heel veel op een schip: een stuurhuis en een voordek. En omdat de schepen toen nog van hout waren, betekende het Griekse ‘archi tekton': de eerste timmerman. Dat voorvoegsel ‘eerste' moet trouwens wel worden gezien als degene die de principes vaststelde.

De Grieken deden het eerst in hout, vervolgens stapten zij over naar het steen, en in de digitale wereld doen wij het met bits.

Laten we eens teruggaan naar de echte bron van het woord ‘architect'. Het Griekse woord ‘architekton' bestaat uit ‘archi' (eerste-,hoofd-) en ‘tekton' (timmerman, handwerksman, (scheeps)bouwer, kunstenaar).

Het Griekse ‘archo' komt van de Sanskrita dhatu ‘arh'. Dit betekent in het Nederlands ‘waardig, verdienstelijk' [15] . Het Griekse ‘tekton' komt van het Sanskrita ‘takshati'. Dit betekent in het Nederlands ‘hij vormt, hij construeert' [16] . Takshati is vormen door te snijden, maken en creëren, maar impliceert uiteindelijk ook het vormen in de geest, dus de mentale wereld. Zo wordt bijvoorbeeld Keizer Augustus algemeen erkend als de architect [17] achter de westerse wetgeving [18] . Veel filosofische [19] en religieuze richtingen beschouwen God, in welke benaming dan ook, als de architect achter het heelal. En dat beperkt zich gelukkig niet tot het fysieke deel, het ondermaanse [20] . De architect is dus bij uitstek degene die de eerste aanzet geeft bij het opstellen van vormen in de mentale wereld, dus zeker ook in de digitale wereld. Er kan dus worden gesteld dat de architect aan de wieg staat van het ontwerp of wellicht al daarvoor. Hij is de eerste vormgever waarna er vele ontwerpers zijn die onder zijn bezielende leiding het ontwerp nader uitdetailleren.

Wat leert deze etymologische beschouwing ons? Het concept ‘architectuur' blijkt een soort wisselbeker te zijn. Begonnen in de subtiele wereld van het Sanskrita, fysieker gemaakt in het Grieks, naar de digitale wereld van de moderne tijd. Architectuur lijkt nauw verbonden met het vakgebied waarnaar de meest maatschappelijke belangstelling uitgaat. En dat wordt ongetwijfeld de digitale wereld.

Is er trouwens een fysieke architect die mij het essentiële verschil kan uitleggen tussen een kantoorgebouw als werkinstrument en een digitale werkplek?

Groot probleem is trouwens dat het architectuurbegrip in de digitale wereld een stuk ‘abstracter' [21] is dan in de fysieke wereld. IT is voor veel mensen al redelijk abstract. En in feite is architectuur ook tamelijk abstract, het wordt immers indirect waargenomen. Dus digitale architectuur is een abstractie over een abstractie. Daardoor hebben veel mensen nog wat moeite om in te zien dat er een nieuw soort architect aan de horizon is verschenen. Maar digitale architectuur is niet meer tegen te houden. Als student in de theoretische natuurkunde droomde ik van de Nobelprijs. Deze droom heb ik nu ingewisseld voor de Pritzker prijs [22] .

Menig fysieke architect heeft gereflecteerd over de vraag “met welke zintuigen wordt architectuur waargenomen?”. Daar is nog geen eenduidig antwoord op, maar die vraag lijkt trouwens nog een stuk moeilijker voor de digitale wereld. Toch zien we overal om ons heen een ‘experience' economie opkomen, een emotie-economie. Beleving wordt belangrijker dan prijs.

De term ‘architectuur' wordt in de IT-sector veelvuldig en al jaren lang gebezigd, zowel nationaal als internationaal. Al in de zestiger jaren van de vorige eeuw gebruikten Frederick Brooks en Gerrit Blauw [9] de aanduiding ‘architectuur' bij de beschrijving van het operating system OS/360 van IBM en Andy Tanenbaum [23] [10] gebruikte de term ‘architectuur' voor de technische infrastructuur. Jacques Theeuwes [11] en Jan Truijens [12] pasten het architectuurconcept eind tachtiger jaren toe op het niveau van de informatievoorziening. De uitermate verdienstelijke visionair James Martin gebruikte de term ‘architectuur' in de negentiger jaren vanuit een meer businessachtige beschouwing van de inzet van IT-middelen. In zijn baanbrekende boeken ‘The Great Transition: using the seven disciplines of enterprise engineering to align people, technology, and strategy' [13] en ‘Cybercorp: the new business revolution' [14] positioneert hij reeds in 1995 architectuur op enterprise niveau. In die zelfde tijd gunt onze Nederlandse architectuur guru Jaap van Rees ( www.jaapvanrees.nl ) middels zijn boekje ‘de informatie-architect' [15] ons een nuchtere kijk op architectuur met een aantal heldere, bruikbare constructieprincipes.

Door de Landelijk Architectuur Congressen [24] ( www.lac2004.nl ) waarbij ik in de eerste vijf jaar qua organisatie intensief betrokken ben geweest, heeft architectuur een niet meer uit te wissen plaats in Nederland ingenomen. Dit overigens geheel in de lijn met wat er in de rest van de wereld is gebeurd.

1.3 De definitie

In gesprekken met fysieke architecten is het heel moeilijk hen een bruikbare definitie te ontfutselen over architectuur; een aardige beschouwing is overigens gegeven door Paul Shepheard [17]. Velen zien architectuur als een van de eerste kunstvormen [25] en probeer daar maar eens een definitie van te geven.

In Compton's Encyclopaedia vinden we een wat meer fundamentele definitie van het begrip architectuur:

1. By the simplest definition, architecture is the design of buildings, executed by architects. However, it is more. It is the expression of thought in building. It is not simply construction, the piling of stones or the spanning of spaces with steel girders.

2. It is the intelligent creation of forms and spaces that in themselves express an idea.

Dat laatste sluit mooi aan bij de ‘The Autobiography of an Idea' van Louis Henry Sullivan [18]. Het eerste gaat in feite nog een stap verder en neigt in de richting van Christoffer Alexander's ‘quality without a name' [19]. Hier wordt vooral door IT'ers vaak zeer vaag, bijna mythisch, over gesproken. Maar die ‘ quality without a name' is natuurlijk niets anders dan de subtiele schoonheid zoals bedoeld door Socrates zoals ik reeds aanhaalde in mijn vorige inaugurele rede [20].

Omdat in de digitale wereld in tegenstelling tot de fysieke wereld er meestal geen ‘veiligheidsmarges' worden toegepast in applicaties [26] , is het veel belangrijker om je exact uit te drukken [27] . Een helder begrip van architectuur is daarom een absolute must. Ik hanteer de volgende definitie [2]:

digitale architectuur is ‘een coherente, consistente verzameling principes, verbijzonderd naar uitgangspunten, regels, richtlijnen en standaarden [28] die beschrijft hoe een onderneming, de informatievoorziening, de applicaties en de infrastructuur zijn vormgegeven en zich voordoen in het gebruik'.

A rchitectuur wordt mede bepaald door sociale, financiële en technische randvoorwaarden in de onderhavige onderneming. Daarnaast zullen invloeden van buiten in beschouwing moeten worden genomen, als externe wet - & regelgeving, usance in de bedrijfstak, concurrentieverhoudingen en communicatiepatronen.

Elk ontwerp van de onderneming dan wel haar ondersteuning met IT-middelen, begint dus met een verzameling architectuurprincipes, die als het ware de ontwerpruimte inperkt. Architectuur is daarom een hulpmiddel om ontwerpbeslissingen te vereenvoudigen en te uniformeren.

Om bovengenoemde principes, regels, richtlijnen en standaarden ten opzichte van elkaar te plaatsen worden soms metamodellen gebruikt, zoals bijvoorbeeld de splitsing ‘front office – mid office – back office'. Deze metamodellen zijn zelf veelal ook weer het gevolg van principes op het structureringsniveau.

In wetenschappelijke kringen wordt de definitie IEEE 1471-2000 [21] algemeen aanvaard als uitgangspunt bij alle architectuurbeschouwingen. IEEE definieert architectuur, van software intensieve systemen, als ‘the fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution'.

Dit klinkt als een nogal klinische definitie die architectuur degradeert tot een soort meta-structuur zonder de essentiële beleving van schoonheid.

N.B. Op het niveau van de onderneming zien we dat in de vakliteratuur jammer genoeg termen als ‘bedrijfsarchitectuur' en ‘inrichting van de onderneming' door elkaar worden gebruikt, dus architectuur als een zwak synoniem voor ‘inrichting'.

1.4 Principes

Architectuur, zeker in de digitale wereld, is dus 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. Foute principes kunnen desastreus zijn bij transformaties, zeker in dit tijdperk van verregaande outsourcing. Principes dienen te worden geconcretiseerd naar zaken die moeten, dat zijn de regels en standaarden, en zaken die verstandig zijn: de richtlijnen, ook wel ‘best practices' genoemd. Regels gelden binnen de eigen onderneming. Standaarden zijn nodig voor de communicatie met de buitenwereld en voor het (eventuele) gebruik van gekochte componenten. Richtlijnen hebben wat meer interpretatievrijheid ten opzichte van regels. En omdat bepaalde situaties vaak voorkomen, is het onverstandig vanuit de principes steeds weer de bijbehorende regels, richtlijnen en standaarden vast te stellen. Voor dergelijke situaties wordt een sjabloon in elkaar gezet dat wordt aangeduid met de term ‘pattern'. De relatie tussen principe en pattern is essentieel. Een pattern is iets herbruikbaars en het principe geeft aan welke scope het herbruikbare heeft. Een pattern [29] geeft dus voor een bepaald probleem in een bepaalde situatie een (her)bruikbare oplossing die meestal op detailpunten nog aanpassing nodig heeft. Vooral bij moeilijke beveiligingsproblemen spelen patronen een belangrijke rol.

Deze principes zullen uiteindelijk resulteren in kwaliteitsattributen van informatie en informatiesystemen (zie Guus Delen en Daan Rijsenbrij [23]) of service level agreements bij outsourcing [30] .

Principes zijn nodig op allerlei gebieden vanaf de business tot en met het datacommunicatienetwerk. De vrijheid van het ene principe kan de vrijheid van het andere principe sterk beïnvloeden. Bij een bepaalde keuze van het datacommunicatienetwerk kunnen sommige mogelijke klantcontacten niet worden bewerkstelligd. Daarom dienen de principes onderling consistent te zijn en toekomstvastheid te vertonen.

Veel architectuurprincipes vinden hun oorsprong in de strategie en de beoogde bedrijfscultuur. Ze komen voort uit het eigen missiestatement, de visie en de gekozen concurrentiestrategie, maar ook uit het ecosysteem [31] .

Goede principes zijn holistisch van karakter en daardoor merkbaar in elk haarvat van de onderneming, ze zijn bedoeld om sturing te geven.

Bijvoorbeeld e en principe als ‘wij geven de klant een individuele benadering' werkt door in alle architectuurgebieden: business processen en skills, informatieverkeer in de onderneming, de applicaties en technische infrastructuur.

Een principe als ‘de klant kan 24 uur per dag zaken met ons doen' is een principe dat nogal wat consequenties heeft voor de presentatie in het digitale contact. De klant heeft toegang via een veelheid van interfaces voor verbinding met de leverancier: mobiele telefoon, pc, palmtop, telefoon, automatic teller machine en het loket. Ieder systeem moet de juiste boodschappen kunnen uitvoeren of ontvangen in het juiste formaat.

Belangrijk bij het formuleren van principes is zich af te vragen wat de benodigde keuzevrijheid is waarmee rekening moet worden gehouden bij het opstellen van een ontwerp. ‘What if'-scenario's zijn dus een belangrijke analysemethode om te komen tot een toekomstvaste architectuur.

Niet alleen inzicht in het zakendoen, maar ook inzicht in trends en behoeftes van de markt kan leiden tot principes die een grote impact hebben op de inrichting van een onderneming. De architect van The Opera House van Sydney, Jørn Utzon, heeft de impact van een specifieke visie op dit bouwwerk treffend weergegeven. De specifieke visie is dat mensen graag uit de dagelijkse routine in een fantasiewereld komen:

“everything that is planned for the Opera House is based on the desire to take people from their daily routine into a world of fantasy, a world which they can share with the musicians and actors (juli 1964)”. Dit statement maakt duidelijk waarom het gebouw een sprookjesachtige uitstraling heeft.

Belangrijk voor elke fysieke architect, maar de organische architect in het bijzonder, is het vinden van het ‘ordenend principe' voor de bouwopdracht. Ook in de digitale wereld is dat ordenende principe essentieel. Het ordenende principe borgt namelijk de coherentie van alle principes waaraan het ontwerp en de constructie dienen te gehoorzamen.

Voor een heldere systematische opsomming van principes is een academisch niveau een absolute vereiste. Een reflectieve instelling is nodig om zodanige principes neer te kunnen zetten opdat we tussen de bomen het bos weer gaan zien. Voor het opstellen van e en geïntegreerde verzameling principes dient een veelheid aan factoren mee te worden gewogen, zoals visie, ondernemingsdoelstellingen en -strategie, bestaande structuren, actuele informatievoorziening, sociale, financiële en technische randvoorwaarden, bedrijfscultuur en communicatiepatronen, interne en externe wetten, regels en voorschriften, ontwikkelingen in de omgeving of de markt en concurrentieverhoudingen. Het is dit samenspel van factoren dat uiteindelijk bepaalt hoe taken, activiteiten en processen optimaal door IT kunnen worden gefaciliteerd.

Naast de door de informatica sinds decennia met succes bestudeerde onderwerpen uit de systeemtheorie en de cybernetica zijn daarbij onderwerpen uit de alfa faculteiten van groot belang. Een goede architect heeft een a-inlevingsvermogen en een ß-denkraam.

1.5 Het drieluik van Vitruvius

Vitruvius, de bouwmeester van Julius Caesar en Augustus, onderscheidde in de eerste eeuw voor Christus in zijn ‘architectura' [24] drie aspecten aan architectuur: ‘utilitas', ‘firmitas' en ‘venustas'. Utilitas staat voor de gebruiksaspecten: doelmatigheid, nuttigheid en deugdelijkheid. Firmitas staat voor fysieke zaken als: duurzaamheid, vastheid, en sterkte. En venustas staat voor bekoorlijkheid, uiterlijk schoon, dus de beleving. Een moderne verwoording van een dergelijk drieluik is te vinden op de website www.habiforum.nl . Zij stellen dat als je een huis koopt je let op drie kenmerken: de gebruikswaarde, de belevingswaarde [32] en de toekomstwaarde [33] . De respectievelijke bijbehorende vragen: zijn de gebruiksmogelijkheden passend voor de activiteiten van mij en mijn gezin, past de sfeer van huis en de buurt bij mijn leefstijl en geeft die een aangenaam gevoel, is het huis aan te passen aan veranderende woonwensen, goedkoop in onderhoud en is het op termijn goed te verkopen. Zij stellen dat tezamen deze waarden de ruimtelijke kwaliteit van het huis vormen. Volgens hen zijn dezelfde waarden aan de orde bij het bepalen van de ruimtelijke kwaliteit van een straat, een buurt, wijk of zelfs een regio. Daarbij zullen bij de verschillende waarden wel steeds andere kwaliteitskenmerken worden gebruikt, maar in essentie gaat het om dezelfde waarden.

Architectuur is dus een mengsel van bouwkunde (de structuur van de onderliggende componenten), onderwerpen uit de constructieleer (de technische eigenschappen van de onderliggende componenten en de verbindingen daartussen) en de stijl (‘look' and 'feel').

Vertaald naar de digitale wereld:

· de functionaliteiten en hun onderlinge samenhang (de topologie):
de gebruiksmogelijkheden van het artefact;

· de gebruikte componenten, technologieën en de integratietechnieken [34] :
voor een degelijke constructie;

· het uiterlijk gedrag, de beleving door gebruikers:
voor de sfeerbepaling, het gebruiksplezier.

Dat nog niet elk artefact in de digitale wereld hier volledig aan beantwoordt, weten wij allemaal. Maar dat probleem zien we ook nog steeds in de fysieke wereld na ruim 5.000 jaar, aannemende dat de eerste piramides onder architectuur zijn gebouwd.

Hoewel deze drie aspecten gescheiden worden genoemd staan ze niet los van elkaar. Keuzes in de een kunnen de vrijheid in de ander beïnvloeden , zij zijn innig met elkaar vervlochten. De juiste afstemming zorgt dat een artefact een ziel krijgt, dat het iets is. Dat laatste, die onderlinge harmonie, is het geheim van de architect.

Het is belangrijk om aan alle drie aspecten voldoende aandacht te besteden. We zien echter dat van oudsher het constructieaspect erg veel aandacht krijgt, het gebruiksaspect wordt al wat moeilijker en het belevingsaspect is vaak het stiefkind. Probleem daarbij is dat wij nog niet echt weten wat die gebruiker werkelijk wil. Belangrijk voor dit aspect is het vinden van de ‘Menselijke Maat' in de IT, net zoals een binnenhuisarchitect rekening houdt met de ‘Menselijke Maat' bij het ontwerpen van een kamer.

Bij de beleving staat de gebruiker op de voorgrond [35] , bij de gebruikswaarde de eigenaar en bij de constructie de bouwer of het onderhoudsteam. Rondkijkend door de onderwijsinstellingen in Nederland zou ik willen stellen dat voor beleving wat meer mag worden gekeken naar de Rietveld Academie, de constructie is vanouds het terrein van de technische universiteiten. De structurering (ordening), die als doel heeft inzicht en overzicht te verschaffen, inclusief de sociale, psychologische context hoort bij de ‘universele' universiteiten.

Er kunnen dus drie deelverzamelingen van principes worden onderscheiden: principes die te maken hebben met de functionaliteiten en de ordening daarvan (gebruikswaarde), principes die te maken hebben met de constructie en de materiaalkeuze en principes die te maken hebben met de beleving.

1.5.1. Structuur / gebruikswaarde

Bij het aspect ‘structuur' wordt aangegeven wat de relatie is tussen de verschillende functionaliteiten: een soort functionele decompositie [36] . Dus welke componenten kunnen worden onderkend en hoe werken die met elkaar samen. Een goede structuur borgt de onderhoudbaarheid en de aanpasbaarheid van het artefact waardoor het artefact voor langere tijd bruikbaar zal zijn. Voorbeelden van principes voor een bruikbare structuur zijn de scheiding in front-, mid- en backoffice; de verschillende client-server modellen en de scheiding tussen organisatieafhankelijke en organisatieonafhankelijke gegevensstructuren.

Het onderwerp structuur is terug te vinden op vele aggregatieniveaus, dus voor het totale artefact en vervolgens iteratief voor vele van haar onderdelen.

Structuur is trouwens geen momentopname. Bij veranderingen moet de essentie achter de samenhang in de structuur kunnen blijven bestaan. Veranderingen dienen snel en professioneel te kunnen worden geïmplementeerd. Voor dat laatste geval pleiten wij voor een opbouw in componenten op alle niveaus: business-, software- en technologiecomponenten. Die componenten behoren zodanig te worden gekozen dat mogelijke veranderingen zo weinig mogelijk verschillende componenten tegelijk raken. Eenvoudige veranderingen zijn veranderingen waarin slechts één component wordt veranderd. De volgende categorie veranderingen in moeilijkheidsgraad zijn de veranderingen die niet alleen één component betreffen, maar die tevens de relaties met omgevende componenten verandert. De moeilijkste veranderingen zijn echter degene die ertoe leiden dat de structuur van het systeem aangepast dient te worden. En dat willen we feitelijk zo min mogelijk, dit is de kern van architectuurdenken: architectuur dient rotsvast te blijven staan en houvast te geven terwijl de rest verandert.

De juiste keuze van componenten is dus cruciaal voor een flexibele, snel aanpasbare onderneming. Componenten kunnen trouwens ook services zijn die eventueel van een externe service provider zijn te betrekken.

Het gebruiksaspect wordt meestal gevisualiseerd met eenvoudige modellen waarmee direct de consequenties van eventuele veranderingen zichtbaar zijn.

1.5.2. Constructie

Bij het aspect ‘constructie' buigen we ons over de vragen ‘met welke technologieën' en ‘met welke integratiemechanismen'.

Gaan we pakketsoftware gebruiken of bouwen we zelf, hopelijk met standaard componenten. Gebruiken we Java en XML of doen we het met een 4GL. Passen we een softwarebus toe of gebruiken we andere middleware-oplossingen. Gebruiken we een genetisch algoritme of leggen we een neuraal netwerk neer.

Het uiteindelijke streven is een artefact met ‘intelligente' interfaces dat zich als een ‘ organisch' systeem kan aanpassen aan een veranderende omgeving: stabiel doch flexibel.

Goede principes voor het constructie-aspect zijn belangrijk voor de maakbaarheid van het artefact. En ook de aanpasbaarheid komt hier weer om de hoek kijken.

1.5.3. Beleving

Dat beleving door de gebruikers een essentieel aspect is van architectuur is een open deur. Het artefact is immers bedoeld voor de gebruikers, niet voor de constructeurs. Daarom bepaalt de beleving in belangrijke mate of het artefact bruikbaar is, geschikt voor het doel [37] . De beleving moet de rol ondersteunen die het artefact in zijn omgeving speelt. Maar beleving moet ook passen bij de (bedrijfs)cultuur en werkwijze van de extern betrokkenen.

Veel fysieke architecten, Gaudi in het bijzonder, hebben geworsteld om de sleurbevorderende middelmatigheid te overwinnen. Gaudi had de moed om een frisse belevingsruimte te scheppen in het grijze, grauwe Barcelona van het begin van de vorige eeuw.

Ook in onze tijd zie je een dergelijke revolutie tegen de gezapigheid. Nederlands meest roemruchte architect, Carel Weeber, doet een oproep voor het wilde wonen [25], een opstand tegen de ‘versteende tentenkampen' die middels Vinex worden gepland, die de mens elke vorm van leefgenot ontnemen.

Het ‘tijdloze' was het hoofdmotief van Christopher Alexander in zijn trilogie ‘The timeless way of building' [19], ‘A pattern language' [27] en ‘The Oregon experiment', verschenen eind zeventiger jaren. Het doelt op zijn persoonlijke overtuiging dat architectuur dient aan te sluiten op een innerlijke beleving van de gebruikers en niet op de laatste modefratsen. Hij vond dat de architectuurtheorie op dat moment failliet was. Er lag te veel nadruk op visuele effecten en veel te weinig op ruimtelijke en emotionele beleving.

De parallel met de IT wereld is groot. Ook die wereld wordt tegenwoordig overstelpt door allerlei technologietjes die als spiegeltjes en kraaltjes over de gebruikersgemeenschap worden uitgegoten. Dus veel visueel effect, terwijl de vraag naar een echte noodzaak achterwege blijft.

De werkelijke roeping van een fysieke architect bestaat uit het ontwerpen van steden, gebouwen en landschappen die de creatieve vermogens van mensen aanspreken in een wereld die steeds mechanischer dreigt te worden.

Ook in de digitale wereld komt er steeds meer behoefte aan een architectuur die niet alleen functioneel is, maar die appelleert aan de beleving [38] . Een architectuur die maximaal verleidt tot optimale betrokkenheid. Een informatiesysteem, een PC, een PDA moet aanvoelen als een goedzittende prothese. Het is niet van jou, maar het voelt natuurlijk aan: het knelt niet, het irriteert niet. De realiteit met de hedendaagse computers is daar nog ver vandaan. In feite is de gemiddelde applicatie zo saai, zo sleur bevorderend, zo gebruiksonvriendelijk als de onderliggende chips. Technologisch is er tegenwoordig erg veel mogelijk. In principe kunnen er informatiesystemen worden ontworpen die uitgaan van de mens. Maar wij zien nog te veel informatiesystemen die uitgaan van de technologie. Dit is een werkwijze die veel architecten hebben overgenomen uit het mainframetijdperk, waarin de gebruiker nog de slaaf was van de apparatuur.

Vertaald naar de wereld van IT is beleving de ‘look and feel' van het artefact voor de gebruikers. De belangrijkste elementen die de beleving beïnvloeden zijn: de user interface, de navigatiepaden, de interactieprotocollen en de personalisatiemogelijkheden.

De user-interface kan opgeleukt worden met allerlei iconen en andere vormen van visualisaties. Bovenal biedt hypertext-technologie [39] de mogelijkheid om meerdere niveaus aan te brengen in die user-interface.

Navigatiepaden [40] en de daarbij behorende bewegwijzering om in de doolhof van gelinkte websites en de ter beschikking gestelde applicatiefunctionaliteiten de weg te kunnen vinden dient zodanig te zijn dat er nauwelijks behoefte is aan gebruikshandleidingen, helpschermen of andere tekstuele uitlegvormen.

Met interactieprotocollen wordt bedoeld hoe gebruiker en systeem met elkaar omgaan en ‘wat zij voor elkaar kunnen betekenen'.

Personalisatie betreft de aanpassingsmogelijkheden om iets eigens te geven aan de interface, iets huiselijks. Een gebruiksinterface speciaal voor jou, afgestemd op jouw smaak, jouw behoefte en jouw niveau. Ook het informatieaanbod wordt steeds meer toegesneden op jouw specifieke behoeftes. Dat lijkt heel mooi, aan de andere kant creëert het een intieme relatie met de computer die tot zware emotionele binding kan leiden.

De relatie tussen beleving en structurering lijkt aan te sluiten op de losse definitie uit de fysieke wereld: ‘architecture is the fit between form and function'. Bepaal dus de benodigde functionaliteiten met alle stakeholders (in vakjargon ‘requirement engineering') en pas dan architectuur toe om die functionaliteiten vorm te geven.

1.6 Beschouwingniveau's

Om de architectuuruitdaging in de fysieke wereld enigszins overzichtelijk te maken wordt het probleem opgedeeld over een aantal detailleringsniveau's. Meestal onderscheiden we stedenbouwkundige architectuur (urbanistiek), de architectuur van het omringende landschap en de verbindende infrastructuur, de architectuur van aparte stadswijken en vervolgens de architectuur van de individuele gebouwen. En tenslotte onderscheiden we nog de architectuur van de inrichting van ruimtes (binnenhuisarchitectuur) en het bijbehorende design van meubelen en apparatuur.

De architectuur op het niveau van een stad heeft veel weg van een structuurplan en beschrijft bijvoorbeeld de indeling in gebieden voor wonen, werken, recreëren en natuurgebieden. De architectuur op wijkniveau heeft het karakter van een bestemmingsplan, een nadere detaillering van een bepaald gebied en geeft daar nadere specificaties, regels en richtlijnen voor. Een gebouwontwerp geeft invulling aan een bepaald object binnen dat bestemmingsplan en moet voldoen aan de regels van dat bestemmingsplan.

Deze indeling is ook in de digitale wereld volledig bruikbaar. Ook in de beschrijving van een onderneming waar IT een belangrijke ondersteunende rol speelt, onderscheiden wij, om de complexiteit te reduceren, vaak vier niveau's:

het ondernemingsniveau, het domeinniveau, het niveau van de informatiesystemen en de digitale werkruimte.

1.6.1 Enterprise architectuur

Op ondernemingsniveau maken we een high-level ontwerp van de onderneming in zijn geheel. Het doel is een eerste indeling in domeinen bestaande uit bedrijfsprocessen, de applicaties en de onderliggende technische infrastructuur. Het is verstandig een onderneming te zien als een intern ecosysteem, waarbij de domeinen diensten leveren aan elkaar en aan de (externe) klanten. Een dergelijke organisatorische ontvlechting vergroot de bestuurbaarheid van de onderneming en vereenvoudigt eventuele outsourcing.

Er kunnen meerdere niveaus van enterprise architectuur zijn. Zo zien we op een universitaire instelling een enterprise architectuur op universiteitsniveau, een enterprise architectuur op faculteitsniveau en vervolgens een enterprise architectuur op subfaculteitniveau.

Enterprise architectuur en (technische) infrastructuur horen onverbrekelijk bij elkaar. Onder infrastructuur verstaan we alle voorzieningen die gemeenschappelijk zijn te gebruiken. Behalve de technische infrastructuur kunnen dit ook basisregistraties zijn of gemeenschappelijke functionaliteiten. Een domein maakt in de regel gebruik van de infrastructuur van de gehele onderneming, doch er kunnen eventuele extra's nodig zijn.

Een enterprise architectuur heeft meerdere gebruiksdoeleinden: atlas voor het topmanagement, beheersing van de complexiteit, kaderzetting voor realisatie en communicatiemiddel. Het atlasaspect van de enterprise architectuur wordt gestalte gegeven door een verdeling van de onderneming in een aantal redelijk autonome domeinen. H oofddomeinen zijn vaak: delivery, marketing & sales, leveranciersrelaties & inkoop. O ndersteunende domeinen beslaan zaken als personeel, informatie, organisatie, financiën en huisvesting.

1.6.2 Domein-architectuur

Domein-architectuur valt te vergelijken met het bestemmingsplan van een stadswijk. In één oogopslag moet duidelijk zijn welke principes gelden, welke bedrijfsprocessen er lopen, hoe de business zich ontwikkelt, hoe technologie is geïntegreerd en hoe klanten hierop zijn aangesloten.

In plaats van te spreken over bedrijfsprocessen is het beter een domein te beschouwen als een verzameling van services die zij levert aan de omgeving.

Architectuur is ‘principe georiënteerd', het ontwerp echter is ‘service georiënteerd'. Een domein levert dus services naar andere domeinen of naar buiten. Services die nauwkeurig zijn gedefinieerd met een SLA [41] en geëtaleerd in een duidelijke service-catalogus. Services die zouden kunnen worden geoutsourced.

Naast de informatievoorziening zijn er ook allerlei andere bedrijfsmiddelen die continu veranderen, die aanpassing nodig hebben en die bijsturing behoeven. Denk hierbij aan de organisatorische structuur, het personeel, de gebouwen en de productiemiddelen. Om de verandering van deze zaken synchroon te laten lopen met de veranderende informatievoorziening is domein-architectuur nodig in de rol van een atlas om het overzicht te bewaren en de structuur te bewaken. Bij veel outsourcingdeals zien wij dat een aantal van bovengenoemde bedrijfsmiddelen wordt overgedragen aan de service provider.

Op domeinniveau schetsen we de zaak een stap verder tot de individuele (informatie)systemen.

Het leeuwendeel van de transformaties in een onderneming spelen zich af binnen een domein. Daarom worden op dit niveau representaties van tussenliggende architecturen gemaakt (‘islands of stability') waar, althans tijdelijk, de business- en informatiesystemen gedurende de transformatie doorheen gaan. De winkel moet immers open blijven tijdens de verbouwing. Omdat bij dergelijke transformaties vaak een groot aantal informatiesystemen zijn betrokken wordt hier programma-management toegepast [42] .

1.6.3. Informatiesysteem niveau

Op het laagste niveau wordt de architectuur van de individuele informatiesystemen opgesteld. De architectuur op dit niveau bevat alle principes, regels en richtlijnen die nodig zijn om te beslissen over de realisatie van die informatiesystemen.

De architectuur op dit niveau is een verbijzondering van de architectuur van het onderhavige domein.

Overigens is het verstandig op enterprise niveau een typologie op te stellen van de applicaties met elk hun eigen architectuurkarakteristieken.

1.6.4 Digitale werkruimte

In de fysieke wereld wordt als binnenste architectuurniveau onderkend ‘de inrichting van het gebouw'. De bemoeienis gaat, zoals prof. Bakema al zei “van Stoel tot Stad” [43] , door Jan Brouwer in zijn afscheidsrede [7] gepopulariseerd tot ‘van zitje tot city'.

Ook de digitale wereld heeft een volgend niveau: de digitale werkruimte [44] .

De digitale werkruimte biedt echter veel meer mogelijkheden. Het kan immers tegelijk toegang verstrekken tot een zeer grote verscheidenheid aan domeinen [45] , en daarbij volledig worden maat gesneden op het betreffende roltype. Ik zie een binnenhuisarchitect nog geen keuken ontwerpen die tegelijk toegang beidt tot een kruidenierszaak, een afhaalchinees en de wijnwinkel. Dit is een aspect waarin de digitale architectuur veel ruimer is dan zijn fysieke voorganger.

Dit toeganghebbend tot een aantal domeinen tegelijk is een enorme bevrijding. Ik vraag niet meer aan een gebruiker wat zijn (informatie)behoefte is, nee, als architect creëer ik een digitale ruimte waarin iemand zijn eigen behoefte kan vervullen. Een ruimte gevormd door de digitale mogelijkheden, toegesneden op de rol van de betreffende gebruiker. Hierdoor zijn wij overgestapt van een technologische optiek naar een gebruikersoptiek.

Een onderneming dient zijn medewerkers optimaal te ondersteunen opdat zij zich maximaal kunnen ontplooien in hun werk. Een goed ingerichte digitale werkplek is daarbij een vereiste. Dit kan worden gezien als een soort binnenhuisarchitectuur, waarbij het juiste evenwicht dient te worden gevonden tussen bedrijfsbelang en individuele belangstelling.

Een architectuurprincipe bij het opstellen van een ontwerp voor een dergelijke digitale werkruimte is: ‘zet de mens centraal!'

Een digitale werkruimte moet eenvoudig op andere locaties benaderbaar zijn. Dus of ik thuis zit, onderweg ben of een klant bezoek, ik kan overal in mijn eigen digitale werkomgeving verblijven. Thuiswerk wordt trouwens regel, althans bij digitale producten en diensten. Werken (en ook studeren) moet je doen als je fris bent en dat is voor een ieder op een ander moment en wellicht op een andere plaats. Werken doe je thuis, overleggen doe je op een (gehuurde) werklocatie.

1.6.5 Ecosysteem

De werkelijke waarde van een onderneming wordt steeds meer bepaald door haar rol en plaats binnen het ecosysteem, het valueweb. Alles draait om de mogelijkheden die zij heeft om met partners, leveranciers en klanten samen te werken: kortom haar positie in de ‘connected world' [46] . Om te beoordelen of dit mogelijk en haalbaar is, zullen ondernemingen steeds meer gebruikmaken van extended enterprise architectuur (dus zoiets als ecosysteemarchitectuur [47] ). Een architectuurbeschouwing die zich voortzet tot ver buiten de muren van de traditionele onderneming. Tevens zien wij dat moderne architectuurbeschouwingen op enterprise niveau van buiten naar binnen worden opgesteld, buiten zijn immers steeds meer interessante serviceproviders [48] te vinden.

Voordat kan worden nagedacht over het integreren van ketens of schakels van ketens als onderdeel van een ‘collaborative market' [49] , is het belangrijk om inzicht te krijgen in de samen te stellen delen waaruit een ‘collaborative market' zou kunnen bestaan en de onderliggende afhankelijkheden van deze schakels van IT . Zaken als beveiliging en governance over en binnen de collaborative market zijn belangrijke issues. Zij dienen daarom te worden geadresseerd bij het denken over integratie en samenwerking tussen schakels en het overkoepelende valuemanagement. Een overkoepelende architectuur voor de collaborative market [2] is een noodzakelijk besturingsinstrument in de besluitvorming over het opnemen en integreren van schakels. Als ondernemingen of processen niet goed op elkaar aansluiten, informatiesystemen moeilijk zijn te koppelen of als netwerken op infrastructureel gebied niet goed met elkaar kunnen communiceren, dan zijn dat de eerste vraagstukken die bestudering behoeven in een traject dat is gericht op samenwerking binnen de collaborative market.

In een collaborative market wordt het vermogen tot samenwerken, met wellicht steeds wisselende contacten, belangrijker dan de kracht van concurreren. De crux in een dergelijke markt is te zorgen dat de onderneming zo lenig (‘agile') mogelijk wordt. Alles wat kan worden geoutsourced, moet de deur uit. Zorg daarbij voor betrouwbare, innovatieve providers.

1.7 Verschil tussen de digitale wereld en de fysieke wereld

Hoewel de analogie met de wereld van steden, huizen en landschappen vrij goed opgaat, zijn er toch enkele essentiële verschillen.

Een groot verschil tussen de architectuur van de fysieke wereld en de architectuur in de digitale wereld is dat huizen en steden anorganische artefacten zijn terwijl de informatievoorziening en het bedrijfsgebeuren die daarmee worden ondersteund in feite organisch van aard zijn [50] . Dit impliceert tevens dat de digitale architectuur nooit geheel klaar is, dus de digitale architectuur is een groeimodel.

In de fysieke wereld van de gebouwen lijkt architectuur vaak hoofdzakelijk bedoeld voor het uiteindelijke resultaat: het gebouw, de wijk of de stad. Digitale a rchitectuur is echter geen einddoel, maar een ondersteunend hulpmiddel bij (strategische) besluitvorming en transformatie van de onderneming. Het schrijft voor aan welke eisen de onderneming, de informatievoorziening, applicaties en de technologische infrastructuur moeten voldoen. In de IT-wereld is architectuur dus bedoeld om richting te geven aan het transformatieproces op alle niveaus van de onderneming. Architectuur in IT is dus een raamwerk om een organisch evolutieproces te ondersteunen. Dat vraagt om een architectuur die niet al te gedetailleerd is uitgewerkt als het gaat om zaken die in de toekomst moeten worden geregeld. Dus voor een bruikbare architectuurbeschrijving moet gelden: ‘just-enough' en ‘just-in-time'.

Architectuur is een hulpmiddel om te borgen dat de onderhavige onderneming aangesloten blijft in ‘the connected economy'. De karakteristieken van die ‘connected economy' bepalen mede de eigenschappen welke aan de eigen architectuur dienen te worden gesteld.

Computers, en IT in het algemeen, beginnen een meer en meer dominante rol te vervullen in de menselijke samenleving. Dit heeft grote gevolgen, zowel voor het functioneren van die samenleving als voor het handelen van de individuele mens. Wij stevenen af op een mens-computer samenleving waarin wij terdege rekening moeten gaan houden met de capaciteiten van hoogst interactieve, altijd aanwezige, pseudo autonome artefacten waarvan wij de werking niet geheel meer zullen kunnen doorgronden. Gezien het grote aantal ethische problemen dat daardoor op ons afkomt, rijst de vraag of de mens wel moreel verantwoordelijk gesteld kan worden voor de gevolgen die een artefact veroorzaakt waaraan hij een opdracht heeft gegeven. Het is de taak van de architect om bij het ontwerp van een artefact de werking zodanig te expliciteren dat een gebruiker te allen tijden voldoende kan weten wat hij aanricht.

Fysieke architectuur wordt waargenomen via de zintuigen en heeft daardoor een sterk lichamelijke beleving. Digitale architectuur komt in feite binnen via het denken, het lagere deel van het denken om precies te zijn. Daarom is het ook een extra moeilijke opgave om digitale architectuur te visualiseren, op een zodanige wijze dat zij kan worden begrepen door niet-IT-ingewijden.

In de digitale wereld zijn meer mogelijkheden en ook meer vrijheidsgraden. De veranderbaarheid in de digitale wereld is vele malen groter dan in de fysieke wereld. In de digitale wereld hebben we te maken met actieve artefacten zodat er naast ruimtelijke beschouwingen ook beschouwingen nodig zijn met een tijdsdimensie.

En uiteindelijk kan de digitale architectuur volledig worden maatgesneden op elk individu.

Toch kunnen digitale architecten veel, heel veel leren van architecten uit de fysieke wereld. Architectuur in de fysieke wereld wordt uiteindelijk zichtbaar in het bouwwerk. De architectuur in de digitale wereld blijft een mentale aangelegenheid. Om te leren denken in architecturen zou het daarom zinvol zijn als digitale architecten zich eerst eens bezig houden met het leren genieten en doorgronden van architectuurprincipes in de fysieke wereld.

In de fysieke wereld, bijvoorbeeld in het geval van een bungalow, zien wij architectuur tegenwoordig slechts als een schets van het eindplaatje. In zo'n schets komen de volgende zaken tot uitdrukking: de behoefte van de bewoner, de eisen van de regelgeving, de uitstraling van de omgeving, de aanwezige infrastructuur en de creativiteit van de architect. Desalniettemin blijft een dergelijk object redelijk statisch. Vroeger was dat wel anders. In de Middeleeuwen had de architect een duidelijke visie van wat hij wilde en een nog weinig gedetailleerd plan hoe hij dat dacht te realiseren. Hij zette de plattegrond uit en bouwde van daaruit verder. Dit deed hij op basis van bepaalde principes, regels en richtlijnen die hij in zijn hoofd had en die in zijn tijd in zwang waren. Bij elke bouwbeslissing werd de architect gebruikt om, gebruikmakend van diens vindingrijkheid en creativiteit tot een keuze te komen. Deze middeleeuwse benadering komt dicht bij de wijze waarop architectuur in ons vakgebied wordt gebruikt.

1.8 Slotopmerking

Het is dus overduidelijk, de behoefte aan architectuur begint ook in de digitale wereld op te doemen. Achter deze hype naar architectuur zit een fundamentele behoefte aan orde, maat, discipline en schoonheid in de informatievoorziening, in softwareproducten, in IT-diensten en zelfs in het ontwikkelproces zelf. Bepaalde oplossingspatronen bij bepaalde problemen, bepaalde stijl in bepaalde omgevingen, bepaalde constructies onder bepaalde omstandigheden ofwel architectuur.

Gebruikers zijn niet meer tevreden met ingewikkelde informatiesystemen gemaakt door techneuten die alleen begrepen kunnen worden door andere techneuten. De technology push van allerlei wilde technologieën begint af te nemen. Ondernemingen zijn slechts geïnteresseerd in de daadwerkelijk toegevoegde waarde van de inzet van IT. Gebruikers willen informatiesystemen die natuurlijk aanvoelen, informatiesystemen die je verleiden je te ontplooien in je professionele werk.

Ondernemingen willen een informatievoorziening die ruimte biedt aan groei en ruimte tot aanpassing.

De mogelijkheden die IT ons biedt zijn groter dan ooit. Het belang van een kwalitatief hoogwaardige informatievoorziening is voor het merendeel van de ondernemingen van levensbelang. Juist daarom is het belangrijk dat het management van een onderneming het overzicht niet verliest. Kortom, er is behoefte aan digitale architectuur.

1.9 Literatuur

[1] Nicholas Negroponte (1996), Being Digital , Vintage Books, ISBN: 0 679 76837 8.

[2] 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.

[3] Don Tapscott (1998), De digitale economie: beloftes en gevaren in het tijdperk van de netwerkintelligentie , Scriptum Management, ISBN: 90 5594 100 X.

[4] Pieter van der Ree (2000), Organische architectuur: Mens en natuur als inspiratiebron voor het bouwen , Uitgeverij Vrij Geestesleven, Zeist, ISBN: 90 6038 484 9.

[5] Carel Weeber (2003), Delta Darlings, ‘geen architectuur zonder landschap, het einde van de stedenbouw' ; Uittreeredes van Reh, Frieling, Weeber met bijdragen van Barbieri, Coenen, Schrijnen' Zandbelt & van den Berg, Rotterdam.

[6] Luigi Prestinenza Puglisi (1999), HyperArchitecture, Spaces in the Electronic Age , Birkhäuser, ISBN: 3 7643 6093 3.

[7] Jan Brouwer (2000), De architectuur van het maken , The Making of Architectuur, afscheid van prof. ir. Jan Brouwer, pp 99 – 145, Stichting Nederlandse Architectuur Manifestatie, ISBN: 90 9014391 2.

[8] Monier Monier-Williams (1899), A Sanskrit-English Dictionary , Motilal Banarsidass Publishers, ISBN: 81 208 0069 9.

[9] Manfred Broy and Ernst Denert, editors (2001), Software pioneers: contributions to software engineering , Springer, ISBN: 3 540 43081 4

[10] Andrew S. Tanenbaum (1990), Gestructureerde computerarchitectuur, Academic Service, ISBN: 90 6233 576 4 .

[11] J.A.M.Theeuwes (1987), Informatieplanning , Kluwer, Deventer, ISBN: 90 267 1119 0.

[12] J. Truijens, A. Oosterhaven, R. Maes, H. Jäger, F. Van Iersel (1990), Informatie-infrastuctuur: een instrument voor het management , Kluwer Bedrijfswetenschappen, ISBN: 90 267 1492 0.

[13] James Martin (1995), The great transition: using the seven disciplines of enterprise engineering to align people, technology, and strategy , Amacom, New York, ISBN: 0 8144 0315 8.

[14] James Martin (1996), Cybercorp: the new business revolution , Amacom , New York , ISBN: 0 08144 0351 4.

[15] Jaap van Rees en Pieter Wisse (1995), De informatie-architect , Kluwer Bedrijfswetenschappen, ISBN: 90 267 2155 2.

[16] Daan Rijsenbrij (2001), Het ware gezicht van architectuur , Informatie, November 2001.

[17] Paul Shepheard (1999), What is Architecture: an essay on Landscapes, Buildings and Machines , The MIT Press, ISBN: 0 262 19341 8.

[18] Louis H. Sullivan (1956, origineel gepubliceerd in 1924), The Autobiography of an Idea , Dover Publications, ISBN: 0 486 20281 X.

[19] Christopher Alexander (1979), The Timeless Way of Building , Oxford University Press, ISBN: 0 19 502402 8.

[20] D.B.B. Rijsenbrij (1993), Automatisering: vloek of zegen? ; Inaugurale rede uitgesproken bij de aanvaarding van het bijzonder hoogleraarschap (1993 – 2002) in de bedrijfsinformatica aan de Vrije Universiteit, Lansa Publishing, Leidschedam, ISBN: 90 71996 83 2.

[21] The Institute of Electrical and Electronics Engineers (2000), IEEE Standard 1471-2000: IEEE recommended practice for architecture description of software-intensive systems , ISBN: 0 7381 2518 0.

[22] Alexander Tzonis, Liane Lefaivre, Denis Bilodeau (1989), Klassieke architectuur; de poëtica van de orde , SUN, Nijmegen, ISBN: 90 6168 319 X.

[23] Guus Delen and Daan Rijsenbrij (1992), The Specification, Engineering and Measurement of Information Systems Quality , The Journal of Systems and Software, volume 17, pp 205-217.

[24] Vitruvius, vertaald door Ton Peters (1999), Handboek bouwkunde , Athenaeum – Polak & Van Gennep, Amsterdam, ISBN: 90 253 5870 5.

[25] Carel Weeber (1998), Het Wilde Wonen , Uitgeverij o1o, Rotterdam, ISBN: 90 6450 341 9.

[26] Christopher Alexander (1979), The Timeless Way of Building , Oxford University Press, ISBN: 0 19 502402 8.

[27] Christopher Alexander et al (1977), Steden, gebouwen , constructie: een patroontaal , Educare, Drachten, ISBN: 90 70102 269.

[28] Francis J. Gouillart and James N. Kelly (1995), Transforming the Organization , McGraw-Hill, ISBN: 0 07 - 034067 6.

1.10 Vragen

1. Hoe ondersteunt de digitale wereld het meer geordend functioneren van de fysieke wereld? Wees zo concreet mogelijk.

2. Noem een nieuwe economische vanzelfsprekendheid in de digitale wereld die in de fysieke wereld geen usance was.

3. Hoe zou jouw levensstijl adaptiever kunnen worden?

4. Hoe word jij persoonlijk meer ‘digitaal'?

5. Noem een zekerheid die volgens jou binnen tien jaar gaat verdwijnen door verdergaande informatisering.

6. Geef een definitie van digitale architectuur die je tijdens een receptieborrel aan een niet-IT'er zou vertellen.
Kijk ter inspiratie op de website van het SEI: http://www.sei.cmu.edu/architecture/definitions.html . Hoewel dit software-architectuur betreft kunnen veel definities worden gegeneraliseerd tot digitale architectuur.

7. Welke principes zou je voor jezelf willen formuleren betreffende het studeren aan de universiteit? Welke daarvan zijn architectuurprincipes? En wat zijn de concerns achter die principes?

8. Welke principes zou je voor je zelf willen formuleren betreffende de informatievoorziening en het kennismanagement aan de universiteit? En wat zijn de concerns achter die principes?

9. Noem een paar conflicterende architectuurprincipes (dus een niet-consistente verzameling).

10. Noem een paar architectuurprincipes die weliswaar niet conflicteren, maar die ook geen coherentie vertonen (dus een niet-coherente verzameling).

11. Beschrijf een bestaand architectuurprincipe voor de universiteit compleet, dus inclusief concern, regels, richtlijnen en standaarden.

12. Noem een nieuw architectuurprincipe voor de universiteit. Geef daarbij het concern aan en de mogelijke impact op de bestaande situatie.

13. Waarom heeft een architect een ß-denkraam nodig?

14. Noem enkele symptomen waaruit blijkt dat de wereld steeds mechanischer wordt.

15. Geef een indeling van de universiteit in domeinen.

16. Welke services levert het onderwijsdomein?

17. Wat zit er in het ecosysteem van de universiteit?

18. Wat zou er kunnen worden ‘verhandeld' in een collaborative market voor kennisinstituten?

1.11 Oefeningen

1. Bestudeer een beroemde architect uit de fysieke wereld: wat was zijn werkelijke bedoeling, waar streefde hij naar, wat was zijn leitmotiv. Kortom welke principes hanteerde hij en welke regels en richtlijnen gebruikte hij bij de vormgeving van het artefact waarvoor de architectuur bedoeld was.
Vertaal deze principes, regels en richtlijnen naar de digitale wereld.

2. De zwaartekracht is de dominante kracht [51] waartegen een fysieke architect vecht. Waartegen vecht een digitale architect?"

3. Stel een ER-diagram op van de entiteiten ‘onderneming', ‘domein', ‘architectuur', ‘concern', ‘architectuurprincipe', ‘architectuurregel', ‘architectuurrichtlijn', ‘architectuurstandaard', ‘architectuur-pattern', ‘metamodel'.

2. Architectuur in de digitale wereld

trefwoorden: bedrijfsgebeuren, informatieverkeer, applicatielandschap, technische infrastructuur, beveiligingsarchitectuur, stakeholder, viewpoint, view, abstractieniveaus, framework, noodzaak van architectuur.

2.1 Inleiding

Architectuur wordt een belangrijker onderwerp in de wereld van de informatietechnologie. Immers, het bedrijfsleven, de overheid en eigenlijk onze hele samenleving wordt in snel tempo gedigitaliseerd. Op allerlei gebieden worden handmatige werkzaamheden ondersteund of zelfs vervangen door geautomatiseerde informatiesystemen. De informatietechnologie dringt steeds verder op in producten en diensten. 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.

Tegelijkertijd zien we ook dat de markt continu in beweging is; klanten worden veeleisender en het aantal nieuwe bedrijfskansen lijkt met de dag te groeien.

De wereld om ons heen verandert meer en meer. Maatschappelijke ontwikkelingen zoals de 24-uurs-economie en een ‘web-lifestyle' hebben tot gevolg dat ondernemingen moeten veranderen en als gevolg daarvan de informatievoorziening. Er is een proces van continue verandering in gang gezet, dat veel van ondernemingen vraagt en ook van de IT dienstverlening binnen die ondernemingen. Deze veranderingen voltrekken zich ook steeds sneller. Dit heeft de volgende gevolgen:

· Het ontwikkelen van applicaties moet steeds sneller want kansen dienen direct te worden benut en eisen die de wetgever stelt moeten zeer snel vertaald worden in IT-systemen. Volstond het in het verleden om 9 maanden over het ontwerpen en ontwikkelen van een nieuwe applicatie te doen, tegenwoordig moet dat in 9 weken kunnen of misschien zelfs wel in 9 dagen.
Dit geldt ook voor architectuur. Grote langlopende architectuurtrajecten die nauwelijks wat opleveren tot ze klaar zijn, vertragen de applicatieontwikkeling dusdanig dat ze niet acceptabel zijn. Het gebruik van hulpmiddelen die de verzamelde kennis vasthouden, toegankelijk en bruikbaar maken vanaf het eerste begin zijn een must. Ook is de toepassing van architecturale patronen of referentiearchitecturen noodzakelijk teneinde een verdere versnelling te bereiken.

· De levensduur van applicaties wordt steeds korter. De applicaties van vandaag zijn de legacy systemen van morgen. De integratie van deze legacy systemen is een belangrijk architectuur-issue.

· De afhankelijkheid van IT wordt steeds groter. Hoe meer bedrijfsprocessen door applicaties worden overgenomen, hoe afhankelijker een onderneming ervan wordt.
Applicaties maken echter steeds vaker deel uit van grotere netwerken, hetgeen ons met nieuwe uitdagingen confronteert. De elektronische dienstverlening, bijvoorbeeld via Internet, vereist een voldoende en afdoende beveiliging van gegevens. In het ergste geval kunnen storingen zelfs leiden tot het stilvallen van bedrijfsprocessen dan wel tot het openbaar maken van vertrouwelijke gegevens, met alle relationele en financiële gevolgen van dien. Er worden steeds hogere eisen gesteld aan de betrouwbaarheid van systemen en aan het onderhoud en beheer ervan.

Om te bewerkstelligen dat het geheel van geautomatiseerde ondersteuning blijft functioneren, moet er structuur worden aangebracht. 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'. Het schrijft de manier van ontwerpen en de bouw van een artefact voor. Dat biedt garanties voor de uniformiteit en de algemene kwaliteit van specifieke aspecten van het te bouwen artefact.

Door de (web)mogelijkheden van het Internet verwachten we in de nabije toekomst ondernemingen die onderling vervlochten lijken te zijn met andere ondernemingen als tijdelijke partners met geheel nieuwe economische wetmatigheden. ‘Wereldwijd', ‘transparant' en ‘virtueel' zijn daarbij de sleutelwoorden. Door de snelle opmars en adoptie van het Internet wordt de gehele wereld het strijdtoneel voor de concurrentie, een wereldwijde aaneengesloten marktplaats.

Als gevolg van ‘transparantie' zal de buitenwereld steeds dieper naar binnen kunnen kijken. Klanten willen online de voorraden bekijken, online de productieprocessen kunnen volgen en mogelijkerwijs online een gedeelte van de diensten en knowhow gebruiken. Onder ‘virtueel' in een ondernemingscontext wordt verstaan dat de onderneming mogelijkheden lijkt te hebben die er in werkelijkheid niet zijn. Dat wordt bewerkstelligd door die gedeeltes van het bedrijfsgebeuren, die niet tot de core-competence behoren, te outsourcen. We zullen zien dat in de waardeketen (value chain), die zich vroeger binnen de eigen muren voltrok, steeds meer services van externe providers worden opgenomen.

In dit verband wordt vaak ten onrechte de volgende hype opmerking gemaakt: ‘de onderneming moet kantelen van backoffice centric naar customer centric'. Het is echter niet een kwestie van òf òf, maar van èn èn. De backoffice, gemeten op ‘operational exellence' moet namelijk toegankelijker worden en in de frontoffice hoort ‘client intimacy' centraal te staan.

2.2 Vier werelden

Het terrein van de digitale architectuur omvat vier werelden:

1. het bedrijfsgebeuren, afgekort tot de B-wereld,

2. het informatieverkeer, afgekort tot de I-wereld,

3. de applicaties, afgekort tot de A-wereld en

4. de technische infrastructuur, afgekort tot de T-wereld.

Dit kan ook gezien worden als vier achtereenvolgende lagen. Het startpunt voor architectuurbeschouwingen ligt in het bedrijfsgebeuren, vervolgens worden daarop doorbordurend de architectuurbeschouwingen in de volgende lagen opgesteld. Tegelijkertijd zullen de faciliteiten uit de lagere lagen mogelijkheden kunnen bieden voor de daarop functionerende lagen.

2.2.1. Bedrijfsgebeuren / de B-wereld

In de bovenste laag, getiteld ‘bedrijfsgebeuren', speelt zich de ‘echte' wereld af. Dat is de wereld van het zakendoen, regelen, college geven, onderzoek verrichten etc. etc. Er wordt gesproken over de producten en diensten die de onderneming levert, de bedrijfsprocessen die nodig zijn om die producten en diensten te produceren en de organisatie [52] en besturing van mensen en bedrijfsmiddelen die daarbij nodig zijn. Een bruikbare eerste benadering voor een beschrijving kan worden gevonden in de poging van Douglas McDavid [1] en enkele gedachten van Robert Prins [2] . Voor een architectuurbeschouwing in dit gebied zij verwezen naar Han van der Zee, Paul Laagland en Bas Hafkenscheid [3] en Daan Rijsenbrij, Jaap Schekkerman, Harry Hendrickx [4].

In deze laag wordt ook gesproken over procesarchitectuur [53] . Het ontwerpen van een goed proces is een hele kunst, toch hoort dit eigenlijk tot de ontwerpdiscipline en alleen dat gedeelte dat betreft de principes, regels, richtlijnen en standaarden waarbinnen dat ontwerp dient te blijven hoort tot de business architectuur.

Sommige stellen de vraag “waarom een digitale architect zich met deze wereld zou moeten bezig houden, dit is toch het terrein van de business mensen?”. In de begintijd van SDM [54] werd gesteld dat je eerst moest reorganiseren alvorens je kon gaan automatiseren. Anders ben je immers bezig de wanorde te automatiseren, hetgeen resulteert in een applicatie dat nog sneller een chaos kan creëren. Dat motto wordt nu overgezet naar architectuur: maak eerst een architectuurbeschouwing van de business alvorens je daar lagere architectuurbeschouwing op voort bouwt.

De business heeft vele aspecten, waarbij de meest bekende zijn het financiële aspect, het personeelsaspect, het logistieke aspect en het informatieaspect. In de lagen hieronder gaan we in feit door op dat informatie aspect. Dus we schetsen een business architectuur die dient als uitgangspunt voor de verdere informatisering van de onderneming.

2.2.2. Informatieverkeer / I-wereld

Het soepel en tijdig informeren is wezenlijk voor het functioneren van een onderneming. Juiste informatiestromen zorgen dat de onderneming vitaal en slagvaardig is. In de ‘connected' economie is de vraag bovendien “hoe zorg ik dat mijn relaties zodanig mee ontwikkelen dat een win-win situatie valt te exploiteren?”. Hoe krijgen we de juiste informatie, zowel financieel als niet-financieel, om beslissingen te nemen? Hoe regelen we een informatie-aggregatiemechanisme met dashboards en kpi's [55] om ons te voorzien van de informatie waar we behoefte aan hebben, niet minder doch beslist ook niet meer. Hoe informeren we de medewerker opdat hij zijn werk op adequate wijze kan uitvoeren. Gewenst gedrag wordt voor een groot gedeelte beïnvloed door juiste informatie.

In de I-wereld bevinden zich de informatiestromen, de documentstromen, de informatiebehoeftes, de informatiebronnen en de informatie-uitwisseling met de buitenwereld. Ook het hele terrein van kennismanagement [56] en content-management behoort tot deze architectuurlaag. De informatiearchitectuur [57] , de architectuur van het informatieverkeer, geeft dus inzicht in de structuur en relaties van de informatie- en communicatiehuishouding [58] , onafhankelijk van de automatiseringsgraad.

Het ontwerp van de I-wereld biedt een systematische weerslag van de zaken waarover de business communiceert. Dit betekent dat de informatiearchitectuur nauw verweven is met de businessarchitectuur, aan de ander kant dient voldoende ruimte te zijn voor de organisatorische verbijzondering.

Het implementeren van concepten als informatiemanagement, datawarehousing en kennismanagement heeft alleen zin als bekend is hoe de onderneming waarde produceert. Business intelligence toepassingen, zoals onder andere datamining, leveren alleen zinvolle informatie op bij een goede informatiearchitectuur, waarin ook de context van de informatie is meegenomen. Dit geldt in het bijzonder voor kennismanagement. Bij het bepalen van de informatiestromen speelt waardemanagement dus een belangrijke rol.

Bestuurders moeten zorgen dat beslissingen daar worden genomen, waar ze het beste genomen kunnen worden [59] . Naast de juiste bevoegdhedentoewijzing speelt de informatievoorziening daarbij een belangrijke rol. De architect dient vanuit het begrip van de business te ontdekken waar besturing relevant is, en hoe dat het beste georganiseerd kan worden. Het resultaat is een gezonde onderneming met continuïteit.

De architectuur van de informatie en communicatie vormt het hart van de oplossing van alignmentproblemen. Met een goede architectuur van de informatieverkeer is het immers gemakkelijker andere applicatiecomponenten te introduceren of de infrastructuur te veranderen zonder dat de hele organisatie ‘op de schop' moet. Anderzijds kan er vaak extra bedrijvigheid worden gestart zonder direct de applicaties en de infrastructuur radicaal aan te passen. De architectuur van de I-wereld is de spil als het erom gaat business en technologie op elkaar af te stemmen.

Het is belangrijk te realiseren dat dit het gedeelte van de digitale wereld is waardoor mensen worden verbonden. Een onderneming kan in essentie worden gezien als een verzameling van communities. De architectuur in deze laag zorgt dat die communities worden gefaciliteerd zich optimaal te ontplooien.

Tot de informatiearchitectuur behoort ook de architectuur van de artefacten die op het world wide web zijn gebouwd (zie Louis Rosenfeld & Peter Morville [7]). Zeer interessant hierbij zijn de architectuuroverwegingen over de navigatiepaden en de belevingsaspecten die daarbij een rol spelen.

2.2.3. Applicatielandschap / A-wereld

De architectuur van de applicaties en hun onderlinge verband, het applicatielandschap, is het onderwerp van de A-wereld. In deze laag houdt de architect zich bezig met de applicatie portfolio, integratiemechanismen [60] , de architectuurkarakteristieken in de applicatietypologie en wat men doorgaans noemt de software architectuur [61] .

Naast de applicaties horen in deze laag ook de geautomatiseerde gegevensverzamelingen.

Om redenen van efficiëntie staan applicaties veelal niet los van elkaar. Gemeenschappelijke zaken worden ondergebracht in een technische infrastructuur die door alle applicaties kan worden gebruikt. Een onderdeel van die infrastructuur de middleware geheten vormt als het ware het bindende element tussen alle applicaties.

Voor een bloemlezing betreffende software architectuur wordt verwezen naar: Mary Shaw en David Garlan [10], Lenn Bass, Paul Clements en Rick Kazman [11], Peter Bernus, Kai Mertins en Günter Schmidt [12], The First Working IFIP Conference on software architecture [13], Raphael Malveau en Thomas Mowbray [14], David M. Dikel, David Kane en James R. Wilson [15]. Interessant is een richting in de software architectuur die zich bezig houdt met de architectuur van productenfamilies, waarbij de toekomstvastheid op de voorgrond komt te staan. Voor nadere details zij verwezen naar Jan Bosch [16] en Mehdi Jazayeri, Alexander Ran en Frank van der Linden [17].

De applicatie-architectuur vormt als het ware de ‘brug' tussen het bedrijfsgebeuren (de bedrijfsobjecten, bedrijfsprocessen en bedrijfsorganisatie) en de technische infrastructuur (connectivity, storage en servers).

2.2.4. Technische Infrastructuur / T-wereld

De technische infrastructuur vormt de ‘fundering' waarop de applicaties draaien. Deze fundering bestaat uit netwerken, communicatieverbindingen, hardware, systeemsoftware en gemeenschappelijke software basisvoorzieningen zoals tekstverwerking en e-mail & messaging.

Het kost meestal vrij veel inspanning om de technische infrastructuur grootscheeps te veranderen. Het is daarom erg belangrijk te letten op de toekomstvastheid van de infrastructuur en daar waar mogelijk adaptiviteit in te bouwen.

De moeilijkheid van het veranderen van de infrastructuur is gelegen in het feit dat alle zaken op die infrastructuur zijn voortgebouwd. Dat probleem zien we in de fysieke wereld ook. In een stad als New York is het eenvoudiger om een wolkenkrabber te vervangen dan om het stratenplan (dus de infrastructuur) aan te pakken.

De infrastructuur is meestal voor de gehele onderneming hetzelfde. Het kan voorkomen dat bij bepaalde domeinen enkele extra's worden toegevoegd aan de infrastructuur.

In ieder geval dient de infrastructuur van de onderneming aan te sluiten op de infrastructuur van het ecosysteem waarin de onderneming opereert. Gebruik daarom voor de infrastructuur alleen algemeen erkende standaarden en erkende standaardcomponenten.

Chris Bariton [18] geeft een uitgebalanceerde architectuurbeschouwing over infrastructuur en bijbehorende middleware.

2.2.5 extra aandachtspunten

Voor een gezonde onderneming verdienen alle vier bovenstaande architectuurwerelden de volle aandacht, een goed ontwerp van hun onderlinge relaties is uitermate belangrijk. Belangrijke uitdaging van de architect is te zorgen dat de business maximaal gebruik maakt van de ‘enabling' mogelijkheden van informatie, kennis en de IT (applicaties en infrastructuur).

In het ondernemingsgebeuren en de informatievoorziening zijn mensen betrokken en daarmee sociale organisaties, zij hebben daardoor een dynamisch en adaptief karakter. De applicaties en de infrastructuren die deze sociale organisaties ondersteunen zullen in hoge mate dit zelfde dynamische en adaptieve karakter dienen te vertonen.

Er zijn echter nog twee belangrijke gezichtspunten van waaruit het totaal van die vier werelden wordt beschouwd, namelijk vanuit de beveiliging en vanuit de governance. Beiden vormen een vast onderdeel van een geïntegreerde architectuurbenadering en beslaan alle vier werelden in samenhang.

De beveiligingsarchitectuur [62] beschrijft de manier waarop beveiliging wordt vormgegeven en beschouwt de beveiligingsmaatregelen van gebruiker tot dienst, een end-to-end beschouwing. Elke wereld heeft zijn eigen beveiligingsprincipes, die soms ook nog op gespannen voet staan met de principes uit die wereld zelf. Tussen de toegankelijkheid van een applicatie en de gegevensbeveiliging dient een balans te worden gevonden die past bij de onderhavige applicatie. E-business applicaties brengen bepaalde beveiligingsproblemen mee, maar het volledig ‘dichttimmeren' impliceert tevens dat er ook geen klanten bij kunnen en dat was niet bedoeling van e-business. De beveiligingsprincipes in de verschillende lagen dienen ook op elkaar te zijn afgestemd. Kortom beveiliging [63] vereist een holistische benadering die het hele gebied van business, informatieverkeer, applicaties en infrastructuur consistent en coherent omvat.

De instandhouding van een geïntegreerde architectuur vereist een geïntegreerde governance [64] . Een architectuur is vaak uitermate complex, een complexiteit die wordt opgelost door het geheel in kleinere meer-overzichtelijke stukjes te ontleden. Voor architectuur komt daar als extra conditie bij dat tijdens het ontrafelen in delen de samenhang niet uit het oog mag worden verloren. Dit wordt ook wel aangeduid met de term ‘holistisch'. De governance van de architectuur definieert de organisatie [65] , die nodig is om de architectuur van de vier werelden (te weten bedrijfsgebeuren, informatieverkeer, applicaties en infrastructuur) in onderlinge afstemming te beheren.

Eigenlijk begon in de business community de interesse naar architectuur al toen John Henderson en N. Venkatraman [19] in 1993 over business IT alignment schreven. Architectuur wordt immers ook gebruikt om discrepanties tussen de vier lagen te voorkomen en toekomstvastheid te waarborgen. Toekomstvastheid onder het geweld van steeds nieuwe technologieën. Een jaar later werd voor het oplossen van de alignment-uitdaging enkele praktische handvaten geboden door Bernard H. Boar [20]. Daan Rijsenbrij, Hans Goedvolk, Rik Maes, Jan Dietz cs hebben in 2000 getracht wat meer duidelijkheid te scheppen in deze belangwekkende materie [21, 22].

Er kan dus worden gesteld dat de enterprise architectuur alle vier de architectuurwerelden (business, informatie, applicaties en infrastructuur) op een holistische manier omsluit en adresseert voor de gehele onderneming inclusief de relaties naar de buitenwereld. De diepgang beperkt zich tot het niveau op basis waarvan besluitvorming kan worden ondersteund. M.m. geldt hetzelfde voor domein-architectuur maar dan op een gedetailleerdere, meer specialistischer schaal.

2.3 Stakeholders en Viewpoints

2.3.1 Stakeholders

Er zijn tegenwoordig heel veel stakeholders [66] betrokken bij zaken in de digitale wereld met de meest tegenstrijdige eisen en wensen. Het is aan de architect om een architectuur op te stellen waar de belangrijkste stakeholders zich in voldoende mate in kunnen vinden. Enkele groepen stakeholders zijn de eigenaar en het management, de verschillende soorten (eind)gebruikers, de toekomstige onderhoudsploeg, het toekomstige exploitatiecentrum, de accountant, de bedrijfskundigen. Maar ook buiten de onderneming zijn er belangrijke stakeholders als de verschillende soorten klanten, de leveranciers, de partners en ten slotte ook de aandeelhouders.

Niet elke betrokkene is ook stakeholder. De ontwerper, in het bijzonder de engineer, en de bouwer, zijn wel betrokken bij het realiseren van het artefact, maar zijn geen stakeholder!

Voor het besluitvormingsproces over de architectuur is het vaak praktisch om te constateren dat er in feite drie categorieën van stakeholders zijn: beslissende stakeholders, beïnvloedende stakeholders en overige stakeholders.

De stakeholders van buiten kunnen heel belangrijk zijn, het draait tegenwoordig immers allemaal om samenwerking. Voor de overleving op langere termijn wordt samenwerking zelfs belangrijker dan concurrentie. We zien steeds vaker dat er sprake is van wisselende patronen van partners die nu eens samenwerken en dan weer met elkaar concurreren. Een interessant schaakspel, maar hoogst vermoeiend voor de ouderwetse manager die opgroeide in het industriële tijdperk, waar hiërarchie nog gewoon was.

De werkelijke waarde van een onderneming ligt in de mogelijkheden die ze heeft om met partners, klanten en leveranciers samen te werken; kortom in haar positie in een ‘connected world'. Vaak is de klant de meest belangrijke partner. Om te beoordelen of samenwerking echt mogelijk en haalbaar is, zullen ondernemingen steeds meer gebruikmaken van architectuur, een architectuurbeschouwing die zich voortzet tot ver buiten de muren van de traditionele onderneming.

2.3.2 Viewpoints

Simpelweg gezegd is een viewpoint een (gezichts-)punt van waaruit een ‘systeem' beschouwd wordt. Dus ook bij een architectuurbeschouwing kan gesproken worden over viewpoints. Het resultaat van de beschouwing is een view. Viewpoints zijn dus verschillende gezichtspunten binnen een architectuur ten behoeve van een bepaalde doelgroep of ten behoeve van een bepaald doel.

Voorbeeld uit de fysieke wereld van een viewpoint is de blik op één meter hoogte van een stadswijk, bijvoorbeeld de Bijlmermeer. De stakeholder is de kleuter en de view is de verkeerssituatie. Het principe dat bij deze view hoort voor deze stakeholder is dat een kleuter de hele Bijlmermeer kon doorwandelen zonder met verkeer te worden geconfronteerd.

Bij een viewpoint hoort vaak ook een eigen visualisatievorm die toegesneden is op de betreffende stakeholder. Voor de viewpoint van de financial controller worden vaak spreadsheets gebruikt.

Enkele veelvoorkomende viewpoints in de digitale wereld:

· een ‘management' viewpoint, waarbij aangegeven wordt wie wat bestuurt en controleert;

· een ‘change' viewpoint, waarbij de belangrijkste veranderingen uitgelicht worden;

· een ‘volgorde' viewpoint, waarbij aangegeven wordt in welke volgorde zaken gaan veranderen;

· een ‘interface' viewpoint, waarbij helder uitgelicht wordt hoe de systemen met elkaar gaan communiceren;

· een ‘distributie' viewpoint, waarbij aangegeven wordt hoe (de)centralisatie van mensen en systemen de bedrijfsbehoeften zullen ondersteunen;

· een ‘exploitatie' viewpoint, waarbij specifiek aandacht besteed wordt aan de noodzakelijke service niveaus voor de verschillende organisatieonderdelen en hun ondersteunende systemen.

Het architectuurtraject resulteert uiteindelijk in een architectuurbeschrijving van het artefact dat vervolgens door alle stakeholders aan een evaluatie wordt onderworpen.

De architectuurbeschrijving bestaat uit een groot aantal architectuurmodellen waarmee de architectuur van het toekomstige systeem wordt gevisualiseerd en beschreven. Dit gebeurt op een groot aantal aspecten of views:

· De externe verschijning en het gedrag van het onderhavige systeem.
De klant en de gebruikers evalueren of het ontwerp in voldoende mate voldoet aan hun eisen en verwachtingen.

· De structuur van het systeem en de samenwerking tussen de componenten in het systeem.

· De ontwikkeling, de implementatie en de werking van het systeem.

De ontwikkelaar evalueert dit deel van het ontwerp op beschikbaarheid van de vereiste componenten, de haalbaarheid van de constructie, de kosten en eventuele andere kwaliteitsattributen. De klant en de gebruikers evalueren alleen dat deel van de constructie dat zichtbaar is of met hen interactie heeft;

· Eventueel andere kwaliteiten van het systeem als beveiliging, performance, kosten en business benefits.

Zoals vele goede fysieke architecten, kon Gerrit Rietveld reeds bij het begin van het ontwerpproces zich het geheel (binnen en buiten) voor zichzelf visualiseren. Om het voorstellingsvermogen van zijn toekomstige gebruikers echter niet al te veel op de proef te stellen presenteerde hij in het begin slechts een aantal views. De uiteindelijke plattegrond voor de totale architectuur werd vaak pas in een volgend stadium besproken.

2.4 Systeemtheoretische beschouwing

In sommige architectuurbenaderingen in de digitale wereld is een eerste begin van een meer systeemtheoretische onderbouwing te vinden. Wij verwijzen hierbij naar Eberhardt Rechtin and Mark W. Maier [23, 24]. Dit is ingegeven doordat hun architectuurenken was ontstaan vanuit een engineerings body-of-knowldege. Hetzelfde zie je overigens bij John Zachman ( www.zifa.com ). Hij past als het ware een black box – white box benadering toe en komt daarbij tot de abstractieniveaus: ‘contextual', ‘conceptual', ‘logical', ‘physical'. Deze wijze van redenering is overgenomen door de META Group en Capgemini [25].

Overigens ben ik van mening dat het raamwerk van John Zachman niet zoveel met architectuur heeft te maken, maar meer een raamwerk voor engineers is.

Vanuit de systeemtheorie kunnen er vier abstractieniveaus worden onderkend:

1. het contextuele niveau: de architecturale relatie met de omgeving, hoe dient het artefact te functioneren in zijn omgeving en hoe ziet de omgeving van het artefact eruit?

2. het conceptuele niveau: wat is de functionele inhoud van het artefact en welke eisen en beperkingen horen daarbij?

3. het logische niveau: hoe kan de oplossing worden gerealiseerd?

4. het fysieke niveau: waarmee kan de oplossing worden gerealiseerd?

Soms zien wij nog een aanpalende beschouwing, namelijk die van de transformatie, dus het artefact in de overgang. Maar dit hoort principieel niet bij de eerste vier.

5. transformatieniveau: hoe kan de oplossing worden geïmplementeerd?

In feite wordt op het contextuele en conceptuele niveau een black-box view toegepast, die zich beperkt tot het gedrag en uiterlijk van een artefact in de interactie met externe actoren. Hieraan wordt vaak het begrip ‘stijl' gekoppeld. Zachman geeft aan dat deze twee niveaus bedoeld zijn voor respectievelijk de planner en de ‘gebruiker [67] '.

Op het logische en fysieke niveau wordt de white-box view toegepast waarmee wordt gekeken naar de interne constructie en samenwerking van de componenten van het systeem. Hieraan wordt vaak het begrip pattern [68] gekoppeld. Deze patterns hebben betrekking op de constructie en samenwerking van componenten. Dit is de constructieleer van de engineers.

Bij deze twee niveaus geeft Zachman aan dat ze bedoeld zijn voor respectievelijk de ontwerper en de bouwer.

Vaak loopt het opstellen van de architectuur in de digitale wereld van buiten naar binnen qua niveau's:

In de contextuele fase wordt ook de scope van de architectuur vastgesteld: welk deel van de onderneming en de IT-systemen wordt in beschouwing genomen?

Wat is de omgeving, de invloed van de missie en visie op het beschouwde deel van de onderneming? Wie zijn de stakeholders en wat zijn hun belangen, de context is min of meer gelijk voor alle vier de architectuurgebieden.

De conceptuele fase resulteert in besluitvorming over de producten of diensten die een bepaald architectuurgebied moet leveren. Bij de business zijn dit de producten en diensten die de bedrijfsprocessen moeten leveren. Bij informatie betreft dit de kennis en informatie die door de informatievoorziening moeten worden ondersteund. Bij informatiesystemen is dit de gewenste geautomatiseerde ondersteuning en bij technologische infrastructuur de services die de hardware moet leveren.

De logische fase richt zich op de rollen van mensen, de rollen van soft- en hardwarecomponenten en hun onderlinge samenwerking. Het doel is om op basis van diverse scenario's de organisatieprocessen en IT-mechanismen [69] zo te kiezen dat een werkend geheel mogelijk is.

De fysieke fase is bedoeld om de architectuur – de rollen, processen en mechanismen enerzijds en de soft- en hardwareproducten anderzijds – zodanig in te vullen dat niet alleen een werkend geheel ontstaat, maar ook optimaal aan alle wensen van de stakeholders kan worden voldaan.

De transformatiefase houdt zich bezig met de besluitvorming over de transformatie van de onderneming en de migratie van bestaande systemen die nodig zijn om de business en IT-systemen conform de architectuur te realiseren.

Hierbij dient te worden opgemerkt dat het transformatieniveau buiten de echte architectuur valt en principes bevat die belangrijk zijn voor een verantwoorde transformatie. John Zachman heeft dat goed gezien door te spreken over een ‘out-of-the-context' niveau dat valt onder de verantwoordelijkheid van de ‘subcontractor'.

Deze systeemtheoretische benadering loopt parallel aan het drieluik van Vitruvius, dus de indeling in beleving, structurering en constructie. Laatst genoemde is alleen eenvoudiger uit te leggen voor niet-IT'ers.

2.5 Framework

Als bovenstaande systeemtheoretische verdeling en de vier werelden onderling orthogonaal gezet worden, wordt er een framework (raamwerk) als 4 bij 4 matrix gecreëerd dat als een soort ‘lundia-kast' kan worden gebruikt om allerlei zaken op te bergen.

Dit framework kan we gebruiken om de volgende zaken op te bergen:

· de architectuurprincipes

· de metamodellen

· het ontwerpfragmenten

· de (gerealiseerde) services

Door bovengenoemde zaken op een dergelijke manier systematisch neer te zetten kan de consistentie en coherentie van het geheel worden gerealiseerd en bewaakt.

Dergelijke frameworks zijn bedoeld voor architecten om hun werk te doen. Ze moeten beslist niet worden gebruikt om architectuur te promoten bij niet-IT'ers!

Er bestaat overigens een grote variëteit aan frameworks om de consistentie en coherentie van de verzameling principes te bewerkstelligen en bij verandering te borgen. Een redelijk uitputtend overzicht op het niveau van de enterprise architectuur wordt gegeven door Jaap Schekkerman [26], maar ook het werk van Bernard Boar[27] en Steven Spewak [28] leveren interessante gezichtspunten. Welk framework het meest geschikt is, wordt bepaald door de onderhavige probleemstelling en de persoonlijke voorkeur van de architect.

2.6 Portal

Bij moderne ondernemingen zie je tegenwoordig het begrip ‘portal' opkomen als toegangspoort tot hun digitale aanwezigheid. Een portal is een entree dat toegang geeft tot alle digitale functionaliteiten en informatieverzamelingen die de onderneming ter beschikking stelt. Portals zijn meestal maatgesneden op de desbetreffende gebruikersgroep. U moet zich voorstellen een toegangshal van een financiële instelling die is aangepast aan de mogelijke wensen die past bij de gebruikersgroep waar u toe behoort. Bovendien zijn portals vaak ook nog aan te passen aan de individuele gebruikerswensen, hetgeen de beleving personaliseert. Dit is belangrijk, want het geeft applicaties en websites iets vertrouwelijks, alsof het speciaal voor u is opgezet.

Het niche-bedrijf e-office ( www.e-office.nl ) is bezig vorm te geven aan de digitale werkruimte met behulp van portal technologie. De functionele portal is in feite een website waarmee de functionaliteiten van verschillende web assets zoals applicaties, gegevensverzamelingen, adressen van experts en ander wetenswaardigheden worden ontsloten voor de gebruiker met diens webbrowser. Hiervoor wordt elementaire portaltechnologie gebruikt. Een stap verder is om de portal toe te snijden op de verschillende werkzaamheden die in een onderneming kunnen worden onderkend, dit noemen zij de ‘acitivity portal'. Het grote voordeel van een dergelijke portal is dat het de efficiëntie van de portal gebruiker aanmerkelijk verhoogd doordat hij niet wordt afgeleid door allerlei niet relevante zaken.

De laatste stap is de taakgerichte portal, waarmee een onderneming alles ter beschikking stelt dat nodig is om de onderhavige taak te kunnen uitvoeren. Hierbij worden de taken op de achtergrond verbonden met een workflow-mechanisme. Een taakgerichte portal zal een in-te-zoomen onderdeel worden van de rolgebaseerde portal.

2.7 Noodzaak & doel van digitale architectuur

Nu in het voorliggende anderhalve hoofdstuk is aangegeven wat digitale architectuur omvat, kan de vraag worden beantwoord wat de noodzaak voor digitale architectuur is.

Het IT-landschap van veel ondernemingen, zowel de infrastructuur als de applicatieportfolio, vertoont een chaotisch beeld ondanks de opschonende werking die het Y2K-probleem (de millenniumovergang) en de overgang naar de euro had kunnen hebben.

Systemen worden steeds complexer. Bij veel ondernemingen ontbreekt de echte samenhang tussen de verschillende systemen. Een van de oorzaken hiervan is dat bedrijfsprocessen zijn geïntegreerd door oorspronkelijk losstaande systemen technisch aan elkaar te koppelen. Een tweede oorzaak ligt in het feit dat vaak is gekozen voor de kortste weg tussen vraag en toepassing. Bij een informatiebehoefte is een informatiesysteem gebouwd, waarbij vaak niet in samenhang met andere systemen is ontwikkeld. Zo is door de tijd heen een lappendeken ontstaan van systemen zonder structuur en waarin het overzicht ontbreekt. Het onderhoud en beheer van de systemen is daarom complexer, moeilijker en kostbaarder.

Kortom er ontstaat een noodzaak om fundamenteler te kijken naar ontwerpopdrachten in de digitale wereld, om ontwerpopdrachten te beschouwen in hun context, en oplossing te ontwerpen met de gewenste groeipotentie. Dit is een van de belangrijke redenen voor een architectuurbeschouwing. Doch een bruikbare enterprise architectuur, die kan dienen als stuurinstrument bij cruciale beslissingen over complexe transformaties ontbreekt in veel gevallen.

In het huidige tijdperk van verregaande outsourcing wordt een degelijke architectuurbeschouwing nog crucialer. Populair gesproken staat enterprise architectuur voor ‘breng eens wat ordening aan in het IT gebeuren'. Outsourcing klinkt als ‘doe de was de deur uit'. Het lijkt er dan op dat men zo van de hoofdpijn af komt. Maar de gouden stelregel in Outsourcing luidt: ‘wat men niet kan besturen, kan men ook niet aansturen'. Het is dus absoluut onverantwoord zaken te outsourcen waar men geen overzicht over heeft. Dan wordt de onderneming overgeleverd aan het vrije spel van de service providers, die, onbewust en onbedoeld, de missie, visie en strategie van de onderneming onderuit kunnen halen.

Belangrijke noodzaak tot architectuur is dat er een duidelijke structuur moet worden gedefinieerd in ondernemingen, structuur die leidt tot inzicht en overzicht. Daarmee ondersteunt architectuur de besluitvorming en beperkt risico's.

Tot architectuur horen ook constructieprincipes en richtlijnen voor ontwikkeling [70] . Daardoor ondersteunt architectuur migratieplanning, borgt business IT alignment [71] , ondersteunt businesstransformatie en geeft ruimte aan nieuwe technologieën. Ten slotte is architectuur een referentiekader voor het managen van deelarchitecturen, voor het vereenvoudigen van de integratie met partners, voor systeemintegratie en hergebruik van bewezen oplossingen.

Kortom het gebruiksdoel van een architectuurschets:

· de afhankelijkheid of complementariteit tussen bedrijfsgebieden beter beoordelen;

· beter beslissen over de grens van business modellen;

· uitspraken doen over centralisatie en decentralisatie;

· beter beslissen over óf outsourcing óf partnership;

· de structuur en samenhang van de informatiesystemen vaststellen;

· een toekomstvast en flexibel geheel van informatiesystemen ontwikkelen;

· planningen en kaders voor realisatie opstellen;

· prioriteiten vaststellen;

· koop/maak discussies voeren;

· een stuurmiddel verkrijgen (en hanteren) waardoor toetsing van lopende en geplande ontwikkelingen mogelijk is;

· communiceren over de informatievoorziening;

· een basis voor portfoliomanagement geven.

In meer specifieke zin faciliteert een architectuur de mogelijkheid om een stapsgewijze migratie te plannen vanuit de huidige situatie naar een situatie zoals beschreven door de architectuur.

Maar architectuur vereenvoudigt ook de integratie met partners waaronder service providers. Het is daardoor een hulpmiddel om te borgen dat de onderhavige onderneming aangesloten blijft in ‘the connected economy'.

De kosten van architectuur zijn in vergelijking met de baten te verwaarlozen. Architecten zijn specialisten in het structureren en visualiseren. Zij leiden een proces waarin verschillende belanghebbenden tot een gemeenschappelijke inzicht komen over het toekomstig functioneren van de onderneming. Een dergelijk inzicht is goud waard, zeker als dat nog echt wordt gedragen in de top van de onderneming. De versnelling van de ‘time-to-market' is nauwelijks in geld uit te drukken. In deze hectische tijd geldt voor veel goede business ideeën dat ze gelijk moeten worden geïmplementeerd anders doet de concurrent dat. Weet wel dat het nadeel van Internet is dat iedereen kan meekijken.

Managers verwachten dat architectuur het informatieverkeer in de onderneming zal versoepelen ter vergroting van de bestuurbaarheid. Voorts beogen zij met architectuur de applicatieportefeuille te rationaliseren en outsourcingsmogelijkheden beter te kunnen plaatsen. Zij hopen meer adaptief te kunnen worden ten aanzien van nieuwe relatievormen met klanten en medewerkers.

Architectuur dient door zijn schoonheid (orde / maat & harmonie), uit te nodigen tot ontwikkeling:

· ontwikkeling van de onderneming binnen het spanningsveld van klanten, leveranciers en concurrenten;

· ontwikkeling van de medewerkers in hun werkomgeving;

· ontwikkeling van samenwerking tussen afdelingen en individuen.

Architectuur wordt mede bepaald door organisatorische, culturele, sociale, financiële en technische randvoorwaarden in de onderhavige onderneming. Daarnaast zullen invloeden van buiten in beschouwing moeten worden genomen, als: externe wet- en regelgeving, usance in de bedrijfstak, concurrentieverhoudingen, en communicatie- en samenwerkingspatronen.

2.8 Rol van de digitale architectuur

Enterprise architectuur [72] 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.

2.8.1 Atlas voor de boardroom

Architectuur valt te vergelijken met het bestemmingsplan van een stadswijk. In één oogopslag moet duidelijk zijn welke principes gelden, welke bedrijfsprocessen aanwezig zijn, hoe de business zich ontwikkelt, hoe technologie is geïntegreerd en hoe klanten hierop zijn aangesloten.

Naast de informatievoorziening zijn er ook allerlei andere bedrijfsmiddelen die continu veranderen, die aanpassing nodig hebben en die bijsturing behoeven. Denk hierbij aan de organisatorische structuur, het personeel, de gebouwen en de productiemiddelen. Om de verandering van deze zaken gelijk te laten lopen met de veranderende informatievoorziening is architectuur nodig in de rol van een atlas. Met een dergelijke atlas kan het overzicht worden bewaard en de samenhang worden bewaakt.

2.8.2 Complexiteitsbeheersing voor de transformatiemanager

Ook voor de IT-manager dient architectuur om inzicht en overzicht te houden. Dus: Hoe zorg ik dat ik niet verdwaal in de IT-doolhof? Dat kan door de complexiteit naar beneden te ‘delegeren'. Hier zorgt architectuur ervoor dat de IT-manager kan kijken naar het geheel, naar de verschillende afzonderlijke onderdelen én de rol die zij in het geheel spelen. Voorts beperkt architectuur als tactisch instrument de keuzes, daardoor is het beste wapen om complexiteit te lijf te gaan.

2.8.3 Raamwerk voor uitvoering

Bij het ontwikkelen onder architectuur is het belangrijk dat er een gemeenschappelijk raamwerk is. Veel transformaties in de informatievoorziening bestaan immers uit complexe systeemintegraties en bovendien lopen er vaak meerdere projecten tegelijkertijd. Natuurlijk zijn zaken gescheiden te ontwikkelen, maar uiteindelijk moet alles wel weer met alles samenwerken. Hierbij is het zaaks dat er duidelijke afspraken zijn; welke trajecten komen het eerst aan bod en welke daarna. Dus eerst maken we een plan en dán pas stellen we vast in welke volgorde het plan wordt gerealiseerd.

2.8.4 Communicatiemiddel

Primair is architectuur een communicatiemiddel. De atlas en het raamwerk zijn enkele uitingsvormen; ze laten zien hoe een bepaald systeem in elkaar zit. En aangezien er rond het thema architectuur veel stakeholders zijn, moeten de verschillende architectuurmodellen bruikbaar zijn als communicatiemiddelen. We willen er immers voor zorgen dat er een gemeenschappelijk aanvaarde informatievoorziening wordt opgesteld. A rchitectuur principes moeten op alle niveaus worden gedragen

2.9 De intelligente organisatie en het personal web

Het zwaartepunt van de digitale architectuur ligt in de I-wereld [73] . In die I-wereld zijn er, naast het eigenaarschap van de informatie, twee belangrijke concepten: de ‘intelligente' organisatie en het personal web.

Onder een ‘intelligente' organisatie verstaan we een onderneming die volledig is toegerust om snel en adequaat te reageren op signalen. Het woord intelligent dient hier te worden gezien als een vertaling van het Angelsaksische ‘intelligence'. Dus zoiets als ‘spionerend'.

Het personal web is de cluster van informatie, kennis en digitale services die iemand als persoonlijke bagage nodig heeft om te kunnen functioneren als wereldburger.

2.9.1 Intelligente organisatie

Data- en kennisaggregatie is essentieel om de drie besturingsbronnen ‘informatie van buiten', ‘informatie van binnen' en de ‘aanwezige kennis' (best practices) op elkaar af te stemmen.

CRM gaat over de interactie met de klant zonder fysieke aanwezigheid. Dit levert een belangrijk deel van de informatie van buiten, de informatie over hoe de markt is en verandert. Hiervoor heeft een onderneming geavanceerde informatievoorziening nodig, waarbij klantinformatie uit verschillende processen en bedrijfseenheden beschikbaar komt bij het Point of Contact. Bij Knowledge Management gaat het om het benutten van expertise en inzicht op alle niveaus. Ook hier is aggregatie van informatie en het beschikbaar stellen waar ook in de waardeketen de sleutel. Bij ‘informatie van binnen' (SCM en BI) gaat het om het aan elkaar koppelen van verschillende taken – die soms ook fysiek van elkaar verwijderd zijn – niet alleen op businessniveau, maar ook de bijbehorende informatievoorziening en technische infrastructuur.

De gedachte achter het bovengenoemde onderling afstemmen is dat informatie, kennis én ervaring daar beschikbaar moet zijn, waar men de beste beslissingen kan nemen of waar men het beste de activiteit kan uitvoeren. Het doorvoeren van deze onderlinge afstemming vraagt van ondernemingen grote investeringen. Naast deze investeringen is vaak ook transformatie van besluitvorming nodig. Bovendien stelt hun scope specifieke eisen aan de informatiearchitectuur als onderdeel van de informatievoorziening. Het goed begrijpen van de business en de gekozen concurrentiestrategie is een eerste vereiste. Het uiteindelijke resultaat is de definitie van strategische principes, die direct invloed hebben op de keuze van specifieke activiteiten, en dus daarom ook op de informatiebehoefte. Uit de informatiebehoefte en de strategische principes zijn ook informatie- en kennisdomeinen af te leiden. Dit is noodzakelijk om duidelijkheid in de verantwoordelijkheidsstructuur te scheppen en een juiste vertaling te maken naar applicatiegebieden en informatiesystemen. De samenhang en strategische principes zijn met architectuur bewust aan te brengen en te implementeren in de informatievoorziening. Kortom, informatiearchitectuur is een bruikbaar instrument voor een effectieve bedrijfsvoering.

Niet alleen de eigen organisatie, maar ook de leverancier en de klant worden ‘intelligenter'. Zij reageren sneller op het gedrag van ondernemingen.

2.9.2 Personal web

In feite wordt het personal web de opvolger van de personal computer. Dit personal web hoort wereldwijd overal benaderbaar te zijn. Mensen zijn immers niet bedoeld als lastdieren om technologie te sjouwen [74] , de benodigde informatie moet de mens in conceptuele [75] zin volgen, waar hij ook is.

De inhoud van het personal web zal nog nader dienen te worden verkend, maar wordt een cruciaal middel voor de ‘web liberated human'. Ook op dit terrein is veel academisch onderzoek vereist.

2.10 Literatuur

[1] Douglas.W. McDavid (1999), A standard for business architecture description , IBM Systems Journal, vol 38, no 1, pp 12 – 31.

[2] Robert Prins (1996), Developing business objects: a framework driven approach , McGraw-Hill, ISBN: 0 07 709294 5.

[3] Han van der Zee, Paul Laagland en Bas Hafkenscheid (2000), Architectuur als managementinstrument , Ten Hagen en Stam, ISBN: 90 440 0087 X.

[4] 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.

[5] Stef M.M.Joosten (2002), Praktijkboek voor procesarchitecten , Van Gorkum, Assen, ISBN: 90 232 3862 1.

[6] Mathieu Weggeman (1997), Organiseren met kennis , Inaugurele rede

Scriptum Management, ISBN: 90 5594 095 X.

[7] Louis Rosenfeld & Peter Morville (1998), Information Architecture for the World Wide Web , O'Reilly & Associates, ISBN: 1 56592 282 4.

[8] Melissa A. Cook (1996), Building Enterprise Information Architecture: Reengineering Information Systems , Prentice Hall, ISBN: 0 13 440256 1.

[9] Wim van der Sanden en Bart Sturm (1997), Informatie-architectuur: de infrastructurele benadering , Panfox, ISBN: 90 801270 2 7.

[10] Mary Shaw and David Garlan (1996), Software architecture: perspectives on an emerging discipline , Prentice-Hall, ISBN: 0 13 182957 2.

[11] Len Bass, Paul Clements and Rick Kazman (1998), Software Architecture in Practice , Addison Wesley, ISBN: 0 201 19930 0.

[12] Peter Bernus, Kai Mertins and Günter Schmidt (1998), Handbook on architectures of information systems , Springer, ISBN: 3 540 64453 9.

[13] Patrick Donohoe, editor (1999), Software architecture, TC2 First Working IFIP Conference on software architecture (WICSA1) , Kluwer Academic Publishers, ISBN: 0 7923 8453 9.

[14] Raphael Malveau and Thomas J. Mowbray (2001), Software, Architect Bootcamp , Prentice Hall, ISBN: 0 13 027407 0.

[15] David M. Dikel, David Kane and James R. Wilson (2001), Software Architecture: Organizational Principles and Patterns , Prentice Hall, ISBN: 0 13 029032 7.

[16] Jan Bosch (2000), Design & Use of Software Architectures: adopting and evolving a product-line approach , Addison-Wesley, ISBN: 0 201 67494 7.

[17] Mehdi Jazayeri, Alexander Ran and Frank van der Linden (2000), Software Architecture for Product Families: Principles and Practice , Addison-Wesley, ISBN: 0 201 69967 2.

[18] Chris Britton (2000), IT Architectures and Middleware: Strategies for building large, integrated systems , Addison Wesley, ISBN: 0 201 70907 4.

[19] Henderson , J.C. and Venkatraman, N. (1993), Strategic Alignment: Leveraging Information Technology for Transforming Organizations , IBM Systems Journal vol.32, nr.1.

[20] Bernard H. Boar (1994), Practical Steps for Aligning Information Technology with Business Strategies: How to Achieve a Competitive Advantage , John Wiley & Sons, ISBN: 0 471 07637 6.

[21] Rik Maes, Daan Rijsenbrij, Onno Truijens en Hans Goedvolk (2000), Redefining business - IT alignment through a unified framework , Tweede Landelijk Architectuur Congres, Amsterdam .

[22] Jan Dietz, Hans Goedvolk, Paul Mallens en Daan Rijsenbrij (2000), A conceptual framework for the continuous alignment of Business and ICT ,

Tweede Landelijk Architectuur Congres, Amsterdam.

[23] Eberhardt Rechtin and Mark W. Maier (1997), The Art of Systems Architecting , CRC Press, ISBN: 0 8493 786 2.

[24] Eberhardt Rechtin (1991), Systems Architecting: Creating & Buiding Complex Systems , Prentice Hall, ISBN: 0 13 880345 5.

[25] Hans Goedvolk, Hans de Bruin en Daan Rijsenbrij (1999), Integrated Architectural Design of Business and Information Systems , The Second Nordic Workshop on Software Architecture (NOSA99).

[26] Jaap Schekkerman (2004), How to Survive in the Jungle of Enterprise Architecture Frameworks; Creating or Choosing an Enterprise Architecture Framework , Trafford Publishing's Bookstore, ISBN: 1 4120 1607 X.

[27] Bernard H. Boar (1999), Constructing Blueprints for Enterprise IT Architectures , Wiley, ISBN: 0 471 29620 1.

[28] Steven H. Spewak (1997), Enterprise Architecture Planning : Developing a Blueprint for Data, Applications and Technology , John Wiley & Sons, ISBN: 0 471 59985 9.

2.11 Vragen

1. Geef een voorbeeld van hogere klanteisen in de digitale wereld.

2. Geef een voorbeeld van een nieuwe bedrijfskans in de digitale wereld die in de fysieke wereld niet of nauwelijks uitvoerbaar was.

3. Wat is het verschil tussen een architectuurpattern en een referentiearchitectuur?

4. Hoe is legacy een architectuur-issue?

5. Geef een voorbeeld van een legacy-systeen op de universiteit.

6. Waarin is zichtbaar dat de universiteit steeds meer afhankelijk wordt van een moderne informatievoorziening?

7. Hoe is de digitale beveiliging op de universiteit geregeld? Beveiligingsbeleid? Beveiligingsarchitectuur? Beveiligingsfunctionarissen?

8. Hoe en met wat is de universiteit digitaal vervlochten?

9. Geef een voorbeeld van transparantie op de universiteit.

10. Wat omvat de architectuur van het bedrijfsgebeuren precies? Wat is daarbij de scheiding tussen fysiek en digitaal?

11. Waarom is procesarchitectuur geen architectuur?

12. Is gegevensarchitectuur eigenlijk wel architectuur? Onderbouw het antwoord.

13. Wat is de relatie tussen kennismanagement en contentmanagement?

14. Verklaar waarom de informatiearchitectuur centraal staat bij de business-IT alignment.

15. Geef enkele artefacten op het worldwideweb waarover een architectuurbeschouwing zinvol is.

16. Wat is een applicatietypologie? En geef enkele applicatietypes.

17. Waarom worden de geautomatiseerde gegevensverzamelingen tot de applicatielaag gerekend?

18. Waarom beschouwt Rijsenbrij software architectuur niet als architectuur?

19. Waarom moet de infrastructuur van de onderneming aansluiten op de infrastructuur van het ecosysteem? Geldt dit uitsluitend voor de infrastructuur? Onderbouw het antwoord en geef eventueel voorbeelden.

20. Geef een voorbeeld van een beveiligingsprincipe dat op gespannen voet staat met een ander architectuurprincipe.

21. Welke stakeholders zijn betrokken bij het domein ‘onderwijs' aan een universitaire instelling.

22. Waarom worden de toekomstige onderhoudsploeg en het toekomstige exploitatiecentrum wel als stakeholder gezien en het ontwikkelteam niet?

23. Noem enkele externe stakeholder van de faculteit.

24. Is de student een stakeholder van het onderwijsdomein? Zo ja, is hij een beslissende, beïnvloedende of overige stakeholder. Onderbouw het antwoord.

25. Wat is een black-box white-box benadering? Waarom wordt dit bij architectuurbeschouwingen toegepast?

26. Wat is de reden van de scheiding tussen het ‘logische' en ‘fysieke' niveau in de systeemtheoretische beschouwing?

27. Waarom is een transformatiebeschouwing belangrijk bij het opstellen van een architectuur? Zijn de principes die hierbij een rol spelen architectuurprincipes of bedrijfsprincipes? Onderbouw het antwoord.

28. Geef aan hoe de systeemtheoretische fasering parallel loopt aan de driedeling van Vitruvius.

29. Hoe kan middels een framework de consistentie en coherentie van de verzameling principes worden bewaakt?

30. Welke criteria zijn belangrijk bij de keuze van een framework?

31. Waarom is het belangrijk stil te staan bij de noodzaak van architectuur alvorens wordt begonnen met het opstellen van architectuur?

32. Wat is de noodzaak van architectuur voor de universiteit?

33. Wat zou de gebruiksdoelen van een architectuurschets voor de universiteit kunnen zijn? Prioriteer je opsomming en geef daar een onderbouwing bij.

34. Beschrijf invloeden die externe wet- en regelgeving, usance in de bedrijfstak, concurrentieverhoudingen, en communicatie- en samenwerkingspatronen kunnen hebben op de architectuur van de universiteit.

35. Wat wordt bedoeld met de complexiteit naar beneden ‘delegeren'?

36. Waarom ligt het zwaartepunt van de digitale architectuur in de I-wereld?

37. Wat is het verschil tussen het personal web en de (persoonlijke) digitale werkruimte?

38. Wat zou er in jouw personal web aanwezig dienen te zijn aan digitale informatie en digitale functionaliteiten?

39. Geef een voorbeeld van een ‘intelligenter' wordende leverancier.

40. Geef een voorbeeld van activiteiten waaruit blijkt dat klanten ‘intelligenter' worden.

2.12 Oefeningen

1. Als IT-experiment wordt je door je baas een jaar naar een ‘onbewoond' zonnig paradijseiland gestuurd. Het enige wat je meekrijgt is een laptop op zonne-energie met satellietverbinding. Overigens is er op een naburig eiland een zeer vriendelijke stam die jou van voedsel voorziet maar die nog in het stenen tijdperk leeft en waarmee je behalve glimlachen niet echt kan communiceren.
Je baas wil dat je blijft doorwerken alsof je in de kamer naast hem zit.

Oefening : Welke digitale services en welke digitale informatie (inclusief kennisitems) heb je nodig en hoe dienen die op je laptop te worden gepresenteerd? Let wel: je hebt geen fysiek kladblok, noch een pen of potlood om fysieke notities te maken. Probeer de inrichting zodanig te verwezenlijken dat je niet constant heen en weer moet springen tussen beeldschermpagina's met een kop vol feiten om de draad in je werkzaamheden te behouden. Daar is het immers te warm voor. Zorg dat de digitale werkruimte je maximaal ondersteunt om overzicht en inzicht in je werkzaamheden te behouden.

2. Een architect in de fysieke wereld creëert een ruimte, een ruimte om te leven, een ruimte om te werken. Een ruimte die past bij de maat van de mens.
Wat speelt in de digitale wereld de rol van ruimte?

3. Maak een ER-diagram van de entiteiten ‘onderneming', ‘stakeholder', ‘view', ‘viewpoint' en ‘architectuurprincipe'.

3. Het opstellen van een architectuur

trefwoorden: meerdere niveau's, invloed van missie-visie-strategie, invloed van het ecosysteem, invloed van technologie, de deliverables, visualisatie, eigenaarschap, CSF's, evaluatie, procesingrediënten, maturity, referentie architectuur.

3.1 Inleiding

Het opstellen van een bruikbare architectuur is een ware uitdaging, gezien het abstracte karakter van architectuur. Architectuur is een voorstelling van zaken die je niet ziet, zoals begrip van de context, samenhang van de delen, belevingspercepties door stakeholders en een originele toepassing van technologieën en ‘best practices'. Het inzichtelijk maken van die onzichtbare zaken is de kunst en kunde van een architect.

Architectuur is een teken van beschaving, geeft een corporate identity aan een onderneming en is katalysator voor de gewenste bedrijfscultuur.

Architectuur en ontwerp zijn geen synoniemen. Het opstellen van een architectuur gaat aan het eigenlijke ontwerpproces vooraf.

Architectuur is niet een verzameling cryptische diagrammen die wordt opgesteld door techneuten, bedoeld voor ander techneuten om iets ingewikkelds te maken. Het is daarom geen verzameling van dikke dossiers, gevuld met een overmaat aan details, bestaande uit een onleesbare verzameling van DFD's (data flow diagrammen) en ER plaatjes (entity relatie diagrammen). Architectuur is geen synoniem voor de beschrijving van de onderliggende infrastructuur, noch is architectuur een overzicht van alle aanwezige dan wel geplande applicaties.

Architectuur behoort te passen bij wat mensen in een onderneming doen [76] . Bekende fysieke architecten als Gerrit Rietveld en Frank Lloyd Wright gingen voor het ontwerp van luxe woningen eerst bij hun opdrachtgever een week of twee logeren om te kijken hoe die mensen leefden en kwamen daarna pas met een eerste schets. Dat zijn wij in de IT nog niet gewend. Bij het inhuren van een externe architect vinden opdrachtgevers dat zonde van het geld, er hoeft niet te worden geobserveerd er moeten meters worden gemaakt. Maar goede architectuur kost gewoon geld, dat geldt ook voor digitale architectuur. Probeer het wezen van de bouwopdracht te doorgronden en inventariseer de verwachte toekomstige eisen voor de voorzienbare toekomst. Stel pas daarna de architectuur op als afgeleide van de werkelijke vraag. Dat geldt zowel voor de fysieke als voor de digitale architectuur. Voor digitale architectuur komt als extra daarbij dat er voldoende aandacht dient te worden geschonken aan bestuurlijke en sociologische vraagstukken. Digitale architectuur is namelijk bedoeld voor mensen.

De architect dient een architectuur voor de onderneming op te stellen waarin hij rekening houdt met:

· de gewenste rol en plaats binnen het ecosysteem;

· de plaats van de onderhavige onderneming in de bedrijfstypologie (maar dan niet à la Botter of Starreveld, maar gemoderniseerd naar het Informatietijdperk);

· de ontwikkelingen in het assortiment van producten en diensten van de onderneming, mede in relatie tot haar omgeving / bedrijfstak;

· de interne beschouwingswijze van de onderneming en de managementstijl;

· het mensbeeld binnen de onderneming (zowel individueel psychologische factoren als de medewerker gezien in zijn rol als mens in een werkomgeving);

· de bedrijfscultuur;

· het automatiseringsstadium van de onderneming.

Architectuur is geen statische aangelegenheid en hoort daarom actief te worden onderhouden. Het opstellen van een architectuur, ook wel verwoord als architecting, is daarom een continu proces. Een proces dat professioneel dient te worden beheerd, doorgaans aangeduid met ‘architectuur governance'.

Architectuur in de digitale wereld is nooit geheel klaar en wordt daarom beschouwd als een groeimodel. Leg zaken niet te gedetailleerd vast, de gouden regel voor digitale architectuur luidt ‘just enough' & ‘just in time'.

Ondernemingen transformeren, en om een daarbij passende architectuur op te stellen dient uit beheersmatig oogpunt in de architectuur generieke en specifieke aspecten van elkaar te worden gescheiden. Deze scheiding is niet absoluut en kan na enige tijd, afhankelijk van de dynamiek van de bedrijfsvoering, moeten worden herzien.

Architectuur geeft op globaal niveau invulling aan een aantal belangrijke kwaliteitsattributen, zowel actueel als tegen de achtergrond van een lange termijnvisie. Daardoor is architectuur een hulpmiddel bij het bepalen van de juiste balans tussen stabiliteit en flexibiliteit van de informatievoorziening. Er wordt gezocht naar de stabielere delen van de onderneming en de delen die een maximale flexibiliteit moeten hebben. Zo zijn bij de overheid kosten en baten eigenlijk nauwelijks een issue, als de flexibiliteit maar overeind blijft. De snelheid waarmee een verandering in de politiek kan worden omgezet in uitvoering is kennelijk belangrijker. Bij ondernemingen in dynamische markten speelt dit ook een grote rol. De opdracht van de architect is te zoeken naar de delen in de onderneming die flexibel moeten zijn, en de delen die een grotere mate van stabiliteit kennen. De stabielere delen vormen de meest constante factor. Hun omgeving is relatief voorspelbaar of de taak verandert nauwelijks met de veranderingen in de omgeving. Het organisatieonderdeel is dan vaak stabieler en meer efficiënt in te richten. Dit kan nu de basis vormen van waaruit men werkt. De minder voorspelbare delen probeert men hierop aan te sluiten met een zo eenvoudig mogelijke interface. Bij de minder voorspelbare delen probeert men de inrichting zo dicht mogelijk tegen de bewegingen van de markt te leggen. Voor consultancy bedrijven zijn professionele netwerken zo'n stabiele factor, terwijl de realisatieafdelingen juist weer veel flexibiliteit nodig hebben. Een architect gaat daarvoor op zoek naar de principes die de samenhang bewaken, en een vooraf gesteld overkoepelend doel van het totale waardenetwerk verzekeren.

De toepassing van de juiste architectuur borgt zodoende de toekomstvastheid van automatiseringsoplossingen

Het proces van architecting is afhankelijk van de situatie:

· ‘IT-stadium' bij de klant

· bedrijfscultuur bij de klant

· ontwikkelingen in de business van de klant

Vervolgens heeft iedere onderneming een eigen specifieke invulling van de architectuur. Dat komt doordat iedere onderneming per definitie een unieke combinatie van omgevingsfactoren heeft. Bovendien zoekt iedere onderneming haar eigen onderscheidend vermogen ten opzichte van de concurrentie.

3.2 Op meerdere niveau's

Wij onderkennen vijf abstractieniveaus's: de onderneming in zijn geheel, de domeinen, de applicaties, de technische infrastructuur en uiteindelijk de digitale werkruimtes. Dit impliceert tevens dat er op vijf niveaus architecturen dienen te worden ontwikkeld die elkaar onderling zullen beïnvloeden. De (globale) architectuur, die als besturingsinstrument wordt gebruikt bij het prioriteren van veranderingen en ontwikkelingen, biedt inzicht en overzicht over het geheel en de samenhang van organisatie of onderneming. Dit soort architecturen wordt meestal aangeduid met enterprise- of domeinarchitectuur als een soort kaderstellende architectuur. De enterprise architectuur en de domeinarchitectuur zijn kaderstellend voor de specifieke architectuur van individuele informatiesystemen en de onderliggende infrastructuur. Kaderstellende architecturen zijn vooral bedoeld als beslissingsondersteunend instrument: outsourcing , partnership, overnames, ketenvraagstukken.

De (meer gedetailleerde) architectuur, die als ontwikkelingsinstrument bij het realiseren van de in deze architectuur beschreven onderdelen wordt gebruikt, wordt aangeduid met ‘oplossingsarchitectuur'.

De hogere niveaus leggen beperkingen op aan de lagere niveaus, terwijl de lagere niveaus feedback geven aan de hogere niveaus. Een dergelijk schema wordt daarom continu bijgesteld en is daardoor voortdurend in beweging.

Vaak beginnen we op het hoogste niveau. Dat zien we in de fysieke wereld ook. Zo begint de stadsplanning met een conceptueel ontwerp van de stad in zijn geheel en beschrijft het de missie, de visie en de strategie, de scope, de vereisten, de principes en beperkingen voor de ontwikkeling van de stad.

Het logisch ontwerp start met een plan dat de relaties tussen de stad en zijn omgeving toont en een ‘zoning' plan dat de stad onderverdeelt in domeinen met verschillende rollen met hun onderlinge relaties of interacties. Denk bijvoorbeeld aan woonwijken, industriegebieden, winkelcentra, recreatiegebieden en dergelijke. Belangrijk daarbij is de vaststelling van de infrastructuur die de onderlinge relaties ondersteunt. Het ‘zoning' plan kan ook als blauwdruk dienen voor een transformatieplan om de verschillende stadia te tonen van de toekomstige ontwikkeling of renovatie van de stad.

Het fysieke ontwerp bestaat uit een plan dat toont hoe de hedendaagse situatie is en/of wordt veranderd door de nieuwe ontwikkelingen en plannen. Deze schrijven op hun beurt weer voor welke type componenten en ontwikkelmethoden moeten of mogen worden gebruikt bij de ontwikkeling van de zones.

Op het niveau waar de veranderingen plaatsvinden, moeten voor de start van het project vier belangrijke acties worden uitgevoerd:

· stel de architectuur vast voor het te bouwen systeem;

· bepaal het projectspecifieke kwaliteitssysteem;

· bepaal de te gebruiken methoden, technieken en tools;

· onderzoek de kennisbank op (her)bruikbare componenten [77] .

3.3 Missie-visie-strategie

Naast het ecosysteem wordt de architectuur ook bepaald door de missie, visie, strategie van de onderhavige onderneming

De missie beschrijft de bestaansredenen van een onderneming. Het is belangrijk om helder te hebben wat de missie of doelstelling is van een onderneming, omdat de besluitvorming door het management in het licht staat van de missie. Belangrijk is ook dat medewerkers van de onderneming bekend zijn met deze doelstellingen.

De visie wordt gevormd door het beeld dat een onderneming heeft richting de toekomst en de keuzes die men daarbij maakt. Daarbij is dat toekomstbeeld meestal geen vastomlijnd beeld meer, maar steeds vaker een bewegend doel. Het is voor ondernemingen dan ook de kunst om over voldoend adaptief vermogen te beschikken zodat zij mee kan bewegen met die bewegende doelen. Een visie houdt op zijn minst rekening met zaken als: ‘de markt en haar uitdagingen', ‘economische en politieke ontwikkelingen', ‘demografische en sociale trends', ‘de concurrentie en de competitie', ‘maatschappelijke trends', ‘overheidsregulering', ‘een lucratieve rol in het ecosysteem' en natuurlijk de ‘technologische mogelijkheden en uitdagingen' .

Op basis van de visie kunnen een of meer strategieën worden ontwikkeld die het pad naar de toekomst aangeven (‘roadmap to the future') met de bedoeling een unieke positie te creëren. Hieruit komen meestal niet meer dan zeven strategische principes.

Op basis van de overkoepelende ondernemings- en organisatiestrategie kunnen vervolgens afgeleide strategieën worden ontwikkeld gericht naar bepaalde aspecten, zoals: de IT-strategie, de beveiligings- en beheerstrategie, die tezamen een holistische richting naar de toekomst aangeven.

De geïntegreerde architectuur van de bedrijfsprocessen, de informatievoorziening van de onderneming, van de applicaties en de technische infrastructuur staat in wederkerige relatie met ondernemingsbeleid, informatiebeleid en het beleid over de toe te passen informatietechnologieën.

Gezien deze centrale rol van de architectuur is het een cruciaal hulpmiddel voor de verbetering van de concurrentiepositie. Dit maakt dat architectuur de verantwoordelijkheid van het topmanagement hoort te zijn

3.4 De invloed van technologie op architectuur

Nieuwe technologische ontwikkelingen hebben een grote impact op architecturen zowel in de fysieke wereld als in de digitale wereld en maakt totaal nieuwe architecturen mogelijk. De bouw van wolkenkrabbers werd pas mogelijk door de uitvinding van de personenlift, het is immers ondoenlijk om mensen vijftig verdiepingen te laten lopen. De toepassing van het gewapend beton als constructiemateriaal stelde ons in staat om veel grotere ruimtes te overspannen. In de digitale wereld heeft het Internet gezorgd dat webservices kunnen worden toegepast, de ultieme mogelijkheid om gedistribueerde systemen te ontwerpen. Nieuwe technologie heeft het mogelijk gemaakt om real-time te organiseren over een uitgestrekt gebied waar de situatie van minuut tot minuut verandert.

Daarnaast biedt technologie ruimte voor nieuwe business(activiteiten). Maar business activiteiten kunnen slechts bestaan bij de gratie van de bijbehorende informatiestromen. Daarom is een goede architectuur voor het informatie- en kennisgebied belangrijker dan de onderliggende technologie. Dus technologie is uitermate belangrijk om nieuwere architecturen te realiseren, maar technologie moet in de dienende rol blijven.

Veel high-tech ondernemingen hebben in hun eigen bedrijfsvoering een overdaad aan technologie ingezet. Dit komt door de aard van die onderneming en de vaak slagvaardige houding van haar medewerkers. Bij dergelijke ondernemingen is er altijd veel ruimte voor decentraal initiatief, hetgeen voor de eigen informatievoorziening vaak leidt tot een grote mate van wildgroei. En omdat technologie redelijk goedkoop is en de benodigde vakbekwaamheid in huis is, is de verleiding groot om snel oplossingen in elkaar te zetten. Dit resulteert meestal tot een soort Eftelingachtige informatievoorziening: veel belangrijke (locale) attracties met een uitermate laag onderling verband en elk met hun eigen (beheer)personeel.

Voorts is het de gewoonte dat bij bedrijfsfusies die applicaties en infrastructuren worden geselecteerd die als het beste van de aanwezige mogelijkheden worden beschouwd. Door de vaak grote haast gaat men hier dan zogenaamd pragmatisch mee om en is er geen gelegenheid tot een fundamentele herbezinning op de architectuur van de nieuwe onderneming.

3.5 Deliverables

In deze wat moeilijkere economische tijd blijkt de belangrijkste doelstelling van architectuurstudies efficiency verhoging te zijn in alle gelederen en op alle beschouwingsniveaus: bedrijfsgebeuren, informatieverkeer, applicaties en technische infrastructuur. Daarbij is het belangrijk om een indicatie te verkrijgen in welke mate efficiency verhoging kan worden bereikt door verschillende ‘ingrepen':

· rationalisatie (in het SDM-tijdperk werd ook al geponeerd: eerst reorganiseren en pas daarna automatiseren),

· automatisering (veel handmatige taken kunnen beter en efficiënter door de computer worden uitgevoerd),

· competency clustering (outsourcing / on shore, shared service centers),

· offshoring (near shore / far shore).

Een tweede belangrijke doelstelling bij architectuurstudies is de vergroting van de bestuurbaarheid van de onderneming in haar geheel en haar onderliggende domeinen.

Gezien de redelijk chaotische situatie bij veel ondernemingen is het verstandig om eerst eens een houtskoolschets op enterprise niveau te laten maken. Dus op het niveau van de onderneming in zijn geheel en de belangrijkste business domeinen. Belangrijk daarbij is het vaststellen van de doelstelling die met die houtskoolschets wordt beoogd. Tijdens de intake-gesprekken met de belangrijkste stakeholders dient de doelstelling te worden vastgesteld. Afhankelijk van het aantal en de beschikbaarheid van de belangrijkste stakeholders vergt de intake meestal een doorlooptijd van een week. Hierbij worden ook de belangrijkste CSF's [78] onderzocht.

Inhoud van een houtskoolschets.

- voor de enterprise in haar geheel:

· vaststelling van de belangrijkste stakeholders op ondernemingsniveau en hun rol in de ontwikkeling en het gebruik van de architectuur;

· bepalen en expliciteren van de strategische en bedrijfsprincipes en de daaruit afgeleide informatieprincipes, IT-principes (applicaties en technische infrastuctuur) en security principes;

· een eerste afbakening van de hoofddomeinen (definities en rationele achter de afbakening als afgeleide van de strategie);

· een opsomming van de belangrijkste ‘diensten' per domein, naar buiten en naar elkaar;

· vaststelling van de informatiestromen en communicatiepatronen tussen de domeinen en naar buiten;

· mogelijke besturingsmodellen (aggregatiemechanisme, dashboards en de relatie tussen de governance structuur en de informatiearchitectuur).

- per belangrijk domein:

· vaststelling van de belangrijkste stakeholders op domein niveau en hun rol in de ontwikkeling en het gebruik van de domeinarchitectuur;

· de belangrijkste principes van het domein, nader gedetailleerd;

· een opsomming van redelijk autonoom aanstuurbare activiteitencluster binnen het domein (deze kunnen worden gezien als mogelijk te outsourcen kavels, of kavels die in aanmerking komen voor een shared service center);

· een vaststelling van de informatiestromen en communicatiepatronen binnen het domein;

· mogelijke besturingsmodellen (aggregatiemechanisme, dashboards en de relatie tussen de governance structuur en de informatiearchitectuur) op domein niveau.

Een dergelijke houtskoolschets kan, afhankelijk van beschikbaarheid van de belangrijkste stakeholders en de gewenste diepgang, in een doorlooptijd van ongeveer vier maanden zijn gerealiseerd.

Na die houtskoolschets kunnen de verschillende domeinen separaat verder onder architectuur worden gebracht: het inkleuren van de houtskoolschets eventueel ‘kavel' voor ‘kavel'.

Bij de houtskoolschets hoort ook een ‘roadmap' met prioriteiten hoe de architectuur verder kan worden geconcretiseerd. Parallel hieraan kunnen onderbouwd rationalisatietrajecten worden gestart.

Het IAF [79] model van Capgemini bestaat uit vier kolommen (business, informatieverkeer, applicaties, infrastructuur) en vier rijen (contextueel, conceptueel, logisch, fysiek).

Bij een dergelijke houtskoolschets ligt het zwaartepunt op het kwadrant opgespannen door de kolommen business en informatieverkeer en de rijen contextueel en conceptueel. Dit is het kwadrant dat belangrijk is voor de boardroom en het hogere management van de business domeinen.

Het kwadrant bestaande uit de kolommen applicaties en technische infrastructuur en de rijen logisch en fysiek is belangrijk voor hoofd rekencentrum of bij outsourcing (althans ITO) voor de externe providers.

Belangrijk voor een juiste B-IT alignement is de relatie tussen deze twee kwadranten, waarbij de andere 8 hokken een afstemmende rol spelen.

Na de intake fase kan de lijst met de wenselijke deliverables worden opgesteld. Het resultaat is afhankelijk van de doelstelling van de architectuurstudie en het vervolgtraject.

De resultaten van een architectuurtraject bestaan uit architectuurprincipes, architectuurmodellen en schetsen van de toekomstige situatie [80] voor de verschillende aspectgebieden en de verschillende abstractieniveaus.

Deze resultaten worden ontwikkeld ten behoeve van verschillende doelgroepen en verschillende doelstellingen en kennen derhalve ook verschillende verschijningsvormen. De meest gebruikte verschijningsvorm zijn visualisaties welke als mooie posters een plaatsje zouden kunnen krijgen aan de wand, verbeeldend de toekomstige of bestaande situatie. Daarnaast beschrijven documenten de nadere details van de verschillende elementen en componenten.

Om principes visueel te kunnen ‘tonen' worden vaak modellen gemaakt. Dit zijn niet de modellen die uit het ontwerp rollen, dus modellen om iets te maken (ook wel maakmodellen genoemd). Om spraakverwarring te voorkomen worden de modellen die gebruikt worden in de architectuurfase aangeduid met architectuurmodellen of metamodellen. Het zijn immers modellen achter de modellen dus volgens de systeemtheorie metamodellen. Een voorbeeld is het vroegere ‘client-server' model dat in het Internet tijdperk is uitgegroeid tot een ‘client-services' model.

De architectuurbeschrijving dient zodanig gedetailleerd te zijn dat vervolgens separaat op meerderde plaatsen aan het ontwerpproces kan worden begonnen zonder dat de samenhang verloren gaat.

- enkele mogelijke deliverables

A . mental models [81] (waarmee structuur en beleving worden gevisualiseerd)

· ondernemingsgebeuren: plaatjes van een ‘fully IT enabled' onderneming.

· de omgeving / de markt (ketenarchitectuur, leveranciers etc.).

· functionele opdeling in domeinen en de services.

· viewpoints per stakeholder, eenvoudige gevisualiseerd.
(gedocumenteerd met concerns, principes en eventuele patterns).

· besturingsmodellen / inrichting besturing (inclusief dashboard's, KPI's en CSF's als stuurparameters).

B . principediagrammen tegen de achtergrond van de mental models.

(principeoverzicht in boomvorm met onderlinge afhankelijkheden).

C . globaal-ontwerp schema's op ondernemingsniveau en domeinniveau

(met patterns op de relevante plaatsen).

· producten / services

· bedrijfsprocessen

· generieke organisatiestructuur

· informatieverkeer (informatiearchitectuur incl. data- en kennisaggregatie)

· applicaties

· technische infrastructuur

D . interface schema's

ondernemingsniveau
per domein
per applicatie

E . security architectuur (security-gebieden en security-principes)

F . generieke architectuur van het kennismanagement

G . inrichting van de governance van de architectuur

H . implementatie richtlijnen / migratiepad (transformatieprogramma's, project mapping)

I . terminologielijst (kort en alleen voor de relevante termen)

J . kanttekeningen omtrent:

a) maatregelen voor een optimale business IT alignment / toekomstvastheid

b) architectuur versus technologiebeleid

c) toepassing van ideeën over Adaptive IT etc.

d) architectuur versus bedrijfscultuur

e) menselijke maat ( life balance )

f) rol van architectuur en architect bij transformatie / realisatie

3.6 Visualisatie

Een belangrijk element bij architectuurtrajecten is veel en juist visualiseren [82] , dit draagt niet alleen bij aan beeldvorming maar ook aan draagvlakvergroting binnen de onderneming. Het is verstandig om hiervoor deskundigen in te schakelen. Architectuur is een middel bij het communicatieproces met en tussen de stakeholders. Goede visualisaties van de architectuur en ook het aanbieden van meerdere alternatieven, scenario's genoemd, zal een enthousiaste discussie uitlokken bij de stakeholders, waardoor de betrokkenheid bij het opstellen van de architectuur sterk wordt vergroot en men ook zelf creatief gaat meewerken.

Bij fysieke architecten is het de gewoonste zaak van de wereld dat het ontwerp wordt gevisualiseerd. Als we een bungalow laten ontwerpen wordt een duidelijke bouwtekening gemaakt. Als we een winkelcentrum laten ontwerpen wordt een maquette gemaakt die we kunnen vast houden. Maar in de IT-wereld tonen we vaak een spoorwegemplacement waar de NS nog jaloers op zou worden, maar dat nulkommanul inzicht verschaft aan de toekomstige stakeholders van het object.

In feite zijn wij nog steeds op zoek naar een vormentaal om het proces van stakeholder-consensus te faciliteren.

Maar net zoals een architect in de fysieke wereld visualisaties (schetsen) maakt van een toekomstig artefact, zo dienen ook architecten in de digitale wereld visualisaties te maken van ondernemingen, taken en activiteiten met de bijbehorende informatiestromen of van applicaties en infrastructuren.

Visualisatie tijdens een architectuurproces is altijd de weergave van een bepaald uitgangspunt in de tijd. Die weergave reflecteert het gedachtegoed van dat moment. De architect tracht zijn interpretatie van de structuur weer te geven. Doordat de architect de gedachten van een ander structureert en visualiseert, helpt hij de ander met het ontwikkelen van het gedachtegoed. Anticipeer op het feit dat de eerste versies van de visualisaties er juist op gericht zijn denkpatronen te structureren en te stimuleren en dat de gebruiker van de visualisaties met veranderingen zal komen. Besef ook dat het leerproces van de opdrachtgever zal leiden tot uitbreiding van de scope van het architectuurproces.

De architect moet zich aanpassen aan zijn doelgroep. Dit is een van de redenen waarvoor hij richting opdrachtgever vaak ‘free format' tekeningen maakt, en richting bouwers gebruik maakt van formele diagramconventies die passen bij de doelomgeving.

Architectuur, aangevuld met het globaal ontwerp, is een visualisatie - & communicatiemiddel.

· communicatie tussen architect en klant (verduidelijking van de ontwerpopdracht middels visualisatie);

· communicatie tussen architect en bouwer (duidelijke voorschrijvende bouwopdracht).

Adequate visualisering van de architectuur [83] is een absolute noodzaak om te borgen dat de stakeholders weten waar zij voor kiezen. Het feit dat dit meestal niet de sterkste kant is in de IT-sector, veroorzaakt dat topmanagers niet echt interesse hebben voor IT, laat staan de architectuur daarachter. Dat laatste is dus de eigen schuld van de architecten!

Om de digitale werkomgeving voor de verschillende rollen in de onderneming visueel te maken, wordt vaak een stripachtige weergave toegepast met titels als ‘een dag in het leven van ....'

3.7 CSF's

Een architectuurtraject is vaak een lang en moeizaam proces met vele weerstanden. Het is daarom belangrijk van te voren de CSF's, critical succes factors, in kaart te brengen. Dit zijn die factoren die van doorslaggevend belang zijn voor een succesvolle afloop. Onvoldoende aandacht voor de CSF's zorgt vaak voor een frustrerende maagzweerverwekkende klus.

Of een onderneming iets met architectuur wil, hangt samen met de noodzaak om te komen tot een aantal gemeenschappelijke uitgangspunten en principes die als leidraad kunnen gaan dienen voor gemeenschappelijk gebruik. De noodzaak om tot die gemeenschappelijke zaken te komen, ligt vaak besloten in operationele knelpunten in het functioneren van die onderneming. Dit heeft meestal te maken met de complexiteit van zaken en het ontbreken van samenhang, waarbij structurering en het gezamenlijke belang de belangrijkste knelpunten zijn. Ook voorbereiding op de toekomst kan een sterke drijfveer zijn om iets met architectuur te doen.

De twee belangrijke vragen aan het begin van een architectuurtraject zijn:

· wie is / wordt de eigenaar [84] van de architectuur;

· wie zijn de belangrijkste beslissers bij architecturele vraagstukken.

De vier belangrijkste kritieke succesfactoren zijn

1) daadwerkelijk commitment van het topmanagement en de belangrijkste stakeholders

2) open communicatie met het topmanagement, de stakeholders en overige belangstellenden

3) voldoende kennis, kunde en ervaring:

a) architecten met ervaring in architectuurproces, visie/strategie/planning, programmamanagement, communicatieproces/communicatiemiddelen,

b) programmamanagers met affiniteit tot architectuur en inzicht in het proces van visie/strategie/planning

4) plaats van architectuur in de organisatie.

Deze factoren moeten bij aanvang van een architectuurtraject worden onderzocht en vastgelegd in een plan van aanpak.

Enkele faalfactoren

1. De opdracht is niet duidelijk neergezet.

2. Het probleem dat aanleiding gaf voor de architectuurstudie werd onvoldoende duidelijk (h)erkend. De sense of urgency voor het opstellen van een nieuwe architectuur is daardoor nauwelijks aanwezig.

3. Geen werkelijk relevante uitgangsdocumentatie, geen duidelijk document betreffende missie, visie en strategie.

4. Nog geen duidelijke mening bij de belangrijkste stakeholders.

5. Er is nog geen duidelijk, onvoorwaardelijk commitment van het topmanagement.

Belangrijke tips bij het opzetten van een enterprise architectuur of een domeinarchitectuur:

· Zorg voor eenvoud (complexiteit is fataal).

· Streef geen al te grote uniformiteit na; kijk uit voor de ‘one size fits all' discipline.

· Weet waar uniformiteit moet worden gepromoot en waar diversiteit dient te worden ondersteund.

· Documentalisten en gespecialiseerde techneuten zijn dodelijk voor het proces.

· Maak gebruik van veel visuele terugkoppeling, liefst ondersteund met fysieke zaken.

· Zorg voor teambuilding tussen de belangengroeperingen.

· Schakel niet te veel verschillende leveranciers van hardware, software en middleware in, hetzelfde geldt ten aanzien van service providers

· Voorkom al te veel technische hoogstandjes.

· Werk niet te snel; te ambitieus.

· Hanteer het juiste verwachtingspatroon; architectuur dient gewenst te worden door alle stakeholders.

· Zet een goed informatiecentrum van patterns op, maar etaleer de patterns niet te esoterisch, bezig gewoon taalgebruik.

· Stel een researchfunctie in om de veranderingen op technologiegebied en op het gebied van de business(processen) bij te houden.

· Gebruik duidelijke producten.

· Zorg voor werkelijk management commitment.

· Zorg voor een duidelijk rollenpatroon van de stakeholders bij het architectuurproces.

· Zorg dat de architectuur realiseerbaar is, niet alleen technisch, maar ook sociaal en economisch.

In het architectuurteam moet een duidelijke leider zitten; iemand die de architectuur en het nut van de architectuur kan ‘verkopen' aan alle belangrijke stakeholders.

3.8 Architectuur Evaluatie

Gezien de noodzaak tot het hebben van een bruikbare architectuur, is het belangrijk te weten of men wel de juiste architectuur heeft. Daarom is een validatie van die architectuur, ook wel architectuur-assessment geheten, absoluut noodzakelijk. Ook kan het raadzaam zijn dat aan het einde van een architectuurtraject een onafhankelijk bureau wordt ingeschakeld om een second opinion op te stellen.

Ieder systeem, of het nu een onderneming of een applicatie betreft, kent een architectuur. Soms is deze expliciet bepaald en als zodanig vormgegeven, echter heel vaak is de architectuur impliciet aanwezig zonder dat stil wordt gestaan bij de inrichting, vormgeving en consequenties van deze impliciete architectuur. Een slechte architectuur werkt als een dwangbuis voor de onderneming. Een impliciete architectuur zou best een slechte architectuur kunnen zijn. Daarom wordt architectuur steeds vaker expliciet gemaakt en dient het als referentiekader voor het toetsen en nemen van beslissingen. Dit geldt zowel op organisatorisch gebied als op het gebied van de informatievoorziening.

Als een onderneming niet bewust met architectuur bezig is, dan overkomt het die onderneming. Op basis van ad-hoc beslissingen worden allerlei zaken veranderd dan wel gekocht of gemaakt zonder dat er sprake is van enige samenhang; laat staan dat er is nagedacht over een bepaalde beleving.

Elke architectuur is uniek en afgestemd op de bedrijfsomstandigheden waarvoor het is bedoeld. Wie een standaardarchitectuur koopt, eventueel meegeleverd met een softwarepakket, koopt de technologievisie van een ander. Als de ceo de onderneming een unieke plaats wil geven, dan kan dat niet met de architectuur die de concurrent reeds implementeerde. Als hij dat wel doet, is die concurrent altijd een stap eerder.

In een architectuur moet de dynamiek van een onderneming doorklinken. Deze wordt bepaald door het vooraf gekozen business gebied, de dynamiek in de externe omgeving en de zelfgekozen concurrentiestrategie. Deze factoren geven aan ‘wat' de architectuur moet kunnen, én aan welke kwaliteiteisen de operatie moet voldoen. Bovenal moet een architectuur recht doen aan de strategie die is gekozen om het doel te bereiken.

Er is een uitermate interessante spanning tussen architectuur en cultuur. Enerzijds mag de architectuur ongewenste ingeslepen patronen niet bestendigen. Anderzijds kan de architectuur niet te ver van de bestaande cultuur afstaan vanwege de acceptatiegraad. En net als met verstoringen van buitenaf, moet een architectuur de verstoringen van binnenuit kunnen doorstaan. De architectuur moet adequaat kunnen reageren op concurrentie of veranderende regelgeving. Zo moet een architectuur ook kunnen reageren op het gedrag van de mensen binnen een organisatie en de betrokkenen bij een partnership.

Enkele kenmerken van een waardevolle architectuur:

· de reactiesnelheid van een bestuurder op de te besturen onderneming verhoogt;

· inzicht geeft in de relevante aspecten van de omgeving, de business en de impact daarvan op de bedrijfsvoering;

· ondersteuning bij de alignment (afstemming) tussen de business en de IT;

· zichtbaarheid [85] van structuur en functionaliteit;

· hulpmiddel bij een transformatiepad vanuit de bestaande situatie;

· ondersteuning biedt bij een evolutionaire verandering van de onderneming, geen grootscheepse afbraak;

· ondersteuning biedt bij het bouwen op basis van componenten;

· impliciete regels voor ontwikkeling en onderhoud;

· een mechanisme heeft om zichzelf ook te onderhouden;

· architectuur moet toekomstvast zijn, flexibel en toekomstgericht.

3.9 Ingrediënten van het architectuurproces

Vele wegen leiden naar Rome, maar de keuze van de juiste weg hangt af van het vertrekpunt, het vervoersmiddel, de haast en vele andere factoren. Het is de kunst om de verschillende fases die we doorlopen zo zichtbaar en praktisch mogelijk te houden. Het oplossen van architectuurvraagstukken heeft veel weg van het oplossen van een cryptogram. Begin waar het het eenvoudigst is en als je eenmaal een beginnetje hebt, ploeter je stap voor stap verder waarbij elke stap weer het inzicht en de noodzaak verschaft voor de volgende stap.

Het nut van een strakke methode is zeer dubieus [86] . Gezien het grote aantal beïnvloedende factoren, en de verschillende prioriteiten van die factoren in verschillende situaties, is een standaardaanpak waarbij op mechanische wijze een architectuur wordt geproduceerd uitgesloten. Niet onbelangrijke factoren zijn overigens de filosofie en de creativiteit van de architect zelf.

Een raamwerk waarin duidelijk wordt hoe de verschillende aspecten van de architectuur elkaar beïnvloeden is belangrijk.

Ook voor het ontwerp dat, onder een bepaalde architectuur, wordt opgesteld is een grote dosis creativiteit vereist.

3.9.1 Architectuurprocesfaseringen

Ieder architectuurproces is uniek voor de onderneming waarvoor het wordt uitgevoerd. Dit wordt mede bepaald door de rol van architectuur in die onderneming.

Bij het inzetten van bijvoorbeeld een ERP (Enterprise Resource Planning)-pakket, haalt men ook de bijbehorende architectuur in huis. Men is zich hierbij echter vaak niet bewust van de consequenties die daaraan verbonden zijn. Ook wordt zelden getoetst of die ERP-architectuur en de onderliggende concepten wel passen bij de gewenste architectuur en de concepten waaraan de onderneming belang hecht. Het is dus van cruciaal belang om te kijken of een aan te kopen pakket past bij de enterprise architectuur en of de uitgangspunten en principes niet strijdig zijn. Dit geldt m.m. ook voor outsourcing

Een architectuurstudie is gewoon een project, dat betekent dat er voor elke architectuurstudie een aantal generieke voorbereidende werkzaamheden zijn.

· inventarisatie in het eerste gesprek:

Ø aard en scope van de architectuuropdracht;

Ø wie is de opdrachtgever en wat is de financiële ruimte;

Ø wie is / wordt de eigenaar van de architectuur;

Ø aanleiding voor de opdracht (aanzet tot business case);

Ø wie zijn de belangrijkste beslissers bij architecturele vraagstukken;

Ø aanwezig uitgangsmateriaal.

· scope vaststellen met opdrachtgever

· scannen van relevant uitgangsmateriaal en een eventuele verkennende inventarisatie van bestaande situatie

· eerste mental models opstellen

· intakegesprek(ken) bij de belangrijkst stakeholders

· concretiseren van een eerste versie van het plan-van-aanpak

Voor het opstellen van een kaderstellende architectuur (enterprise of domein) zijn er in het algemeen vijf basisstappen:

1 Onderzoek naar de bestaande situatie (architectuurprincipes, as-is situatie, enzovoort).

2 Sessie(s) met topmanagement om missie, visie en strategie te expliciteren.

3 Sessie(s) met meer-directe stakeholders om principes en eisen/wensen boven tafel te krijgen (die geworteld zijn in de business).

4 Kiezen van architectuurconcepten of archifacten en het uitwerken ervan.

5 Sessie(s) met topmanagement ter accordering.

Mogelijke vervolgwerkzaamheden:

Inventarisatie en herbezinning huidige situatie:

domeinen;
architectuurprincipes per domein
(business, informatie/kennis, informatiesystemen) verbijzonderd naar concretiseringsniveau's (contextueel, conceptueel, logisch, fysiek);
stakeholders / concerns / viewpoints per domein;
infrastructuur per domein,
verbijzonderd naar concretiseringsniveau's (contextueel, conceptueel, logisch, fysiek) en bijbehorende SLA's [87] ;
overall infrastructuur op ondernemingsniveau,
verbijzonderd naar concretiseringsniveau's (contextueel, conceptueel, logisch, fysiek) en eventuele SLA's;
overall architectuurprincipes op ondernemingsniveau,
verbijzonderd naar concretiseringsniveau's (contextueel, conceptueel, logisch, fysiek).

Huidige situatie per applicatie binnen de gekozen domeinen

additionele architectuurprincipes;
functionele specificaties en kwaliteitsattributen;
SLA.

Inventariseren van toekomstige gebruiksrollen van de informatievoorziening

soorten gebruikers

· directe en indirecte eigen gebruikers (incl. samenwerkingspatronen)

· klanten

· potentiële klanten

· partners

· informatiezoekers

· aanbieders

de generieke medewerkersrol (architectuurprincipes etc.)
roltypes en viewpoints (architectuurprincipes etc., aanschouwelijke plaatjes)

welke informatie, kennis en applicaties worden ter beschikking gesteld
vormgeving: user interface / navigatiepaden (belevingsaspect)

Inventariseren van de architecture drivers: business, technology, market.

Inventarisatie en herbezinning constructieregels als onderdeel van de architectuur (het drieluik beleving/vormgeving, structuur, constructie)

Inventarisatie product / (web-)service architectuur.
(structuur en belevingsvorm van de service offerings)

Bepalen van visualisatie vormen.

Plaatjes voor de verschillende stakeholders.

Opzetten nieuwe situatie

domeinen, informatiesystemen, infrastructuren etc.

Ontwerpen toekomstige werkomgevingen

werkplektypes
architectuurprincipes van de werkomgeving
specificatie
vormgeving
SLA

Opstellen van mogelijke migratiepaden.

Het is uitermate belangrijk om de werkelijke reden(en) voor het opstellen van een architectuur steeds voor ogen te houden. Maar ook te borgen dat de stakeholders die redenen op het netvlies houden.

Enkele redenen bij een architectuurstudie kunnen zijn:

Moderner corporate imago.
Meer professionele ondersteuning van de medewerkers in opdrachten.
Betere aansluiting op de klant.
Duidelijker samenhang in de systemen.
Uniformering van de (technische) infrastructuur.
Meer optimale supervisie over de outsourcing.
Meer optimale aansturing van de systeemontwikkeling (programma's en projecten).
Efficiëntere systeemontwikkeling.
Beter kunnen incorporeren van nieuwe ontwikkelingen in de informatievoorziening. Ontwikkelingen voortkomende uit te volgen technologie trends, marktontwikkelingen of andere trends
Meer signaleringsmogelijkheden en een betere bestuurbaarheid van de onderneming.

Onderhoud van architectuur vraagt om blijvende aandacht. Zoals al eerder aangegeven, is het werk niet klaar wanneer een architectuur is ontwikkeld. De ervaringen tijdens de realisatie en het operationeel maken van systemen kunnen de oorspronkelijke architectuur immers beïnvloeden. En alleen al om die reden moet een architectuur worden onderhouden. Daarnaast zorgt de continue dynamiek – in zowel de organisatie als ook de technologie – voor aanhoudende veranderingen die in de architectuur moeten worden weerspiegeld. Ook daarom heeft een architectuur onderhoud nodig.

3.9.2 Starten met architectuur

Benoem een enterprise architect en een programma-manager voor het transformatie traject.

Bewaak samenhang en focus in de veranderingen!

Stel een lange termijn architectuur op als richtinggevend instrument.
Realiseer enkele quick wins zowel voor de onderneming als voor de medewerkers.
Lanceer elke maand een nieuw duidelijk verbeter-initiatief.
(dus op de rails gezet).
Etaleer de architectuur-vorderingen op het Intranet, waarbij een ieder commentaar kan geven.
Herontdek de basisregistraties.
Laat de belangrijkste services van de belangrijkste domeinen in kaart brengen. Services, richting de medewerker!
Implementeer dit vervolgens maximaal met employee self service faciliteiten.
Plaats de belangrijkste technology leveranciers ten opzichte van elkaar tegen de achtergrond van een ‘grand design'. En laat hen referentiearchitecturen aandragen.
Voer een globaal adaptiveness onderzoek uit.
Bepaal de ‘fixed' end-to-end processen.
Maak ‘voorschriften en procedures' beter zichtbaar, meer toegankelijk
(de IC [88] functie).

3.9.3 Workshops

Belangrijk bij architectuurtrajecten is een interactieve werkvorm met en tussen de belangrijkste betrokkenen. Het gaat immers niet alleen om het maken van verhelderende plaatjes en het formuleren van structurerende principes, maar het gaat ook om ‘team building'. De belangrijkste stakeholders moeten gezamenlijk achter de nieuwe architectuurschets gaan staan.

Workshops en workshoptechnieken zijn hulpmiddelen om een team of groepsproces een versnelling te geven waardoor informatie sneller of eenvoudiger boven tafel komt. Effectieve teaming geeft de hoogste productiviteitswinst.

Besturing van het architectuurproces, het opstellen en het onderhouden van de architectuur, vindt plaats op basis van stakeholders win-win condities; stakeholders belangen worden in balans gebracht op elk niveau: ondernemingsniveau, systeemniveau en alle mogelijke tussenniveaus.

3.9.4 Maturity van de onderneming en architectuur

De manier waarop een onderneming met architectuur wenst om te gaan, wordt sterk bepaald door de mate waarin die onderneming architectuur een plaats in de eigen organisatie heeft gegeven. Zoals reeds aangegeven, gaat architectuur hand in hand met transformatiemanagement en strategie. Om de mate van volwassenheid van het onderwerp ‘architectuur' in een onderneming aan te geven, zijn er zogenaamde het ‘architecture maturity modellen', zie Han van der Zee, Paul Laagland en Bas Hafkenscheid [1] .

Afhankelijk van de ‘architecture maturity' van de onderneming inzake het onderwerp architectuur zullen ook de processen, om tot een architectuur te komen, anders worden ingestoken.

Een onderneming is niet klaar als het een architectuur heeft. Wat heeft het voor zin als enkele professionals een architectuur maken en er is niemand die daar de vruchten van kan plukken? De onderneming kan een architectuur effectiever toepassen naarmate zij beter de volgende vragen kan beantwoorden:

· Hoe is de cultuur van de onderneming?

· Hoe complex is de besluitvorming ofwel de politiek?

· Hoe gaat topmanagement om met IT?

· Hoe is de informatievoorziening in de organisatiestructuur ingebed?

· Hoe zijn verantwoordelijkheden verdeeld?

· Hoe is de besluitvorming van aanpassingen?

· Hoe complex is het politieke spel? Speelt iedereen het politieke spel ten behoeve van de onderneming of is het contraproductief?

· Waar is IT in de plancyclus gepositioneerd? Direct bij de start of volgende op de business beslissingen?

Als de toestand van de informatievoorziening, de documentatiegraad daarvan en de ‘maturity' van het management met betrekking tot het denken in architectuur onvoldoende is, is het vaak raadzaam om eerst een aantal voorbereidende gesprekken te voeren. Een eerste ronde om een gevoel te krijgen wat de problemen precies zijn en welke oplossingsrichtingen reëel lijken. Dergelijke gesprekken hebben een tweeledig doel. Behalve onderzoek wordt ook getracht het denken in architectuurtermen wakker te roepen.

Uit dergelijke gesprekken [89] blijkt vaak de ‘sense of urgency' bij de belangrijkste stakeholders.

3.10 De rol van referentiearchitecturen

Architectuur zal steeds vaker een verbijzondering zijn van bepaalde algemeen aanvaarde referentiearchitecturen (voorbeeldarchitecturen). Een groot aantal van de principes, regels, richtlijnen en standaarden komt elke keer weer terug in bepaalde probleemsituaties. Daarvoor worden referentiearchitecturen, als een soort superpattern gebruikt. Het is dan de uitdaging en de creatieve kracht van de architect om de referentiearchitectuur te verbijzonderen naar iets eigens voor de onderhavige onderneming.

Het gebruik van referentiearchitecturen zal het opstellen van een architectuur voor een bepaalde onderneming enorm kunnen versnellen. Voorbeelden hiervan zijn architecturen voor de inrichting van de kantoorautomatisering, architecturen voor het gebruik van mobiele flexibele werkplekomgevingen. In een goede referentiearchitectuur is de kennis en de jarenlange ervaring van architecten samengevat. Gelouterd door het gebruik.

Het opstellen van een architectuur die aan alle eisen, wensen en beperkingen van de opdrachtgever voldoet vereist maximale creativiteit. Een aanzet hiertoe hoort in een referentiearchitectuur te worden gegeven.

Er is een grote overeenkomst tussen referentiearchitecturen en patterns.

Elk pattern is een regel die uit drie delen bestaat en die de relatie uitdrukt tussen een zekere context, een probleem en een oplossing.

De context is het geheel van (ruimtelijke [90] ) omgeving en cultuur waarbinnen zich steeds opnieuw problemen voordoen. Een probleem bestaat uit een stelsel van conflicterende krachten die binnen de gegeven context werkzaam zijn. Dit kunnen bijvoorbeeld psychologische, culturele, constructieve of natuurkundige krachten zijn.

De oplossing beschrijft welke (ruimtelijke) configuratie die krachten met elkaar in evenwicht brengt en hoe die configuratie kan worden gerealiseerd. Verder hoort bij ieder pattern nog het verband met andere patterns. Voorbeelden hiervan zijn onder andere toegangspatterns tot netwerken en systemen, ontsluiting van informatie, presentatie van informatie, communicatie tussen elementen, structuren van dataopslag enzovoort.

3.11 Literatuur

[1] Han van der Zee, Paul Laagland en Bas Hafkenscheid (2000), Architectuur als managementinstrument , Ten Hagen en Stam, ISBN: 90 440 0087 X.

3.12 Vragen

1. Waarom is architectuur abstract?

2. Waarom is architectuur een teken van beschaving?

3. Hoe kan architectuur een onderneming ‘corporate 'identity' geven? En hoe zou dat kunnen bij de universiteit?

4. Wat zijn generieke en specifieke aspecten bij architectuur? Geef voorbeelden voor een universitaire instelling.

5. Geef voorbeelden van stabielere, meer voorspelbare delen en minder voorspelbare delen bij de universiteit, vanuit de optiek van architectuur.

6. Waarom heeft elke onderneming haar eigen specifiek architectuur nodig?

7. Waaruit bestaat het ecosysteem van de universiteit? Wat zijn de concurrenten van de universiteit?

8. Geef enkele karakteristiek principes voor de universiteit die afkomstig zijn uit haar ecosysteem?

9. Wat is de missie en visie van de universiteit en concretiseer dat in principes. Welke van die principes leiden tot architectuurprincipes?

10. Welke strategie heeft de universiteit en hoe bepaalt dat de architectuur?

11. Noem enkele technologische ontwikkelingen die het functioneren van de universitaire gemeenschap de afgelopen 25 jaar significant hebben veranderd.

12. Van welke technologische trends verwacht je dat die het opleidingsgebeuren danig zullen veranderen? En welke zullen het onderzoeksgebeuren danig veranderen?

13. Is de universiteit te beschouwen als een high-tech onderneming? Onderbouw het antwoord? En wat zijn de consequenties van dat antwoord?

14. Welke rationalisaties kunnen bij de universiteit worden doorgevoerd waardoor de automatisering eenvoudiger wordt?

15. Welke handmatige taken kunnen op de universiteit worden weggeautomatiseerd?

16. Wat zijn de belangrijkste stakeholders van het onderwijsdomein? En geef daarbij aan welk beslissingsniveau zij hebben.

17. Noem enkele doelstellingen van een architectuurstudie.

18. Wat is het verschil tussen een model en een metamodel?

19. Wie is de eigenaar van de architectuur bij de universiteit?

20. Heeft de universiteit een expliciete houtskoolschets of is dit onderdeel van beleidsnotities?

21. Welke architectuurdeliverables zijn bij de universiteit aanwezig. Zijn ze actueel?

22. Welke verschillende vormen van architectuurvisualisaties worden op de universiteit onderkend? Geef daarover een waardeoordeel in termen van stakeholder-vriendelijkheid.

23. Noem enkele weerstanden op de universiteit tegen het opstellen van een architectuur.

24. Waarom zou het raadzaam zijn om aan het einde van een architectuurtraject een second opinion te laten uitbrengen?

25. Som de vijf belangrijkste kenmerken op van een waardevolle architectuur voor de universiteit. Geef een onderbouwing van je prioritering.

26. Waarom is het belangrijk de architectuurprincipes van een te kopen standaardpakket dan wel de architectuurprincipes van een externe provider in geval van outsourcing te kennen?

27. Waarom is het belangrijk de werkelijke reden(en) voor het opstellen van een architectuur expliciet te maken?

28. Waarom zijn quick wins belangrijk?

29. Noem enkele quick wins die met architectuur op de universiteit zouden kunnen worden behaald.

30. Welke basisregistraties zijn op de universiteit aanwezig?

31. Welke self service faciliteiten zouden op de universiteit zinvol kunnen zijn.
Onderbouw het antwoord.

32. Welke karakteristieke bedrijfscultuuruitgangspunten heeft de universiteit die van invloed zouden kunnen zijn op de architectuur?

3.13 Oefeningen

1. Maak een schets van een generieke dag in het leven van een student. Geef daarbij aan welke technologieën in geding zijn en welke architectuurprincipes worden vereist.

2. Bestudeer de scriptie van Michel Houben en zet een eenvoudig flowchart op voor een klein architectuurtraject.

4. De architect in de digitale wereld

trefwoorden: soorten, taakinhoud, rol, positie in de organisatie, profiel, vaardigheden, werkprincipes, architectuurteam, architectentitel, architectuurscholen, honorarium

4.1 Inleiding

Ondernemingen staan voor ingewikkelde uitdagingen [91] in een snel veranderende wereld. Uitdagingen die zeer complex zijn, maar beheersbaar worden door toepassing van de juiste vakdeskundigheid. Er is een nieuwe, meer praktische, discipline in de consultancy aan het ontstaan om de essentiële vragen op het juiste moment expliciet te maken: de architect [92] .

De architect is de intermediair tussen de belevingswereld van de onderneming met al haar belanghebbenden enerzijds en de realisatiemogelijkheden anderzijds. Deze bemiddelende rol vraagt niet alleen een hoog abstractievermogen, maar tevens de attitude goed te kunnen luisteren naar wat er werkelijk nodig is.

Er is zeer veel geschreven over de architect. Voor een encyclopedische inspiratie over de fysieke architect wordt verwezen naar een compilatie door Spiro Kostof [1]. Marc en Laura Sewell [2] hebben een aardig boek geschreven over het beroep van de software architect dat voor een groot deel is te generaliseren tot de architect in de digitale wereld. Voor een beschrijving van rol en taak van architecten in de digitale wereld wordt verwezen naar de vele bijdragen op de Landelijk Architectuur congressen, bijvoorbeeld [3] en [4]. In Nederland zijn de digitale architecten verenigd in het NAF (Nederlands Architectuur Forum; www.naf.nl ) en het GIA (genootschap voor informatiearchitecten; www.gia.nl ).

4.2 Soorten architecten

Er zijn vijf soorten digitale a rchitecten [93] te onderkennen die elk weer hun eigen specialismen kunnen hebben. Wij onderscheiden de kaderzettende [94] architect en wat in de Angelsaksische literatuur wordt aangeduid met ‘solution-architect' [95] , of systeemarchitect [96]

kaderzetted

· de enterprise-architect

· de domeinarchitect

oplossingsgericht

· de applicatie-architect

· de technische-infrastructuur-architect

· de werkruimte-architect

De scope van het werkterrein van de enterprise-architect is de onderneming in zijn geheel, de relatie met haar ecosysteem en de opdeling in domeinen. Het zwaartepunt van zijn werkzaamheden zal liggen in het informatiegebeuren [97] . Een beschouwing van de onderneming kan immers niet zonder een beschouwing van de informatie- en communicatiepatronen, die nodig zijn om de onderneming optimaal te laten functioneren. De enterprise-architect onderzoekt welke informatie waar en wanneer beschikbaar dient te zijn voor ondersteuning van de bedrijfsproducten, -diensten, -processen en -organisatie. De informatieafhankelijkheden tussen de verschillende activiteiten maakt de onderneming bestuurbaar en legt daarmee de dynamiek van de business bloot. Een enterprise architect dient dus het wezen van de besturing van een onderneming te doorgronden: welke rollen hebben welke informatie nodig. Hiervoor heeft hij een goed begrip nodig van het type van de onderneming. De uitdaging voor de enterprise-architect is te ontdekken wáár beslissingen worden genomen die essentieel zijn voor het waardecreërend vermogen van de onderneming. Vervolgens zal hij architectuurprincipes definiëren, om zich ervan te verzekeren dat informatie op effectieve en efficiënte wijze op de juiste plek komt. Een architect zal daarbij mechanismen die toegang tot informatie mogelijk maken op elkaar moeten afstemmen en faciliteiten ontwerpen die een cultuur stimuleren die bevorderlijk is voor gewenst gedrag.

Vanuit missie, visie en (concurrentie)strategie zal hij een architectuur opstellen die de samenhang van de onderneming ondersteunt. Natuurlijk zal hij zich daarnaast ook bezighouden met het ondernemingsbreed opstellen van principes in de andere architectuurwerelden, zoals het bedrijfsgebeuren, de applicaties en de infrastructuren.

De domeinarchitect zal zich bezig houden met het opstellen van een architectuur voor een specifiek domein. Het zwaartepunt van zijn werkzaamheden zal liggen in het bedrijfsgebeuren [98] . Deze functionaris houdt zich bezig met een beschouwing van de producten, de diensten, de bedrijfsprocessen behorende tot het domein inclusief haar organisatie, maar dat alles voorzover als nodig is voor het opstellen van een digitale architectuur voor dat domein.

Een domeinarchitect helpt daarom mee bij het ontwerpen van de ‘business'. Hij beoordeelt de realiseerbaarheid van een businessconcept en geeft zijn adviezen over hoe een domein in de steigers kan worden gezet. Zijn vak is de business begrijpen. Vanuit dat begrip van die business en gebaseerd op businesskennis, ervaring en ‘best practices' definieert hij de architectuurprincipes. Op basis van deze principes schetst (visualiseert) hij de verschijningsvorm van het betreffende domein.

Naast consultancyvaardigheden behoort de domeinarchitect te beschikken over specifieke branchekennis, kennis van producten en distributiekanalen plus kennis en ervaring over het dynamische effect van nieuwe technologische ontwikkelingen voor dat specifieke domein.

De applicatiearchitect stelt de architectuurprincipes op voor applicaties op enterprise-niveau, op domeinniveau en op het niveau van een individuele applicatie. Op het niveau van de individuele applicatie zal de architectuur bestaan uit een maatgesneden deelverzameling van de principes die gelden op de kaderzettende niveau's. Door nieuwe inzichten in het vakgebied van de software engineering, nieuwe technologische mogelijkheden, veranderende gebruikerswensen en door ervaringen uit de projecten waarin individuele applicaties worden gebouwd, zal een eventuele bijstelling plaatsvinden van de principes op de kaderzettende niveau's.

De technische-infrastructuur-architect stelt de architectuur op van de technische infrastructuur zowel op het niveau van de gehele onderneming, mede in relatie tot het ecosysteem, als de specifieke toevoegingen per domein. Hierbij gaat het om de architectuurbeschouwingen over de toepassing van IT in de infrastructuren. Dit behelst het hele gebied van servers, storage, connectivity, operating systems en middleware. De verwachting is dat er een grootscheepse sanering komt in de grote verscheidenheid van componenten op dit gebied. Als gevolg daarvan zal de inhoud van deze functie drastisch vereenvoudigen.

De werkruimte-architect creëert de digitale werkruimte voor de verschillende interne en externe rollen van de onderhavige onderneming. In de werkruimte komt voor de gebruiker alle digitale functionaliteit te samen, daarom zal hier de beleving van de gebruiker een hoofdrol spelen. Een effectief en efficiënt gebruikt van alle IT-middelen wordt sterk bevorderd door een juist ingerichte digitale werkruimte.

Het is belangrijk dat er een separate security-architectuur wordt opgesteld, omdat security een holistisch karakter heeft. Echte security is immers ‘end-to-end'; dus van het business niveau, via het niveau van de applicaties tot in de infrastructuur en weer terug via de applicaties, naar het business niveau. Echte security kan slechts worden verkregen door het architectureel te benaderen, waarbij de architect [99] security-engineers raadpleegt dan wel inschakelt.

Jammer genoeg lijken bovenstaande zaken langzamerhand allemaal aparte disciplines te worden.

Maar de werkelijk goede architecten in de fysieke wereld hielden zich echter bezig met het totale scala. “Bouwen is universeel in de zin van ‘alles omvattend'”, zo stelt prof. ir. Jan Brouwer in zijn afscheidscollege, getiteld ‘The making of Architecture' [5] op p116. “De ontwerper dient zich bezig te houden met het gehele proces van programma tot en met hergebruik. Dat heeft tot consequentie dat de architect een aantal generalistische trekjes vertoont. De bemoeienis gaat, zoals Bakema al zei,'Van Stoel tot Stad'. Als deze uitspraak wordt aangepast aan het fin de siècle zou je zeggen: 'Van Zitje tot City'.”.

Een goed voorbeeld van deze universele opvatting was de Nederlandse architect Gerrit Rietveld. Rietveld vestigde zich in 1911 als zelfstandig meubelmaker in Utrecht in de voetsporen van zijn vader. In 1919 breidde hij zijn creatieve vormgevende talenten uit tot het beroep van architect. Na een aantal verbouwingen, ontwierp hij in 1924 zijn eerste huis, het later zo beroemde Schröderhuis in Utrecht. Het meubelmaken bleef echter een van zijn belangrijke passies, hetgeen resulteerde in een hele serie wereldberoemde rood-blauwe stoelen. Het interieur was (als de meest directe belevingswereld) vaak het startpunt van zijn totale ontwerpproces.

4.3 Taakinhoud

Een digitale architect inventariseert de wensen en eisen, die de omgeving oplegt en de gebruikers, de opdrachtgevers en/of de belangengroepen [100] stellen. Dit vertaalt de architect vervolgens in een globaal, meestal conceptueel ontwerp voor de ontwerpers en de technisch specialisten. Zij moeten immers het gedetailleerde ontwerp en de bouw uitvoeren. Tot welk detailleringsniveau de architect moet gaan, is wat vaag.

Er is een wezenlijk verschil in de rol van een kaderzettende architect als een enterprise architect of een domeinarchitect enerzijds en een systeemarchitect anderzijds. Laatstgenoemde stelt de architectuur op van een specifieke applicatie of de architectuur van een infrastructuur. Beiden hebben overigens wel een bemiddelende rol tussen de stakeholders. De kaderzettende architect heeft daarentegen een meer planningsachtige rol, terwijl de systeemarchitect een concrete architectuur moet neerzetten waarmee de bouwer van het artefact eenduidig uit de voeten kan.

Bovendien hebben kaderzettende architecten bij een onderneming meestal stafachtige functies, terwijl systeemarchitecten meestal in de operationele business unit zitten, dicht bij de operaties.

Een architect houdt zich dus in eerste instantie bezig met de grote lijnen van een ontwerp, en alleen met details als deze essentieel zijn voor de performance van de informatievoorziening waarvoor die architectuur wordt vastgesteld. Daarnaast vervult de architect een bemiddelende rol tussen alle stakeholders.

De architect levert modellen. Het gaat daarbij om:

· modellen, die de verschijning en het gedrag van een artefact visualiseren zoals de klanten en gebruikers het zullen gaan ervaren. Zij moeten met deze modellen kunnen beoordelen of de toekomstig architectuur zal voldoen aan hun vereisten;

· voorschrijvende modellen gebaseerd op principes van de architectuur, omtrent de structuur en de samenhang en samenwerking tussen de verschillende delen;

· modellen om de implementatie van de andere kwaliteitsattributen te kunnen beoordelen, zoals: security, performance, kosten, business benefits.

4.4 Rol & plaats van een architect

De rol en plaats in de onderneming is sterk afhankelijk van het soort architect.

4.4.1. Werkrelatie van de enterprise architect in de top van de onderneming

De Corporate Architectural Officer (CAO) is een enterprise architect op het hoogste niveau en hoort in feite de ‘slimme' denker te zijn die het overzicht over de onderneming bewaakt. Hij behoudt het overzicht over de samenhang tussen onderneming en de IT, vastgelegd in een aantal uiterst eenvoudige schema's. Deze schema's fungeren voor de boardroom als een atlas om beslissingen te kunnen overzien en de eventuele impact te kunnen inschatten. Voor de rest van de onderneming dienen die schema's als referentiekader.

De Corporate Executive Officer (CEO) is de hoogste strateeg in de onderneming die de architectuur gebruikt als een hulpmiddel om het ‘willen' (de strategie) en ‘kunnen' (de realisatieruimte) ten opzichte van elkaar te kunnen afwegen tegen de achtergrond van de financiële impact. Hij zal veelvuldig met de CAO afstemmen om dat ‘kunnen' te kunnen aanpassen of oprekken.

De Corporate Information Officer (CIO) is de hoogste procesbewaker in de IT-functie. Hij stuurt de programmamanagers en de IT-lijnafdelingen aan. Hij zal met de CAO regelmatig overleggen over de realisatiestrategieën van het transformatieproces.

De inzet van IT komt bij een onderneming pas echt tot zijn recht als deze drie functionarissen (CEO, CIO en CAO) goed op elkaar zijn ingespeeld, waarbij de CAO functioneel zijn eigen verantwoordelijkheid heeft en als zodanig aan specifieke besprekingen in de boardroom dient deel te nemen.

Nog te vaak zien wij echter dat de CAO wordt beschouwd als het slimste jongetje in de klas, die netjes in een kamertje apart wordt opgeborgen. De CAO behoort echter, ten behoeve van een deugdelijke aanpak in de planningscyclus van de onderneming op bestuursniveau te worden opgenomen.

Vaak zien we nog een andere belangrijke functionaris rond lopen in de top van IT-intensieve ondernemingen, de Corporate Technology Officer (CTO).

Voor product- of dienstinnovaties of voor optimalisatie in de bedrijfsprocessen is een creatieve CTO uitermate belangrijk. Het is daarom essentieel dat de CTO regelmatig met de hoofdarchitect de nieuwste technologische mogelijkheden voor de onderneming doorneemt. De architect kan er daardoor voor zorgen dat die nieuwe technologieën, die van belang zijn of van belang kunnen worden voor de onderneming, kunnen worden geïncorporeerd in de architectuur.

De rollen van CTO en CAO zijn echter uit hoofde van functiescheiding niet met elkaar in één persoon te verenigen.

4.4.2. Systeemarchitect

Op systeemniveau speelt de architect een bemiddelende rol tussen de opdrachtgever (meestal een business unit manager) en de bouwer of leverancier.

Systematisch gezien bestaat de taakinhoud van de architect uit drie onderdelen:

1. De architect representeert alle stakeholders (belanghebbenden):

alle klantgroepen;
interne gebruikers en eindgebruikers;
indirecte gebruikers;
het toekomstige onderhoudspersoneel;
het toekomstige exploitatiepersoneel;
regelgevers,

en is regisseur van het beeldvormingsproces.

2. Hij maakt en bewaakt het integrale concept.

3. Hij zorgt voor een goed gedefinieerde opdracht richting de uitvoerder.

Belangrijk daarbij is dat hij een vertrouwensrelatie onderhoudt met de opdrachtgever.

Meer dan vijftig procent van de inspanning van de architect bestaat uit waarnemen en daar ligt tegelijk ook het principiële verschil met de ontwerper. De ontwerper gebruikt zijn creatieve vermogens en vakdeskundigheid om binnen een strak gedefinieerd eisenpakket een aantrekkelijke en bruikbare vormgeving te vinden. De architect bevindt zich in het traject daarvoor.

De belangrijkste rol van een systeem-architect is die van bemiddelaar tussen opdrachtgever en uitvoerder.

Naar de opdrachtgever en mogelijke eindgebruikers geeft hij de mogelijkheden en beperkingen aan, vertaalt de gebruikerswensen naar een bouwconcept, ontwerpt volgens de architectuur en visualiseert het mogelijke eindproduct.

Naar de uitvoerende(n) vertaalt hij de eisen en wensen van opdrachtgever in concrete specificaties, onderhandelt hij over eisen en wensen versus beperkingen en kosten en bewaakt veelal de uitvoering met betrekking tot de architectuur en het resultaat van het product [101] . (in tegenstelling tot het proces).

4.4.3. De systeemarchitect als bouwmeester

Een systeemarchitect moet de gebruikers kunnen begrijpen en hun verwachtingen kunnen vertalen naar een goed ontwerp. Ook moeten de ontwerpen van de architect begrijpelijk zijn voor de detailontwerpers. Hij moet dus de ontwerptaal en hun problemen kennen. Eigenlijk moet de architect zijn architectuur helemaal doorspreken met de detailontwerper óf ten minste in het begin van het detailontwerp meelopen in het project.

Net als in de bouwwereld komt het regelmatig voor dat de architect niet alleen de architectuurbeschrijving maakt, maar dat hij ook tijdens de uitvoering als supervisor aan het te realiseren systeem blijft verbonden. Soms komen bouwers met slimme oplossingen die goedkoper zijn, maar net niet helemaal aan de architectuur voldoen. Hierbij kan het zo zijn dat een financieel gewin op korte termijn duur komt te staan op de middellange termijn. Het getuigt daarom van professionaliteit als elke architecturale beslissing, die een bouwer wil wijzigen, eerst aan de architect wordt voorgelegd.

Naast deze begeleidende rol heeft een architect ook een controlerende rol. Tijdens de implementatie, het deployment en het onderhoud van een systeem dat onder architectuur wordt ontworpen verifieert een architect of de architectuur wordt gerealiseerd zoals ze bedoeld is.

4.4.4.Gemeenschappelijk

Resumerend zit er een gemeenschappelijke noemer achter bovenstaande soorten architecten:

· ondersteuning en visualiseren van de strategievorming in de business;

· structurering van de klantwensen;

· communicatie met de stakeholders, zowel in de business als in de IT;

· wegen van de verschillende belangen;

· bepalen van oplossingsalternatieven;

· creëren van een bruikbaar en haalbaar ontwerp;

· kiezen van oplossingen;

· managen van kwaliteit;

· managen van complexiteit;

· risico's beperken.

Alle soorten van architecten in de digitale wereld vechten tegen ‘complexiteit'. De wereld wordt steeds complexer, steeds minder bestuurbaar. Een van de belangrijkste activiteiten die een architect verricht is ‘simplificeren'. Maar het is ook de bedoeling dat daar een leefbare wereld uitkomt. Bij een goede architect staat de mens centraal. Een architect dient daarom drie vaardigheden te beheersen. Hij moet zuiver kunnen denken en structureren, hij moet zich kunnen inleven in gebruikers en dus een aantrekkelijke digitale wereld kunnen ontwerpen, en hij moet voldoende verstand hebben van constructie.

Om de doelen van de stakeholders te borgen, heeft een architect niet alleen een holistische kijk en structurerende kwaliteiten nodig, maar ook een grote mate van creativiteit plus het vermogen te inspireren en te mobiliseren. Zo kan de architect het nieuwe geweten van het bedrijf zijn.

4.5 Profiel & vaardigheden

Voordat we het profiel van een goede architect schetsen, kijken we eerst naar wat de grondlegger van de westerse (fysieke) architectuur, Marcus Vitruvius Pollio (kortweg Vitruvius) hierover heeft geschreven. Vitruvius was Romeins bouwmeester ten tijde van keizer Augustus. In zijn ‘architectura' [6], een lijvig epistel van tien boekwerken, komen zeer uiteenlopende zaken aan de orde zoals de bouw van woningen en tempels, de aanleg van steden, maar ook de constructie van waterleidingen, de vervaardiging van uurwerken en oorlogsmachinerieën. Het is het oudste systematische werk over architectuur dat wij in de westerse beschaving kunnen achterhalen. Vitruvius verkreeg zijn informatie deels uit eigen ervaring en voorts borduurde hij voort op Griekse bronnen die inmiddels alle verloren zijn.

Vitruvius omschrijft in de eerste eeuw voor onze jaartelling de ideale architect als volgt:

‘de ideale architect is een geleerd schrijver, een wiskundige, bekend met geschiedkundige stijlen, toegewijd aan de filosofie, vertrouwd met muziek, niet onbekend met de geneeskunde ,onderlegd in de repliek van de rechtspraak, vertrouwd met sterrenkunde en astronomische voorspellingen.'

Ik vraag mij af of de gemiddelde fysieke architect hier nog wel aan voldoet?

Als we de uitspraak van Vitruvius omzetten naar een wat moderner taalgebruik zou gezegd kunnen worden: ‘een fysieke architect moet goed kunnen luisteren en formuleren, gevoel voor stereometrie en ruimtelijke verhoudingen hebben, gevoel voor maat, orde en harmonie hebben, gevoel tonen voor factoren die het menselijk welzijn beïnvloeden, bekend zijn met de trends uit de geschiedenis, en een praktisch filosoof zijn.'

Met bovenstaande wijze inspiratie zou het profiel van een goede architect in de digitale wereld als volgt omschreven kunnen worden:

1. hoog abstractievermogen (kunnen inzoomen en uitzoomen, naast een goed opgebouwde principe-boom);

2. creatief (business creatief en human interface creatief);

3. goed ontwikkeld voorstellingsvermogen;

4. zakelijk gevoel voor de businessbehoeften;

5. nuchtere visie op technologie (ongevoelig voor hypes);

6. subtiel gevoel voor organisatiecultuur;

7. helder kunnen formuleren [102] ;

8. kunnen luisteren (inlevingsvermogen) en presenteren;

9. gevoel voor menselijke maat;

10. veel geduld.

Natuurlijk is de benodigde creativiteit voor een enterprise-architect wezenlijk anders dan de creativiteit voor een applicatiearchitect.

Een fysieke architect is de specialist in wooncreativiteit. De digitale architect gebruikt zijn creativiteit enerzijds voor het slim toepassen van allerlei technologische mogelijkheden, anderzijds zal hij in zijn rol van ontwerper aantrekkelijke vormen creëren.

De ideale digitale architect beheerst drie belangrijke bekwaamheden:

· Met de consultancybekwaamheid helpt de architect de klant in het beantwoorden van de vraag: wat heb ik werkelijk nodig? Vaak is de opdrachtgever of gebruiker zich daar niet voldoende van bewust.

· In de rol van architect helpt de architect de klant met de vraag: hoe moet het artefact eruit gaan zien, zowel qua structuur als qua beleving? Het is zijn opgave om de structuur af te beelden op mogelijke belevingen [103] .

· Met zijn engineeringkennis helpt de architect de klant met de vraag: waarmee dient het artefact te worden gerealiseerd?

Zwart-wit gesteld moet de architect dus enerzijds met zijn consultancyvaardigheden voorkomen dat de klanten en hun gebruikers een luchtkasteel wensen. Anderzijds moet de architect met zijn engineeringkennis zien te voorkomen dat de bouwer er een kaartenhuis van maakt.

4.5.1. Architect versus consultant

Consultant en architect zijn verschillende rollen. Een echte consultant wordt primair gezien als een raadgever. Qua persoonlijke vaardigheden beschikt de consultant over sterke communicatieve en sociale eigenschappen en legt hij gemakkelijk contact. De architect dient als extra nog te beschikken over sterke analytische en conceptuele eigenschappen. Hij kan zaken structureren en integreren (stijl, functie en ontwerp), zaken terugbrengen tot de essentie en daar in praktische zin over communiceren.

4.5.2 Architect versus IT-engineer

Architecten volgen een ‘top down' benadering op basis van inzicht en overzicht over het geheel. Zij hebben dan ook een holistische visie op wat zij moeten creëren en leggen een sterke nadruk op de gevoelswaarde van hetgeen zij maken, de beleving dus.

IT-engineers [104] volgen een ‘bottom up' benadering. Zij verzorgen vanuit product- en oplossingskennis een deeloplossing binnen een groter geheel. Dit gebeurt dus veel minder vanuit een architectuur en meer vanuit een constructie- of engineeringbenadering. Hierbij is vervolgens de eigen creativiteit beperkt tot de invulling binnen de kaders van de gewenste oplossing, zoals aangegeven door de architect.

Een architect staat dus voor het grote geheel en de omgeving. Engineers geven vervolgens invulling aan vraagstukken op het gebied van beveiliging, software oplossingen, pakkettoepassingen, infrastructurele voorzieningen. Dit alles binnen de uitgangspunten, principes en grenzen die de architect heeft aangegeven.

Behalve het verschil in generieke en specifieke benadering tussen beide disciplines, is er ook een sterk verschil in karakter, persoonlijkheidskenmerken en ‘soft skills'.

Architecten moeten een totaaloverzicht hebben, de samenhang kunnen bewaken en in staat zijn het proces te managen of te begeleiden, al dan niet in nauwe samenwerking met een transformatiemanager. Dit vereist, naast kennis en kunde van de ondernemingen, branches en markten, ook kennis van de technologische mogelijkheden en de haalbaarheid ervan in een bepaalde situatie. Ook moet de architect, eventueel samen met de transformatiemanager, de haalbaarheid van een traject toetsen in het licht van de organisatiecultuur, volwassenheid van de organisatie en de aanwezige kennis en kunde.

Dit zijn dus totaal andere vaardigheden dan die een goede IT-engineer bezit. Die wordt immers aangesproken op zijn deskundigheid op een bepaald gebied. De IT-engineer moet zijn deskundigheid kunnen etaleren binnen de context van een groter geheel, waar meerdere IT-engineers aanwezig zijn met verschillende deskundigheden. Dit betekent dat de IT-engineer moet kunnen samenwerken met andere IT-engineers en moet kunnen communiceren met anderen op het grensvlak van zijn eigen deskundigheid. Hierbij is kennis van de raakvlakken naar andere disciplines vanzelfsprekend een voorwaarde.

Het fundamentele verschil in benadering tussen een architect en een engineer wordt typerend weergegeven door het volgende citaat van Jaap van Rees: ( www.euronet.nl/~jaapvanrees ).

‘Tijdens het bouwen van ons huis ging ik een paar keer per week kijken op de bouwlocatie. Op een dag was er een metselaar bezig twee muurtjes te bouwen, van de vloer tot aan het plafond, op een plek waar ik hooguit een muurtje op kniehoogte had verwacht. Dat leidde tot een discussie met achtereenvolgens de uitvoerder, vervolgens de aannemer en ten slotte ook de architect. De tekening bleek voor verschillende interpretaties vatbaar. Daardoor stond ik dus op een gegeven moment met de aannemer en de architect over de plattegrond van ons huis gebogen. Op dat moment werd mij duidelijk dat architect en aannemer met behulp van die tekening met elkaar communiceren, over hetzelfde huis, maar in die tekening iets heel anders lezen. De aannemer kijkt naar de zwarte strepen, want dat zijn de muren en vloeren die hij moet bouwen. Alles daartussen is voor de aannemer lucht en dat kost niets. De architect kijkt naar de witte vlakken. Dat zijn de ruimten, die hij heeft ontworpen. Ruimten, waarin wij zouden gaan leven. Vanuit het ruimtelijk denken van de architect waren de twee muurtjes en de kast, die daartussen zou komen, een vreselijke verstoring van de ruimtelijke beleving. Onvoorstelbaar dat iemand daar ook maar aan had kunnen denken.'

4.5.3. De enterprise-architect

De enterprise-architect is het geweten van de onderneming. Zijn aandachtsveld is het gedrag, de structuur en de transformatie van de onderneming. Om hier goed in te kunnen functioneren, heeft de architect de volgende vijf vaardigheden:

1. goed inzicht in de invloed die nieuwe wetmatigheden uit het ecosysteem hebben op de onderneming;

2. creatief talent voor interessante mogelijkheden die voortkomen uit nieuwe technologieën;

3. open oog voor de impact die nieuwe wetmatigheden hebben op de verschillende spelers, zoals werknemers en aandeelhouders;

4. kennis in het gebruik van coördinatiemechanismen;

5. een goede beheersing van visualisatie en communicatie.

4.6 Werkprincipes

Een architect heeft zelf ook bepaalde leidende principes volgens welke hij zijn werk uitvoert. Wij gaan uit van de volgende zeven werkprincipes:

1. De omgeving, het ecosysteem, is het startpunt.
De inrichting van een onderneming is verschillend als dezelfde doelen in een andere omgeving of context worden geplaatst. De missie en concurrentiestrategie bepalen welke zaken uit de omgeving relevant zijn. Een verandering van concurrentiestrategie kan een andere inrichting van de onderneming vereisen.

2. De business strategie is leidend.
De missie en visie bepalen de vorm van de onderneming. De visie over de context, het ecosysteem, en de concurrentiestrategie bepalen hoe op de meest effectieve wijze de businessdoelen kunnen worden bereikt.

3. Een bruikbare architectuur is toekomstvast en onderhoudbaar.
Een architect houdt dus rekening met de mate waarin de onderneming moet reageren op verstoringen van buitenaf (uit het ecosysteem) en van binnenuit. Een verstoring van buitenaf kan zijn een nieuwe technologische ontwikkeling, een overheidsmaatregel of een tactische zet van een concurrent. Een verstoring van binnenuit kan betrekking hebben op het uit de hand lopen van natuurlijke spanningen die in de onderneming zijn ingebouwd, of op een technische storing van het netwerk.

4. Een architect houdt rekening met de onderlinge afhankelijkheid tussen de architectuurgebieden: business, informatie, applicaties en technische infrastructuur. Verandering in het ene gebied heeft hoogst waarschijnlijk consequenties voor een ander gebied.

5. Bij de beschrijving van een architectuur houdt de architect rekening met onderlinge samenhang tussen de verschillende abstractieniveaus contextuele, conceptuele, logische en het fysieke niveau. Verandering in een van de niveaus werkt door in de inrichting van het aangrenzende niveau. De architect van het Sydney Opera House vertelt treffend dat alles in het ontwerp rekening houdt met de wens om mensen van de werkelijke wereld in een fantasiewereld te brengen. Er zijn dus veel disciplines bij betrokken. De beste manier om te zorgen dat het primaire architectuuridee consistent doorwerkt, is het opbouwen van een gemeenschappelijke architectuurvisie op de toekomst en deze consequent door te vertalen in de verschillende abstractieniveaus.

6. Een architect leidt een proces waarbij de stakeholders met elkaar één set van principes overeenkomen en deze met elkaar delen [105] . Concerns van stakeholders worden gedeeld en meningen geformuleerd. De principes geven hun richting bij de onderlinge communicatie over deze concerns. Het visualiseren en onderhouden van de principes is een grote uitdaging, maar absoluut noodzakelijk in meer complexe ondernemingen.

7. De architect beschrijft alleen wat algemeen geldig is voor een effectieve operatie. Hij zal dus alleen de concerns van stakeholders behandelen die een relatie hebben met andere stakeholders of direct met de doelen van de onderneming.

Belangrijk voor architecten is research, hetzij zelf verricht hetzij ingekocht bij een extern bureau. Research moet plaatsvinden op het gebied van:

· mogelijke wijzigingen in de marktomstandigheden;

· mogelijke wijzigingen in het klantengedrag;

· wijzigingen in de mogelijkheden van de technologie.

4.7 Architectuurteams

Het spreekt voor zich dat een architect nooit in zijn eentje alle niveaus en aspecten van de architectuur voor een complexe situatie beheerst. Toch moeten alle aspecten en niveaus uiteindelijk een goede balans en samenhang vertonen in de opgestelde architectuur. Dat is de reden dat er architectuurteams worden samengesteld. Gecombineerde architectuurteams waarin verschillende disciplines zijn vertegenwoordigd, vormen de basis voor een succesvol architectuurtraject. Want zonder voldoende ondersteuning van de diverse disciplines zijn uitvoering, acceptatie en implementatie van de resultaten niet goed mogelijk.

Een dergelijk team bestaat uit een mix van deskundigen, afhankelijk van de plaats en de scope van het onderhavige probleem. Bij het samenstellen van de teams is behalve de juiste deskundigheid ook de juiste chemie in het team van essentieel belang.

Enkele benodigde deskundigheden zijn: verschillende soorten architecten, ontwerpers, arbeidskundigen, AO [106] specialisten, infrastructuur engineers, usability consultants, ergonomen, user interface experts, SLA-experts, security experts, governance deskundigen.

Een team heeft een managing-architect nodig met volwassen leidinggevende capaciteiten. Deze functionaris wordt wel eens aangeduid met de term ‘lead' architect of principal architect, hij dient tevens zelfstandig opdrachten te kunnen verwerven binnen de onderneming en met de klant daarover te kunnen onderhandelen. Omdat er veel dient te worden gevisualiseerd in het architectuurproces, naast de wat meer formele afbeeldingen, is het aan te bevelen professionele cartoon-artiesten in te huren.

Aangezien onder architectuur ontwikkelen nog steeds niet vanzelfsprekend is, moet er nog het nodige evangelisatiewerk worden verricht. Daarom verdient het aanbeveling ook een architectuurpromotor in het team op te nemen: iemand die de architectuur ‘aan de man brengt' en die bovendien beschikt over pr-talenten en daar ook de ruimte voor krijgt.

Tijdens het opstellen van de architectuur wordt vaak uitgebreid nagedacht over de structuren, principes en uitgangspunten waaraan die architectuur moet voldoen. Het maken alleen is echter onvoldoende als niet ook geborgd wordt dat de architectuur onderhouden kan worden. Grote ondernemingen richten daarom eigen architectenbureaus op, die in staat zijn ondersteuning te bieden aan het management in samenhang met programmamanagement, strategie en planning.

4.8 Vorming van een architect

4.8.1 Herijken van de rollen in de IT

Bij het schrijven van software ontstond eerst het beroep van programmeur. Deze deskundige zorgde op vrij introverte wijze dat de computer (toen nog mainframe geheten) deed wat die programmeur in zijn hoofd had. Toen bleek dat die computer veel grotere en complexere taken kon ondersteunen, werd de hoeveelheid te schrijven programmatuur zelf ook groot en complex. Om het een en ander te structureren ontstond het beroep van technisch ontwerper [107] .

Vervolgens werd het bestaan van de eindgebruiker onderkend. Men werd zich expliciet bewust dat het uiteindelijk ging om die eindgebruiker. Toen ontstond het beroep van functioneel ontwerper, een ontwerper die samen met die eindgebruiker probeerde te ontdekken wat in de praktijk werkelijk nodig was en suggesties deed wat betreft de vormgeving.

De programmeur, de technisch ontwerper en de functioneel ontwerper waren hiërarchisch gesproken allen keurig ingedeeld in de afdeling automatisering of zaten bij een ‘software house'. Zo ontstond een tweedeling ‘opdrachtgever versus ontwikkelaar', waarbij de ontwerper bij de ontwikkelaar in één ruimte zat.

Nu de automatisering volwassen wordt, zou het goed zijn deze functiescheiding radicaal te herzien. Er zijn in feite vier hoofdberoepen, te weten: architect, ontwerper, bouwer en beheerder. Deze laatste laten we hier even buiten beschouwing, omdat dit minder relevant is in de plaatsbepaling van de architect.

De architect brengt de toekomstige belevingswereld van de (eind-)gebruiker in beeld. De cultuur in een onderneming is daarbij uitermate belangrijk. De functioneel ontwerper, die vroeger samen met de eindgebruiker probeerde te ontdekken wat nodig was, zorgt dat de architectuureisen systematisch doorvertaald worden naar de systeemfunctionaliteit. En de engineer en programmeur, moeten bouwen wat het ontwerp voorschrijft.

4.8.2 Scholing

Een architect staat niet op uit de schoolbanken, zelfs niet van een universitaire instelling. Een architect is iemand met ten minste zeven jaar grondige algemene automatiseringservaring, bij voorkeur met consultancy ervaring enerzijds en ervaring in systeemontwikkeling en beheer anderzijds.

Na een aantal jaren gewerkt te hebben als domein- of applicatie-architect is doorgroei naar enterprise-architect mogelijk, als de ambitie, kennis, ervaring en gevoel voor besturing en politiek aanwezig is. De eerdergenoemde kwaliteiten zoals inlevingsvermogen, verwachtingsmanagement en omgang met politiek zijn hierbij belangrijke ingrediënten.

Bij een loopbaan tot digitale architect geloven wij sterk in het meester-gezel principe. Want een aankomend architect leert niet alleen door studie, maar meer nog door mee te lopen in een architectuurtraject onder begeleiding van een ervaren architect in de rol van coach.

De digitale architectuur heeft nog een forse weg af te leggen ten opzichte van de fysieke architectuur. Te denken valt aan:

· academische opleiding / verankering;

· onafhankelijk certificering & registratie;

· bijscholing en nascholing;

Dit zijn zaken die reeds in de notitie ‘Strategische Inzet van Software in Nederland' van het ministerie van Economische Zaken staan opgesomd.

Het zal echter ongeveer 4 jaar duren voor de eerste kandidaat-architecten uit een academisch circuit kunnen rollen.

4.9 Het gebruik van de architectentitel in de digitale wereld

De Nederlandse wetgever heeft het per 1 oktober 1988 wenselijk geacht de architectentitel, in de fysieke wereld, te beschermen door middel van de Wet op de architectentitel [108] . Doelstellingen van deze titelbescherming zijn:

1. het bevorderen van de kwaliteit van de gebouwde omgeving;

2. de bescherming van de afnemer van architectendiensten door erkende deskundigheid publiekelijk herkenbaar te maken;

3. aansluiting zoeken bij de Europese Architectenrichtlijn die een systeem van wederzijdse diploma-erkenning behelst.

Het is een gemiste kans dat het geldigheidsgebied van deze wet slechts beperkt is tot de fysieke wereld [109] . Immers, bovenstaande doelstellingen komen ook voor in de digitale wereld. Voorts is het onbegrijpelijk dat de wetgever niet heeft opgemerkt dat de rol en titel van ‘architect' ook in de IT-sector al redelijk waren ingeburgerd.

Het is bij de Amerikaanse overheid tegenwoordig zelfs vereist dat er een architectuurstudie wordt verricht alvorens een groot automatiseringstraject wordt uitbesteed: de Clinger-Cohen act. De rol ‘architect' in de digitale wereld staat ook voor het streven naar een hogere professionaliteit in de ontwikkeling van systemen / software. In de notitie van mei 2002, ‘Strategische Inzet van Software in Nederland', die op verzoek van het ministerie van Economische Zaken is opgesteld is geschreven wordt zelfs een oproep gedaan om de architect in de IT-sector te certificeren.

De digitale wereld is voor veel mensen abstracter dan de fysieke wereld. Dit impliceert tevens dat de architectuur van die digitale wereld veel abstracter is dan de architectuur van de fysieke wereld. Dat betekent overigens niet dat het niet terecht zou zijn dat er in de digitale wereld over architectuur en architecten gesproken kan worden.

Het begrip ‘architect' in de digitale wereld doet volledig recht aan de originele bedoeling van dat woord ‘architect'. Het is ook niet redelijk om deze rol met een andere naam aan te gaan duiden. Nederland kan geen uitzondering in de beschaafde wereld worden.

Om het onderscheidend vermogen dat elke titel eigen is geen geweld aan te doen, zou het goed zijn een expliciet onderscheid te maken tussen digitale architecten en fysieke architecten.

De vermeende controverse tussen fysieke en digitale architecten zou moet worden overbrugd. Uiteindelijk gaat het erom een fijne werkplek voor mensen te creëren, zowel in fysieke als in digitale zin. Daarvoor zullen fysieke en digitale architecten moeten leren luisteren naar elkaar.

Certificatie van de architect

Veel ondernemingen verwachten terecht dat architecten een steeds belangrijkere rol zullen gaan spelen. In de toekomst zal men, als de informatievoorziening slecht functioneert of als de technische infrastructuur een dwangbuis voor de onderneming wordt, naar de architect wijzen. Daarom ontstaan er steeds meer (interne) certificeringsprogramma's om de kwaliteit van architecten te waarborgen.

Enkele belangrijke zaken bij certificatie zijn:

1 praktijkervaring;

2 sociale vaardigheden en attitude;

3 gemeenschappelijk denk- en doe-kader;

4 kennis en ervaring in bepaalde methoden of technieken.

Met praktijkervaring wordt bedoeld architectuurwerk onder begeleiding van een gecertificeerde architect. Daarnaast zullen van een architect, naast vakinhoudelijke vaardigheden, ook capaciteiten op het gebied van softskills en creativiteit worden gevraagd.

Het is echter nog veel te vroeg om te spreken over bedrijfsonafhankelijke certificering.

Er is nog nauwelijks consensus tussen de verschillende architecten over wat zij eigenlijk doen. De verschillende smaken waren te horen op het Landelijk Architectuurcongressen ( www.lac2004.nl ). De werkelijke behoeftes van de klant, gezien vanuit de klant, zijn nog niet echt in kaart gebracht. En er zijn nog geen algemeen erkende opleidingspaden.

Daarom heeft het Nederlands Architectuur Forum ( www.naf.nl ) een taskforce in het leven geroepen met als doelen:

· eindtermen voor een academische vorming van architecten voor de digitale wereld;

· certificeringseisen voor de verschillende soorten architecten in de digitale wereld;

· het onafhankelijk beleggen van het beheer en uitvoering van certificering;

· hoe om te gaan met de architectentitel in de digitale wereld tijdens de overgangsfase, dus het tijdperk totdat alles correct is geïmplementeerd, inclusief een migratiepad;

· hoe huidige architecten in de digitale wereld, die bewezen hebben professioneel bezig zijn, de titel kunnen verwerven zonder alsnog de te plannen opleidingen te moeten volgen.

4.10 Architectuurscholen?

In de fysieke bouw wordt gesproken over architectuurscholen. Natuurlijk levert elke architect een uniek product. Elke architect heeft zijn eigen creativiteit. Maar binnen een school zijn er bepaalde gemeenschappelijke karakteristieke zaken, soms aangeduid met ‘(architectuur)stijl [110] '. Antroposofische gebouwen zijn bijvoorbeeld ‘abge-eckt'. Zou dat bij de IT-architectuur ook zo zijn? Het is overduidelijk dat een architectuur voor bijvoorbeeld een e-business uitdaging opgesteld door Oracle andere karakteristieken heeft dan een architectuur opgesteld door Microsoft. Architectuur heeft namelijk iets te maken met het ‘geloof' in wat werkelijk fundamenteel is. Oracle gelooft in een database in het midden, terwijl Microsoft gelooft in ‘Dot.Net' als drager voor e-Business activiteiten.

Een aantal gemeenschappelijke stijlkenmerken voor een denkbeeldige architectuurschool in willekeurige volgorde:

· iedere onderneming heeft haar eigen unieke context en dus haar eigen unieke architectuur: architectuur is maatwerk;

· samengaan van business en it. Alleen geïntegreerde benaderingen waaraan een business case ten grondslag ligt met duidelijke businessvoordelen zullen uiteindelijk succesvol zijn;

· een integrale architecturale benadering van security en governance is een must;

· de architectuur borgt een naadloze aansluiting tussen ‘binnen' en ‘buiten';

· maximale zichtbaarheid van het gedrag van de informatievoorziening: de gebruiker weet wat hij doet;

· technologie heeft een ondersteunende rol, doch het is de informatie die de onderneming doet functioneren;

· de mens (als medewerker, als gebruiker) staat centraal;

· elke gebruiker heeft eenvoudige hulpmiddelen om zelf zijn digitale (werk-)omgeving nader in te vullen;

· de menselijke maat is uitgangspunt.

Ook zaken als de stijl en karakteristieken van het visualiseren en het gebruik van bepaalde hulpmiddelen ter ondersteuning van het opstellen en onderhouden van een architectuur bepalen in belangrijke mate de beleving die van een bepaalde architectuurschool uitgaat.

Naast de visuele resultaten bepalen schoolstijl-kenmerken mede de wijze waarop het proces doorlopen wordt om tot architectuur te komen. Ook in dit proces herkennen we bepaalde patronen die kenmerkend zijn voor een bepaalde architectuurschool.

4.11 Honorarium

Na vele diepgaande gesprekken kom ik tot de conclusie dat er niets is dat een fysieke architect doet in de fysieke wereld dat een digitale architect niet doet in de digitale wereld.

Maar hoeveel is een architect waard in die digitale wereld? Kort antwoord: ‘zijn gewicht in goud'! [111]

Vroeger in de tijd van de lineaire systeemontwikkelmethode [112] , waaronder het beroemde SDM [8], was er een boerenwijsheid dat een fout in het technisch ontwerp 10 keer zoveel kostte als een fout in het programmeertraject. Een fout in het functioneel ontwerp kostte 10 keer zoveel als een fout in het technische ontwerp. Dus hoe eerder in het traject van het opstellen van een informatiesysteem een fout werd geïntroduceerd, hoe meer het kostte om die fout te herstellen. Er kan nu echter worden gesteld dat een fout in de architectuur kan impliceren dat de onderneming een doodlopende weg inslaat [113] , dus einde exercitie!

Zoals gesteld zijn er meerdere soorten digitale architecten. Maar de CAO (Corporate Architectural Officer) [114] , de enterprise architect die op ondernemingsniveau de eindverantwoordelijke is over het architectuurgebeuren in de onderneming is van cruciaal belang. Wel beschouwd is een CAO wellicht belangrijker voor de continuïteit van de onderneming dan de CFO (Corporate Financial Officer) in dit hectische tijdperk waar het adaptieve vermogen in de onderneming van levensbelang kan zijn. Dus de vraag ‘hoeveel is een architect waard' verschuift naar de vraag ‘wat mag de continuïteit van de onderneming' kosten? Dan wordt architectuur ineens een ‘shareholder value'.

Als de toparchitect van een onderneming drie à vier cruciale strategische ideeën per jaar heeft dan is hij zijn salaris meer dan waard.

Een goede architect ziet meestal al vrij snel wat er nodig is, hoe het toekomstige ontwerp er in hoofdlijnen uit zou kunnen zien. Dit geldt zeker bij goede externe architecten. Door hun meestal wat bredere [115] blik kunnen zij vaak beter zien [116] wat er werkelijk nodig is voor de onderneming. Maar net als hun fysieke broeders spreken zij dat niet gelijk uit.

Een roemruchte fysieke architect vertrouwde mij eens toe dat in het eerste gesprek over eisen en wensen met de belangrijkste stakeholders hij zich al een redelijk goede voorstelling kon maken van waar het ontwerp naar toe zou kunnen gaan. Maar zei hij: “voordat ik die voorstelling als een houtskoolschets aan mijn klant opstuur, wacht ik twee weken omdat het anders zo vreemd overkomt dat ik daar een rekening bij doe van anderhalve ton euro's”. En dat is de waarde van een architect. Goede, uitvoerbare, ideeën zijn goud waard!

Bruikbare architectuur hoort gebruikers, zowel als werknemer en als wereldburger, uit te dagen zich te ontplooien. Maar hoeveel architecten luisteren echt naar de ware behoefte van die gebruikers? Hoeveel architecten proberen eerst de ware vraag achter de bouwopdracht te doorgronden, alvorens met allerlei prefab oplossingen te komen aansjouwen? Daarom e nkele waarschuwingen voor opdrachtgevers:

Wantrouw architecten die niet kunnen luisteren, dit leidt alleen maar tot ‘autistische' IT-systemen;
Wantrouw architecten die bij hun eerste kennismaking pronken met hun uitgebreide collectie ‘patterns' (kant-en-klare deeloplossingen);
Wantrouw architecten die niet willen blijven tijdens de realisatie [117] ;
Wantrouw architecten die niet eenvoudig, dus op uw niveau, kunnen visualiseren wat u krijgt;
Wantrouw architecten die verliefd zijn op technologie.

4.12 Literatuur

[1] Spiro Kostof, editor (2000), The Architect; chapters in the history of the profession, University of California Press , ISBN: 0 520 22604 6.

[2] Marc T. Sewel and Laura M. Sewell, The software Architect's Profession: an introduction, Prentice Hall, ISBN: 0 13 060796 7.

[3] Erik Vermeulen en Daan Rijsenbrij (2000), De architect als informatieplanner of als informatieregisseur; wie levert welke architect?, Tweede Landelijk Architectuurcongres, Amsterdam.

[4] Daan Rijsenbrij, Jaap Schekkerman, Harry Hendrickx, Hans Goedvolk en Jack van 't Wout (2001), De Architect, Derde Landelijk Architectuur Congres, Zeist.

[5] Jan Brouwer (2000), De architectuur van het maken, The Making of Architectuur, afscheid van prof. ir. Jan Brouwer , pp 99 – 145, Stichting Nederlandse Architectuur Manifestatie, ISBN 90 9014391 2.

[6] Vitruvius, vertaald door Ton Peters (1999), Handboek bouwkunde, Athenaeum – Polak & Van Gennep, Amsterdam, ISBN: 90 253 5870 5.

[7] D.B.B Rijsenbrij en G. Vlasblom (1992), Resultaatgerichte systeemontwikkeling, Informatie 34-2, pp 81-93.

[8] D.B.B.Rijsenbrij (1993), Basisconcepten in systeemontwikkeling, Informatie, jaargang 35, nr. 11, blz. 664-678.

4.13 Vragen

1. Welke soorten architecten zijn te onderkennen aan de universiteit?

2. Geef twintig verschillende titels van digitale architecten die je tegenkomt in sollicitatieadvertenties. Geef aan wat je daarvan wel een architect vindt en wat niet. Onderbouw het antwoord.

3. Welk soort architect stelt de architectuur van een waardennetwerk op? Onderbouw het antwoord.

4. Welke van de verschillende soorten architecten horen beslist op de eigen loonlijst van de onderneming en welke kunnen ook wel extern worden ingehuurd? Onderbouw het antwoord.

5. Als vraag 4, maar dan in een outsourcingssituatie.

6. Noem enkele verschillen tussen een fysieke architect en een digitale architect.

7. Onder welk soort architect valt een webdesigner?

8. Waarom is het niet zinvol om te spreken over een security-architect?

9. Waar ligt de grens tussen de architect en de ontwerper?

10. Wie heeft de (bij)rol van CAO (Corporate Architectural Officer) bij de Radboud universiteit? En hoe ruim zijn zijn bevoegdheden?

11. Heeft de universiteit een CTO? En wat was daarbij de overweging?

12. Welke zaken in het profiel van een goede architect in de digitale wereld kunnen worden aangeleerd en welke dienen als talenten aanwezig te zijn? Onderbouw het antwoord.

13. Zijn er eigenlijk nog wel consultants nodig als er architecten voorhanden zijn? Onderbouw het antwoord.

14. Voel jij je meer architect of meer engineer? Onderbouw het antwoord.

15. Wat is de relatie tussen werkstijl en architectuurstijl?

16. Welke relatie zou er moeten zijn tussen architectuur en innovatie? Geef eerst duidelijk aan wat wordt verstaan onder innovatie.

17. De opleiding tot architect hoort op academisch niveau. Toch is het uitermate belangrijk dat er ook op HBO-niveau architectuuropleidingen worden gegeven. Verklaar deze stellingname.

18. Hoe zouden in de toekomst fysieke en digitale architecten kunnen samenwerken bij het architecturen van een artefact, bijvoorbeeld van een huis of van een werkplek?

19. Zou het niet beter zijn om de wet op de architectentitel af te schaffen en de beroepsgroep zelf de certificering te laten verrichten? Onderbouw het antwoord.

20. Welke juridische aansprakelijkheid zou een (digitale) architect kunnen lopen? Is dat vergelijkbaar met een consultant? Expliciteer en onderbouw het antwoord. Hoe is dat geregeld bij de fysieke architecten?

4.14 Oefeningen

1. Beschrijf het karakteristieke profiel van de architect die jij over 10 jaar zou willen zijn.
Bestudeer daarvoor paragraaf 4.6 ‘werkprincipes' en probeer daarin je eigen (toekomstige) werkstijl te vinden.

2. Maak een organogram van de top van de universiteit en geef aan waar en op welke wijze de architectuur is belegd.

3. Onder architectuurstijl wordt verstaan een beperkte verzameling samenhangende principes die een bepaalde architect of architectuurschool altijd toepast en waaraan wordt herkend welke architect of architectuurschool het artefact heeft gearchitectureerd.
Probeer van een bekende digitale architect te achterhalen wat zijn architectuurstijl is.

4. Interview bekende fysieke architecten over hoe zij zijn gevormd. Probeer dat te transponeren naar de digitale wereld.

5. Transformatie onder Architectuur

trefwoorden: streefbeeld, bouwwijze, weerstanden, drastische maatregelen, strategische driehoek.

5.1 Inleiding

Architectuur ‘toont' de vrijheid binnen de gebondenheid. Het is daardoor een hulpmiddel bij transformatie, een hulpmiddel waarmee orde wordt geschapen en discipline bij de ontwikkeling wordt ondersteund (zie bijvoorbeeld Han van der Zee e.a. [1]). Door het gebruiken van architectuur wordt snelle, kort-cyclische ontwikkeling verantwoord en veilig in termen van kwaliteit. Het gebruik van regels en standaarden borgt gewenste uniformiteit en voorkomt als zodanig de wildgroei die kan ontstaan door het ontwikkelen onder grote tijdsdruk.

Architectuur geeft regels voor de verdeling van functionaliteiten zowel horizontaal (over de verschillende lagen) als verticaal (over verschillende componenten). Hierdoor legt architectuur de basis voor ‘make, buy or outsource' - beslissingen en geeft een kader voor gesystematiseerd hergebruik.

Hierdoor wordt de ‘time-to-market' van applicaties verkort, resp. de kosten om appliacaties te assembleren verlaagd. Kortom architectuur nodigt uit tot een meer industriële vorm van softwareontwikkeling.

De kardinale vraagstelling voor de boardroom luidt: ‘master of your own destiny'. In feite geldt deze vraag voor de onderneming in haar totaliteit, maar ook voor elke business unit tot het niveau van de individuele medewerker aan toe.

De vraag is hoe word of blijf ik master over het value network of hoe verwerf ik een profitabele plaats in het ecosysteem.

De grote kunst in dit dynamische tijdperk is je niet dood te staren op de concurrentie. Innoveren op de (toekomstige) behoefte van de klant is de sleutel tot een toekomstvaste bedrijfsvoering. Bedenk nieuwe ketens die worden ingevuld met partners waarmee wellicht slechts een tijdelijke relatie wordt aangegaan. Samenwerken wordt belangrijker dan concurreren.

Een dergelijke open instelling naar buiten, naar de klanten en naar de partners, vraagt een andere organisatiecultuur. Een organisatiecultuur die een nadrukkelijke invloed heeft op de bedrijfscultuur. Ook vergt het meer flexibele en wellicht andere vaardigheden van de werknemers. In dit tijdperk wordt steeds meer transparantie vereist, te denken valt aan SOX en Basel II. Het is belangrijk bij transformaties om een open oog te hebben voor verhoogde transparantie-eisen. De regelgeving kan ook beschouwd worden als een infrastructureel gegeven. Als de bedrijfsarchitectuur van de onderneming in pas loopt met de architectuur van de regelgeving kan de onderneming zich optimaal ontplooien onder die regelgeving, anders werkt dit ook als een dwangbuis. Anticipeer bij transformaties op die veranderde regelgeving.

5.2 Streefbeeld

Zonder transformatiemogelijkheden heeft een architectuurprent geen zin. Een architectuurprent is geen eindpunt, maar slechts een richtpunt: een streefbeeld.

Een goede architect heeft een toekomstbeeld waarnaar wordt gestreefd. Vraag daarom aan een architect wat zijn karakteristieke stijl is. Laat hem zijn visie expliciteren. Waar gelooft hij werkelijk in?

In mijn visie is de ideale onderneming een (virtuele) onderneming die volledig van de mogelijkheden van IT gebruikmaakt en gericht is op de eindgebruiker:

met een duidelijke visie en strategie op het gebied van e-business,
ondersteund door ‘web-enabled' kennismanagement,
waar applicaties en infrastructuur voortdurend worden verbeterd om in de pas te lopen met de behoeften van de eindgebruikers.

Cruciaal voor een goede concurrentiepositie zijn:

naadloze integratie tussen bedrijfsactiviteiten en IT,
ultrasnelle ontwikkeling en verspreiding van applicaties,
binnen de kaders van een toekomstvaste enterprise architectuur.

Ik droom van een slanke overheid waarbij ik als burger maximaal wordt gefaciliteerd om mijn administratieve en financiële verplichtingen te vervullen.

Het probleem is hier het transformatietraject, de forse hoeveelheid dossiers, oude procedures, verouderde organisatiestructuren etc. etc. die moeten worden opgeruimd. De overheid staat dus een gigantische omwenteling te wachten. Veel overheidsdiensten zullen in de toekomst kunnen worden gebruikt vanaf browsers op personal devices. Veel regelende klussen zullen worden uitgevoerd door softbots [118] . Dit geeft aan de ene kant een meer flexibele overheid, aan de ander kant zal een licht gevoel van geïntensifieerde overheidsbevoogding (overmatige regulering) gaan ontstaan.

Interessante vraag wordt hoe overheden in de toekomst rampen denken te gaan bestrijden of te voorkomen. En hoe zien de rampzalige gevolgen eruit van foutieve interpretaties van de verstrekte informatie en wie waarborgt dat?

De overheid is altijd een dankbaar object om te bekritiseren, zij functioneert in een glazen huis, maar menige onderneming vertoont dezelfde problemen als die overheid.

5.3 Bouwwijze

Het is voorts belangrijk dat een architect een duidelijke mening heeft over de wijze van bouwen en een visie over zaken die belangrijk zijn bij dat bouwen. Dit heeft een directe weerslag op de architectuur, die architectuur moet immers maakbaar zijn.

Persoonlijk geloof ik niet in zelf bouwen, maar in maximale outsourcing / offshoring van alle services die niet echt van levensbelang zijn voor de onderneming (zie http://outsourcing.rijsenbrij.com ). Voorts geloof ik in partnership als basisstrategie, om optimaal gebruik te maken van de mogelijkheden van het ecosysteem.

Het pad naar maximale outsourcing bestaat uit drie stappen:

1. Bepaal eerst de core business; doe de rest de deur uit (dus b.v. BPO [119] van procurement).

2. Bepaal vervolgens binnen de core business de core competence (à la Prahalad ); doe de rest de deur uit (dus b.v. de polisadministratie bij een verzekeringsconcern).

3. Borg dat je core competence gaat evolueren binnen het ecosysteem door een externe partner in te schakelen als coach.

Elke onderneming zal dit pad volgen, de snelheid is slechts afhankelijk van de ‘sense of urgency' en de volwassenheid van de onderhavige onderneming.

Overigens is een degelijke (enterprise) architectuur een absolute noodzaak voor een verantwoorde outsourcing (Rijsenbrij, [2]).

Wij voorspellen daarom een toekomst met uitermate slanke [120] ondernemingen waarbij heel veel is geoutsourced; geoutsourced door abonnementen op webservices, middels publieke catalogi, en geoutsourced naar een aantal service-providers op partner-basis.

Bovengenoemde services zullen betrekking hebben in alle vier de werelden, dus business services, informatieservices, applicatieservices en technische services. Een business service als ‘billing', een informatieservice als de weersverwachting, een applicatieservice als het berekenen van een pensioengat, en een technische service als hosting.

Dit leidt tot een uitermate fascinerende toekomst. Een toekomst waarin naast de enterprise architect de domeinarchitect een belangrijke rol speelt bij de continuïteit van de onderneming. De domeinarchitect die met zijn of haar creativiteit de mogelijkheden van het eigen domein weet te combineren met de voorzieningen / de services uit de omgeving tot nieuwe business concepten.

5.4 Verbetergebieden

Ten slotte dient een architect een persoonlijk inzicht te hebben in een aantal cruciale zaken die in een onderneming spelen:

· op bedrijfsniveau het moderniseren van de business.
Hieronder vallen zaken als business-rationalisatie door verbeterde toepassing van IT; business-concept-innovation mogelijk geworden door IT; Enterprise Analytics (Metrics) ondersteund door IT; digitalisering van de bedrijfsprocessen leidend naar een ‘digital enterprise'.

· op het gebied van informatie en samenwerking de architectuur van de informatie-infrastructuur.
Daarbij spelen tevens zaken als digitale documenten, digitale (werk)ruimtes, informatiemanagement (Business Intelligence inbegrepen) & contentmanagement en kennismanagement.

· voor wat de applicatieportfolio en technische infrastructuur betreft: de aanwezigheid, wellicht offshore, van interessante applicatieservices en infrastructuur services.

· zaken op het gebied van security en privacy als: business continuity; security principes en identity management.

· belangrijk is een gedegen inzicht in governance.
Zaken die daarbij spelen zijn: IT-governance / service management; compliancy & transparency; demand management / alignment tussen de business en de extern ingehuurde services.

· een goed gevoel voor de mogelijke gevolgen van IT op de eindgebruiker is essentieel.
Hierbij kan gedacht worden aan de menselijke maat in IT-gebruik, de ergonomie van de gebruiksinterface, de sociale impact van IT op de maatschappij en de pedagogische impact op het proces van volwassenwording.

5.5 Weerstanden

Het opstellen van een bruikbare architectuur is geen sinecure. Hiervoor zijn deskundigen nodig van academisch niveau met een groot inlevingsvermogen in mensen en bedrijfssituaties. Goede architectuurstudies leiden tot vereenvoudiging en helderheid, wat nogal wat weerstanden oproept in ondernemingen. Zoals in dit hoofdstuk wordt aangegeven is architectuur slechts de helft van het probleem. De artefacten dienen ook nog te worden gerealiseerd en daarbij zien we vaak veel weerstanden tegen verandering. Een kleine anekdote over hoe men vroeger met dergelijke weerstanden omging.

Toen Lodewijk Napoleon (Napoleon III) aan de macht kwam werd hij geconfronteerd met een onbestuurbaar Parijs [121] . Door de Franse revolutie (de echte en die van 1848) was het volk gewend aan ‘vrijheid blijheid' en na de deceptie over de teloorgang van de Franse grandeur door de nederlagen van Napoleon Bonaparte (Napoleon I) was de eenheidsgedachte ook ver te zoeken. Het grotere geheel stond niet meer centraal. Het lot van Parijs lag in handen van een verzameling van toevallige individualisten. Zelfs met behulp van het leger was Parijs niet meer tot discipline te brengen.

De smalle straten nodigden uit tot het oprichten van barricades. De huizen in Parijs stonden zelfs zo dicht op elkaar dat de mensen zich gemakkelijk van huis tot huis konden bewegen door over de straten heen te springen.

Toen nam Lodewijk Napoleon een stedenbouwkundige architect in de arm, baron Georges Eugène Haussmann [122] , en gaf hem de opdracht een architectuur op te stellen die voorwaardenscheppend was voor een grotere beheersbaarheid.

Haussmann ontmantelde rücksichtslos het dichtgeslibde centrum (wij zouden tegenwoordig zeggen de ‘legacy'), plaatste een ster in het midden (place de l'étoile) en creëerde enkele brede aanvoerroutes, de Grands Boulevards.

Sommigen vragen zich af of baron Hausmann zijn werk in Parijs wel goed heeft gedaan gezien de fileproblematiek in het centrum van het huidige Parijs. Maar laten we eerlijk zijn, deze architect kon niet anticiperen op de uitvinding van de auto en de onbeteugelde wildgroei die men daarin heeft toegestaan. Zo hebben wij, een aantal jaren geleden, ook niet kunnen voorspellen dat over een paar jaar eenieder enkele devices bij zich zal hebben waarmee hij met elke persoon en met elk apparaat op elk willekeurig tijdstip vanaf elke plaats digitaal contact zal kunnen leggen.

Een wat actuelere probleemsituatie is de stad Bangkok. De stad is volledig dicht geslibd en overdag nauwelijks voor auto's toegankelijk. Er is als het ware een file van ‘s ochtends 9.00 uur tot ‘s avonds 18.00 uur. Er zijn fly-overs over fly-overs om nog iets te doen aan de verkeersproblematiek aan de randen van de stad. Zou de verkeersproblematiek kunnen worden opgelost door slimmere stoplichten of andere technische hoogstandjes op verkeersgebied? Neen! Er is een toparchitect nodig om het stadsplan drastisch te veranderen: eerst een moderne architectuur en pas daarna verkeerstechnologie.

Bovenstaand beeld van het centrum van Parijs geldt voor heel veel ondernemingen, inclusief de Nederlandse overheid. Veel ondernemingen zijn nauwelijks bestuurbaar, informatiestromen lopen niet, rapportagekanalen zitten verstopt. Het automatiseringslandschap is vaak een lappendeken van applicaties die nauwelijks effectief noch efficiënt functioneren. De kosten om de applicaties in de lucht te houden zijn vaak veel en veel te hoog, de servicegraad is van bedenkelijk niveau. De informatievoorziening staat nauwelijks ten dienste van de klanten, zelfs niet van de medewerkers. Ondernemingen zijn nauwelijks transparant voor de klant en hebben weinig echte identiteit. Ze zijn nauwelijks te categoriseren als een ‘adaptive enterprise'. De adaptiveness van die onderneming wordt slechts gemanifesteerd door het individuele adaptieve vermogen van de bekende 20% van de medewerkers.

Ook het beeld van Bangkok moet heel herkenbaar zijn voor veel IT-managers. En net als de verkeerstechnologen proberen de IT-technologen de dichtgeslibde informatievoorziening op te lossen door er nog meer IT in te pompen in plaats van het informatieverkeer eerst eens op te schonen.

Signalen uit de onderneming conform situaties à la Parijs en Bangkok zouden voor de CEO een teken moeten zijn dat er echt iets dient te gebeuren. Maar de ‘sense of urgency' om werkelijk te beginnen aan een nieuwe architectuur blijkt bij veel ondernemingen laag, wellicht veroorzaakt door de grote werkdruk om in de bestaande situatie nog enigszins het hoofd boven water te kunnen houden.

5.6 Drastische maatregelen

Een waardevolle startactiviteit voor het opstellen van een enterprise architectuur is het inventariseren welke drastische maatregelen à la Haussmann het functioneren van een onderneming significant zouden kunnen verbeteren. Probeer daarbij een aantal quick-wins te vinden om de appreciatie voor transformatie te verhogen.

Hieronder een bonte verzameling van drastische maatregelen uit mijn eigen praktijk bij verscheidene grote ondernemingen.

1 . Stap af van een hiërarchische aansturing van de onderneming. Beschouw de onderneming als een federatie van business units, elk met een duidelijke kerncompetentie. Regel binnen die federatie:

· een centraal CV - en beschikbaarheidsysteem voor staffing doeleinden;

· een centraal bestand van digitale personeelsfiles;

· een centraal bestand van klantcontacten;

· bruikbare, eenduidige klantprofielen;

· een bruikbaar, levend KM systeem;

· een (interne) marktplaats van service offerings en professionele competenties, die eventueel ook door externe klanten te raadplegen is.

Transformeer het geheel van de onderneming naar een ‘net liberated company' waar het geheel fungeert als een ecosysteem rond de business unit. De ‘holding' krijgt daarbij een dienstverlenende rol en acteert voorwaardenscheppend voor een waardegedreven bedrijfsvoering.

2 . Breng de menselijke maat terug in de besturing. De business unit wordt weer de (financiële en sociale) hoeksteen van de onderneming. Dat wil zeggen de unitmanager wordt ondernemer. Hij bestuurt delivery, marketing & sales, HRM en competences. Hierbij wordt hij bijgestaan door de (centrale) staf. Maar staf is slechts ondersteunend. Stafdiensten worden betaald door de units op abonnementsbasis en moeten in principe concurreren met de vrije markt.

3 . Breng daadwerkelijk ondernemerschap aan op engagementniveau [123] . Het primaire fundament van het bedrijfskundig handelen ligt in het managen van de verzameling van ‘delivery engagements'. Laat de engagementmanager sturen op de winst van de engagement. Geef hem daarbij een financieel dashboard naast voortgangs- en kwaliteitsrapportages.

4 . Zelfs de medewerker (ook de interne) wordt opgevoed tot een nuchtere zakelijke ondernemer. De medewerker betaalt/bepaalt de aan hem verstrekte diensten. De OR gaat zich expliciet inspannen voor een ‘gezonde' digitale werkomgeving van de medewerker.

5 . Stafdiensten zijn verplicht expliciet hun toegevoegde waarde te tonen naar de operationele units en zelfs naar het collectief van de individuele medewerkers.

De administratieve plichten van de medewerker worden geëvalueerd tegen het 3-G principe: gemak, gewin en genot.

6 . Publiceer de SLA's op het Intranet voor alle interne diensten die worden geleverd, zodat een ieder kan zien wat hij mag verwachten en waarvoor wordt betaald.

7 . Verwijder de ‘leemlagen' in de onderneming door verregaande automatisering.

Teveel staforganen en tussenniveaus werken verlammend op de besluitvaardigheid.

8 . Keer terug naar een nuchtere, zakelijke vorm van management. Er wordt gestuurd op basis van cijfers en metrieken, gevisualiseerd in eenvoudige real-time (customizable) dashboards op alle niveaus:

· medewerker;

· engagement manager;

· operational unit;

· en alles daarboven.

Maak een business scorecard voor de evaluatie van het intern en extern functioneren, waarvan de parameters kunnen worden gevolgd met behulp van bovengenoemde dashboards.

Overweeg zelfs een dashboard voor de externe klant!

9 . Verlaag de drempel voor medewerkers om over te stappen naar voor hen interessante business units of stafdiensten.

10 . Breng weer een gezonde Hollandse klantgerichtheid aan.

Meet elke activiteit op de toegevoegde waarde richting de eindklant.

De ‘echte' klant zit buiten!

11 . Eenieder is verantwoordelijk voor zijn eigen agenda. De secretaresse wordt omgeschoold tot informatiemanager.

12 . Stop fysieke bijeenkomsten over interne aangelegenheden. Indien bijeenkomsten toch nodig zijn, vervang deze dan door virtual meetings en ondersteun deze met IT.

Geef desnoods een cursus effectief vergaderen in het digitale tijdperk.

13 . Discipline wordt hersteld als wezenlijk onderdeel van de bedrijfscultuur en verbijzondering van ‘total respect'. Maak duidelijke afspraken en houd je eraan!

Discipline wordt ‘afgedwongen' met/door IT en verankerd in de architectuur.

Bij discipline wordt rekening gehouden met de menselijke maat, een mens is immers geen machine [124] .

14 . Iedereen is verantwoordelijk voor zijn eigen zichtbaarheid. Elke medewerker krijgt 100 MB aan webspace om een eigen website te bouwen: het personal web.

Er wordt een cursus, liefst CBT [125] , aangeboden ‘hoe bouw ik mijn eigen website'.

Eenieder houdt zijn eigen CV bij, zijn eigen etalering naar binnen en naar buiten.

15 . Daag medewerkers uit om ‘adaptive' te acteren. Laat een medewerker zich ‘verkopen' door een aantrekkelijke en informatieve website te maken waarop duidelijk staat wat zijn verdiensten zijn, wat zijn toegevoegde waarde is voor de onderneming. Introduceer het principe ‘master of your own destiny'.

16 . Breng met een beperkte groep topexperts de gewenste adaptiviteit van de onderneming in kaart. Zoek snel de ontkoppelpunten op.

17 . Het kennismanagementsysteem is van een bedenkelijk niveau.

Stop alle activiteiten aan dit soort kennismanagement en stel eerst een architectuur op voor een levend kennismanagement. Expliciteer als eerste een netwerk van tacit knowledge. Een oud Indisch spreekwoord zegt: ‘kennissen zijn belangrijker dan kennis'.

18 . Het emailverkeer wordt drastisch teruggebracht. Geen ongevraagde e-mail.

Meer gebruikmaking van community ruimtes en virtual project rooms. Zet reverse communication consequent door. Eenieder is verplicht om minstens eens per week op het Intranet (de digitale ‘socio room') te kijken.

Ook aan leveranciers wordt kenbaar gemaakt dat papieren informatie niet gewenst is en dat persoonlijke benadering van medewerkers uit den boze is, alleen via community spaces.

19 . Alle informatie in en rond de onderneming wordt gedigitaliseerd. Kasten, ladekasten etc. etc. worden verwijderd. Bureaus horen schoon te zijn als men naar huis gaat, anders gooit de schoonmaakster alles weg. Slepen met koffertjes, aktetassen en laptops is bedoeld voor pakezels en niet voor mensen in het digitale tijdperk.

20 . Ieder is verantwoordelijk voor zijn eigen informatie. De onderneming zorgt, als technische service, slechts voor betrouwbare storage. We onderkennen zeven categorieën van informatie:

· Persoonlijke informatie

· Community informatie

· Business Units informatie

· Domeininformatie

· Werkmaatschappij informatie

· Enterprise informatie

· Informatie van buiten

Er wordt een cursus aangeboden ‘hoe manage ik mijn persoonlijke informatie'.

21 . Installeer in de onderneming een intern ASP centrum.

Het wordt absoluut verboden voor medewerkers, business units, werkmaatschappijen, domeinmanagers om eigen software te gebruiken voor de informatiehuishouding van de onderneming. Centraal beheerde datamodellen zijn daarbij een vereiste.

22 . Er wordt überhaupt niets gebouwd voor eigen gebruik in de onderneming, er wordt uitsluitend gebruik gemaakt van pakketsoftware. Zelfs MS-Excel en MS-Access worden verwijderd als productivity tools uit de kantooromgeving.

23 . Stel de domeineigenaar zelf verantwoordelijk voor de informatisering; de automatisering van zijn eigen domein.

24 . Elke introductie van nieuwe / vernieuwde technologische mogelijkheden gebeurt volgens een didactisch model. Alleen grondig geteste functionaliteit wordt verstuurd naar medewerkers; functionaliteit die volledig zelfinstallerend is.

25 . De helpdesk wordt afgeschaft. Enerzijds zijn een groot aantal werkzaamheden volstrekt overbodig bij een meer volwassen implementatiestrategie van de software, anderzijds kan een volwassen vorm van self service de rest opvangen.

26 . Durf de klant te laten spreken. Vraag aan belangrijke klanten hoe zij in de nabije toekomst een digitale onderneming willen beleven. Vraag welke rol de onderneming mag spelen in hun ecosysteem.

27 . Houdt op met treuzelen! Bepaal met een zeer beperkte denktank de hoogste prioriteiten, de grootste pijnpunten in het functioneren van de onderneming.

Los deze pijnpunten snel op door de beste medewerkers erop te zetten en voorkom het imago dat dit een interne klus is (dus verkapte leegloop).

Om te borgen dat deze transformatie zakelijk wordt uitgevoerd, kan overwogen worden om het project aan externen uit te besteden.

28 . Alles wat bij klanten wordt geadviseerd en gerealiseerd, wordt ook op de eigen onderneming toegepast: ‘verbeter de wereld, begin bij jezelf!'.

5.7 Architectuur en Transformatie

De besturing van de evolutie van ondernemingen verloopt in een spanningsveld tussen drie polen, ‘de strategische driehoek':

1. strategie: wat willen we met de onderneming?

2. enterprise architectuur: wat kunnen we, gezien de huidige inrichting?

3. transformatie: hoe gaan we het doen , hoe implementeren we de veranderingen in de onderneming?

Het ‘willen' kan ook in de tijd worden gefaseerd, er ontstaat dan een wisselwerking tussen strategie en transformatie. Er wordt dan een transformatietraject bewerkstelligd via een aantal relatief stabiele (rendementvolle) tussenstadia (‘islands of stability' [126] ). In alle eerlijkheid is er, in deze tijd van continue verandering, geen stabiele eindtoestand meer waar naar kan worden gestreefd. Er is slechts een toestand van een eeuwig veranderend heden; waarbij een zogenaamd einddoel wordt geprojecteerd om richting te geven voor de stakeholders.

De relatie tussen enterprise architectuur en transformatie drukt uit dat aan de ene kant architectuur borgt dat de transformaties ordelijk verlopen. Aan de andere kant zullen de transformaties wellicht additionele architectuurprincipes, regels en richtlijnen vergen.

Tegen de achtergrond van bovengenoemde strategische driehoek spelen een aantal belangwekkende processen die bij een grote onderneming van cruciaal belang zijn en daarom boardroom aandacht vereisen. Enkele interessante boardroom issues waarin architectuur een cruciale rol speelt:

· Rationalisatie na fusie of overname;

· Transformatie naar praktische e-business;

· Globalisatie;

· Multi-channel relaties;

· Integratie en optimalisatie van IT oplossingen;

· Business IT fusion [127] ;

· Kansen die IT levert naar nieuwe business strategieën.

Voorts speelt enterprise architectuur een belangrijke faciliterende rol bij:

· Verlaging projectrisico's;

· Migratieplanning;

· Het aanpassen van packet software;

· Het realiseren van een geïntegreerd klantbeeld;

· Flexibele sourcing (in and out) [128] .

Architectuur begint steeds vaker een gespreksonderwerp te worden in de boardroom van moderne ondernemingen. Dat is nog niet zo vreemd omdat het huidige zaken doen meer en meer dynamisch begint te worden. Niets is meer zeker en de voorsprong van vandaag door het hebben van goede infrastructuren kan een belemmering vormen voor de kansen van morgen. ‘Kansen en bedreigingen', een afweging die naast de analyse met betrekking tot ‘sterkte en zwakte' regelmatig op de tafel van de boardroom hoort te liggen, vraagt een architecturele benadering. In feite hebben we hier te maken met de balans tussen ‘willen' en ‘kunnen', of de strijd tussen 'willen' en ‘niet kunnen'/‘niet meer kunnen'.

Hoewel wij dus uit ervaring weten dat enterprise architectuur vaak impliciet als onderwerp in de boardroom aan de orde komt, wordt het niet altijd als zodanig herkend en benoemd. Immers, bij alle discussies over nieuwe strategieën, nieuwe producten en diensten, mogelijke gevaren van concurrenten of substituten, speelt de vraag: ‘wat is onze ruimte om te handelen?'. Handelen, niet alleen in financiële zin en met de vaardigheden van de medewerkers, maar meer nog in de zin van: kan de informatievoorziening en de bijbehorende infrastructuur de beoogde strategie faciliteren? En natuurlijk is de architectuur aan te passen, maar dat heeft z'n prijs. Dus impliciet worden veel discussies in de boardroom gevoerd tegen de achtergrond van dat ‘willen' en ‘kunnen' .

De toenemende vraag naar groei of kwaliteitsverbetering zet ondernemingen onder druk. De toegevoegde waarde die een onderneming creëert, moet blijven stijgen. De groeiende connectiviteit en de structurele vraag naar groei hebben een flinke impact op industrieën en ondernemingen. Zet waarde centraal: creëer waarde en houd deze vast. Gebruik het gehele waardenetwerk als arena voor concurrentie of samenwerking. Zorg voor een hoge reactiesnelheid en een adaptieve onderneming.

In sourcingstermen betekent dit dat men voortdurend kritisch de toegevoegde waarde van alle onderdelen van de onderneming moet afwegen tegen de kosten en de managementaandacht die daaraan besteed wordt. Er wordt dan verder geïnvesteerd in de onderdelen met de hoogste toegevoegde waarde en er wordt geprobeerd de delen met de laagste toegevoegde waarde uit te besteden aan een andere onderneming. In beide gevallen staat de business case natuurlijk centraal (Rijsenbrij, [3]).

De business- en de IT-visie op de onderneming worden met behulp van een framework op elkaar afgestemd. Daaruit komt een verscheidenheid aan projecten voort, voor verschillende systemen, zoals: bedrijfssystemen, nieuwe en/of aangepaste informatiestromen en infrastructuren. Vanwege de onderlinge verbondenheid van business en IT in veel ondernemingen worden de meeste ontwikkelingen ‘concurrent' uitgevoerd. Hiermee bedoelen we dat de transformatie in de business en IT gelijktijdig plaatsvindt. Een framework speelt hierin een afstemmende rol. Enterprise architectuur is dus een borgingsinstrument dat zorgt dat grootscheepse transformaties ordelijk verlopen en tot de gewenste eindresultaten leiden.

Architectuur wordt uiteindelijk gebruikt om op een ordelijke manier hoogwaardige applicaties te ontwikkelen, door velen aangeduid met projectarchitectuur. Dit proces wordt beschreven door Roel Wagter, Martin van den Berg, Joost Luijpers en Marlies van Steenbergen [4] en Art Ligthart en Jan Vis [5]. Op projectniveau is architectuur een basis voor hergebruik. Maar ook delta-analyse is belangrijk voor snelle ontwikkeling. Door het gebruik van architectuur kan ontwikkeling evolueren van een mechanistische methode naar een organisch groeimodel, waarbij de business case leidend is. Hierbij is het zeer belangrijk om de scope [129] te bewaken en incrementeel in te voeren. Inzicht in de ware behoefte van de eindgebruiker groeit immers iteratief, een dergelijk ontwikkelaanpak wordt ook wel aangeduid met ‘lerend ontwikkelen'.

In plaats van projectarchitectuur is het juister te spreken over de architectuur van de individuele systemen.

In de hedendaagse urbanistiek worden twee hoofdproblemen onderkend bij het saneren van steden: toegankelijkheid en de afvoer van het afval.

Toegankelijkheid is ook een centraal thema in de digitale architectuur, zowel fysiek in termen van bandbreedte en connectiviteit als in functionele zin (dus op contentgericht). De analogie van de afvoer van het afval mag de lezer zelf invullen, maar denk eens in de richting van het afscheid nemen van verouderde service offerings, verouderde competenties en het opschonen van het Intranet.

5.8 Transformatie van de onderneming

Wij worden dagelijks geconfronteerd met het feit dat de wereld in steeds sneller tempo verandert. Deze verandering wordt trouwens hoofdzakelijk veroorzaakt door de snelle infiltratie van de informatietechnologie in producten, diensten, productieprocessen en managementstructuren. Vaste patronen, vaste waarden en zekerheden en een vast referentiekader, dit alles begint door deze onstuimige verandering te verdwijnen als sneeuw voor de zon. Flexibiliteit is daarom een absolute noodzaak om te kunnen overleven in het aanstormende informatietijdperk. Flexibiliteit in de structuur van de diensten en de producten die wij leveren en flexibiliteit in het productieproces. Ten slotte het meest kardinale: flexibiliteit in de geest van alle betrokkenen, in ons vakgebied, zowel bij de informatici en automatiseerders als bij de eindgebruikers.

De verandering, voor zo ver het het vakgebied van de informatici en automatiseerders betreft, kan worden gelokaliseerd in een drietal transformatiegebieden:

1. bedrijfstransformatie;

2. evolutie in het gebruik van informatietechnologie;

3. transformatie van het informatievoorzieningssysteem [130] .

5.8.1 bedrijfstransformatie

Transformatie van het bedrijfsgebeuren, mede in relatie tot haar ecosysteem, wordt, volgens Gouillart en Kelly [6], onderverdeeld in vier kwadranten. Die vier kwadranten betreffen:

1. Herijking van de ondernemingsrichting: heroriëntatie op de bedrijfsdoelstelling en het vinden van een vernieuwde visie.

2. Herstructurering van de onderneming: het construeren van een nieuwe bedrijfsstructuur.

3. Revitalisering van de onderneming: het verzorgen van een nieuwe impuls, nieuwe kracht.

4. Verfrissing van de medewerkers: geestelijke verfrissing van de medewerkers, verjonging.

In het eerste kwadrant komt de beleving/perceptie van de onderneming en haar medewerkers omtrent de buitenwereld aan bod. De kunst is de zaak weer in beweging te krijgen: creëer een gemeenschappelijke uitdaging en bestendig de veranderrichting door middel van K.P.I.'s.

Het tweede kwadrant bevat de factoren waarmee de herstructurering van de onderneming wordt aangepakt. Naast een economisch waarderingssysteem om de toegevoegde waarde in de bedrijfsprocessen meetbaar te kunnen maken, wordt de fysieke infrastructuur zoveel mogelijk opgeschoond en de werkarchitectuur geoptimaliseerd. De beide laatste factoren vertonen een sterke interactie met het informatievoorzieningssysteem.

In het derde kwadrant wordt een nieuwe impuls/kracht toegevoegd aan de onderneming door van buiten naar binnen te ‘werken'. De kunst is om met de ogen van de klant opnieuw naar je aanbieding te kijken. Bedenk nieuwe producten en diensten door bestaande mogelijkheden te kruisen. Gebruik informatietechnologie om de communicatie met de buitenwereld te verbeteren. Dit zijn drie oefeningen om nieuwe vitaliteit aan de onderneming toe te voegen.

In het laatste kwadrant, getiteld verjonging, komen de medewerkers aan bod. Naast een beloningssysteem dat voldoende uitdagend moet zijn om de mensen enthousiast te houden, is het belangrijk dat de medewerkers een immateriële uitdaging krijgen om te excelleren. Bij dit laatste is het van essentieel belang dat medewerkers binnen de onderneming in ‘groepsverband' tot een hoger prestatieniveau komen. Een onderneming is immers een juridisch zelfstandige groep mensen en middelen waarmee, in een veranderende omgeving, resultaten worden bereikt die na een zeker tijdsbestek dienen te leiden tot een vooraf gesteld bedrijfsdoel. Het zijn de mensen die bewustzijn schenken aan een organisatie; de overige productiehulpmiddelen als natuur, kapitaal en kennis vormen slechts het decor waarin deze groep mensen functioneert en het liefst floreert.

Onderstreept dient te worden dat de indeling in deze kwadranten slechts een mindmap is waarbij op voorhand geen volgorde van belangrijkheid tussen de factoren kan worden aangegeven. De volgorde van uitvoering hangt onder anderen af van de toestand van de onderneming, de doelstelling van het beoogde transformatieproces en de onderlinge relaties tussen de transformatiefactoren.

In feite borduurt deze indeling voort op een oudere indeling, waarmee de drie werelden van het bedrijfsgebeuren wordt uitgebeeld: de binnenwereld - de onderneming zelf dus -, de buitenwereld en de contacten tussen beiden. Dit komt redelijk overeen met kwadrant 2 respectievelijk kwadrant 1 respectievelijk kwadrant 3. Het effect van deze drie werelden op het bedrijfsresultaat, wordt vaak uitgedrukt middels de formule:

BR = BSR + BPR +BNR

ofwel :

Business Redesign = Business Scope Redefinition

Business Process Redesign

Business Network Redesign

Als extra wordt door Gouillart en Kelly expliciete aandacht geschonken aan de medewerkers, hetgeen de meer mensgerichte benadering onderstreept van de bedrijfstransformatie.

5.8.2 evolutie in het gebruik van informatietechnologie

De toepassing van informatietechnologie doorloopt een leerweg, waarlangs de onderneming leert om te gaan met de onderhavige technologie. In die leerweg zijn een zestal groeistadia aan te geven, te weten: ontkenning, verkenning, vervanging, integratie, transformatie en transparantie.

Nadat de technologie uit de R&D [131] -fase komt, zien we meestal het eerste stadium in het bedrijfsleven: de ontkenning. Hierbij horen kreten als ‘dit is niks', ‘dit is niks voor ons' of ‘dit waait wel over'.

Vervolgens zien we dat er schoorvoetend kleine lokale experimentjes worden ondernomen, hetgeen betiteld kan worden met het stadium verkenning. Dit alles draagt nog het stempel gewenning, een snuffelen aan het nieuwe speeltje.

Op een zeker moment gaat men omwille van efficiencyredenen door de bocht en wordt de technologie echt ingezet.

De volgende stap die dan kan worden onderscheiden is de integratie, het integreren van de betreffende technologie in de informatievoorziening om de effectiviteit van haar toepassing te vergroten.

Maar waar het uiteindelijk om gaat is de verbetering van het bedrijfsgebeuren met behulp van die informatietechnologie. Dat kan alleen optimaal als de betreffende bedrijfsprocessen worden opgewaardeerd om de nieuwe technologie te kunnen incorporeren. Dus na de tweede keer dat het bedrijf door de bocht gaat begint de wederzijdse beïnvloeding van het betreffende bedrijfsproces en de toepassingsvorm van die informatietechnologie. Deze verrijkingsslag begint met het stadium transformatie, hier ligt met name business process redesign en de herinrichting van de digitale werkruimte. Overbeek [7] beschrijft een architectuurschets van de digitale werkruimte van een topmanager.

Zoals in alle leerwegen, evolutiepaden, groeischema's ligt aan het einde het walhalla, de uiteindelijke verlichting van alle lasten. Dit draagt hier de aanduiding transparantie waarmee wordt aangegeven dat de bewuste technologie voor de gebruiker volledig transparant is. Bij verandering van het bedrijfsproces verandert dan de toegepaste informatietechnologie naadloos en instantaan mee.

Belangrijk bij de beschouwing van deze leerweg is de vraag welke technologieën relevant zijn voor de bedrijfssector waarin u zit, hoever zijn de concurrenten op de leerweg, welke concurrentievoordelen liggen in het verschiet bij versnelde toepassing.

5.8.3 transformatie van het informatievoorzieningssysteem

De informatievoorziening vormt het werkterrein van informatici en automatiseringsdeskundigen. De informatievoorziening wordt beschouwd te zijn opgebouwd uit drie lagen; van onder naar boven: technische structuur (de apparatuur, het netwerk en het operating system), gegevensstructuur (de structuur van de systeemgebonden en bedrijfsbrede gegevensverzamelingen) en informatiesystemen. Daarnaast zijn er nog verschillende organisaties rond de informatievoorziening (zoals directe gebruikers, beheerders, exploitatiepersoneel). Belangrijk in deze beschouwing is het streven om steeds meer zaken infrastructureel/facilitair te regelen.

De cruciale succesfactoren voor een bruikbare informatievoorziening zijn enerzijds het vermogen tot veranderen (flexibiliteit), doch anderzijds is de garantie voor stabiliteit van levensbelang. Het is de grote kunst om deze ogenschijnlijk tegengestelde tendensen in balans te krijgen. Voor een fundamentele aanpak hiervan is het nodig om grondig in te gaan op concepten als ‘architectuur' en ‘infrastructuur'. Dat afstemmingsspel voltrekt zich gedeeltelijk al tijdens het informatiebeleid.

5.8.4 onderlinge beïnvloeding

Idealiter zou de informatievoorziening naadloos dienen aan te sluiten bij de bedrijfsvoering. Anderzijds mag van een hedendaagse informatievoorziening worden verwacht dat zij zo flexibel is dat er voldoende ruimte wordt geboden om deze met nieuwe technologieën snel aan te passen aan de mogelijkheden van deze tijd.

Een van de redenen van inflexibiliteit die bij veel ondernemingen kan worden waargenomen komt door de grote kloof tussen de structuur van de bedrijfsvoering en de architectuur van de informatievoorziening. Daarom vormt de huidige informatievoorziening voor een onderneming nog al te vaak een belemmering om snel in te kunnen spelen op veranderende eisen en kansen van respectievelijk in de markt: het overbekende dwangbuisgevoel. Deze kloof kan worden overbrugd door architectuurstudies en modellering.

Een goede en flexibele architectuur van de informatievoorziening dient afgeleid te worden van een flexibele architectuur van het bedrijfsgebeuren. Binnen deze architectuurbeschouwingen vindt de modellering plaats: van bedrijfsmodellering via informatiemodellering naar applicatiemodellering. Modellering is in feite een specificatievorm die tot grotere flexibiliteit kan uitnodigen.

Bij de totstandkoming van een flexibele informatievoorziening dient maximaal gebruik te worden gemaakt van herbruikbare elementen. Dit omvat het hele scala aan referentiemodellen tot en met herbruikbare software, variërend van objecten en modulen tot pakketten. Voor het snel en goedkoop ontwikkelen worden kort-cyclische systeemontwikkelmodellen toegepast, waarbij het in elke iteratie belangrijk is om de toegevoegde waarde voor de gebruiker te bewaken door middel van ‘benefit tracking'. Trouwens de snelste manier van het ontwikkelen van informatiesystemen is nog steeds het simpelweg ontwikkelen van minder software. Door goede architectuurkeuzes kan worden getracht om meer zaken infrastructureel te regelen ofwel applicaties die - al dan niet gemodificeerd - bedrijfsbreed kunnen worden gebruikt. Een soort hergebruik in gebruik.

Zeer belangrijk zijn de relaties tussen de informatietechnologie enerzijds en het bedrijfsgebeuren en de informatievoorziening anderzijds. De bedrijfstransformatie en de verandering in de informatievoorziening dienen gemeenschappelijk te worden aangepakt. De informatievoorziening en haar transformatie dienen immers uitsluitend ter ondersteuning van een efficiënt, effectief, innovatief en flexibel bedrijfsgebeuren.

De cruciale voorwaarden in het streven naar flexibiliteit zijn: het architectuurvraagstuk, (bedrijfs)modellering, het managen van de aanwezige kennis en het hergebruik hiervan.

Resumerend wordt gesteld dat de architectuur van de informatievoorziening de flexibiliteit dient te bieden om mogelijke veranderingen in het bedrijfsgebeuren snel met applicaties te kunnen ondersteunen. Daarom dient de architectuur van de informatievoorziening een afgeleide te zijn van de architectuur van het bedrijfsgebeuren. Bovendien dient er voldoende ruimte te zijn in de gekozen architectuur om nieuwe standaarden en technologieën te kunnen incorporeren.

5.9 Literatuur

[1] Han van der Zee, Paul Laagland en Bas Hafkenscheid (2000), Architectuur als managementinstrument , Ten Hagen en Stam, ISBN: 90 440 0087 X.

[2] Daan Rijsenbrij en Guus Delen (2004), Enterprise architectuur is een noodzakelijke voorwaarde voor verantwoorde outsourcing , IT Service Management; best practices, Van Haren Publishing, pp 35-57, ISBN 90-77212-1217-5.

[3] Daan Rijsenbrij (2004), Checklist voor een business case , Informatie, april 2004 (outsourcing special).

[4] Roel Wagter, Martin van den Berg, Joost Luijpers en Marlies van Steenbergen (2001), DYA: snelheid en samenhang in business- en ICT-architectuur , Tutein Nolthenius, ISBN: 90 72194 62 4.

[5] Art Ligthart en Jan Vis, redactie (2002), Applicatieontwikkeling onder architectuur , ten Hagen & Stam, Den Haag, ISBN: 90 440 0667 3.

[6] Francis J. Gouillart and James N. Kelly (1995), Transforming the Organization , McGraw-Hill, ISBN: 0 07 - 034067 6.

[7] Sietse Overbeek (2005), Digitale architectuur: een architectuurschets van de digitale werkruimte van een topmanager . Master's thesis, Radboud Universiteit Nijmegen, ISBN: 90-9019196-8.

[8] Jürgen Laartz, Ernst Sonderegger, and Johan Vinckier (2000), The Paris guide to IT architecture , The McKinsey Quarterly 2000, number 3 pp. 118 – 127.

5.10 Vragen

1. Verklaar de zin: 'architectuur toont de vrijheid binnen de gebondenheid'.

2. Hoe wordt de universiteit master over haar value network?

3. Wat is voor de universiteit de toekomstige behoefte van haar klanten (welke?) waarop zij zou kunnen innoveren?

4. Hebben SOX en Basel II invloed op de architectuur? Onderbouw het antwoord.

5. Verklaar de uitspraak: ‘zonder transformatiemogelijkheden heeft een architectuurprent geen zin'.

6. Welke visie heeft de universiteit op het inzetten van e-business?

7. Hoe staat het met de forse hoeveelheid dossiers, oude procedures, verouderde organisatiestructuren op de universiteit? Onderbouw het antwoord.

8. Wat is bij de universiteit de kerncompetentie van de core business?

9. Welke ‘sense of urgency' heeft een universiteit om te beginnen aan een bruikbare architectuur?

10. Waarom roept ‘vereenvoudiging en helderheid' hetgeen wordt getracht te bereiken met een architectuurstudie, weerstand op?

11. Wat is het verschil in weerstand die optreedt bij een architectuurstudie en de weerstand die optreedt bij een transformatie?

12. Hoe kan het ondernemerschap op een universiteit worden aangemoedigd en gefaciliteerd?

13. Hoe maak je van een student een ondernemer in de context van zijn functioneren op een universiteit?

14. Wat is het belang van dashboards? En relateer dat aan het motto ‘ master of your own destiny '.

15. Welke rol zou de OR van een onderneming kunnen/moeten spelen bij het architectuurtraject en welke rol bij het transformatietraject?

16. Formuleer een aantal drastische maatregelen die op de universiteit zouden moeten worden genomen. Onderbouw het antwoord.

17. Hoe dienen de rollen in de drie bollen van de strategische driehoek op de universiteit organisatorisch te worden neergelegd? Onderbouw het antwoord.

18. Wat is het verschil tussen alignement en fusion ?

19. Noem enkele kansen en bedreigingen voor een universiteit die binnen 5 jaar kunnen actualiseren.

20. Waarom is projectarchitectuur eigenlijk een oneigenlijke benaming?

21. Wat zijn de belangrijkste producten en diensten van het onderwijsdomein en hoe kunnen die meer flexibel worden?

22. Beschrijf de zes fasen van de evolutie in het gebruik van informatietechnologie aan de hand van een technologie die reeds de transparantiefase heeft bereikt en voor een technologie die nog ergens halverwege is.

23. Som enkele technologieën op die mislukt zijn en geef de reden daarbij aan.

24. Welke relatie is er tussen de leerweg van de evolutie in het gebruik van informatietechnologie en de hypecycles van Gartner?

5.11 Oefeningen

1. Maak een schets van een niet-hiërarchische universiteit.

2. Maak een schets van de bedrijfstransformatie voor een universiteit in termen van Gouillart en Kelly en geef daarbij aan welke technologieën kunnen worden ingezet.

6. Menselijke Maat in IT: verantwoordelijkheid van de architect

trefwoorden: de mens centraal, mensbeeld, informatieovervloed, menselijke transformatie, mens-machine samenleving, realiteitsbesef.

6.1 Inleiding

Waarom aandacht voor de menselijke maat in een dictaat over digitale architectuur? Maat als middel tot echte bruikbaarheid is de verantwoordelijkheid van de architect. Het is niet redelijk om een bouwer [132] te verwijten dat het artefact niet aansluit bij de behoefte van de onderneming dan wel de behoefte van de eindgebruikers.

De Menselijke Maat is bij alles wat wij bouwen of construeren van kardinaal belang. Immers wij, als mensen, moeten het kunnen gebruiken. Het moet ons ondersteunen in ons zijn, ondersteunen in ons functioneren.

‘De mens is de maat van alle dingen' aldus Protagoras, de belangrijkste sofist uit de Griekse verlichting in de 5 de eeuw voor Christus. Deze zin bevat een aantal intrigerende woorden: ‘mens', ‘maat', ‘alle dingen'. Woorden waar nog veel op moet worden gestudeerd.

Het begrip Menselijke Maat is ook in de fysieke architectuur voortdurend onderwerp geweest van veel reflectie. Reeds in de grijze oudheid introduceerde Pythagoras de gulden snede. Maar de werkelijke studie van de menselijke maat is begonnen in de hoogtij van de Italiaanse Renaissance door Buonarroti Simoni Michelangelo di Lodovico (1475-1564) [133] .

Al sinds mijn eerste inaugurele rede getiteld ‘automatisering: vloek of zegen?' [1], ben ik bewust bezig met het vinden van de menselijke maat in IT-toepassingen en -gebruik.

Voor de fysieke wereld is een aardig boekje over de menselijke maat geschreven door twee deskundigen uit Delft, met als ondertitel ‘een studie over de relatie tussen gebruiksmaten en menselijke afmetingen, bewegingen en handelingen' [2]. Hierbij wordt de gewenste maatvoering afgeleid van de afmetingen van het menselijk lichaam, meestal gesymboliseerd door de ‘Vitruvius-man' van Leonardo da Vinci, tegenwoordig afgebeeld op de Italiaanse één euromunt. Le Corbusier heeft voor het ontwerpen van gebouwen in 1945 zelfs een proportieleer opgesteld uitgaande van de verdeelbaarheid van het menselijk lichaam volgens de Gulden Snede.

Voorbeeld van hoe het niet moet is de hoogbouw van de Vrije Universiteit: daar zijn de plafonds zo laag dat je je als mens in elkaar gedrukt voelt. En dat soort fenomenen zijn er op IT-gebied ook in overvloed. Er zijn van die applicaties waarbij je van die gekke dingen moet doen dat je je afvraagt ‘in welke dwangbuis hebben ze me nu weer gestopt?'

Wij staan op de drempel van het industriële tijdperk naar het informatietijdperk. Een stap die een grotere impact zal hebben dan het binnentreden van het industriële tijdperk rond 1865. Het zal grote moeite kosten voor de samenleving om enigszins ongeschonden door de informatierevolutie heen te komen. In dit tijdperk zullen namelijk totaal andere regels gelden, zowel economisch, sociaal, cultureel als ethisch. Willen wij als mensheid niet degraderen tot slome slachtoffers van een overdaad aan veelal nietszeggende informatie en plat amusement, dan moeten wij bewust iets doen.

Het Grote Drama in de IT-industrie wordt veroorzaakt door het feit dat er schijnbaar (op korte termijn) erg veel geld is te verdienen met de overhaaste toepassing van die IT. Daardoor worden de meeste uitvindingen nog voordat ze gerijpt zijn in de ‘laboratoria' tot een stabiel product, reeds ingezet in het functioneren van ondernemingen en overheid [134] .

De digitale wereld is nog steeds een wereld die wordt gedomineerd door technofreaks: techneuten die constructies creëren waarbij de technologische mogelijkheden centraal worden gesteld in plaats van de werkelijke behoefte van mens en onderneming. Daar word je als gebruiker meestal niet gelukkiger van.

De Menselijke Maat is een tweezijdig probleem. Ten eerste dient onze attitude ten opzichte van IT te worden gewijzigd, onze wijze van omgaan met IT dient meer volwassen te worden. We moeten leren op een menswaardige manier te functioneren in een technologische samenleving. Misschien ontstaat in de toekomst wel het beroep IT-pedagoog, die ons van jongs af aan leert hoe met IT om te gaan. Ten tweede moet software meer antropomorf ontwikkeld worden. Er moet tijdens het ontwerp meer rekening gehouden worden met de menselijke maat. Apparaten en digitale diensten dienen ons te worden aangeboden op een intelligentie- en vaardigheidsniveau dat bij ons past. Tot nog toe wordt de meeste software geschreven vanuit een tamelijk technische invalshoek door mensen die houden van het oplossen van problemen, hoe ingewikkelder hoe leuker. Wat wij nodig hebben is software die wordt geschreven door mensen die houden van mensen, software die past in de menselijke maat. En dat is de grote uitdaging voor de IT gemeenschap: ‘vind de Menselijke Maat in IT!'.

De tijd dringt! We moeten de menselijke maat ontdekken in de techniek voordat de computer de eerste mens heeft gemaakt. Het wordt een race tegen de klok, erop of eronder, wij (mensen) of zij (de computers): aan ons de keus!

Er is daarom een grote noodzaak dat digitale architecten in het komende informatietijdperk zich gaan bezinnen over hoe de mensheid staande kan blijven, zowel in het werk als in de privé-sfeer. Het is noodzakelijk dat bekeken wordt hoe de menselijke waardigheid bewaard kan worden en hoe bewustzijnsvernauwing wordt voorkomen in de steeds zogenaamd intelligentere vormen van automatisering.

In de bloeitijd van de Griekse beschaving werd veel werk gemaakt van allerlei beschouwingen over wiskundige onderwerpen. De plaats van de wiskunde als ordenende wetenschap wordt in onze tijd overgenomen door de informatica en de informatiekunde.

We zitten nu in het midden van een hectisch overgangstijdvak. Alles om ons heen wordt IT enabled en moet op het Internet. Nieuwe technologieën spoelen over ons heen. Logisch dat wij zo af en toe het gevoel hebben te verdrinken in de chaos van nieuwe IT-uitdagingen.

In deze behoefte aan orde en maat heeft het begrip architectuur zijn intrede gedaan in de digitale wereld. Er is een fundamentele behoefte aan orde, maat, discipline en schoonheid in de informatievoorziening, in software producten, in IT-diensten en zelfs in het ontwikkelproces an sich.

Bepaalde oplossingspatronen bij bepaalde problemen, bepaalde stijl in bepaalde omgevingen, bepaalde constructies onder bepaalde omstandigheden. Of wel digitale architectuur: een coherent en consistent stelsel van principes, regels, standaarden, richtlijnen, en metamodellen waaronder een informatievoorziening (of een deel daarvan) wordt ontworpen en geïmplementeerd.

Een binnenhuisarchitect hoorde ik laatst poneren dat een ruimte lekker moet aanvoelen, je moet je vrij en ontspannen voelen in een ruimte. Een ruimte moet ruimte bieden om optimaal te functioneren.

Een artefact, zowel fysiek als digitaal, voldoet aan de menselijke maat als het past in het denkraam van de eindgebruiker. Oftewel die eindgebruiker heeft begrip van het functioneren, hetgeen natuurlijk nogal persoonsafhankelijk is. Elke actie van de eindgebruiker leidt tot een voor hem herkenbaar resultaat. Dit geeft een gevoel van ‘comfortabiliteit'.

Een applicatie, een digitale werkplek, een PC of een ander elektronisch apparaat moet aanvoelen als een goedzittende prothese. Het is niet van jou, maar het voelt bijna natuurlijk aan. Het knelt niet, het irriteert niet. De realiteit met hedendaagse IT lijkt daar nog ver vandaan. Daarom worden veel applicaties ervaren als (on)dingen die hoofdpijn veroorzaken en je eindeloos dom werk laten verrichten. IT-systemen kunnen het bloed onder je nagels weghalen. Als je haast hebt laat het systeem het afweten, het systeem kan vaak de meest imbeciele foutwaarschuwingen genereren en het systeem is bijna altijd sneller of langzamer dan jij zou willen. Dat is niet wat je je werknemers wilt aandoen in het derde millennium. Daarom is elke ondernemer moreel verplicht om een volwassen digitale werkomgeving ter beschikking te stellen uit respect voor de mens achter de medewerker. Een juist ingerichte werkomgeving verleidt tot ontplooiing, verleidt tot groei in de uitoefening van je beroep. Het werkt als een katalysator voor professioneel enthousiasme. Dit geldt zowel voor de medewerker als in de relatie met de klant.

Naar de relatie tussen Mens en IT dient nog veel wetenschappelijk onderzoek te worden verricht. Verwacht in dit hoofdstuk dus geen pasklare antwoorden. Er wordt geprobeerd de probleemstelling wat helderder te krijgen, en zoals bekend: als de vraag echt helder is, is het antwoord nabij!

6.2 De Mens centraal

[135]

Een onderneming of een (overheids-) instelling bestaat uit mensen. Mensen die gezamenlijk proberen een doel na te streven. Alleen het menselijk bewustzijn brengt de onderneming tot leven. De rest, zoals financiën, fabriekshallen, kantoorgebouwen, vrachtauto's, apparaten, grondstoffen en halffabrikaten zijn slechts het decor waarin het bewustzijn zich manifesteert [136] .

Essentieel om die mensen, als groep, te laten functioneren is informatie-uitwisseling: ‘gebruikers hebben informatie nodig, geen apparaatjes!'. Toch laten gebruikers zich PC's, laptops, PDA's en GSM's aanpraten door technologieverkopers terwijl ze alleen maar informatie en communicatie willen. En dat terwijl al jaren wordt beweerd dat technologie slechts ondersteunend hoort te zijn.

Als ik zo af en toe gebruikers zie worstelen met slecht ontworpen applicaties, denk ik wel eens: waarom? Waarom, weiger je niet gewoon om er mee te werken. Als de luchtverversing het niet doet of als de baas te weinig uitgeeft aan de verwarming of de koffie niet te drinken is, leggen we het werk neer. Maar als we met hoofdpijnverwekkende IT-systemen moeten werken en met IT allerlei mallotige toeren moeten uithalen om eenvoudige dingen te realiseren, dan durft niemand wat te zeggen. Dan houden we onze mond stijf dicht, bang dat we voor dom worden versleten [137] . Mensen zijn niet dom, computers zijn dom! Zij kunnen slechts eindeloos hetzelfde kunstje herhalen [138] .

Het grootste probleem in onze industrie: ‘de gebruiker klaagt niet echt'. Onze bedrijfstak mist een soort consumentenbond die als pressiegroep namens de gebruikers misstanden aan de kaak stelt. Daarom heb ik in de Automatiseringgids in 2001 [3] een oproep geplaatst: ‘ gebruiker, word mondig! '? De technologie is tegenwoordig zo krachtig dat het mogelijk is om vanuit de mens te ontwerpen, in plaats van de technologie centraal te zetten. Door de dot.com-crise en het umts-debacle is een technologische ontnuchtering op gang gekomen. Een ontnuchtering die gevolgd zou moeten worden door een meer volwassen architectuuraanpak, die resulteert in IT-systemen die de mens dienen in plaats van de mens te degraderen tot een slaafje van de computer. Bij jezelf blijven is in de digitale wereld al moeilijk genoeg.

Architectuur is een teken van beschaving. Het cultiveert de belevingswereld van de eindgebruikers. Met technologie kan er zoveel dat het tijd wordt dat er mensvriendelijke applicaties worden gebouwd in plaats van de autistische systemen uit het mainframe tijdperk. HRM-directeuren en ondernemingsraden horen daadwerkelijk te participeren in de beoordeling van architectuurvoorstellen. Naast de directeur zijn zij verantwoordelijk voor de totstandkoming van een leefbare digitale werkomgeving.

De relatie tussen architectuur en (bedrijfs-)cultuur verdient genuanceerde aandacht, evenals het cultuuraspect bij het bijbehorende proces om te komen tot een architectuur. De mens als gebruiker hoort steeds centraal te staan, zijn maat is bepalend voor de juiste architectuur en het proces om te komen tot die architectuur. Architectuur gaat in feite over socio-culturele systemen.

De werkelijke uitdaging in de fysieke wereld is te bewerkstelligen dat architectuur een katalysator is om tot jezelf te komen of bij jezelf te blijven. Naast vormen zijn kleuren daarbij erg belangrijk. Het ‘tijdloze' bij de fysieke architect Christopher Alexander, auteur van ‘The timeless way of building' [5], doelt op zijn persoonlijke overtuiging dat architectuur dient aan te sluiten op een innerlijke beleving van de gebruikers en niet op de laatste modefratsen. Volgens hem was de architectuurtheorie in de zeventiger jaren van de vorige eeuw failliet. Te veel nadruk op visuele effecten en veel te weinig op ruimtelijke en emotionele beleving.

De overeenkomst met de IT wereld is groot. Ook die wereld wordt overstelpt door allerlei technologietjes, die als spiegeltjes en kraaltjes over de gebruikersgemeenschap worden uitgegoten. Veel visueel effect. De vraag naar een echte noodzaak blijft meestal achterwege. En, laten we eerlijk zijn: menig IT-systeem is zo saai, zo slaapverwekkend, zo sleurbevorderend als de onderliggende chips.

een mensbeeld

Verantwoorde toepassing van IT vraagt een modern mensbeeld. Maar eigenlijk hebben we geen adequaat mensbeeld voor het computertijdperk.

Een mens is meer dan zijn lichaam. Wij hebben in de digitale wereld dan ook meer nodig dan het bekende plaatje van Leonardo da Vinci. Daarom grijpen we terug naar oeroude modellen die herontdekt zijn door Gurdjieff [6], mede opgetekend door Ouspensky. Als men de mens wil gaan begrijpen en ook de zintuiglijke, fysieke wereld waarin hij zich geplaatst ziet, zal men oog moeten krijgen voor de drievoudige aard van de mens. De mens denkt, voelt en beweegt [139] . Dus zijn er Rede, Gevoel en Actie als centra of principes. Dit is een sterk vereenvoudigde voorstelling, maar voldoende voor onze beschouwing. Deze centra hebben ieder hun eigen aard en eigen functie en daarmee hun eigen wijze van functioneren. Maar een mens zal pas echt gaan functioneren wanneer hij alle drie centra weet te ontwikkelen. Hoe harmonieuzer hoe beter. Probleem is dat we een absoluut verkeerd beeld hebben met betrekking tot wat gevoel is. En vreemd genoeg denkt bijna iedereen ten onrechte dat hij of zij kan denken.

Het werkterrein van de computer overlapt met de uitvoerende delen van het denk- en bewegingscentrum. Denken en bewegen, althans op uitvoerend niveau, kan door de computer steeds beter worden gedaan. Voelen is een mogelijkheid die wij hem graag toedichten, maar die de computer absoluut nooit zal kunnen.

Interessant wordt nu de confrontatie tussen de machines: de mens-machine [140] en de computer-machine. Wie zal er uiteindelijk winnen? De computermachine die veel sneller is, nooit moe wordt en er geen humeur op nahoudt. Of de mens die wakker kan worden, die kan ‘ontsnappen' naar een hoger niveau.

6.3 De huidige toestand

De grot van Plato [7]

De schepping bestaat conceptueel uit verschillende presentieniveaus: het goddelijke niveau, het causale niveau (de ideeënwereld), het subtiele niveau en het fysieke niveau. De mens heeft de potentie op alle niveaus te kunnen functioneren. De computer functioneert slechts in de fysieke wereld en kan dus nooit een mens worden. Een mens kan echter wel degraderen tot een presentietoestand die beperkt is tot de fysieke wereld of erger nog tot de slaaf van de computer.

Plato stelt in de mythe van de grot dat we alleen maar naar de schimmen op de wand van de grot zitten te turen in plaats van bezig te zijn met de echte dingen des levens. Wie staart naar de schimmen in de grot leeft slechts op het fysieke niveau.

De automatisering van de samenleving betekent in feite dat wij druk bezig zijn om een kelder in de grot aan te leggen [141] . Wij staren immers naar de computerprojecties [142] van de schimmen, dus nog één niveau lager in het bewustzijnspectrum. Een kelder waar, wellicht net als vroeger, de apparaten (toen de CV [143] ketel en de wasmachine) staan opgesteld. Apparaten die moeten zorgen dat ons leven wordt veraangenaamd. In plaats dat wij na 2500 jaar proberen om uit de grot, de gevangenis van de zintuiglijke wereld, te ontsnappen, zijn wij bezig die gevangenis steeds luxer en behaaglijker in te richten. De kans is zeer wel aanwezig dat wij een enorme fascinatie gaan krijgen voor al deze ‘dode' apparaten en in die kelder willen gaan wonen.

Volgens Plato dienen wij omhoog te gaan: de grot uit. Maar wij gaan juist omlaag, verder de grot in. We gaan steeds verder de kelder in totdat iemand opstaat en zegt: "Alle gebruikers ter wereld wordt wakker, wordt Mens!".

Met behulp van de IT zijn wij dus voortdurend doende een subschepping in de schepping te creëren vol verleidelijke gemakken en doelen die wij in de schepping menen te moeten na streven. Een subschepping die door de uitgebreide netwerken (pseudo verbondenheid) oneindig groot lijkt te zijn. Maar zoals Krishnamurti nadrukkelijk stelde: ‘de beschrijving is niet het beschrevene'.

Het wilde wonen

Op 4 april 1997 interviewde Bernard Hulsman van NRC Handelsblad prof. Carel Weeber, toenmalig voorzitter van de Nederlandse bond van architecten. Dit roemruchte interview onder het kopje ‘Het Wilde Wonen' heeft veel los gemaakt in het Nederlandse architectenwereldje [8, 9]. Prof. Weeber ageerde tegen de grijze grauwe saaiheid, veroorzaakt door de rigide planningspraktijken à la Berlage. Het toenmalige vinex-beleid resulteerde volgens hem tot versteende tentenkampen die de mens elke vorm van leefgenot ontneemt.

Weeber's protest handelde over de architectuur in de fysieke wereld, de wereld van steden, gebouwen en landschappen. Maar ook de architectuur in de digitale wereld: de wereld van informatie, computers en netwerken lijdt aan iets dat lijkt op rigide planningspraktijken. Veel IT-systemen zijn gebouwd door techneuten die houden van slimme dingen in plaats van volwassen architecten die respect hebben voor mensen. Het wordt daarom de hoogste tijd dat er een volgende architectuurrevolutie wordt ingezet, maar nu in de digitale wereld. Het wordt tijd dat er een generatie van jonge architecten opstaat. Niet jong van jaren, maar jong van geest. Dus niet behept met al die moeizame constructie-ideeën uit de vorige eeuw. Architecten die houden van mensen en die hun creativiteit gebruiken om systemen te ontwerpen die mensen uitdagen zich te ontplooien.

Zeer veel vragen

Er zijn veel vragen om op te reflecteren over wat er allemaal op ons af komt in het aanstormende informatietijdperk. Vragen die belangrijk zijn voor het overleven in het informatietijdperk, zowel persoonlijk als als maatschappij:

1. Hoe gaan wij om met de alsmaar groter wordende vloedgolf aan informatie: informatiebehoefte of informatiehebzucht ?

2. Wat doen wij met de ongebreidelde mogelijkheden van de digitale snelwegen: communicatiebehoefte of ongebreidelde nieuwsgierigheid ?

3. Hoe ontplooien we onze creativiteit in een mechanische / geautomatiseerde samenleving: creativiteit versus mechaniciteit (zuigkracht en verslaving) ?

4. Hoe zorgen wij dat wij aan het roer blijven staan: het besluitvormingsproces (bewust beslissen versus mechanische afwegingen) ?

5. Hoe houden wij een gezonde relatie tot de natuur: verregaande technische automatisering en robotisering ?

6. Hoe vinden wij het juiste maatgevoel ondanks de ‘hectiek' door de computer: orde & discipline ?

7. Hoe blijven wij onszelf in een virtuele wereld: ontwikkeling van een ‘digital lifestyle' ?

8. Hoe voorkomen wij een steeds groter wordende tweedeling in de maatschappij: IT-enabled en IT-disabled people?

9. IT is voedingsbodem voor een vloedgolf aan nieuwe ziektes, zowel lichamelijk als geestelijk! Enkele zaken die nu reeds worden gezien:

· R.S.I. en andere lichamelijke klachten (ogen, nek etc.);

· C.R.A. (Computer Related Anger);

· verslaving (mondiaal zappen, spelletjes, chatten);

· verminderde lichaamsbeweging en minder buitenlucht;

· ritmeverstoring (gejaagdheid, veroorzaakt door de apparatuur);

· informatie-stress;

· verminderd realiteitsbesef; schijn- versus werkelijkheidsproblemen (verminderd contact met de fysieke wereld);

· vereenzaming in een geautomatiseerde subschepping (inclusief bewustzijnsverlaging);

· identiteitsproblemen;

· onverschillige slordigheid (van sleur, via ‘sleurdigheid' naar slordigheid).

Hoe nu verder?

De IT-problemen door de overgang naar het jaar 2000 hebben getoond dat het functioneren van de samenleving en in het bijzonder de economie, niet meer zonder IT kan.

Dat vereist dat de overheid toezicht houdt op de kwaliteit van die IT en haar inzet. De overheid waakt over ons welzijn, zowel geestelijk als lichamelijk. Een fysieke architect heeft daarom te maken met steeds meer overheidsregels waaraan zijn bouwwerken moeten voldoen om te voorkomen dat mensen ziek worden [144] . Waar blijft die overheid met regels voor IT-systemen? Regels om te zorgen dat haar burgers gezond kunnen werken. Op dit gebied lijkt zij zich te beperken tot privacyreglementen. Is de regelgever niet toegerust voor de digitale wereld of laat zij dit maar een tijdje op haar beloop?

Het wordt tijd dat wij gaan beseffen dat de kwaliteit van ons leven in het geding is. Hoe echt is ons bestaan nog, hoe inspirerend? Is er nog ruimte voor echte creativiteit?

In de volgende subparagrafen wordt de probleemstelling verder uiteengerafeld:

6.4: Informatie of Transformatie; naar een nieuwe pedagogiek?

6.5: Mens-Machine samenleving; naar een nieuwe sociologie?

6.6: Psychologische ontwikkeling van de mens in het IT-tijdperk; naar een nieuwe psychologie?

6.7: Realiteit & Creativiteit in een geautomatiseerde omgeving; naar werkelijk Leven!

6.4 Informatie of Transformatie?

Moderne informatietechnologie zorgt middels computers en communicatietechnologieën dat de vloedgolf aan te verwerken informatie steeds groter wordt. Maar hoe vertaalt zich dit in menselijke ontwikkeling? Laten wij ons volstoppen met steeds meer informatie (van soms oncontroleerbare kwaliteit), of proberen wij die informatie te verwerken, te transformeren waardoor ons wezen wordt verrijkt? Door onze bijna aangeboren neiging tot hebzucht proberen we steeds meer informatie te vergaren. Is dit zinvol? Geeft dit ons meer zekerheid? Zullen wij ooit genoeg krijgen? Of moeten wij resoluut een halt toeroepen aan het ‘hebben' in de digitale wereld!

De kwaliteit van het bestaan wordt steeds meer afhankelijk van de kwaliteit van die informatie en de mate waarin die informatie ook daadwerkelijk verwerkt (verteerd) wordt.

De stortvloed aan informatie neemt welhaast exponentieel toe in de tijd. Niet de beheersing van de technologie maar het leren omgaan met die informatie dient op de eerste plaats te staan. De keus in die informatieovervloed is ‘matig of verzuip', immers ‘ in der Beschränkung zeigt sich der Meister'. De grote kunst is hoe leren wij op een volwassen wijze om te gaan met informatie.

Blijf af van informatie die je niet echt nodig hebt. Er zijn drie soorten informatie: nodige, onnodige en ‘nog-niet-nodige'.

De eerste categorie is direct duidelijk. De grens tussen de tweede en derde categorie is enigszins vaag. Maar de laatste categorie is de grote verleider. Hebzucht naar informatie maakt dat wij een gigantische hoeveelheid schijfruimte nodig hebben. Bang dat wij zijn dat, als het tijdstip aanbreekt dat wij de bewuste informatie nodig hebben, wij er niet bij kunnen, gaan wij het alvast opbergen. Deze laatste categorie verleidt ons ook tot een soort verzamelwoede die niet onder doet voor geldelijke hebzucht.

Wij dienen te komen tot een volwassen vorm van kennismanagement. Maak een ‘personal web' waarin slechts een summiere hoeveelheid paraat benodigde informatie / kennis aanwezig is en veel links naar plaatsen en personen waar je additionele informatie en kennis kunt vinden.

Een oud Indisch spreekwoord luidt: ‘kennissen zijn belangrijker dan kennis'. In plaats van alles voor jezelf te willen weten is het verstandig kennis met anderen te delen en te vertrouwen op de kennis van anderen. Dit vraagt de juiste kennissenkring (wellicht digitaal [145] ) en het vertrouwen dat je op het uur ‘u' ook een beroep op die kennis kan doen.

De moderne technologie biedt ons de mogelijkheid om op elk moment en met iedereen te communiceren. Wat zal dat voor invloed hebben op onze sociale patronen, op onze werkomstandigheden? Gaan wij digitale kennissenkringen ontwikkelen? Worden wij digitaal door een overheid bestuurd? Wordt onze ontplooiingsruimte door die informatietechnologie werkelijk vergroot?

Het ‘World Wide Web' is een vloek en een zegen voor de mensheid. Het multimediale circus van het ‘World Wide Web' bloeit op tot Disney-achtige proporties. Aan de ene kant een nieuwe uitdaging om onze creativiteit te uiten (ontplooiingsruimte in cyberspace), aan de andere kant het risico te worden opgesloten in een gevangenis van schone schijn.

Zwervend over het ‘World Wide Web' verbaas ik mij telkenmale over de veelheid aan weetjes die er op deze aardkloot aanwezig zijn. Ik denk daarbij vaak aan de uitspraak van Socrates, toen hij met een leerling over de markt van Athene wandelde: “wat is er toch veel in de wereld wat ik niet nodig heb”. Het Internet en de mogelijkheden die ons, onder de noemer e-business, worden aangeboden hebben veel weg van een lopend buffet. Alles ziet er aanlokkelijk uit, het een lonkt nog verleidelijker dan het ander. Maar als je niet uitkijkt, blijf je na dat je veel en veel te veel naar binnen hebt gewerkt, zitten met een gevoel van pijn in je buik. En dat heeft niets meer te maken met genieten! Voor een lopend buffet zijn maat en discipline van groot belang om daadwerkelijk te genieten, dat geldt m.m. ook voor het Internet en het ‘World Wide Web'.

Wij moeten leren informatie persoonlijk te verwerken. Informatie waar wij niet iets mee doen is overbodige ballast. Het remt ons in adequaat functioneren, als een dikke winterjas in hartje zomer. Stilstaande informatie (in onze kop, in onze kast, op onze harde schijf) is als niet-stromend water, het gaat ‘rotten'. Wij raken overbelast en kunnen werkelijk relevante informatie niet meer naar waarde schatten.

Door informatie te verwerken, verrijken wij ons functioneren. Dit kan zelfs leiden tot transformatie. In feite geldt dit niet alleen voor de mens als individu en als werknemer, maar zeer zeker ook voor een onderneming en zelfs voor de gehele samenleving.

6.5 Mens-Machine samenleving

In het algemeen wordt het gebruik van gereedschappen gezien als een teken van menselijke beschaving. Heel lang zijn die gereedschappen volledig passief geweest. We zijn nu in een fase gekomen waar we gereedschappen en apparaten kunnen maken die pseudo-intelligent gedrag vertonen. Gereedschappen, al of niet fysiek, die uitgerust zijn met chips.

Door hun interactieve karakter en het feit dat ze langzamerhand zelf initiatieven lijken te kunnen gaan ontplooien (althans voorgeprogrammeerde opdrachten kunnen uitvoeren geïnitieerd door een externe impuls), impliceert dat ze ons leven en werken fundamenteel beginnen te beïnvloeden. Wij moeten rekening houden met hun aanwezigheid.

In het tijdvak 1950 – 2000 is de administratieve en bestuurlijke automatisering opgebloeid. Een ontwikkeling die gestadig zal doorgaan. In het tijdvak 2000 – 2050 zullen wij de toepassing van de robotologie zien opbloeien.

In het eerste tijdvak zagen we een steeds verdere penetratie van IT in onze samenleving. Aan het begin werden voornamelijk het eenvoudige denkwerk, geheugenwerk en de administratieve, routinematige handelingen ondersteund door computers. Wat volgde, was een eerste aanzet tot een volledige automatisering van de communicatie, waardoor alles met alles kan worden verbonden. Door gebrek aan deugdelijke architectuur heeft dit tot chaos geleid (Y2K, euro, SOX). Nieuwe technologieën spoelden over ons heen. Logisch dat wij zo af en toe het gevoel hadden te verdrinken in de chaos van nieuwe IT-uitdagingen. We zagen vooral de fouten en letten minder op de goede dingen. We waren bezig met uit te sorteren wat wel werkte en wat niet, maar op technologiegebied boekten we enorme vooruitgangen.

Het tweede tijdvak zal worden gekarakteriseerd door de automatisering van de sensoriek en de motoriek. Door de opkomst van robots worden vele menselijke functies in het vlak van waarneming en beweging (fysieke handelingen) ondersteund dan wel volledig overgenomen. Dit zijn niet alleen fysieke robots uitgevoerd in blik & plastiek, maar ook zogenaamde softbots. Softbots zijn actieve stukken software die opdrachten kunnen uitvoeren geïnitieerd door een externe impuls [11].

Nu reeds (2005) zien wij dat de wereld veel ingewikkelder wordt door de snel voortschrijdende computerisering van onze maatschappij. Steeds meer handelingen worden ondersteund of zelfs volledig uitgevoerd door computers. Steeds meer apparaten worden uitgerust met chips zoals intelligente magnetrons, intelligente wasmachines, intelligente thermostaten, intelligente televisies. En straks kunnen al die intelligente apparaten óók nog, via een eigen deel van het Internet, met elkáár communiceren. Kortom de fysieke wereld wordt een uiterst rationeel en mechanisch gebeuren.

Is dit de terugkeer naar het paradijs of wordt het leven een kil strijdtoneel waarop er straks voor de mens niets meer is te doen. Wordt het leven gedegradeerd tot het uitzitten van een slordige honderd jaar, ondersteund door wat interactieve televisie en gecontroleerd via het Internet?

De traditionele sociologie houdt zich bezig met het gedrag van groepen mensen en hun onderlinge interactie. Bij steeds meer handelingen van en tussen mensen zullen machines aanwezig zijn. Wij gaan naar een samenleving waar wij serieus rekening moeten gaan houden met het gedrag van machines richting ons mensen en het gedrag van machines onderling. Omdat heden ten dage de meeste informatie direct dan wel indirect door machines wordt geleverd, wordt de relatie tussen machines en mensen een belangrijk sociologisch vraagstuk. Aan de ene kant verlossen computers ons van veel geestdodende werkzaamheden, aan de ander kant is er niets zo eigenwijs als een computerprogramma. Maar we zullen ze moeten leren verdragen.

Binnen een decennium zullen wij omringd zijn door tientallen chips die met ons communiceren en met elkaar. Een ‘intelligent environment' die ons leefmilieu verrijkt, bewaakt en in de gaten houdt. Allemaal elementen waaraan wij een vals gevoel van veiligheid overhouden.

In de toekomst zal blijken dat computers in veel zaken die wij nu als belangrijk zien, beter zullen zijn dan wij. De computer kan heel veel sneller associëren, deduceren, combineren, classificeren, indrukken opbergen, vergelijken, redeneren en ideeën formuleren dan de mens. Daarnaast wordt hij niet moe, heeft geen gemoedswisselingen en heeft altijd zin. De ogenschijnlijke complexiteit van onze samenleving wordt zo onbeheersbaar dat het lijkt dat alleen machines dit nog aankunnen. Het bedrijfsleven en de overheid kunnen niet meer zonder IT.

Computers hebben meedogenloze discipline. Mensen zijn erg slordig. Als de mens niet wat doet met die discrepantie, gaat hij ten onder aan de computerstress.

De aandachtsboog van de mens wordt o.a. door IT-gebruik steeds korter. Daar zijn meerdere redenen voor:

· individualisering impliceert dat er veel aandacht wordt opgeëist;

· ontmanteling van de hiërarchie;

· alles is met alles verbonden, dit zorgt voor een toename van de complexiteit.

Het aantal fouten dat een mens maakt per handeling, doordat zijn aandachtsboog zeer kort is, neemt heel langzaam af over de afgelopen millennia. Maar de computer zorgt voor een snelle uitvoering. Dus het aantal fouten dat een mens per tijdseenheid maakt, in de ‘ogen' van een computer, neemt drastisch toe. Bovendien beginnen fouten onderling te interfereren.

Voorts is er veelal een groot tempoverschil tussen de mens en de computer. Dit veroorzaakt veel onrust en hectiek.

Aandacht voor ‘aandacht' en ‘ritmeverschillen' vormen de twee belangrijke factoren voor een harmonische mens-machine samenleving.

Moeten wij nu al aan dit probleem, van de mens-machine samenleving, aandacht schenken, terwijl de machine-dichtheid nog redelijk beperkt is? Ja, bij de introductie van de auto is er geen echt moment geweest waar wij hebben nagedacht aan de mogelijk toekomstige verkeersproblematiek. Steeds wat meer auto's, steeds wat meer wegen, die allengs steeds breder werden. Totdat wij bijna stikten in de files. Laat de mensheid bij de grootscheepse invoering van pseudo-intelligente machines wat meer beleid aan de dag leggen.

Een van de belangrijk zaken in een mens-machine samenleving is identiteitsbeheer. Niet alleen gebruikers van vlees en bloed dienen te kunnen worden geauthenticeerd, maar ook applicaties en devices. Er worden door SOX en Basel II [146] steeds zwaardere eisen gesteld aan de controleerbaarheid van de onderneming. Er moet dan ook duidelijk zijn wie en wat zijn geautoriseerd en gekoppeld aan applicaties, databases en directories. Ook bij calamiteiten dient duidelijk te zijn wie en wat met de betreffende systemen in aanraking zijn geweest [147] .

De informatietechnologie zal in een relatief klein aantal jaren het aanzien van de wereld drastisch veranderen. Oude normen en waarden zullen worden ontmanteld. Oude zekerheden over werkverbanden en zogenaamde sociale garanties zullen voorgoed tot het verleden gaan behoren. De grote vraag is hoe wij in psychologische zin als mensheid door deze ‘stille' revolutie zullen heenkomen. Anders dan de industriële revolutie die zich slechts voltrok in de fysieke wereld zal deze revolutie ons totale wereldbeeld omverwerpen. Dit is immers een revolutie die haar zwaartepunt heeft in de mentale wereld.

In die nieuwe computerondersteunde wereld zien we drie lagen, als het ware drie soorten gemeenschappen: mensen, ‘stukken' software (waaronder actieve software [148] ) en hardware devices. Dit geeft een heel nieuw beeld van samenwerken. Samenwerken binnen je eigen soort, maar ook samenwerken tussen die gemeenschappen.Dat zal flink wat spanning opleveren. Immers elke gemeenschap heeft zijn eigen doelstellingen, zijn eigen aard en zijn eigen tempo.

Het is de verantwoordelijkheid van de architect om te zorgen dat de gebruiker ten volle begrijpt hoe het apparaat functioneert. Architecten moeten een samenleving ontwerpen waarin een verantwoorde symbiose wordt aangegaan met deze apparaten die steeds slimmer beginnen te worden. Sommigen zullen zeggen dat het slechts onze slimheid is waarover ze beschikken, slimheid die wij erin gestopt hebben. Dat is waar, maar wel de slimheid van een zeer groot aantal van ons, uitgevoerd met een snelheid waar wij als eenvoudige stervelingen niet meer aan kunnen tippen.

6.6 Persoonlijkheidsontwikkeling in het IT-tijdperk

IT ondersteunt onze psychologische zwakheden. Door de uitvinding van de computer zijn geen wezenlijk nieuwe psychologische problemen geïntroduceerd. Wij, als mensen, zijn alleen zo lui geweest dat we in het verleden onze problemen niet hebben opgelost. Problemen als privacy, copyright, georganiseerde misdaad, diefstal, ongelijkheid, etc., etc.

Deze problemen spoelen nu, IT-enabled, op wereldschaal en met de snelheid van het Internet over ons heen.

Door de sterke interactie tussen machines en mensen dringt zich de vraag op wie programmeert wie. Niet alleen dat mensen de computer programmeren, de computer op zijn beurt programmeert [149] ook zijn gebruikers: steeds vaker, steeds omvangrijker en steeds indringender. Is de machine soms al bezig bij ons een persoonlijkheid te maken die past bij diezelfde machine?

De mens wordt geboren met een essentie. Vanwege deze essentie, kan ieder mens komen tot de ontwikkeling van zijn individualiteit, met specifieke kenmerken, talenten en karaktereigenschappen.

Om te kunnen leven in het ondermaanse worden een groot aantal rollen ontwikkeld waarmee de vertaalslag van binnen naar buiten en vice versa wordt bewerkstelligd. Deze rollen vormen samen de persoonlijkheid. Het woord persoonlijkheid komt van per-sona (dat waar het geluid doorheen komt). Of te wel het masker dat toneelspelers vroeger gebruikten om een bepaalde rol vorm te geven. De persoonlijkheid ontwikkelt zich in het beste geval tot een instrument dat dienstbaar hoort te zijn aan de essentie.

Wij hebben de persoonlijkheid dus nodig voor de communicatie tussen de binnenwereld en de buitenwereld. Vanwege noodlottige omstandigheden in de schepping wordt er bijna altijd in de persoonlijkheid een extra rol geformeerd die tracht het functioneren van de essentie over te nemen: het ego. Die rol, ook wel aangeduid met ‘ik, mij en mijn' [150] , probeert de baas te spelen en verontreinigt veel van de andere rollen.

De persoonlijkheid zou in niet verontreinigde vorm als neutraal vertaalinstrument (van de essentie) kunnen functioneren.

De persoonlijkheid wordt op een bepaalde manier geprogrammeerd door het lichaam, door de ouders, de buren, de school etc. etc, en dus in feite door het leven zelf. Maar in dit IT-tijdperk is de computer met al haar applicaties de grootste ‘boosdoener' bij het programmeren van de persoonlijkheid.

Vaak zien wij dat de valse persoonlijkheid de essentie overwoekert en voorkomt dat de essentie tot bloei komt. Het gebruik van computers, waarin samenspraak volledig achterwege blijft, blijkt bij uitstek de ontwikkeling van valse persoonlijkheid te bevorderen.

Het tempo van de computer kan de persoonlijkheid oververhitten en blijvende schade toebrengen. De huidige computerprogramma's interacteren met hun menselijke gebruikers in hun eigen tempo. Ze houden absoluut geen rekening met het tempo dat geschikt is voor die gebruiker. Daardoor komen ze vaak ‘drammerig' over, veroorzaakt door de botte consequentheid van het functioneren van de computer.

Als mens hebben wij vaak het gevoel dat wij ons moeten aanpassen aan het tempo van die bepaalde applicatie. Dat is niet zonder gevaar. De chips worden in hoog tempo verder opgevoerd. Wij, mensen, kunnen onze verwerkingssnelheid alleen opvoeren door de computerverwerking te transcenderen.

Voorts lijkt het of de computer onze werkbelasting gaat dicteren. Het is daarom belangrijk dat wij aan onze eigen orde en structuur trouw blijven. Hiertoe moeten wij ons als mondige mensen kunnen en durven opstellen. Wie brengt de moed op zijn onvermogen ten opzichte van de computer publiekelijk te erkennen?

Vrij naar Marx kan worden gesteld dat IT opium is voor het volk. IT sust mensen in slaap. Enerzijds biedt de informatietechnologie fascinerende mogelijkheden om ons te verlossen van geestdodende werkzaamheden. Aan de andere kant bieden geautomatiseerde producten en diensten een vaak verslavende zuigkracht en verleidt diezelfde technologie ons tot een ‘geautomatiseerd' leven. En hierin ligt het grootste gevaar van die automatisering. De grote angst van deze eeuw wordt de mechanisering van onze handelingen, doordat de computer ons verleidt tot eindeloze herhaling van hetzelfde. Door de IT worden wij ingekapseld in vaste patronen: gevangenen van het web van het geautomatiseerde denken [12].

De atoombom, de nachtmerrie van de vorige eeuw waar wij langzamerhand uit verlost zijn geraakt, kon de wereld vernietigen. De uitvinding die nu wereldwijd wordt uitgerold, is dan niet in staat de wereld fysiek te vernietigen, maar kan wel het menselijk bewustzijn doen bevriezen en de menselijke creativiteit om zeep brengen.

De kunst aan ons om deze prachtige technologie aan te wenden tot zegen van de mensheid. Belangrijke vraag in de toekomst wordt ‘wie er nog de moed op kan brengen zich zo af en toe IT-loos voor te doen'.

Teveel virtualiteit kan de persoonlijkheid uit balans brengen. De persoonlijkheid wordt onder andere geprogrammeerd, geconditioneerd door de waarnemingen uit de ons omringende wereld. Sommige waarnemingen zijn echt, andere zijn kunstmatig. Teveel te worden geconfronteerd met virtuele werkelijkheden in een te laag bewustzijnsniveau zorgt dat in onze persoonlijkheid een onwaar (verontreinigd) beeld van de werkelijkheid wordt ingegraveerd. Dit heeft een uitermate verwarrende uitwerking waardoor de daadkracht van onze persoonlijkheid verzwakt.

6.7 Realiteit & Creativiteit in een digitale wereld

Door de invoering van het Internet hebben we de mogelijkheid gekregen met onze laptops of PDA's door de hele wereld heen te werken alsof wij thuis of op kantoor zijn. Iedereen is met iedereen verbonden via Internet, via satelliet, via GSM: ‘always connected, always on'. Een wereldwijde infrastructuur die grenzen doet verdampen. Grenzen tussen volkeren, maar ook grenzen tussen vrije tijd en werk. En het einde is nog niet in zicht. We gaan waarschijnlijk naar een soort Startrek-achtige interface met alomtegenwoordige computerfaciliteiten.

Het is straks vreemd, bijna stiekem, als je even niet te bereiken bent.

De combinatie van de proliferatie van de chips en de toenemende realiteit van gegevens levert een virtuele wereld. Een wereld die net echt lijkt, maar volledig mechanisch is.

Via het Internet reizen mensen door een elektronisch landschap. Verkennen al zomerhuisjes zonder dat ze fysiek op de plaats van bestemming zijn, kunnen concerten multimediaal mee maken zonder van huis te hoeven, kunnen lessen volgen met een coach op afstand. Daarnaast regelen ze hun bankzaken vanuit hun huiskamer, bestellen boeken en kopen vliegtuigkaartjes zonder uit hun stoel te komen.

Het wordt uitermate moeilijk om de werkelijkheid echt te beleven [151] . Bovendien helpt de computer ons zaken virtueel te maken, oftewel dingen te laten zien die er niet zijn. De computer creëert daardoor een schijnwerkelijkheid.

Maar omdat elk instrument interpreteert en vertaalt, rijst de levensgrote vraag naar het waarheidsgehalte van die waarneming. Bovendien hebben we nauwelijks meer zicht op de kwaliteit (juistheid, volledigheid, actualiteit, nauwkeurigheid) van de tussenliggende data.

Waarneming middels computers is dus vaak lichtelijk vervuild en werkt versluierend. De computer, zeker als wij haar laten samenwerken met andere instrumenten zoals de telescoop, de microscoop en de telefoon, verruimt ons waarnemingsvermogen op een gigantische schaal. Aan de andere kant zouden wij ons er meer van bewust moeten zijn dat met hetzelfde gemak een gigantische beperking kan optreden.

De mens is een scheppend wezen. Creativiteit is zijn belangrijkste potentie. In een schijnwereld die dicht geprogrammeerd is met mechanische patronen, is het welhaast onmogelijk om de creativiteit naar buiten te laten komen. Een leven zonder creativiteit is saai en stomvervelend.

IT is een must voor bedrijven, overheid en samenleving, doch creativiteit en ondernemerschap zorgen voor de finishing touch. De huidige IT is vaak een dwangbuis voor menselijke creativiteit en onderscheidingsvermogen. De mens dreigt de toetsenbord-slaaf te worden van (slechte) software, totdat de computer de mens niet meer nodig heeft.

Wie neemt de echte beslissing, de programmatuur [152] of de mens?

Uiteindelijk gaat het om de verhoging van de kwaliteit van ons leven, hoe echt is ons bestaan nog, hoe inspirerend. Is er nog ruimte voor echte creativiteit?

Zou de IT-wereld zich hier niet veel meer moeten verbinden met creativiteit in de ware zin des woords? IT moet mensen en organisaties uitdagen zich te ontwikkelen en moet ontplooiingsruimte aanreiken.

Niet alleen door het sponsoren van concerten en culturele aangelegenheden, maar door samen met kunstenaars creatieve invallen opnieuw te ondergaan, te waarderen en vervolgens met de opgedane ervaring ook de IT en haar gebruikers tot bloei brengen.

Schoonheid is de richtingaanwijzer om echtheid te onderscheiden en creativiteit tot bloei te laten komen, zie de dialoog tussen Socrates en Diotima, die ik in mijn eerste inaugurele rede ook reeds heb aangehaald [1]. Schoonheid impliceert schoon-zijn, schoon van allerlei vervuilende, kleinzielige zaken die onrust oproepen. Schoonheid is een bruikbaar middel om uit de sleur der gewoonten te komen. Een middel om onszelf terug te vinden.

Een pleidooi dus om het scherm het scherm te laten en je af te vragen waar je jezelf geraakt weet door schoonheid.

6.8 Literatuur

[1] D.B.B. Rijsenbrij (1993), Automatisering: vloek of zegen? ; Inaugurale rede uitgesproken bij de aanvaarding van het bijzonder hoogleraarschap (1993 – 2002) in de bedrijfsinformatica aan de Vrije Universiteit, Lansa Publishing, Leidschendam, ISBN: 90 71996 83 2.

[2] A.J.H. Haak en D. Leever-van der Burgh (1994), De menselijke maat: een studie over de relatie tussen gebruiksmaten en menselijke afmetingen, bewegingen en handelingen , Delftse Universitaire Pers, ISBN: 90 6275 048 6.

[3] Daan Rijsenbrij (2001), ‘Gebruiker: word mondig!; eis mensvriendelijke IT-systemen; neem een echte architect in de arm' , Automatisering Gids, nummer 47, pagina 14.

[4] Pieter van der Ree (2000), Organische architectuur: Mens en natuur als inspiratiebron voor het bouwen , Uitgeverij Vrij Geestesleven, Zeist, ISBN: 90 6038 484 9.

[5] Christopher Alexander (1979), The Timeless Way of Building , Oxford University Press, ISBN: 0 19 502402 8.

[6] Jean Vaysse, 1983, Ontwaken in onszelf, een benadering van de door Gurdjieff nagelaten leer , Mirananda, ISBN 90-6271-680-6.

[7] Plato, de mythe van de grot, over schaduw en werkelijkheid , de Staat VII, 514 – 518.

[8] Carel Weeber (1998), Het Wilde Wonen , Uitgeverij o1o, Rotterdam, ISBN: 90 6450 341 9.

[9] redactie: Joep Habets , Kees van der Hoeven (1999), Het Wilde Wonen: de prijsvraag , Uitgeverij o1o, Rotterdam, ISBN: 90 6450 374 5.

[10] OC&W, VROM, V&W en LNV, Ontwerpen aan Nederland: architectuurbeleid 2001 – 2004 , SDU Uitgevers, Den Haag, ISBN: 90 12 08982 4.

[11] Hans Goedvolk en Daan Rijsenbrij (1999), Actor-based: The Next Generation Architecture , Proceedings of the First BeNeLux conference on Software Architecture.

[12] Krishnamurti J. (1983), Het web van het denken , Mirananda, Wassenaar.

6.9 Vragen

1. Waarom is de menselijke maat de (eind)verantwoordelijkheid van de architect?

2. Geef enkele normen betreffende de menselijke waardigheid.

3. Geef enkele voorbeelden van wat jij verstaat ook menselijke maat in het informatieverkeer, bij het gebruik van een applicatie, bij het gebruik van apparatuur.

4. Geef een voorbeeld van menselijk maat in het ontwikkelproces. Hoe kunnen tools daarbij helpen om terug te keren tot de menselijke maat.

5. Geef een voorbeeld van een ‘imbeciele' foutmelding.

6. Met welk mensbeeld ben jij opgevoed? Voldoet dit mensbeeld nog in het informatietijdperk? Is het mogelijk met dit mensbeeld de problematiek van de menselijke maat in IT op te lossen? Onderbouw de antwoorden.

7. Wat wordt bedoeld met ‘bij jezelf blijven'?

8. Volgens Rijsenbrij is ‘architectuur een teken van beschaving'! Hoe zou je hier beschaving willen definiëren.

9. Beschrijf een digitale subschepping waarin jij graag verblijft.

10. Geef voorbeelden van de eerste verschijnselen van een mens-machine samenleving.

11. Noem enkele zaken die computers beter kunnen dan mensen en waar wij, als mensen, vroeger trots op waren.

12. Geef voorbeelden van complexiteit die alleen computers nog maar kunnen managen.

13. Hoe blijf je de baas over je eigen aandacht in een hectische mens-machine samenleving?

14. Hoe ga je om met tempoverschillen tussen IT devices en jouw eigen levensritme.

15. Geef een voorbeeld van een applicatie die drammerig overkomt.

16. Noem enkele virtualiteiten die jij zelf gebruikt. Welke zijn al zo transparant dat wij ze niet eens meer herkennen als virtualiteit?

17. Welke virtualiteiten zijn schadelijk voor jonge kinderen?

18. Noem enkele applicaties die onze creativiteit daadwerkelijk uitdagen.

6.10 Oefeningen

1. Maak voor jezelf een lijstje afspraken met bijbehorende maatregelen waardoor je de vloedgolf aan informatie en kennis op een ordentelijke manier kan managen.
Pas dit minstens zes maanden toe.

2. Vind enkele website die een dergelijke architectuur hebben dat ze beschaving uitstralen en enkele websites die een totaal gebrek aan beschaving laten zien. Onderbouw je waardeoordeel.

3. Bestudeer grondig de grot van Plato. Analyseer welke applicaties je verleiden om in de grot te blijven. Bepaal wat je daar aan kan doen. En doe het!

[1] Zie ter inspiratie de digitale economie van Don Tapscott [3].

[2] We worden uitgedaagd ons een meer adaptieve ‘lifstyle' aan te meten om staande te kunnen blijven in een uiterst volatiele omgeving.

[3] Met ‘onderneming' wordt hier ook bedoeld (overheids-) instelling. Het woord ‘organisatie' reserveren wij voor het resultaat van het organiseren.

[4] Ordening, ook wel structurering, is een gebruiksaspect.

[5] Digitale architectuur is een verkorte schrijfwijze voor ‘architectuur in de digitale wereld'. Semantisch geeft een bijvoeglijk naamwoord een nadere kwalificatie van het daarop volgend zelfstandig naamwoord, maar dat wordt hier niet zo bedoeld. Dus niet de architectuur is digitaal maar de artefacten waarvoor die architectuur wordt opgesteld. Dit gebruik van het voorvoegsel ‘digitaal' is gemeengoed geworden. Als de consumentenbond spreekt over de digitale consument dan bedoelt ze de consument in de digitale wereld en niet een softbot die namens ons aan het winkelen is. Een digitale camera is een fysiek apparaat; het voorvoegsel digitaal slaat daar op de verwerkingswijze.

M.m geldt hetzelfde voor de digitale architect, dat is een mens van vlees en bloed die bezig is met het opstellen van digitale architectuur.

[6] Organisch bedoeld als georiënteerd op het Leven.

[7] Louis Henry Sullivan gaf aan het einde van de eervorige eeuw de wolkenkrabber haar wezenlijke stijl.

[8] Het meesterwerk van Frank Lloyd Wright ‘Fallingwater' is het prototype van de harmonieuze wisselwerking tussen de ‘binnenruimte' en de ‘buitenruimte'.

[9] De belangrijkste leidraad van Henry van de Velde was de terugkeer van schoonheid en menselijke waardigheid.

[10] Antoni Gaudi liet op een soort middeleeuwse wijze zijn ontwerpen evolueren. Tegenwoordig zouden we zeggen ‘go with the flow'. Hij wordt algemeen erkend als de grootmeester van het krachtenspel.

[11] Blader bijvoorbeeld eens door ‘HyperArchitecture: Spaces in the Electronic Age' van Luigi Prestinenza Puglisi [6].

[12] Zie Jan Brouwer [7] pagina 131.

[13] Misschien is het zuiverder om over een supplement te spreken.

[14] M.m. geldt hiervoor hetzelfde als bij voetnoot 5.

[15] Monier Williams p 93 [8].

[16] Monier Williams p 431 [8].

[17] Zijn ‘fysieke' bouwmeester, Vitruvius, had zelf trouwens ook een veel bredere opvatting over architectuur dan de meeste van zijn huidige soortgenoten.

[18] Montesquieu heeft in 1748 met zijn ‘trias politica' daar nog een organisatiearchitectuur aan toegevoegd middels principes over de scheiding der machten.

[19] De vrij metselaars hebben dat wel heel aanschouwelijk weergegeven ( www.vrijmetselarij.nl ).

[20] Of erger nog de grot van Plato.

[21] De abstractheid van digitale architectuur lijkt veel op de abstractheid van een radiotelescoop. Bij een radiotelescoop biedt een netwerk van 25.000 kleine antennes verspreid over een zeer groot gebied samen met een supercomputer dezelfde functionaliteit als een gigantisch grote klassieke schoteltelescoop, maar ziet er totaal anders uit.

[22] De Pritzker Architecture Prize is als het ware de Nobelprijs voor fysieke architecten; in 2000 uitgereikt aan onze landgenoot Rem Koolhaas.

[23] Na het lezen van paragraaf 1.5 zult u wellicht net als ik enige moeite hebben met de Nederlandse titel van zijn boek ‘gestructureerde computerarchitectuur'. Dit komt nogal pleonastisch over, te meer daar de engelse titel gewoon ‘structured computer organization' luidt. Maar wellicht had men toen al het gevoel dat de term ‘architectuur' interessanter klinkt voor de kopers van het boek.

[24] Geïnitieerd in 1999 vanuit de Vrije Universiteit en Cap Volmac door Daan Rijsenbrij, Hans de Bruin en Hans van Vliet en vervolgens Nederland-breed uitgegroeid. Er is hierdoor in Nederland een breed veld van uiteenlopende architectuurideeën ontstaan. Ik heb in 2001 getracht daar wat duidelijk in te brengen middels een notitie met de enigszins arrogante titel ‘ Het ware gezicht van architectuur' [16] .

[25] Overduidelijk verwoord met de ondertitel van het standaardwerk over de Klassieke architectuur van Alexander Tzonis, Liane Lefaivre, Denis Bilodeau [22] ‘de poëtica van de orde' .

[26] Een foute regel in een programma leidt 100% zeker tot een fout resultaat als de processor ‘langs komt'.

[27] In de digitale wereld ontstaat regelmatig spraakverwarring omdat hetzelfde woord voor verschillende begrippen wordt gebruikt. Dat kennen we bijvoorbeeld reeds van ‘ontwerp' en ‘objectoriëntatie'.

[28] Het onderscheid ligt in de mate waarin ervan kan worden afgeweken. Regels worden voorgeschreven en moeten worden nageleefd. Richtlijnen zijn een voorschrift, maar zijn in tegenstelling tot de regels niet dwingend. Standaarden betreffen een voorschrift of set van voorschriften waarover overeenstemming bestaat in de IT-sector en die moeten worden opgevolgd.

[29] Helaas zijn veel zogenaamde patterns in de IT slechts technische, herbruikbare oplossingen en zijn zeker niet wat Christopher Alexander bedoelde met doorleefde oplossingen.

[30] Attributen van productkwaliteit die te verifiëren zijn door de klant; proceskwaliteit is de uitdaging van de leverancier.
P.S. Architectuur is een product, en beslist geen proces!

[31] Principes uit het ecosysteem zijn veelal afhankelijk van de interpretatie die een bestuurder daaraan geeft.

[32] Beleving brengt je in het ‘hier en nu', het Internet trekt je naar het ‘daar en toen'. Als wij niet oppassen raken wij zo volkomen los van de werkelijkheid.

[33] Hoewel ‘toekomstwaarde' geen synoniem is voor ‘firmitas' is het wel een zeer belangrijk aspect, zeker voor digitale artefacten.

[34] We onderkennen vier integratiesoorten: community-integratie (connectivity, directories, tacit knowledge), rolintegratie (integratie van services tot een werkruimte middels portal technologie), applicatie-integratie en gegevensintegratie.

[35] Het motto van Louis Henry Sullivan ‘vorm volgt functie' geldt ook in de digitale wereld. Een boekhouder ziet immers liever een spreadsheet, terwijl een kleuter icoontjes wil zien.

[36] U itgedrukt in ‘coupling' en ‘binding'

[37] In de kwaliteitsleer aangeduid met ‘fitness for purpose'.

[38] John Keats: “A thing of beauty is a joy for ever”.

[39] Hypertext is de bevrijding van het lineaire denken, jammer dat wij daar nog zo weinig gebruik van maken.

[40] Ik zou het motto van de Italiaanse pedagoge Maria Montessori ‘leer mij leren' willen omzetten naar ‘leer mij navigeren' door het schier oneindige aanbod aan mogelijkheden en informatie.

[41] Service Level Agreement

[42] Een project wordt gemanaged op tijd, geld en kwaliteit. Een programma wordt gestuurd door benefit tracking.

[43] Architecten als Gerrit Rietveld zijn begonnen met het ontwerpen van stoelen.

[44] Werkruimte i.p.v. werkplek omdat het een functioneel concept is en niet fysiek.

[45] Hiervoor wordt portaltechnologie gebruikt.

[46] Het grootste risico van een onderneming is de kans op ‘being not connected', dan doet men namelijk niet meer mee.

[47] Naast standaarden ten behoeve van organisatorische interoperabiliteit (procesniveau) en technische interoperabiliteit (de technische interfaces) speelt semantische operabiliteit (gegevensniveau) een cruciale rol. Voor een waardegenererend ecosysteem is veel overleg nodig tussen de stakeholders over standaarden.

[48] Om processen en bijbehorende middelen aan een andere onderneming te kunnen overdragen moeten ze eerst worden ontvlochten uit de eigen onderneming.

Ontvlechten is verfijnd vakwerk, maar is onder andere namen al vaak gedaan sinds het begin van het IT-tijdperk. In 1975 maakten de automatiseerders zich druk over de afbakening van een (software)module, met regels betreffende ‘coupling & binding'. Vervolgens werd dat dunnetjes overgedaan met ‘objecten' en daarna weer met ‘componenten'.

[49] Een valueweb met een overkoepelend management wordt aangeduid met ‘collaborative market'.

[50] Zie Gouillart en Kelly ‘Transforming the Organization'[28] voor een moderne beschouwing van een onderneming.

[51] Ik heb soms ook het gevoel dat een fysieke architect vecht tegen de wethouder ruimtelijke ordening.

[52] De bedrijfsorganisatie en de bedrijfsprocessen zijn twee verschillende gezichtpunten op het bedrijfsgebeuren van een onderneming.

[53] Z ie bijvoorbeeld het pionierswerk van Stef Joosten [5].

[54] SDM staat voor system development methodology een van de grote faseringsmodellen uit de begintijd van de automatisering.

[55] Key Performance Indicators.

[56] Over kennismanagement heeft Mathieu Weggeman een verhelderende inaugurele oratie gehouden [6].

[57] De informatiearchitectuur rust op de gegevensarchitectuur als inrichtingsonafhankelijke entiteit, zij biedt de ruimte voor de dynamiek in de bedrijfsvoering.

[58] Veel boeken en artikelen met ‘informatiearchitectuur' in de titel zoals Melissa Cook [8] en Wim van der Sanden en Bart Sturm [9] gaan eigenlijk over iets wat met de term ‘de data-architectuur' wordt aangeduid. Dit is een onderdeel van de applicatiearchitectuur en hoort beslist niet thuis in de I-wereld.

[59] Beslissingen dienen bij een volwassen onderneming zo laag mogelijk in de organisatie te worden genomen.

[60] Bij applicatie-integratie zijn er drie mechanismen: integratie door directe aanroep, integratie via de database en integratie via een dictionary. Dat laatste wordt steeds meer ondersteund door de toepassing van XML.

[61] Veel software architectuur bestaat slechts uit software engineerings best practices. De rest zou ik willen hernoemen tot applicatiearchitectuur, software is immers slechts het bouwmateriaal voor applicaties. Overigens kan er veel worden geleerd van bepaalde delen van die software architectuur, dit geldt met name van Mary Shaw [10] en Rick Kazman [11].

[62] Hoewel ik wel een voorstander ben van een expliciete beveiligingsarchitectuur, geloof ik niet in beveiligingsarchitecten. Architectuur is een holistische aangelegenheid en we moeten oppassen allerlei aspect-architecten te introduceren. Het is de verantwoordelijkheid van de architect, geadviseerd door beveiligingsspecialisten, om een beveiligingsarchitectuur op te stellen die consistent is met andere architectuureisen.

[63] Hierbij dienen ook de ‘privacy' principes in beschouwing te worden genomen.

[64] Door de grote financiële schandalen van de afgelopen tijd zien we een begrip als ‘transparantie' opkomen. Dit overstijgt als het ware het ‘passievere' governance omdat het ook als concurrentiemiddel kan worden ingezet.

[65] Een organisatie van mensen, beslissingsstructuren en hulpmiddelen.

[66] Sommigen prefereren het Nederlandse woord ‘belanghebbende'.

[67] Hij verwart dat met de eigenaar.

[68] In alle eerlijkheid dient te worden gesteld dat dit begrip ‘pattern' vaak niet hetzelfde is als Christoffer Alexander bedoelde. Er wordt zelfs wel gesproken over patterns voor de ontwikkelprocessen van ondernemingen en systemen, maar dit is in feite niet meer dan de methodologie van de ontwikkelaars.

[69] Onder een IT-mechanisme wordt verstaan de logica achter de mogelijke oplossing.

[70] Hierbij horen ook beschouwingen over een verantwoorde fit voor pakketsoftware.

[71] Architectuur ondersteunt een analyse van de kloof tussen business en IT.

[72] Dit geldt op een lager beschrijvingsniveau natuurlijk ook voor domeinarchitectuur.

[73] Vroeger werd dit aangeduid met kantoorautomatisering. Maar omdat alle medewerkers, witte en blauwe boorden, voor een groot gedeelte kenniswerkers zijn is het begrip kantoorautomatisering achterhaald.

[74] Het is trouwens te verwachten dat wij in de nabije toekomst IT zullen dragen, dus in onze kleren en sierraden, in plaats van IT te sjouwen.

[75] In fysieke zin zal het personal web ergens in een beveiligde datakluis ‘onder de grond' zijn opgeborgen.

[76] De wijze waarop mensen gewoon zijn om samen te werken, soms verwoord als bedrijfscultuur, is een belangrijke randvoorwaarde voor een bruikbare architectuur. Als de architectuur een te grote discrepantie vertoont met de bestaande bedrijfscultuur zal het heel moeilijk worden om de medewerkers naar de nieuwe architectuur te migreren. Aan de andere kant dient te worden gewaakt dat architectuur niet bestaande ineffectieve inefficiënte patronen bekrachtigt.

[77] Architectuur hoort uit te gaan van geschikte componenten. De snelste manier van programmeren is niet programmeren, dat is het motto van CBD (Component Based Development). Maar de (her) bruikbaarheid van standaardcomponenten komt niet uit de lucht vallen. Herbruikbaarheid op grote schaal is alleen mogelijk als daar tijdens het opstellen van de architectuur rekening mee is gehouden.

[78] CSF staat voor critical succes factor

[79] IAF staat voor Integrated Architecture Framework. Maar in wezen is dit een framework waar strategische principes, architectuurprincipes en engineeringsprincipes aan elkaar worden gekoppeld.

[80] Uitgedrukt in de te realiseren artefacten.

[81] Een mental model is een model waarmee de stakeholder wordt uitgedaagd zijn wensen en eisen te formuleren.

[82] Het is belangrijk te beseffen dat niet de architectuur wordt gevisualiseerd maar bepaalde aspecten van het ontwerp van het onderhavige artefact. Ook wordt wel getracht de interactie tussen het artefact en de verschillende soorten gebruikers te visualiseren. Belangrijk bij de visualisaties is dat wordt aangegeven welke principes hierbij tot uitdrukking worden gebracht.

[83] Eigenlijk het ontwerp van de artefacten die onder die architectuur zullen worden gerealiseerd.

[84] De ceo (chief executive officer) is verantwoordelijk voor het in balans houden van alle ontwikkelingen waar een onderneming mee te maken heeft. Hij is dan ook de meest aangewezen persoon voor de ‘accountability' van architectuur. In de praktijk zal hij de cio en één of twee andere leden van het managementteam daarbij nauw betrekken.

[85] Zichtbaarheid impliceert dat de architectuur niet toestaat dat er verborgen relaties zijn in het applicatielandschap of in de infrastructuur. Dus geen impliciete transacties waarvan de gebruiker zich niet echt bewust is. Als wij ethisch gezien een gebruiker verantwoordelijk stellen voor zijn daden, ook met een computer, dan moet hij voldoende begrijpen hoe het systeem functioneert.

[86] Verwijzing naar Jaap van Rees: de methode doet het niet. Een goede architect is een absolute noodzakelijkheid.

[87] SLA is een afkorting van Service Level Agreement.

[88] IC staat voor Interne Controle.

[89] Als het moeilijk is om deze gesprekken in te plannen en/of als zij vaak worden verschoven is dit een duidelijk negatief signaal voor de ‘sense of urgency'. Meestal komt dit omdat de boardroom niet zichtbaar genoeg het belang van architectuur etaleert.

[90] Ruimtelijk geldt voor fysieke architectuur.

[91] De beveiliging van het IT-gebeuren (in het bijzonder bij web-gebaseerde systemen), het ontwarren en verminderen van complexiteit, steeds snellere oplevering van toepassingen, een stortvloed aan nieuwe technologieën, de ontmanteling van legacy systemen en tenslotte de voortdurende afstemming tussen bedrijfsdoelen en IT.

[92] Er ontstaat geen waardevolle architectuur zonder echte architecten.

[93] Vroeger in het tijdperk voor de entree van de digitale architecten verliep automatisering rechttoe rechtaan. Een analist stelde een vraag en het antwoord was min of meer direct implementeerbaar. Tegenwoordig werpt een vraag een antwoord op dat een nieuwe vraag genereert in een andere richting of andere discipline omdat alles met alles samenhangt. Het multidisciplinaire is van zichzelf al complexer, en als digitale architect moet je daarin een weg weten te banen naar een goede ‘overall' oplossing.

[94] Met kaderzettend wordt bedoeld een eerste afbakening. Een kaderzettende architectuur ondersteunt de planning en biedt een soort referentiekader.

[95] Een solutionarchitectuur ondersteunt ontwerp en bouw; schrijft standaards en richtlijnen voor; geeft relevante patterns aan; bevordert hergebruik.

[96] Het woord ‘systeem' wordt voor vele zaken gebruikt, immers alles kan worden beschouwd als een systeem. Maar hier wordt systeem bedoeld als een artefact dat wordt gemaakt in tegenstelling tot indelingen en planningen die worden gemaakt.

[97] Dus de laag die in hoofdstuk 2 wordt aangeduid met de I-wereld.

[98] Dus de laag die wordt aangeduid met de B-wereld.

[99] Wij spreken niet over security architecten. Security is een engineeringsdicipline

[100] Gerrit Rietveld besteedde erg veel aandacht aan het leren kennen van de toekomstige bewoners. Dat ging zelfs zover dat hij soms een tijdje bij hen ging logeren alvorens hij met de ontwerpopdracht aan de gang ging.

[101] Het proces is de verantwoordelijkheid van de projectleider of de programma-manager.

[102] Het is verwonderlijk dat veel IT'ers niet echt helder kunnen formuleren. Automatiseren is niets anders dan schrijven, herschrijven, herschrijven en net zolang herschrijven tot de gewenste functionaliteit van de te automatiseren probleemstelling in een vorm komt die door een mechanische processor kan worden geïnterpreteerd [7]. Dus van vage gebruikerswensen tot een eenduidig interpreteerbare beschrijving. Als tijdens dat proces van formuleren slordigheden optreden komt er iets uit waar een computer ook geen chocolade meer van kan maken.

[103] Door fysieke architecten wordt dit meestal aangeduid met ‘fit between form and function'.

[104] Er lopen veel IT-deskundigen rond die zich architect noemen, maar dus eigenlijk IT-engineer zijn, zoals infrastructuur engineers, netwerk engineers, applicatie engineers, software engineers; security engineers, engineers voor Enterprise Application Integration, Java engineers.

[105] Het team building effect onder de stakeholders is zeer belangrijk.

[106] AO staat voor administratieve organisatie. Dit zijn deskundigen die vaak in groot detail de werkrelaties, werkstromen en allerlei regels uitwerken om te borgen dat de onderneming naar behoren kan functioneren.

[107] De technisch ontwerper wordt nu meestal aangeduid met engineer.

[108] Zie de website van het SBA: www.architectenregister.nl

[109] Het is duidelijk dat de wet bedoeld is voor de bebouwde wereld en niets heeft te maken met de digitale wereld. Digitale architecten kunnen dus gewoon de aanduiding ‘architect' gebruiken als het in de context maar duidelijk is dat hun werkzaamheden niet de bebouwde (fysieke) omgeving betreffen.

[110] Onder architectuurstijl wordt verstaan een beperkte verzameling samenhangende principes die een bepaalde architect of architectuurschool altijd toepast en waaraan wordt herkend welke architect of architectuurschool het artefact heeft gearchitectureerd.

[111] Het zou trouwens verstandig zijn als een digitale architect zich eens afvroeg hoe het zit met zijn juridische aansprakelijkheid.

[112] Volgens een voormalig medewerker van mij, Yvonne Kampmeier, is een goed inzicht in de lineaire systeemontwikkeling van essentieel belang voor het begrijpen van alle andere systeemontwikkelvarianten. Een overeenkomstige rol die het Latijn heeft voor de West-Europese talen .

[113] Hetgeen wellicht te veel vertraging veroorzaakt om de concurrentie nog te kunnen bijhouden.

[114] Gezien het cruciale belang van continuïteit in het architectuurdenken hoort de CAO beslist op de loonlijst van de eigen onderneming. Veel architecten op andere niveaus kunnen worden ingehuurd om een capaciteitsprobleem of manco's in de expertise tijdelijk in te vullen. De rol van de CAO lijkt trouwens meer op die van de Rijksbouwmeester of de minister van VROM dan op die van een operationele architect.

[115] Het voordeel van externe architecten is dat zij overeenkomstige uitdagingen in andere ondernemingen al een keertje hebben doorgrond.

[116] Een externe architect staat fris tegenover de probleemstelling omdat hij niet onderworpen is aan de cultuur van de onderhavige onderneming. Voorts kan hij makkelijker knopen doorhakken omdat hij geen blijvende werkrelaties heeft met de medewerkers in de onderneming.

[117] Een architect heeft een goede technische achtergrond nodig, met een ‘wiskundige' instelling.

[118] Een robot die uitsluitend bestaat uit software.

[119] BPO staat voor Business Process Outsourcing

[120] Slank wordt in de Angelsaksische literatuur vertaald met ‘agile'.

[121] Parijs blijkt een zeer geliefde inspiratie voor digitale architecten, zoals ook kan worden gezien in een geschrift van McKinsey [8].

[122] Ik weet dat ik de aanduiding ‘stedenbouwkundig architect' voor baron Haussmann gebruik ‘avant la lettre', officieel was hij namelijk de prefect van het departement Seine.

[123] De Angelsaksische uitdrukking ‘engagement' staat voor een contact met een klant. Delivery engagement is de leveringsovereenkomst.

[124] Het is de uitdaging van de digitale architect de discipline van de machine en de creativiteit van de mens te combineren tot een vruchtbare samenwerking.

[125] CBT staat voor computer base training.

[126] Ook wel aangeduid met plateaus.

[127] Het gaat om ‘fusion', dat is veel meer dan alignment.

[128] Het denken over outsourcing begint in feite al bij de visie en de strategie van de onderneming. Een hogere vorm van adaptiviteit kan worden verkregen door alles wat niet essentieel is voor de missie van de onderneming te outsourcen.

[129] Scope creep, of te wel het ongepland groter worden van de afbakening van het project is een belangrijke mislukkingsfactor van projecten.

[130] Het informatievoorzieningsysteem is de applicatielaag en de infrastructuurlaag.

[131] R&D = Research & Development.

[132] Zelfs de ontwerper kan maar gedeeltelijk de menselijke maat van het artefact beïnvloeden.

[133] Zijn meesterwerk als architect was zonder meer de Sint Pieter in Rome.

[134] Vooral applicaties op mobiele telefoons zijn vaak nog maar half ‘af' op het moment dat de telefoon de markt op wordt gebracht. De nieuwe typen toestellen volgen elkaar razendsnel op, wat de kwaliteit van de software niet altijd ten goede komt.

[135] Volgens Schopenhauer speelt een ieder de hoofdrol in zijn eigen drama en een bijrol in andermans drama.

[136] Een dergelijke zienswijze is reeds aanwezig bij fysieke architecten in een richting die wordt aangeduid met ‘organische architectuur' [4].

[137] In feite ligt er een grote verantwoordelijkheid bij ondernemingen die moeten ophouden uitsluitend ‘technische' architectuur te willen, en zich niet bekommeren over het feit dat hun medewerkers meer harmonieus kunnen functioneren.

[138] In wezen kan een computer alleen maar instructie na instructie verwerken, verder niets.

[139] In sommige beschouwingen wordt het vermogen tot ‘willen' geplaatst in het bewegingscentrum. Handelen en willen worden daar gezien in elkaars verlengde.

[140] We spreken over een mens-machine omdat bijna iedereen bijna altijd op zijn automatische piloot functioneert, en nauwelijks bewust aanwezig is.

[141] Een moderne variant hiervan is de film ‘The Matrix'.

[142] De prestaties van de computer zijn immers de geautomatiseerde schimmen.

[143] CV staat hier voor centrale verwarming.

[144] De overheid maakt op fysiek gebied zelfs beleid met betrekking tot het ontwerpen aan Nederland [10]. Het wordt de allerhoogste tijd dat zij op digitaal gebied ook eens iets gaat ondernemen.

[145] Social nets zoals Linked-In doen een stapje in de goede richting op dit gebied.

[146] SOX en Basel II slaan op de financiële huishouding. Maar er mag worden verwacht dat de controleerbaarheid van de onderneming (en zelfs de samenleving in zijn totaliteit) zich ook zal uitbreiden naar niet-financiële gebieden, bijvoorbeeld: privacy, milieuwetgeving en terrorismebestrijding.

[147] Dit is zeer belangrijk als we te maken hebben met ketenintegratie, waarbij klanten en leveranciers zijn betrokken.

[148] Ook wel aangeduid met actoren.

[149] Soms wordt dit aangeduid met ‘conditioneren'.

[150] De rol van ‘ik, mij en mijn' samen met haar verontreinigingen wordt ook wel aangeduid als de valse persoonlijkheid. De valse persoonlijkheid is een entiteit die dus niet nodig is in de schepping maar waarmee we terdege rekening moeten houden. Wat de computer niet kan (liegen), kan deze entiteit als de beste.

[151] En dat was reeds moeilijk in het precomputertijdperk (zie de grot van Plato)

[152] DSS kan veel ondersteuning geven maar het daadwerkelijk beslissen hoort door de mens te worden gedaan.


e-mail & contact oratie & update E-Magazine VNA discussie overheids- architectuur digitale kantoortuin
			architectuur is een teken van beschaving Dit geldt voor de fysieke wereld van steden, gebouwen, landschappen en interieuren. Dit geldt echter nog veel meer voor de digitale wereld, de wereld van digitale services, het digitale informatieverkeer, applicaties, computers, netwerken en werkplekken. Daan Rijsenbrij
Op 1 oktober 2004 heb ik mijn inaugurele rede gehouden op de Radboud Universiteit te Nijmegen, getiteld 'Architectuur in de Digitale Wereld'. inaugurele rede, getoonde plaatjes, uitgesproken teksten. Met een grote groep studenten probeer ik middels een workshopachtig college de essentie van digitale architectuur te doorgronden. Daarbij wordt gebruik gemaakt van een collegedictaat dat bedoeld is voor studenten. Probeer ook eens enkele tentamenvragen. Middels stage-opdrachten wordt getracht verdieping te verkrijgen in onderwerpen van de architectuur in de digitale wereld. Commentaren van andere belangstellenden op deze poging om meer scherpte te krijgen in dit onderwerp zijn van harte welkom.
Stellingen over digitale architectuur Stelling 1. Het zal blijken dat de belangrijkste architecten van de eenentwintigste eeuw de architecten van de digitale wereld zijn. Deze nieuwe loot aan het architectuurdenken zal een veel grotere impact krijgen op het functioneren van mens, onderneming en maatschappij dan de architectuur van de fysieke wereld. Ik ben er echter ook van overtuigd dat er in de toekomst mixed teams zullen ontstaan van fysieke architecten en digitale architecten, gezien de vervlechting van de beide werelden. Daarom is de houding van het SBA inzake het alleenrecht van de architectentitel voor de fysieke wereld beslist ongepast en niet meer van deze tijd. Dit blokkeert een synthese tussen de architecturen van de beide werelden. Stelling 2. Veel onbegrip over digitale architectuur komt doordat architectuur in de digitale wereld veel abstracter is dan architectuur in de fysieke wereld. Hierdoor hebben sommige fysieke architecten nog wat moeite om een beeld te vormen van een architect in de IT-sector. Voorts is het artefact onder beschouwing veel dynamischer, wat veel hogere eisen stelt aan de onderhavige architectuur. Veel problemen in de digitale architectuur zijn ook veel complexer dan in de fysieke wereld. Het zal blijken dat door de wat fundamentelere opstelling die wordt vereist van enterprise architecten zij uiteindelijk zullen komen tot oplossingswijzen die ook leerzaam zullen zijn in de stedenbouwkundige architectuur. De complexe problemen in de stedenbouwkundige architectuur zijn immers de toegankelijkheid van de stad en de afvoer van het afval. Stelling 3. De wanorde in het applicatielandschap en de IT-infrastructuur bij veel ondernemingen wordt veroorzaakt door een gebrek aan digitale architectuur. Een slechte enterprise-architectuur werkt als een dwangbuis voor de onderneming. Elke onderneming heeft echter een enterprise-architectuur, veelal een impliciete, niet bewuste. Een impliciete enterprise-architectuur zou echter best een slechte kunnen zijn. Veel ondernemingen hebben ten onrechte de indruk dat de problematiek in de IT kan worden opgelost met meer IT in plaats van het concipiëren van een heldere enterprise architectuur met de daarbij horende domeinarchitecturen. IT toevoegen bij IT-problemen heeft vaak het zelfde effect als olie op het vuur gooien. Je bent druk in de weer, maar het wakkert de problemen alleen maar aan. Stelling 4. Met goede digitale architectuur zijn er minder automatiseerders nodig en minder personeel om infrastructuur en applicaties in de lucht te houden. In plaats van alsmaar meer mensen te moeten (om)scholen, wordt het tijd dat het vakgebied daadwerkelijk wordt 'verdiept' door architectuur centraal te stellen. Een volwassen digitale architectuur is nodig om de kwaliteit van inzet en gebruik van IT-middelen op een hoger peil te krijgen; zo'n beslissing heeft direct impact op het rendement in bedrijfsleven, overheid en samenleving. Omdat de meeste ondernemingen nog steeds veel te veel IT-ers aan het werk hebben, geldt de bekende vuistregel: wat één IT-er kan presteren in één week, kunnen twee IT-ers in twee weken. Stelling 5. Een brede academische vooropleiding is een absolute voorwaarde voor een bekwame digitale architect. Er is grote behoefte aan architectuuropleidingen op academisch niveau. Een digitale architect dient naast architectuurkennis ook voldoende kennis te hebben van bedrijfskundige, sociologische en psychologische zaken naast fundamentele kennis van systeemtheorie en cybernetica. De digitale architect 'vecht' enerzijds tegen complexiteit, anderzijds tracht hij een 'bewoonbare' digitale wereld te scheppen. Het formuleren van de totale digitale architectuur in een onderneming heeft een moeilijkheidsgraad die slechts wordt overtroffen door de wat moeilijkere onderwerpen uit de theoretische natuurkunde, ondanks het feit dat er geen formules worden toegepast. Academisch niveau blijkt uit heldere consistente formuleringen, die de toets der kritiek kunnen doorstaan. Formules zijn slechts een verkorte notatievorm voor die formuleringen. Het concipiëren van een consistente, coherente verzameling principes met een hoge mate van toekomstvastheid in een driedimensionale ruimte (opgespannen door de dimensies architectuuraspecten, beschouwingniveaus's (scope) en 'de vier werelden') vergt een bijzonder hoog niveau van abstract denken. Daarenboven heeft een digitale architect nog te maken met ondoorgrondelijke 'objecten' als mensen. Stelling 6. De CAO (corporate architectural officer), de hoogste architect, dient juist te worden gepositioneerd in een onderneming. Architectuur is het middel bij uitstek om te borgen dat een onderneming kan ontplooien naar een fascinerende, onbekende toekomst. Daarbij is de enterprise-architect belangrijker voor de continuïteit van de ondermening dan de CFO. Te vaak komt het nog voor dat de CAO wordt gezien als het knapste jongetje van de klas die met heel moeilijke zaken bezig is. In een moderne onderneming echter zitten de CEO, CIO en de CAO eens per kwartaal om de tafel om de strategische mogelijkheden voor de onderneming te evalueren / bij te stellen. Stelling 7. Technologie is zeer belangrijk voor architectuur. Maar zet niet de CTO (corporate technology officer) op de plaats van de CAO (corporate architectural officer). Nieuwe technologieën bieden mogelijkheden tot geavanceerdere architecturen. Maar de inzet van technologie dient dienend te blijven. De CTO hoort daarom een inspiratiebron te zijn voor de CAO. Het is uiteindelijk de verantwoordelijkheid van de CAO om nieuwe technologieën zodanig aan te wenden dat ze de effectiviteit, de efficiency en het innovatieve vermogen van de onderneming bevorderen. Enterprise-architectuur is een teken van beschaving en geen vrijbrief voor een technologie-uitstalling. Stelling 8. De huidige populatie van architecten in de IT-gemeenschap behoeft danige opschoning. Het is tegenwoordig in de mode om je architect te noemen. Dit wordt enerzijds ingegeven door het grote gebrek aan echte architecten in de bedrijfstak, anderzijds klinkt het natuurlijk reuze interessant om op een verjaardagsfeestje te vertellen dat je architect bent. Architect in een digitale wereld nog wel! Veelvuldig wordt het begrip 'architectuur', zoals bedoeld in de fysieke wereld, en het begrip 'pattern', zoals bedoeld door Christopher Alexander, door IT-yuppen misbruikt om interessant te doen. Het wordt de hoogste tijd dat dit wordt teruggedraaid. Het zou verstandig zijn een limitatieve opsomming op te stellen van de 'archifacten' die een rol spelen bij digitale architectuur en daarmee zorgvuldig het werkterrein van de architect af te bakenen. PS: Misschien geldt wel voor de hele IT-gemeenschap dat er opschoning vereist is. In ieder geval is het verstandig om bij het aannemen of inhuren van IT deskundigen eerst de lakmoesproef te doen. Stelling 9. Digitale architectuur hoort helaas nog thuis in het rijtje kwaliteitssysteem, security, methodologie, risicomanagement, kennismanagement en vakmanschap. Als het goed gaat met de onderneming wordt het als ballast ervaren. Als het slecht gaat, is er geen geld voor. Het zal nog lang duren voordat de boardroom echt voor digitale architectuur zal kiezen. Continuïteit is immers minder belangrijk dan de kortetermijnpositie op de effectenbeurs. En dat terwijl enterprise-architectuur de absolute voorwaarde is om de complexiteit de baas te blijven, zeker bij outsourcingssituaties. Outsourcing zonder enterprise-architectuur lijkt op autorijden zonder veiligheidsgordel. Positief is echter de tendens dat bij veel ondernemingen die wat 'volwassener' zijn op IT-gebied steeds vaker een digitale architect wordt ingehuurd waar vroeger nog een consultant werd geraadpleegd . In voetbaljargon: 'Geen woorden, maar daden'! Stelling 10. Het wordt tijd dat er een functionaris wordt benoemd die voor de digitale Nederlandse samenleving een soortgelijke taak krijgt als de Rijksbouwmeester voor de fysieke wereld. Ook voor de Nederlandse overheid wordt digitale architectuur een steeds belangrijker issue. Hiervoor zouden documenten dienen te worden geconcipieerd zoals in de fysieke wereld Ontwerpen aan Nederland (Ministeries van OC&W, VROM, V&W en LNV, 2000). Op de dag van mijn oratie, 1 oktober 2004, werd Mels Crouwel de nieuwe Rijksbouwmeester. Hopelijk toont hij wat meer affiniteit met de opkomst van de digitale architectuur dan zijn voorganger Jo Coenen.


tentamen college 2004	28 - 01 - 2005
her-tentamen college2004	17 - 06 - 2005
tentamen college 2005	20 - 01 - 2006
her-tentamen college 2005	03 - 03 - 2006

titel	auteur	publikatiedatum	nadere informatie



Architecture Governance	Martijn Scheepstra	07 - 05 - 2004
ICT complexiteit binnen organisaties (architectuur als stuurmiddel)	Roel Konieczny	07 - 05 - 2004
Digitale Architectuur (een architectuurschets van de digitale werkruimte van een topmanager)	Sietse Overbeek	18 - 03 - 2005	eigen website
Successful Modelling of the Enterprise	Chris Magee	19 - 05 - 2005
Defining architectural principles for an adaptive enterprise	Bas Verbruggen	19 - 05 - 2005	eigen website
Het opstellen van een applicatiearchitectuur ppt voor de applicatiearchitectuur ppt voor een fysieke architectuur	Michel Houben	01 - 08 - 2005
Architecture & Visualisation	Gerben Hoogeboom	12 - 08 - 2005
Architectuur principes van de Radboud Universiteit voor het domein 'onderwijs'	Ron van Nuland	16 - 08 - 2005
Ondernemingstypering uit architectuurcontext	Ruben Melaard	17 - 08 - 2005
Selectie Architectuurraamwerken	Jeroen Janssen	17 - 08 - 2005
Architectuurprincipes en clustercriteria voor de afbakening van outsourcebare kavels	Erwin van der Graaf	03 - 02 - 2006	eigen website
Security binnen Enterprise Architectuur	Lucien Bongers	10 - 02 - 2006
De Menselijke Maat in de IT	Michiel Rutteman	01 -12 - 2006	eigen website
Digital Architecture - Uncovering the focus of architectural principles -	Sean Natoewal	19 - 01 - 2007	eigen website
Fundamenten van het Principe (op weg naar een prescriptieve architectuurmodelleertaal) - scriptie - bijlagen	Pieter Buitenhuis	02 - 03 - 2007	eigen website
Architectenpopulatie bij outsourcing/offshoring	Mark van Liefland	05 - 07 - 2007	eigen website

Architectuurevaluatiegroep
Raamwerk Architectuurdocumentatie Evaluatie
try out op NORA
- aspect adaptiviteit	Robin van 't Wout	25 - 06 - 2007
- aspect security & privacy	Paul van Vlaanderen	06 - 07- 2007
- aspect menselijke maat & beleving	David Campbell	02 - 07 - 2007
try out op de Architectuur 'Gemeente Amsterdam'
- aspect adaptiviteit	Guido Chorus	22 - 06 - 2007
- aspect security & privacy	Yves Janse	22 - 06 - 2007
- aspect menselijke maat & beleving	Chris Nellen	22 - 06 - 2007