Architectuur/X. Leerboeken/Rijsenbrij/2. Architectuur in de digitale wereld

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 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. 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 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 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 en content-management behoort tot deze architectuurlaag. De informatiearchitectuur, de architectuur van het informatieverkeer, geeft dus inzicht in de structuur en relaties van de informatie- en communicatiehuishouding, 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. 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, de architectuurkarakteristieken in de applicatietypologie en wat men doorgaans noemt de software architectuur.

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

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

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 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 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. Daardoor ondersteunt architectuur migratieplanning, borgt business IT alignment, 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 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. Architectuur 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. 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, de benodigde informatie moet de mens in conceptuele 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’.

---