Inleiding

In dit artikel willen we ingaan op de vraag hoe Enterprise Architectuur de transformatie van een organisatie kan ondersteunen. Alhoewel de term Enterprise Architectuur veel interpretaties en omschrijvingen kent, is de meest gehanteerde definitie van Enterprise Architectuur gegeven door het Amerikaanse Institute of Electrical and Electronics Engineers ([IEEE00]). Zij luidt, vrij vertaald, als volgt:

In de praktijk wordt dit vaak uitgewerkt als een beschrijving van het geheel aan IT-middelen, -processen en -organisatie, op een gegeven moment in de tijd.

Naar analogie met de bouwwereld: het hebben van een architectuur is essentieel bij het nieuw bouwen van een pand, of het grootschalig verbouwen ervan. Het vertaalt de wensen van de eigenaar van het pand naar de plannen voor nieuwe kamers, dakkapellen, parkeergarages, infrastructuur zoals een waterleiding, enz. Zo ook bij het inzetten van een architect bij de transformatie van een bedrijf. Het ontwikkelen en gebruiken van een Enterprise Architectuur biedt de mogelijkheid om transformaties van strategische omvang te vertalen naar veranderingen in de IT-functie (het geheel aan IT-middelen, -processen en -organisatieonderdelen). En doet dat op een zodanige wijze dat de mogelijkheid ontstaat op het hoogst mogelijke abstractieniveau, dat van de ‘enterprise’ ofwel de organisatie, beslissingen te nemen en deze gestructureerd en consistent door te voeren in de organisatie. Het geeft de organisatie ook de mogelijkheid om ingrijpende IT-veranderingen te toetsen aan een langetermijnvisie.

Allereerst stellen we dat er niet zoiets bestaat als een ‘silver bullet’: gecontroleerd veranderen met Enterprise Architectuur is geenszins een recept voor een geslaagde transformatie. Wij geloven echter wel dat Enterprise Architectuur, in de juiste vorm en de juiste mate, een belangrijke succesfactor kan zijn voor een transformatie, op zowel persoonlijk, organisatorisch, als op technisch gebied.

Ons devies is niet het kiezen van een architectuur, maar het opstellen en naleven van de juiste architectuur. En met juist bedoelen we hier niet dat de architectuur is opgesteld conform een vast en veelgebruikt raamwerk. Met juist bedoelen we dat er een goede aansluiting is met de context en het operationeel model van het bedrijf.

Daarnaast denken wij dat het cruciaal is dat bij het aanstellen van een architect of architectuurteam gekeken moet worden naar organisatorische inbedding van dit team maar vooral ook naar de juiste vaardigheden op technisch, organisatorisch, leidinggevend en communicatief vlak. Hij of zij zal een set vaardigheden moeten bezitten die Enterprise Architectuur het draagvlak geeft dat benodigd is om de transformatie gecontroleerd door te voeren in de IT-functie.

In het vervolg van het artikel zal nader worden ingegaan op de meest voorkomende typen transformatie en de daarbij passende Enterprise Architectuur-patronen, de rol van de architect en de architectuur in het proces van transformatie en ten slotte het opstellen van een Enterprise Architectuur-roadmap op basis van in de markt bekende raamwerken en modellen. Verder hopen we te onderbouwen dat de juiste Enterprise Architect de voorgenomen transformatie kan adviseren en vergemakkelijken en in die zin een efficiëntievoordeel kan bieden voor het bedrijf.

Typen transformatie en Enterprise Architectuur-patronen

In de inleiding en in wat nu volgt wordt de term transformatie gebruikt. Het is goed om even stil te staan bij wat we hiermee bedoelen. Net als voor Enterprise Architectuur zijn er vanuit de literatuur vele beschrijvingen en definities van ‘transformatie’ bekend. De omschrijving die we hier kiezen is te duiden als: ‘een ingrijpende verandering van de organisatie met als doel de afstemming van de organisatiestrategie met de organisatievorm, de werkprocessen en het geheel aan mensen en middelen te optimaliseren.’ ([Weil94])

Transformaties ontstaan zelden ‘zomaar’; organisaties hebben in hun omgeving en intern verschillende invloeden die al dan niet een transformatie initiëren. In figuur 1 hebben we de invloedsfactoren voor een transformatie geprobeerd samen te vatten. Strategieverandering omvat die invloeden die door analyse van markt en portfolio een organisatie doen besluiten een verandering in te zetten. Een voorbeeld is het besluit van veel dagbladen hun producten en diensten uit te breiden met een onlinevariant. Carve-outs en Mergers & Acquisitions zijn factoren die, soms onverwacht, de organisatie ertoe bewegen om onderdelen af te stoten of te fuseren met andere organisaties. Een voorbeeld is de recente acquisitiegolf in de bedrijfssoftwaremarkt. Wet- en regelgeving omvat die factoren die een gevolg zijn van maatschappelijke of juridische afspraken of wetten. Ten slotte is agility een factor die een verandering van de verandervaardigheid beoogt, ofwel de capaciteit van een organisatie om veranderingen in de omgeving eenvoudiger te vertalen naar de operatie.

