Architect in balans Toegevoegde waarde van de architect

Architect in balans Toegevoegde waarde van de architect Het vak van de architect1 is nog jong en aan het product ‘architectuur’ wordt nog druk geschaafd. Architectuur heeft echter wel een gevoelige snaar geraakt: architectuur wordt tegenwoordig steeds meer gezien als vanzelfsprekende activiteit van veel ICT-afdelingen. Toch heeft architectuur niet altijd opgebracht waar van tevoren op gehoopt was. In dit artikel bespreken we eerst de beïnvloedbare oorzaken daarvan en daarna de omgeving waar we rekening mee hebben te houden. We willen echter niet de schuld bij de omgeving neerleggen. De architect zal zelf moeten zorgen voor een realistische taakstelling. Wij geven hier een eerste voorzet die hij daarvoor kan gebruiken.

Auteurs J.T.P. Campschroer; S.O. van de Riet

november ’03

Trefwoorden Architect Architectuur Competentie Taak Kwaliteit

Ordina Public Consulting Burg. Burgerslaan 44-60 5245 NH Rosmalen www.ordina.nl

1

Overal waar in dit artikel wordt gesproken over “architectuur” en “architect”, wordt “ICT-architectuur” en “ICT-architect” bedoeld. © 2003 Ordina

tot ICT en kunnen omgaan met verschillen in doelstellingen; • Vlees versus staal: proces versus structuur: de samenkomst van het organische bedrijf en de mechanische ICT geeft een “structure clash”; • Paradigma van de architect: de architect heeft een onvoldoende duidelijk beeld van zijn resultaat. Deze kwesties behandelen we eerst. Met deze kennis kijken we vervolgens naar de functie van de architect. Wat is de uitgangsituatie, met welke krachten heeft hij te maken en naar welk resultaat kan hij streven. Tot slot gaan we in op de taken die wij weggelegd zien voor de architect en welke competenties hij moet bezitten om deze taken op zich te kunnen nemen. De architect dient zijn omgeving meer als gegeven te beschouwen en moet zich daar op aanpassen. Onze omgeving moet niet ons beter begrijpen, maar wij moeten onze omgeving beter begrijpen.

Inleiding Het vak van de architect is nog jong en aan het product ‘architectuur’ wordt nog druk geschaafd. Architectuur heeft echter wel een gevoelige snaar geraakt: architectuur wordt tegenwoordig steeds meer gezien als vanzelfsprekende activiteit van veel ICT-afdelingen. Toch heeft architectuur niet altijd opgebracht waar van tevoren op gehoopt was. Architectuur heeft haar beloftes niet goed weten waar te maken. Voor sommigen is het nog steeds dé oplossing voor vele ICT-problemen, maar er zijn ook tal van sceptische geluiden te horen. Hoe komt dat? Waar gaat het mis? Wat kunnen we eraan doen? Waarom bracht architectuur niet de waarde die eraan gehecht werd? Wij zoeken de oplossing in een duidelijke en vooral haalbare taakstelling van de architect. Dat wil zeggen een taakstelling waar hij2 op kan en wil worden afgerekend. Nu zijn er nog veel onduidelijkheden rondom de taken van de architect: wat is zijn doel, zijn werkveld, zijn resultaat en welke input heeft hij nodig om deze doelen te kunnen bereiken? Om grip te krijgen op met name de haalbaarheid, geven we eerst een schets van de mogelijke oorzaken waarop het nu mis gaat. We zien zes kwesties die het ‘succes’ van architect en architectuur in de weg staan, waarbij we afzien van de kwestie waarbij personen zich ineens architect zijn gaan noemen, omdat dat beter verkocht: • Interpretaties van architectuur: het is niet duidelijk hoe architectuur welk probleem oplost; • Bedrijfsdoelen en -visie: de doelen en de visie op de organisatie zijn niet helder om uitgangspunt te zijn voor de architect; • Omgevingsfactoren: de omgeving wil of kan niet meewerken; • Diverse belevingswerelden: geen inzicht of gevoel hebben bij de verschillende gevoelswaarden van alle betrokkenen met betrekking