Figuur 1. Factoren van invloed op een transformatie.

De meeste invloeden zijn te herleiden tot één van deze basistypen. Wet- en regelgeving is wat ons betreft een vreemde eend in de bijt, hier komen we later nog op terug. Ook agility, of verandervaardigheid, neemt wat ons betreft een bijzondere plaats in. Naast een strategische keuze kan agility namelijk ook een gevolg zijn van een transformatie.

We gaan in iets meer detail in op de factor strategieverandering. Hieronder verstaan we herstructureren, het toetreden tot nieuwe markten of juist het afstoten van bepaalde markten, productinnovatie, -differentiatie en -rationalisatie en zelfs het toegeven aan de persoonlijke wensen van bijvoorbeeld een nieuwe bestuurder. We kiezen ervoor om in dit artikel de strategieverandering, met behulp van de waardedisciplines van Treacy en Wiersema ([Trea97]), verder onder te verdelen met de dimensies Product Leadership, Customer Intimacy en Operational Excellence. Dit model geeft in het kort weer welke strategische opties er voor marktleiders zijn waaruit ze moeten kiezen om te kunnen excelleren. Hierin zijn drie basiskeuzen te onderscheiden: Customer Intimacy, waarbij de relatie met de klant centraal staat en diensten en producten nadrukkelijk op wensen van de klant worden ingericht of aangepast. Voorbeeld is van Lanschot Bankiers. Operational Excellence gaat uit van het optimaliseren van het proces dat ten grondslag ligt aan het produceren en leveren van diensten en producten. Voorbeeld: Toyota. Ten slotte benoemt Product Leadership het product en/of dienst van de organisatie als focuspunt. Voorbeeld: Apple.

Figuur 2. De strategische waardedisciplines van Treacy en Wiersema.

Kort gezegd kunnen we stellen dat een organisatie het proces van transformatie ingaat, omdat zij ziet dat een transformatie het antwoord is op de wens of noodzaak die zich in de omgeving manifesteert. Hoewel de term noodzaak onvermijdelijkheid impliceert, grijpen organisaties de transformatie ook vaak aan om een langgekoesterde wens voor een strategiewijziging in te laten gaan.

Hoe kunnen Enterprise Architectuur-patronen bij transformatie helpen?

Een goede architect staat in verbinding met zijn organisatie, en de wereld eromheen. Een verandering van buitenaf mag dus feitelijk niet als verrassing komen voor hem. Het liefst heeft hij beleid voorbereid en voorgelegd, zodat wanneer het feit zich aandient, er kordaat op gereageerd kan worden. Eén van de instrumenten die de architect daarvoor kan inzetten, is het gebruiken van patronen. Deze patronen kennen verschillende verschijningsvormen en verschillende namen: ‘value traps’, ‘design patterns’, ‘industry blueprints’ en ‘architectuurparadigma’s’, om er maar een paar te noemen.

Naar onze mening dienen ze hetzelfde doel: het aanbieden van oplossingen voor ‘standaardsituaties’ waarin een bedrijf zich kan bevinden. En deze patronen kennen een gelaagdheid; dat wil zeggen dat patronen die zich op enterpriseniveau manifesteren, terug kunnen komen op het niveau van individuele systemen of processen.

Een voorbeeld van een patroon is het scheiden van proces, bedrijfsregels en informatie. Dit patroon, dat door één van onze klanten is benoemd als ‘het scheiden van de know van de flow‘, is doorgevoerd op procesniveau (medewerkers die zich met de kennisregels, de know, bezighouden zijn niet betrokken in het proces ofwel de flow).

Voor onze behandeling van Enterprise Architectuur-patronen zullen we ingaan op typische ‘antwoorden’ op de typen transformaties waarin bedrijven zich kunnen bevinden. Uiteraard kent iedere situatie haar eigen, unieke uitgangsvoorwaarden. Aan de orde komen:

1. Strategiewijziging
   1. Transformatie naar Product Leadership
   2. Transformatie naar Customer Intimacy
   3. Transformatie naar Operational Excellence
1. Mergers/acquisition
   1. Strategieën cf. Architecture as a Strategy ([Ross06])
   2. Best-of-breed
3. Carve-out
4. Wet- en regelgeving
5. Verandervaardigheid.

Transformatie naar Product Leadership – het ‘lego’-patroon

Product Leadership heeft een aantal kenmerkende eigenschappen:

• Het bedrijf is zeer sterk in innovatie en merkmarketing.
• De focus ligt op (product)ontwikkeling, een korte time-to-market. Hoge winstmarges in een korte periode.
• Het bedrijf kent een flexibele bedrijfscultuur.
• Productontwikkeling neemt een centrale positie in binnen de organisatie.

We zien in deze tak van de driehoek dat, ondanks het feit dat een bedrijf zich in een bepaalde sector bevindt, de inrichting van het bedrijf in principe onafhankelijk is van die sector. Het bedrijf is een ideeënfabriek, gericht op het snel en vaak lanceren van nieuwe producten en concepten.

De IT die daarbij hoort is dus eveneens niet op producten gericht, maar op het creëren van producten. Het typische patroon dat daarbij past is het zogenaamde ‘lego’-patroon: een weinig restrictieve, open omgeving waarin met bouwblokken wordt gewerkt. Deze bouwblokken zijn gestandaardiseerd, zodat de creativiteit vooral zit in de combinatie van die bouwblokken. Hierbij denken we bijvoorbeeld aan een bedrijf dat korte, iteratieve systeemontwikkelprocessen inzet, liefst gezamenlijk met producteigenaren.

De architect gedraagt zich in dit bedrijf als een bewaker van de standaardisatie van de bouwblokken, van het juist opdelen in bouwblokken en het handhaven van de slagvaardigheid van de IT-organisatie. Hij bewaakt het aantal procedures en adviseert zijn klant over de mogelijkheden die nieuwe technologie biedt. Dit patroon is ook bekend als het ‘lego’-patroon.

Transformatie naar Customer Intimacy – het ‘alles in één doos’-patroon

Customer Intimacy wordt gekenmerkt door:

• Het bedrijf blinkt uit in klantaandacht en klantenservice.
• De organisatie is in staat naar de wensen van de klant te luisteren.
• De beslissingsbevoegdheid ligt laag in de organisatie, is decentraal, en ligt bij de werknemers die dicht bij de klant staan.
• De bedrijfscultuur is gericht op langdurige relaties, klantloyaliteit en klantwaarde.

Ook voor dit type bedrijf geldt dat de branche waarin het zich bevindt, van ondergeschikt belang is. Zoals het Product Leadership-bedrijf een ideeënfabriek was, is het kapitaal van dit bedrijf kennis van en over de klant. Of deze nu een levensverzekering afneemt, of een nieuw bankstel koopt.

De primaire systemen van dit bedrijf zijn dan ook gericht op relatiemanagement en de belangrijkste data binnen het bedrijf zijn de klantdata.

De Enterprise Architect in dit bedrijf richt zich op het beleggen van eigenaarschap van (delen van) de klantdata en zorgt dat deze eenduidig en betrouwbaar voor het hele bedrijf beschikbaar zijn. Hierdoor krijgt het model van één centrale, bedrijfskritische applicatie, met daaromheen al het overige, al gauw de voorkeur boven een volledig gedistribueerde omgeving. Datakwaliteit, eenduidigheid van informatie en duidelijk belegde verantwoordelijkheden rondom processen die de hub raken, zijn belangrijke aandachtspunten.

Transformatie naar Operational Excellence – het ‘fabrieks’patroon

De kenmerken van een bedrijf dat zich op Operational Excellence richt zijn als volgt:

• superieure operatie;
• redelijke kwaliteit voor een lage prijs;
• taak- en procesgedreven aansturing van werknemers (logistieke benadering);
• geen franje; het volume is belangrijk;
• weinig afwijkingen in productassortiment en procedures.

Dit bedrijf richt zich, in tegenstelling tot de voorgaande twee bedrijven, met name op het product of de dienst die geleverd wordt. De IT-systemen zijn het liefst volledig aangepast aan het te produceren product en staan weinig aanpassing toe. De processen die ondersteund worden door de IT-systemen zijn optimaal getuned op doorlooptijd en aantal menselijke interacties.

De Enterprise Architect stelt zich in dit bedrijf voornamelijk op als waakhond: zo veel mogelijk processen zijn geautomatiseerd en kennen een strenge controle aan de bron. Vervolgens vindt er zo min mogelijk interactie met het proces plaats (Straight Through Processing) en is het proces zelf efficiënt (Lean) en kent het een hoge transactionele integriteit. De IT-afdeling streeft naar een hoog CMM-kwaliteitsniveau om de voorspelbaarheid te verhogen. Werknemers houden zich met name bezig met uitvalverwerking.

Carve-outs en Mergers/acquisitions-patronen

Jeanne Ross heeft een aantal operationele businessmodellen gedefinieerd ([Ross06]). De stelling is dat bedrijven die een duidelijk operationeel model hebben gekozen, meer profiteren van een carve-out of fusie dan bedrijven zonder deze duidelijke keuze. Daarnaast heeft het team van Ross ook de Enterprise Architectuur-patronen beschreven (zie figuur 3).

Figuur 3. Operationele modellen te beschouwen bij carve-outs, fusies en overnames.

Voor elk van deze operationele modellen volgt een IT-focus. Ieder model is het meest effectief als de ondersteunende IT toegespitst is op het gekozen model. Het hebben van een IT-architectuur wordt daarmee benadrukt, maar bovenal het hebben van de juiste IT-architectuur voor dit operationele model. Bij afstoten, acquisitie of fusie is het dus van belang om te onderkennen of de operationele modellen van de twee bedrijven (of bedrijfsonderdelen) aansluiten bij elkaar. Er zijn daarna vier keuzen:

1. een nieuw operationeel model kiezen;
2. het model van bedrijf(sonderdeel) A hanteren;
3. het model van bedrijf(sonderdeel) B hanteren;
4. niets doen; beide onderdelen handhaven hun (verschillende) model.

Deze keuze bepaalt in hoge mate de inspanningsverwachting voor de IT-afdelingen, maar geeft tegelijk ook richting aan de samenwerkings- en synergiedoelstellingen.

• Is de toekomstige keuze gericht op het Coordination-model, dan moet binnen de IT-afdeling gekozen worden voor vooral het delen van gemeenschappelijke gegevens en het leggen van betrouwbare verbindingen tussen de bedrijfsonderdelen. Hier ligt het gevaar van ‘het beste van twee werelden’ ofwel ‘best-of-breed’ op de loer. Hoewel dit een zinnige strategie lijkt, blijkt in de praktijk dat de werelden zo ver uit elkaar liggen, zelfs bij bedrijven uit dezelfde branche, dat systemen en processen zelden uitgewisseld kunnen worden, zonder daarmee direct een stoet randverschijnselen (gelieerde systemen, handmatige processen, kantoorautomatisering) naar binnen te slepen. En die randverschijnselen voldoen vaak niet aan het ‘best-of-breed’-paradigma.
• Bij Unification moet de IT-afdeling kiezen voor één van de twee. Het is immers niet de bedoeling meerdere merken naast elkaar te laten bestaan (labels uitgezonderd), dus profiteert het bedrijf het meest van een eenduidige en enkelvoudige vastlegging van gegevens. Het voordeligst is het vaak om, op basis van de te volgen productstrategie, de systemen van één van de twee te kiezen. Hier ligt het gevaar ‘gelijk een slag maken’ op de loer. De integratie van beide bedrijven wordt aangepakt om direct procesverbeteringen door te voeren of nieuwe functionaliteiten in te voeren. Dit is vaak een recept voor mislukking, aangezien bij latere problemen niet kan worden achterhaald of de integratie van de bedrijven ten grondslag ligt aan die problemen, of één van de nieuwe functionaliteiten.
• Bij een keuze voor Diversification verandert aan de IT hooguit organisatorisch iets. Het idee is dat de twee bedrijfsonderdelen zelfstandig blijven functioneren. De businesscase voor de fusie of overname heeft waarschijnlijk vooral in toename marktaandeel of in concurrentievoordeel gezeten. De voordelen zijn voorzichtig te behalen op bijvoorbeeld inkoopafdelingen en het poolen van softwarelicenties. Gaan er meer processen gedeeld worden, dan is wellicht de strategie reeds gewijzigd naar Coordination.
• Bij een keuze voor Replication moeten we in het IT-perspectief vooral denken aan het standaardiseren van sommige diensten (zoals inkoop, facturatie) en het bouwblokgewijs vastleggen van de processen rondom het concept of het product. Het is de bedoeling dat deze gemakkelijk te kopiëren of te gebruiken zijn door nieuwe vestigingen. De architect is op zoek naar een gemakkelijk uit te rollen IT-strategie, die locatieonafhankelijk is. Vergelijk dit met het ontwerpen van een tent of caravan versus het ontwerpen van een wolkenkrabber of bungalow.

De benadering bij een carve-out lijkt in beginsel eenvoudiger. De inspanning hier is afhankelijk van het model dat het bedrijf volgde. De Enterprise Architect met de vooruitziende blik heeft rekening gehouden met de mogelijkheid van een carve-out en waarschijnlijk opereert het bedrijf in één van de categorieën Diversification, Coordination of Replication.

Als de scope van de carve-out goed is gekozen, geldt voor deze drie categorieën dat een carve-out relatief gemakkelijk te realiseren moet zijn; de onderdelen zijn immers voor het grootste gedeelte zelfstandig, en afhankelijk van de precieze scope moet hooguit een aantal systemen (en data) gekopieerd worden meegeleverd. De shared service-afdelingen hebben simpelweg een klant minder en wellicht gaat het inkoopvoordeel verloren.

In de categorie Unification moet de Enterprise Architect allereerst droevig (of teleurgesteld) met de leiding van het bedrijf om tafel en vragen om toelichting van de businesscase. Het moet hem namelijk sterk lijken dat de carve-out gunstig is voor het bedrijf.

Een carve-out op een Unification-bedrijf is namelijk een zeer gevoelige en tijdrovende operatie. De grenzen in de carve-out zijn, als het goed is, voor de IT-afdeling niet terug te vinden in de systemen en processen en zullen dus kunstmatig moeten worden aangebracht. Daarbij de integriteit en betrouwbaarheid van diezelfde systemen en processen handhaven is welhaast onmogelijk.

Wet- en regelgeving