Interpretaties van architectuur De realiteit van het vakgebied van de architect kenmerkt zich door een grote varië teit aan interpretaties van architectuur. We noemen enkele situaties die we zijn tegenkomen, nadere uitwerking komen we o.a. tegen bij Van den Berg en Dijk (2001): • Architectuur als modeverschijnsel: men gaat aan de slag omdat iedereen instinctief de globale voordelen wel kan benoemen, maar inhoud en doel van de werkzaamheden zijn niet duidelijk. Architectuur heeft geen duidelijke businesscase. • Architectuur als managementgril: men gaat aan de slag, omdat het management architectuur als oplossing verklaart voor problemen, maar het is niet duidelijk hoe architectuur die problemen oplost. Architectuur als Haarlemmerolie. • Architectuur als fase: architectuur wordt ingezet als extra ontwerpfase bij het specificeren van toekomstige systemen en er is geen samenhang met vervolgprojecten en andere projecten die ook nieuwe systemen moeten opleveren.

2

In het vervolg spreken we steeds van “hij” en “zijn”, waar ook “zij” of “haar” kan staan.

2

Alle situaties hebben in zich dat er een vage notie is van een ongewenste situatie, en dat er een vaag idee is hoe architectuur bijdraagt aan de oplossing. Wat het probleem precies is en in hoeverre architectuur bijdraagt aan de oplossing, is echter niet duidelijk. De architect, blij dat hij aan de slag mag, gaat onverdroten aan het werk. De opdrachtgever, blij dat blij dat het probleem is belegd, haast zich om weer met de waan van de dag bezig te zijn. Zonder een goede verbinding tussen probleem en probleemeigenaar enerzijds, en oplossing en opdrachtnemer anderzijds, is falen het resultaat.

Vanuit de geformuleerde doelen – voor zover aanwezig – is het niet altijd even makkelijk om ICTdoelen te destilleren. Ross (2003) beschrijft hoe een chief architect een ICT-strategie wilde bouwen die de bedrijfsstrategie moest ondersteunen. Maar in plaats van een bedrijfsstrategie vond de architect alleen beloftes – wij worden de grootste! – waar ICT moeilijk technologische oplossingen aan kan verbinden. Niet alle doelen blijken even smart: specifiek, meetbaar, acceptabel, realistisch en tijdsgebonden. Automatisering duldt echter geen dubbelzinnigheid. Systemen inrichten op basis van woorden als ‘misschien’en ‘dat hangt er vanaf’ gaat nog steeds moeilijk. Bedrijfsdoelen moeten een heldere afbakening kennen met duidelijke keuzes. En zoals Sanden en Sturm (1997) schrijven dienen bedrijfsdoelen ingevuld te worden met een visie op de inrichting voordat er een passend ICT-plan of architectuur voor ontwikkeld kan worden.

Bedrijfsdoelen en -visie

Omgevingsfactoren

De afgelopen jaren hebben – terecht – sterk in het teken gestaan van een normalisatieslag op het gebied van ICT. Net als voor andere middelen moet het voor ICT duidelijk zijn wat de relatie is tussen de gestelde bedrijfsdoelen en de inspanningen op het gebied van ICT. Er moet een plan zijn en dat plan moet stroken met de ambities van het bedrijf. En ICT moet – net als andere middelen – een duidelijke bijdrage leveren wat betreft het realiseren van deze doelen.

Er zijn echter ook factoren in de omgeving aan te wijzen die maken dat het moeilijk is om architectuur vanaf het begin te laten bloeien. Deze problemen ontstaan vaak op het raakvlak van organisatie en ICT. In de literatuur wordt deze afstemming vaak ‘alignment’ genoemd, bekende modellen zijn er onder andere van Parker en Benson (1989) en Henderson en Venkatraman (1993). De auteurs van deze modellen willen laten zien dat er idealiter diverse verbindingen bestaan tussen het bedrijfsdomein en het IT-domein. Om verschillende redenen kan alignment problematisch zijn binnen een organisatie, zie ook Hirschheim en Sabherwal (2001): • Autonomie, het optimaliseren van geautomatiseerde processen vraagt om afstemming tussen afdelingen, deze afstemming en samenwerking tussen afdelingen is vaak een moeizaam proces, met name wanneer het rendement van de samenwerking onzichtbaar is; • Distributie, de ICT-infrastructuur en alle systemen zijn verspreid over de gehele