Hoewel het vaak gezien wordt als unieke aanleiding, is onze stelling dat wet- en regelgeving ‘an sich’ nooit de oorzaak is van een transformatie, aangezien het hier altijd om een tweetrapsraket gaat: de wet- en regelgeving stelt bijvoorbeeld nieuwe eisen aan het product. Deze nieuwe eisen worden vertaald naar requirements voor een systeem en kunnen volgens een normaal proces worden doorgevoerd. Wetgeving heeft soms grotere gevolgen dan ‘slechts’ een nieuwe eis aan het product. In dat geval kan het bedrijf besluiten om de wetgeving in te voeren door middel van een reorganisatie of een strategiewijziging. Kortom, door middel van een transformatie.

Wet- en regelgeving is wat ons betreft dus een aanleiding voor elk van de andere typen transformatie en nooit een opzichzelfstaand transformatietype.

Verandervaardigheid

Zoals we eerder al stelden, vinden we verandervaardigheid, of agility, sterk verbonden met Product Leadership. In principe zijn dezelfde aandachtspunten dus van belang: het componentsgewijs opzetten van het IT-landschap (conform het ‘lego’-patroon) levert de hoogste flexibiliteit voor toekomstige veranderingen. Groot verschil met het streven naar Product Leadership is hier echter dat het doel anders is: de organisatie heeft als doel om wendbaarder te zijn, beter in te kunnen spelen op externe factoren, en niet om haar marktdiscipline te verbeteren of te veranderen. Een voorbeeld van een dergelijke transformatie is het streven van overheidsorganisaties om wetswijzigingen sneller te kunnen doorvoeren. Dat streven staat los van het feit dat de meeste overheden streven naar een vorm van Customer Intimacy of Operational Excellence, afhankelijk van hun relatie met de burger of het bedrijfsleven.

Het transformatieproces – de ‘betrokken architect’

In deze paragraaf gaan we in op de antwoorden op de ‘hoe’-vraag van de ingezette transformatie, en dan met architectuur als gezichtspunt. Het besluit over een transformatie kan, zoals we hierboven hebben gezien, door directie of strategisch management van de organisatie genomen worden. Soms is het ook een gevolg van markt- of omgevingsdynamiek die noopt tot een reactieve wijze van besluitvorming. Naar onze mening moet de Enterprise Architect in beide gevallen in een vroeg stadium betrokken zijn bij de besluitvorming. Hij fungeert als adviseur, klankbord en geweten van de organisatie.

In alle gevallen leidt de ingezette transformatie tot een sneeuwbaleffect dat in alle geledingen van de organisatie gevoeld kan gaan worden. Zoals in de eerste paragraaf beschreven, is de noodzaak van controle op deze transformatie essentieel. Vanuit de theorieën over verandermanagement en strategie komen handreikingen over, onder meer, het herinrichten van de financiële functie, marketing, de procesmodellen en de cultuuraspecten ([Thom93]). In menig MBA-programma wordt hieraan aandacht besteed en in de praktijk zijn succesvolle transformaties bekend. Het is echter nog tot op de dag van vandaag een uitdaging om strategische transformaties succesvol te vertalen naar duurzame IT-veranderingen. Vaak wordt de IT-functie van een organisatie gezien als een ‘probleemkind’ bij veranderingen dat ingezette transformaties te laat, te chaotisch of op zijn minst moeizaam volgt. Uiteraard zijn er gevallen bekend van succesvolle transformaties die juist dankzij de mogelijkheden van informatietechnologie zijn ingezet. Toch wordt ook in deze gevallen de specifieke technologie die voor een verandering benodigd is (bijvoorbeeld het toevoegen van een digitaal distributiekanaal naar klanten) als het ware ‘toegevoegd’ aan de bestaande informatiesystemen en dreigt het gevaar van wildgroei en onbeheersbaarheid indien deze veranderingen elkaar snel opvolgen.

Enterprise Architectuur biedt de mogelijkheid om gecontroleerd de transformatie door te voeren in de IT-functie. De raamwerken, methoden en tools die tegenwoordig beschikbaar zijn hebben veelal dit doel en hebben hun praktijkwaarde bewezen. Het gebruikmaken van architectuurraamwerken biedt tevens de mogelijkheid om controls in te bouwen teneinde aan te tonen dat het proces van transformatie gevolgd wordt met maximale risicobeheersing. Daarnaast bieden deze raamwerken de mogelijkheid om tussentijdse controlemomenten in te voegen. Een voorbeeld hiervan is het gebruikmaken van de mogelijkheid om projecten en programma’s die gestart worden in het kader van de transformatie, te toetsen aan de Enterprise Architectuur. Deze toetsing, die te vergelijken valt met een bouwvergunning, is in verschillende architectuurraamwerken opgenomen als bijvoorbeeld ‘projectstartarchitectuur’. In figuur 4 is schematisch aangegeven hoe de Enterprise Architectuur die rol kan vervullen.

Figuur 4. De rol van Enterprise Architectuur bij een transformatieproces.

In figuur 4 is aangegeven dat de transformatie van de IT-functie (de combinatie van de IT-organisatie & governance met de technische infrastructuur) gestuurd wordt door de IT-strategie. De Enterprise Architectuur vertaalt deze IT-strategie naar richtlijnen, principes en keuzen voor beide onderdelen van de IT-functie.