•

Architectuur wordt gezien als “meer en beter van te voren nadenken”. Architectuur als project: men ziet architectuur als tijdelijk project waarvan het resultaat blijvend is en niet verandert in de tijd. Architectuur wordt niet ingebed in de veranderorganisatie.

In de praktijk blijkt dat niet altijd even makkelijk te zijn: • Bedrijfsdoelen zijn niet expliciet benoemd; • Beschreven bedrijfsdoelen binnen de organisatie spreken elkaar tegen; • De doelen worden niet onderschreven door alle betrokkenen en/of telkens voorzien van een andere interpretatie; • Bedrijfsdoelen blijken telkens te veranderen nog voordat ze bereikt zijn.

3

•

organisatie, wat het moeilijk maakt om overzicht en grip te krijgen over het hele werkveld. Daarnaast is ook de verantwoordelijkheid voor ICT verspreid over meerdere personen; Onverschilligheid, ICT wordt als onbelangrijk ervaren en het belang van meedenken over oplossingen wordt als lastig ervaren. De verantwoordelijkheid wordt vervolgens wel in zijn geheel bij ICT neergelegd. Het komt ook voor dat gebruikers het moeilijk vinden om de mogelijkheden van ICT in te schatten.

•

Figuur 1 – Denkbeelden (gebaseerd op Prahalad en Ramaswamy, aangepast)

Klanten denken niet in termen van loyaliteit, zij verwachten een bepaalde prestatie van de organisatie en rekenen de organisatie af op de resultaten. De architect staat voor de uitdaging om de doelen die het bedrijf bepaalt, te vertalen in realiseerbare doelen in de ICT-wereld en bruikbare oplossingen voor de klant. Dat is geen kleine opgave, want in de ICT-wereld wordt vaak te snel gedacht vanuit mogelijke technologische oplossingen, zoals beschreven door Ligthart, Vis et al. (2002).

Diverse belevingswerelden Maar ook als de bedrijfsdoelen wel helder zijn en er een duidelijke visie is op de organisatorische inrichting kan het vertalen van deze doelen stuiten op onbegrip in het ICT-domein. Bedrijf- en ICT-mensen hebben verschillende belevingswerelden. Het kost hen veel moeite om hier van los te komen en de wereld te zien door de ogen van de ander. De architect moet echter ook steeds meer rekening houden met de wereld van de klant van de organisatie. In toenemende mate maken klanten gebruik van de systemen van de organisatie, bijvoorbeeld via websites. Dit heeft als gevolg dat ICT te maken heeft met hoe de klanten van de organisatie uiteindelijk omgaan met de aangeboden oplossingen. Prahalad en Ramaswamy (2002) wijzen op een verschil in denken tussen consument en bedrijven. Consumenten denken in termen van ‘behoeftes’en ‘aspiraties’, terwijl organisaties vaak intern georië nteerd zijn. En hoewel we binnen organisaties zien dat afdelingen steeds meer elkaar nodig hebben, het zijn nog vaak aparte werelden. Men kijkt anders naar de wereld (zie figuur 1). •

•

satie, Logistieke performance, Voldoen aan wettelijke eisen. Klant-denkbeelden Wensen, Verwachtingen, Emoties, Transparantie, Compromissen, Activiteiten.

Vlees versus staal, proces versus structuur Het werk van de architect bedient – zoals gepredikt door alignment auteurs – twee domeinen: het systeemdomein en het organisatiedomein. (zie tabel 1). Deze beelden komen we onder andere tegen in de systeemwereld bij Checkland (1999) en in de architectuurwereld bij Van Berkel (2002). Systeemdomein Er zijn (toekomstige) systemen die een plaats moeten krijgen in een groter geheel Instrumenten om te representeren

Organisatiedomein Er is complexiteit en verwarring die ik kan beschrijven en waar mee gewerkt moet worden Instrumenten om te sturen

Tabel 1 – Architectuur bedient verschillende domeinen

ICT-denkbeelden Business intelligence, CRM, ERP, WFM, Technical automation, J2EE. Bedrijfsdenkbeelden Product assortiment, Loyaliteit, Procesoptimali-

Een architect kijkt naar nieuwe systemen die gerealiseerd moeten worden of oude systemen die aanpassing behoeven en beschrijft deze ontwikkelingen – oftewel hij representeert het ‘staal’. Aan de andere kant moet de architect ook rekening houden met de gevolgen die de systeem-

4

instrumenten zijn vaak formeel van aard en worden dan ook vaak gebruikt binnen het systeemdomein. De ontwerpaanpak werkt minder goed binnen het organisatiedomein. De rationaliteit gebaseerd op feiten is hier veel minder aanwezig. We constateerden al dat dynamiek het moeilijk maakt om vaste grond onder de voeten te vinden. Voor aanvang van een project is het verleidelijk om vaste grond te creë ren door het ‘bevriezen’van de huidige situatie. Tijdens het project komen we er meestal achter dat dit onbegonnen werk is en dat de organisatie gewoon in beweging blijft ondanks dat misschien afspraken formeel zijn vastgelegd. Daarnaast is de totstandkoming van een technologische oplossing goed door te denken, maar het effect dat de oplossing heeft op de organisatie is veel minder goed te rationaliseren. Naast de ontwerpaanpak moet dan gekeken worden naar de ontwikkelaanpak. Functies van mensen kunnen veranderen, omdat taken niet meer handmatig uitgevoerd hoeven te worden. In de nieuwe functie krijgen medewerkers vaak te maken met nieuwe eisen en verantwoordelijkheden. Een geleidelijke aanpak is nodig om de organisatie – en met name de mensen – voor te bereiden op deze nieuwe situatie. De architect moet kunnen beschikken over instrumenten om de organisatie de juiste kant op te sturen. De resultaten van deze instrumenten zijn vaak gebaseerd op beelden die leven en hierdoor meer informeel van aard. Architectuur kan gezien worden als de paraplu waaronder verschillende instrumenten geplaatst worden die de representatie dienen en instrumenten die gebruikt kunnen worden om te sturen. Alle instrumenten gebruikt de architect om zowel de organisatie alsook de ICT-omgeving in de juiste richting te coachen.

aanpassingen hebben binnen de organisatie. Er moet anders gewerkt worden, taken veranderen en functies krijgen een nieuwe inhoud. Een architect geeft zo goed mogelijk deze gevolgen aan. Hij stuurt de organisatie in de juiste richting, zodat er goed ingespeeld kan worden op de nieuwe situatie. De architect heeft te maken met de samenkomst van het organische, procesgerichte bedrijf en de mechanische, systeemgerichte ICT. Het is de vraag of instrumenten – zoals diagrammen, prototypes en plannen – geschikt zijn om tegelijkertijd te representeren en te sturen. Zaken als vorm, mate van detail en interesse van de doelgroep spelen hierbij een rol. Voor iemand in de organisatie is het niet interessant welke systeemonderdelen gebruikt worden bij een proces terwijl dat voor ICT-mensen van wezenlijk belang is. Bij systemen speelt het ontwerpen – oftewel het vormgeven – van een toekomstige situatie een belangrijke rol, terwijl bij de organisatie vooral gebouwd moet worden op de huidige situatie, omdat personen nu eenmaal niet makkelijk te veranderen zijn. Het verschil in benadering vinden we bijvoorbeeld terug bij Bosma (2002) die de verschillen tussen ontwikkel- en ontwerpinstrumenten op een rij heeft gezet. Hij geeft aan dat de ontwerpaanpak gebruikt kan worden bij bekende, niet-complexe problemen en dat de ontwikkelaanpak geschikter is voor de meer complexe problemen waarbij de oplossing niet voor de hand ligt. Als we kijken naar het gemiddelde ICT-project dan zien we dat een combinatie van beide aanpakken nodig is. Het lukt tegenwoordig vrij goed om vast te stellen wat er op het ICT-vlak moet gebeuren om gewenste functionaliteit te realiseren. Natuurlijk kan het hierbij gaan om zeer complexe oplossingen waarbij van tevoren niet altijd duidelijk is of het gewenste resultaat behaald kan worden; toch zijn de stappen vaak vanuit rationeel standpunt goed te benoemen. Om de realisatie te ondersteunen is er behoefte aan instrumenten die de nieuwe situatie duidelijk representeren, gebaseerd op feiten. Deze