Een voorbeeld van een dergelijke relatie kan gegeven worden aan de hand van een organisatie die haar marktaandeel wil vergroten in een bestaande markt met bestaande producten. De IT-strategie van deze organisatie wordt dientengevolge geënt op drie pijlers, te weten eenvoud, schaalbaarheid en standaardisatie. Vervolgens worden deze kernelementen vertaald door de Enterprise Architect naar een patroon en inrichtingsprincipes voor de IT-functie, bijvoorbeeld ‘gebruik voornamelijk standaardsoftware’, ‘outsource het werkplekbeheer naar een marktpartij’ en ‘maximaliseer op servervirtualisatie’.

Dit voorbeeld geeft aan dat de Enterprise Architectuur inhoudelijk leidend is voor de IT-transformatie en op een hoog abstractieniveau richting geeft aan de veranderprojecten van de organisatie. Het is daarmee de blueprint of de bouwtekening van de nieuwe IT-functie – overigens is daarmee niet gezegd dat de doelarchitectuur uitsluitend een ‘mooie plaat’ is aan de muur van de IT-directeur. Een Enterprise Architectuur is veel meer een set van principes, richtlijnen en keuzen over de inrichting van de IT-functie. Uiteraard zijn grafische weergaven een prima communicatiemiddel om deze principes over te dragen aan belanghebbenden. Hierover later in dit artikel meer.

De projecten die de organisatie uitvoert kennen vaak een borging met de architectuur die soms expliciet benoemd wordt in projectplannen. Een versie hiervan is de reeds genoemde en veelgebruikte ‘projectstartarchitectuur’, waarin de inhoudelijke borging met de doelarchitectuur wordt beschreven en afwijkingen beargumenteerd worden opgenomen. Hiermee wordt tevens geborgd dat de projecten gecontroleerd bijdragen aan de gehele IT- en daarmee businesstransformatie. Dit biedt tevens de mogelijkheid aan een externe auditor van een dergelijk transformatieproces om te toetsen of projecten en programma’s in overeenstemming zijn met de Enterprise Architectuur, dan wel er beargumenteerd en beheerst van afgeweken hebben.

Overigens is het wel belangrijk een aantal succesfactoren van een dergelijke Enterprise Architectuur te benoemen:

1. Voorkom een ‘ ivoren toren’-architectuur. Zoals hierboven beschreven, is het noodzakelijk dat elke belanghebbende in de organisatie de rol van de architectuur ook als zodanig ervaart en accepteert. De druk om een transformatie te laten slagen kan als gevolg hebben dat projecten in de IT-functie met hoge prioriteit en tijdsdruk worden omgeven zodat borging in ‘het grote geheel’ als minder belangrijk wordt ervaren. Met name de traditionele aansturing van projecten op tijd en budget zet het daadwerkelijk inhoudelijk bijdragen van die projecten aan de transformatie onder druk. Het gevaar ontstaat dat project- en programmamanagers zonder architectuurborging hun projecten managen. Daarmee verwordt de Enterprise Architectuur tot een papieren tijger die al snel aan relevantie en actualiteit inlevert. De rol van de Enterprise Architect komt onder druk te staan en hem of haar rest nog weinig meer dan het adagium ‘architecture pour l’architecture’. Dit vereist een business sense bij de Enterprise Architect, gecombineerd met voldoende draagvlak bij IT’ers.
2. ‘Reik hoog, maar blijf staan.’ Ga uit van mogelijkheden, maar ook onmogelijkheden van de techniek. De stand van de huidige IT-functie, zowel organisatorisch, bestuursmatig als technisch, is een zeer relevant vertrekpunt voor de Enterprise Architect. Een goede analyse van de huidige situatie is essentieel om de Enterprise Architectuur realistisch te laten zijn.
3. Kijk over de grenzen van de organisatie heen. Een Enterprise Architectuur heeft weliswaar als scope de IT-functie van de organisatie (per definitie), maar keten- of businesspartners, klanten en leveranciers kunnen waardevolle assets bieden of eisen stellen die de Enterprise Architectuur dient mee te nemen in het opstellen van de doelarchitectuur. Een voorbeeld daarvan is het gebruik van referentiearchitecturen zoals de NORA[Nederlandse overheidsreferentiearchitectuur.].
4. ‘Architectuur is een proces, geen plaat.’ De relevantie van de Enterprise Architectuur blijft gewaarborgd als er een adequaat architectuur governance-proces aanwezig is. Dit houdt voornamelijk in dat de Enterprise Architect zich blijft voeden met de inzichten en veranderingen die zich manifesteren in de organisatie en deze vertaalt naar de doelarchitectuur.

Uit het bovenstaande volgt vooral dat de rol van de Enterprise Architectuur een cruciale is bij het gecontroleerd veranderen, maar dat het tevens hoge eisen stelt aan de architecten die deze Enterprise Architectuur opstellen, uitdragen en beheren. Een hoge mate van volwassenheid van de organisatie met betrekking tot architectuur is een belangrijk ingrediënt voor succesvol transformeren. Daarnaast zal de Enterprise Architect zich moeten bekwamen in de werelden van de IT, de strategie en de bedrijfsvoering van de organisatie.