Paradigma van de architect Soms staat de architect zelf het succes in de weg. De omgeving de schuld geven is altijd makkelijk, een kritische zelfblik kan ook een verhelderende blik op de situatie werpen. Twee denkbeelden die

5

worden tegelijkertijd fundamenteel anders ingericht. Doelen verschuiven, mensen stromen in en uit en systemen krijgen een update: alles is in flux. Waar moet je als architect dan vanuit gaan? Het is alsof je een gebouw neer moet zetten in een stad die bestaat uit een complete bouwput. Je weet niet waar de wegen komen en hoe hoog het gebouw naast je is. Waar wil je ooit, straks, morgen zijn? Is daar een gemeenschappelijk beeld van? Medewerkers weten nog niet waar ze aan toe zijn. Er is geen ervaring met de nieuwe wijze van werken. Op het moment dat de ervaring van morgen er is, is het beeld waar we straks willen zijn al weer veranderd.

succes het meest in de weg kunnen staan zijn volgens ons: • Architectuur als superstructuur, de architect verwacht dat één overkoepelende structuur de hele organisatie kan afdekken. Hij werkt net zolang door tot alles in de structuur is ondergebracht, zonder te checken of dit meerwaarde met zich meebrengt. • Architectuur als monument, de overkoepelende structuur moet voldoen aan een ideaalbeeld – vaak alleen bekend binnen het hoofd van de architect – en zal voor lange duur in de organisatie moeten gelden als fundament. Trajecten vervallen in theoretische exercities waarbij het echte doel, het realiseren van complexe veranderingen, en het middel, architectuur, worden verward.

Omdat alles in beweging is, heeft het weinig tot geen zin om als architect te proberen om dé perfecte oplossing te realiseren. Het ideaalbeeld van veel architecten, het vooraf ontwikkelen van één gemeenschappelijke architectuur, zal losgelaten moeten worden. Op dit moment ontwikkelen technologie, organisaties en voorkeuren zich te snel om ondergebracht te kunnen worden in één plaatje. De tijd zal het leren of dit voor altijd het geval is.

Uiteindelijk resultaat van de architect afhankelijk van de uitgangssituatie In voorgaande paragrafen hebben we laten zien dat doelen en context binnen het werkveld architectuur vaak niet duidelijk zijn. Waarom is deze onduidelijkheid erg? Aan het einde van een project moet er een bepaald doel bereikt zijn. Steeds vaker zijn organisaties afhankelijk van gerealiseerde ICT-functionaliteit om die doelen te halen. Een architect werkt toe naar het realiseren van deze ICT-functionaliteit en kijkt welke input hij hiervoor nodig heeft van de organisatie. Om doelen te behalen moet een architect de verschillende lagen binnen een organisatie aan elkaar weten te knopen: doelen die gesteld worden binnen de strategie moeten deels gerealiseerd worden door de ICT-infrastructuur, de systemen die hier op draaien en de mensen die met deze systemen werken. Een complex samenspel.

Weill en Broadbent (1998) stellen dat succesvolle organisaties onderscheid maken naar een gemeenschappelijke laag, de bedrijfsbrede infrastructuur, en hierboven verschillende domeinen die elk een eigen doel hebben. Van der Sanden en Sturm (2000) zien een infrastructuur als dé oplossingsrichting om te kunnen voldoen aan de gewenste flexibiliteit. De elementen in de gemeenschappelijke laag, de nuts-voorzieningen, veranderen niet snel en leveren betrouwbare diensten voor de gehele organisatie, zoals e-mail, de kern van een ERP-systeem of gemeenschappelijke gegevensverzamelingen. Buiten de gemeenschappelijke laag moeten we leren werken met de dynamiek en complexiteit van vandaag. Daardoor kunnen bepaalde dingen dubbel gebeuren of minder efficië nt dan ultiem haalbaar. Architecten moeten werken aan lerende systemen (organisaties) die zich blijven aanpassen aan de wijzigende

Tegelijkertijd versterken de factoren dynamiek en complexiteit de problematiek. De hedendaagse organisatie kenmerkt zich door voortdurende veranderingen in de organisatie, de producten en de omgeving. De veranderingen worden complexer. Processen worden niet alleen geautomatiseerd, ze

6

verantwoordelijkheid te laten dragen die de business al draagt. Maar om zijn doel te kunnen bereiken heeft de architect vanzelfsprekend te maken met zowel de ICT-kant als de organisatorische kant. We zien daarom drie belangrijke taken voor de architect: • Het organiseren van betrokkenheid; • Het bevorderen van samenwerking en • Het realiseren van de benodigde oplossing door juiste sturing.

omstandigheden. Dit in samenwerking met andere disciplines binnen het bedrijf die hier ook verantwoordelijk voor zijn zoals HRM, operations en corporate development. De architect moet telkens de vraag beantwoorden wat effectiever is voor een bepaalde situatie: decentrale doelen nu halen of iets langer werken om iets gemeenschappelijk te maken. Op basis van het antwoord moet de architect zelf bepalen welke input hij nodig heeft en waar deze te vinden is. De architect zal hierbij een leidende rol moeten innemen richting het bedrijf. Niet alleen moeten de bedrijfsmensen begrijpen welke input zij kunnen en moeten leveren bij het realiseren van ICT-oplossingen, de architect moet ook duidelijk kunnen maken welke mogelijkheden ICT biedt om doelen aan te scherpen en realistisch te maken. Door de verwachtingen aan het adres van het bedrijf duidelijk te verwoorden en er op toe te zien dat er aan die verwachtingen wordt voldaan, moet de architect laten zien dat de bedrijfsmensen een onmisbare rol spelen bij de realisatie van goede ICT-oplossingen.

Vanuit problemen en obstakels: de taken en competenties van de architect

Binnen een organisatie waar een architect te maken krijgt met autonomie, distributie en onverschilligheid is het onmogelijk om hem direct verantwoordelijk te maken voor het realiseren van oplossingen. Deze verantwoordelijkheid is immers decentraal belegd en beslissingen worden autonoom genomen. In deze situatie is de eerste verantwoordelijkheid van de architect om betrokkenheid te organiseren en samenwerking te bevorderen. Daarvoor zal hij in de schoenen moeten gaan staan van die betrokkenen om hun beleving, hun zorgen en hun taal te kunnen spreken. De architect zal als conceptuele bruggenbouwer de verschillende werelden bijeen moeten zien te brengen. In de onzekerheid van alle dag is het belangrijk het doel voor ogen te houden. Na elke (kleine) stap moet bekeken worden wat de volgende stap is, zie ook Campschroer en Ligthart (2002). Daarbij moeten telkens keuzes gemaakt worden. Keuzes die de architect moet begrijpen en ondersteunen. De architect brengt daarbij zelf creatieve ideeë n in om de weerbarstige werkelijkheid te overwinnen. Alles beweegt, de architect en de architectuur dus ook. Hij zal af moeten stappen van het idee van een gigantische ontwerp vooraf en een grootscheepse lineaire ontwikkeling.

Op basis van de problemen die we aan het begin van het artikel schetsten en de situatie die we willen bereiken kunnen we toewerken naar de taken van de architect. Uitgangspunt is dat het uiteindelijke doel altijd moet bijdragen aan een betere ICT- of informatievoorziening. Het heeft geen zin om de architect