Het opstellen van de Enterprise Architectuur-roadmap

Adoptie en realisatie: aanpakken met een roadmap

Zoals eerder gesteld, is een Enterprise Architectuur veel meer een proces dan een ‘plaat’. Dit impliceert een vorm van sturing aan het proces van totstandkoming en iteraties van de doelarchitectuur. Een veelgebruikte techniek hierbij is het gebruik van een roadmap. Een Enterprise Architectuur-roadmap is een geordende volgorde van Enterprise Architectuur-initiatieven die nodig zijn om de overgang van de huidige (enterprise) architectuur tot de toekomstige Enterprise Architectuur te faciliteren en te realiseren.

Enterprise Architectuur-initiatieven kunnen zijn:

• het realiseren van benodigde documentatie, ontwerpen en communicatiekanalen;
• het uitvoeren van een haalbaarheidsstudie of volwassenheidsonderzoek;
• de sponsoring van een project voor de uitrol van nieuwe businesscontent op basis van het Enterprise Architectuur-model;
• training en opleiding in Enterprise Architectuur, of onderliggende (software) architectuurprincipes en -stijlen, zoals bijvoorbeeld servicegeoriënteerde architectuur.

De Enterprise Architectuur-roadmap zal idealiter ook aantonen dat de voorgestelde Enterprise Architectuur-initiatieven overeenkomen met de initiatieven en doelstellingen uit het transformatieprogramma en de (IT-)strategie. Hierbij geldt overigens ook een wederkerigheid: de Enterprise Architectuur-roadmap kan voeding geven aan de gehele transformatieplannen. Vooral bij IT-gedreven of -intensieve transformaties zal dit gelden. Daarnaast biedt de roadmap een houvast voor de review of audit van een dergelijke transformatie.

Succesfactoren van een Enterprise Architectuur-roadmap

Organisatietransformatie in combinatie met een verandering op het gebied van de Enterprise Architectuur is een complexe zaak waarbij alleen een maatwerkbenadering recht doet aan het vraagstuk. De maatwerkbenadering moet haar reflectie vinden in de op te stellen aanpak en methodologie: de specifieke veranderingsroadmap. Het opstellen van de roadmap kent vanuit de praktijk een aantal succesfactoren:

Draagvlak voor de Enterprise Architectuur en de nieuwe manier van werken

Eén van de succesfactoren voor een succesvolle acceptatie en uitrol van de Enterprise Architectuur is een snelle, concrete toepassing van de architectuur in de praktijk en dus op de ‘werkvloer’. Dat betekent dat de Enterprise Architectuur-roadmap daadwerkelijk en op korte termijn moet bijdragen tot het verhogen van de kwaliteit, efficiëntie en effectiviteit van de IT-functie. In de praktijk (op de ‘werkvloer’) betekent dit dat de Enterprise Architectuur voelbaar moet bijdragen aan:

• waarborgen van de toegankelijkheid van de essentiële informatie voor individuen en groepen;
• ondersteuning en optimalisering van de activiteiten van de individuele kenniswerker;
• stimulering van kennisdeling en doorstroming.

Een goede aanpak moet snel een draagvlak op de ‘werkvloer’ laten ontstaan die haar vruchten zal afwerpen bij volgende initiatieven (verdere uitrol van de Enterprise Architectuur als kloppend hart binnen de informatiehuishouding en toepassing op verdere businesscontent).

Managen van verwachtingen

Werken onder architectuur betekent voor de IT-functie een fundamentele wijziging in het omgaan met veranderingen. Het mogelijk gevoelde verlies aan autonomie door de IT-(project)managers kan worden gecompenseerd door het inzetten van een krachtige verandermanager en bijna overdadige communicatie. Het managen van verwachtingen is in de overgangsfase cruciaal.

TOGAF Architecture Development Method

Om de Enterprise Architectuur-roadmap vorm te geven, waarbij we de succesfactoren die hierboven zijn benoemd meenemen, kan worden teruggevallen op meerdere in de markt bekende methoden. De bekendste daarvan zijn Zachman Framework en TOGAF (The Open Group Architecture Framework). Binnen de TOGAF-set van methoden, modellen en best practices lichten we de Architecture Development Method (ADM) verder toe; deze kent een groot marktaandeel en is door zijn vrije beschikbaarheid via The Open Group niet verbonden aan een ICT-dienstverlener of productleverancier.

Figuur 5. Het TOGAF Architecture Development Method-raamwerk.

TOGAF ADM onderscheidt zich van andere frameworks en methoden doordat het minder belang hecht aan normalisering en specifieke standaarden (in tegenstelling tot Zachman), maar veeleer de bouwstenen biedt voor maatwerkrealisatie van Enterprise Architectuur en daarbij een goed midden houdt tussen het business- en technology-end.