Verandering zal via een samenspel van kleinere veranderingen gebeuren die de flexibiliteit vergroten, maar tegelijkertijd een zware wissel trekken op de sturing. Een ICT-architect moet kunnen schaken op meerdere borden tegelijkertijd. Door op de juiste plaatsen de knip te leggen – of te laten leggen –

Instrumenten kunnen de architect ondersteunen bij het vergaren van de juiste informatie en het presenteren ervan. Het Archimate project (2002) en het visualisatieonderzoek van Koning (2001) dragen daar aan bij. Door de varië teit aan mogelijkheden (ontwerp versus ontwikkel, centraal versus decentraal, korte termijn versus lange termijn) en de verschillende doelgroepen (ICT, bedrijf, operationeel, strategisch) is één universele oplossing een illusie.

7

tussen de mogelijkheden van technologische vooruitgang, de werkelijkheid van dynamische organisaties en omgevingen en de grenzen van werkbaarheid en beheersbaarheid. Het werk van de architect vergroot het verandervermogen van de organisatie, omdat telkens opnieuw verbindingen tot stand worden gebracht, zowel binnen de organisatie alsook naar buiten. Voor besluitvormers houdt de architect de zaken simpel en overzichtelijk door telkens duidelijk af te bakenen. Hij ondersteunt de bestuurders door een gedragen, wenselijke en haalbare oplossing te bieden binnen de gestelde randvoorwaarden van tijd, kwaliteit en benodigde middelen.

moeten beheersbare projecten opgetuigd worden die binnen de gestelde tijd het gestelde doel kunnen realiseren. Architecturen worden dus niet gemaakt voor de eeuwigheid, maar voor het realiseren van die kleine stapjes in samenhang.

Conclusie Er is nog veel te doen. Architecten moeten – los van de ICT – nadenken over de context en de input van hun werkzaamheden. De architect moet vooral doelgericht aan de slag gaan en op een pragmatische manier proberen om het bedrijf te verbinden met de ontwikkelingen op ICT-gebied. Het gebruik van architectuur zal vaak in kleine stappen gebeuren met realistische verwachtingen te scheppen: architectuur en architecten zijn geen Haarlemmerolie.

De architect leeft van de ruimte tussen droom en daad, maar zal tegelijkertijd steeds vaker afgerekend worden op de effecten van gerealiseerde oplossingen. Hij moet ‘nee’ durven zeggen, als de randvoorwaarden voor succes onvoldoende zijn. Telkens zal hij, in afstemming met de opdrachtgever, moeten komen tot een realistische taakstelling. Een architect staat daarbij niet buiten die organisatie maar staat –met zijn laarzen aan– er middenin.

We zullen ons erbij neer moeten leggen dat de wereld niet zo maakbaar is als we wel zouden willen. Een organisatie kan nu eenmaal niet telkens opnieuw ‘ontworpen’ worden vanuit een ideaalbeeld. De wereld draait hiervoor te snel. De tekentafel is geduldig en laat architecten grote stappen rustig uitwerken, de organisatie wil doorgaans sneller resultaat zien. Verschillende domeinen vragen om verschillende aanpakken en verschillende instrumenten. De ontwerpaanpak zal steeds vaker gepaard gaan met de ontwikkelaanpak. Veranderen wordt steeds meer een gestructureerd leerproces gecoacht door de architect.

Referenties The Archimate project, www.telin.nl/NetworkedBusiness/Archimate, Telematica Insitituut. •Van den Berg M. and Dijk, R., “Misvattingen over architectuur. Beter inzicht leidt tot beter gebruik”, Architectuur en infrastructuur, nr. 4, 2001, Den Haag: Ten Hagen en Stam •Van Berkel, Ben, “The Blue Period”, lezing voor het Nederlands Architectuur Instituut, Rotterdam, 19 september 2002 •Bosma H., “Samenwerken met architectuur”, artikel op het Landelijk Architectuur Congres, 2002 •Campschroer J. and Ligthart A. “Organiseren van verandering: verandering van organiseren”, Architectuur en infrastructuur, nr. 2, 2002, Den Haag: Ten Hagen en Stam •