TOGAF ADM is een framework dat ‘bouwblokken’ biedt voor de realisatie van een Enterprise Architectuur. Het vormt een cyclisch geheel van fasen die elkaar opvolgen maar dat niet per se altijd uit dezelfde fasen hoeft te bestaan. Hier wordt de flexibiliteit van ADM duidelijk: mocht de organisatie bijvoorbeeld al beschikken over een formele ‘Architectuur Visie’, dan zou fase A (Architecture Vision) overgeslagen kunnen worden.

Toetsing en risicobeheersing

Naast een stuurinstrument is de Enterprise Architectuur ook een instrument dat risico’s in kaart kan brengen, kan beheersen en de mogelijkheid biedt om controls in de IT-transformatie in te bouwen. De Enterprise Architectuur is een centraal punt waarbinnen IT-beslissingen worden gedocumenteerd, geanalyseerd en getoetst aan vooraf gestelde principes en richtlijnen. Juist het gebruik van een raamwerk als TOGAF maakt het mogelijk om Enterprise Architectuur te gebruiken als zodanig. In figuur 5 is te zien dat Implementation Governance een belangrijke stap in ADM is. Dit houdt vooral in dat vanuit de architectuurfunctie bekeken wordt of de implementatie van onderdelen van de Enterprise Architectuur (door middel van software-implementatieprojecten bijvoorbeeld) conform vooraf gestelde criteria verloopt. ADM kan daarmee ook ingezet worden als instrument van een externe auditor om te valideren of alle stappen doorlopen zijn, en indien er afwijkingen geconstateerd zijn of deze afwijkingen gecontroleerd, gedragen en gedocumenteerd zijn.

Voorbeeld uit de praktijk

Een groot Nederlands overslagbedrijf in de petrochemische industrie heeft in 2007 de beslissing genomen zijn strategie te wijzigen. De belangrijkste redenen hiervoor waren de toenemende margedruk op het transport en de overslag van aardolie en het feit dat concurrenten, voornamelijk uit Azië, goedkoper konden opereren.

De strategiewijziging hield voornamelijk in dat er een concentratie plaatsvond in de producten- en dienstenportfolio (het afstoten van een eigen rederij bijvoorbeeld) en het maximaliseren van het rendement op bestaande klanten. Dit valt grotendeels te begrijpen als een beweging naar Customer Intimacy. De vertaling van deze bedrijfsstrategie naar de IT-strategie (of ‘IT-vision 2012’, zoals het bedrijf dit zelf noemde) is in de loop van 2007/2008 gedaan door een extern bureau. Een bijbehorend IT-transformatieprogramma is opgezet door de IT-directeur en zijn Enterprise Architect. Dit is een belangrijke voorwaarde voor het succes gebleken: de Enterprise Architect en de IT-directeur zijn het gehele traject als team opgetreden en de Enterprise Architect bezat voldoende mandaat om het ‘bouwen onder architectuur’ te laten slagen.

Het Enterprise Architectuur-patroon dat past bij deze transformatie is, zoals beschreven, het zogenaamde ‘lego’-patroon waarbij standaardbouwblokken worden gedefinieerd die, afhankelijk van klantwensen, kunnen worden samengevoegd. Deze bouwblokken werden door dit bedrijf benoemd als ‘Common Solutions’. Uiteraard is de transformatie over een langere periode uitgesmeerd, een periode van vier jaar werd realistischer geschat. Figuur 6 toont de plateauplanning die door de Enterprise Architect is gebruikt. Voor de realisatie van Common Solutions is op projectbasis gewerkt, waarbij een combinatie van het TOGAF-raamwerk en de projectstartarchitectuur van DYA (architectuurraamwerk van Sogeti) is gebruikt.

Figuur 6. Plateauplanning voor de Enterprise Architectuur.

Een aantal succesfactoren bij deze transformatie is geweest:

• teamwerk van IT-directeur en Enterprise Architect;
• incrementeel (opdelen in plateaus) opbouwen van de Enterprise Architectuur;
• gedegen afstemming van IT-visie en bedrijfsstrategie alvorens te starten;
• goed omschreven proces van ontwerp, toetsing en bouw van onderdelen van de Enterprise Architectuur (gebaseerd op TOGAF).

Conclusie

Als we kijken naar Enterprise Architectuur als veranderinstrument bij strategische organisatietransformaties, is er een aantal punten van aandacht. Allereerst zagen we dat het type transformatie van de organisatie als geheel een grote invloed heeft op de inrichting van de Enterprise Architectuur en de rol van de architect bij deze transformatie. Het is belangrijk dat deze typen transformaties onderkend worden en leidend zijn voor de architect bij het opstellen en gebruiken van de Enterprise Architectuur. Vervolgens zagen we dat bij de implementatie van de Enterprise Architectuur nadrukkelijk gekeken moet worden naar de rol en het draagvlak van de architectuurfunctie, de (keten)partners van de organisatie en de borging met het veranderprogramma en de projecten daarbinnen. Uiteindelijk is het essentieel dat de Enterprise Architectuur resulteert in een roadmap die prioriteiten stelt en de toegevoegde waarde voor zowel de organisatie, de transformatie als de architectuur zelf centraal stelt.