De architect wordt vaak gepositioneerd als een bruggenbouwer. Hij creëert de benodigde verbinding tussen twee landschappen met daartussen een brede kloof: aan de ene kant de bedrijfsprocessen, aan de andere kant de ICT-processen. Wij zijn van mening dat een architect van toegevoegde waarde is, als hij het voor elkaar krijgt om telkens die wijzigingen in het systeemlandschap te laten realiseren die nodig zijn om het bedrijf op een werkbare en beheersbare wijze zijn doelen te laten bereiken. Een architect balanceert daarmee continu

8

Checkland, Peter and Scholes, Jim, “Soft Systems Methodology in Action”, Chichester: Wiley, 1999 •Henderson, J.C.; Venkatraman, N. (1993), “Strategic alignment: Leveraging information technology for transforming organizations”, IBM Systems Journal, vol. 32, no. 1, p. 4-16. •Hirschheim R. and Sabherwal R., “Detours in the Path toward Strategic Information Systems Alignment”, California Management Review, vol. 44, nr. 1, fall 2001 •Koning, H. “Communication of IT-Architecture", www.cs.vu.nl/~henk . •Ligthart A. (red.), Vis J. (red.), Bernhard P., Brattinga M., Campschroer J., Hordijk W., Steetskamp R., Verver R., “Applicatieontwikkeling onder architectuur”, 2002, Den Haag: Ten Hagen en Stam •Parker, M.M.; Benson, R.J. (1989), “Enterprisewide information management: State-of-the-art strategic planning”, Journal of Information Systems Management, vol. 6, issue 3, p.14-23 •Prahalad, C.K. and Ramaswamy, V., “The CoCreation Connection”, Strategy+Business, issue 27, second quarter, 2002 •Ross, J.W. “Creating a strategic IT Architecture Competency: Learning in Stages”, MIS Quarterly Executive, vol. 2, no. 1, march 2003 •Sanden, W.A.M. and Sturm, B. , “Informatiearchitectuur, de infrastructurele benadering”, 2e druk, 2000, Panfox •Weill, P. and Broadbent, M., “Leveraging the new infrastructure: How market leaders capitalize on IT”, 1998, Harvard Business School Press •

Dankwoord Bij deze bedanken we Wim Bakkeren, Louis Stevens, Paul Weghorst en Margreet Wessels voor hun commentaar en opbouwende kritieken op eerdere versies.

9

over de auteurs

over Ordina

Drs. Sven van de Riet is consultant bij Ordina Public Consulting. Zijn opdrachten liggen op het vlak van de toepassing van nieuwe technologie en de organisatie van IT-dienstverlening. Tevens is Sven actief binnen de Ordina Groep als trendwatcher waarbij hij professionals uit de gehele organisatie ondersteunt bij het uitvoeren van klantprojecten en professionalisatie van business development. Sven is telefonisch te bereiken via 073-5282828 of via mail op het adres [email protected].

Ordina is een beursgenoteerde en toonaangevende dienstverlener in de markt voor Informatie en Communicatie Technologie. De organisatie, opgericht in 1973, telt circa 3.300 medewerkers. Ordina ondersteunt haar opdrachtgevers met behulp van hoogwaardige informatie- en communicatietechnologie om strategisch voordeel te behalen, door toepassing van gedegen vakkennis van ICT in combinatie met voortdurende innovatie en een heldere kijk op bedrijfskundige vraagstukken. Het dienstenpakket van Ordina bestaat uit management- en businessconsultancy, systeemontwikkeling en -integratie en managed services. Het aandeel Ordina N.V. is genoteerd aan de Amsterdamse Effectenbeurs.

Dr. Jan Campschroer is principal consultant bij Ordina Public Consulting. Hij is verantwoordelijk voor het ontwikkelen van kennis, producten en diensten. Daarnaast voert hij opdrachten uit als informatie of applicatiearchitect, en adviseert en coacht hij bij het gebruiken van architectuur. Jan is telefonisch te bereiken via 073-5282828 of via mail op het adres [email protected] .

10