Het succesvol zijn als onderneming onder uitdagende (markt)omstandigheden vergt een topfitte organisatie: een doordacht producten- of dienstenaanbod, efficiënte bedrijfsprocessen en slagvaardige en kundige medewerkers. Het verbeteren van de conditie van uw organisatie vraagt om programma’s rondom producten/dienstenrationalisatie, procesverbetering met bijvoorbeeld Lean/Six Sigma en personele reorganisaties. Maar hoe houdt u uw IT-systemen en -infrastructuur op dergelijke ingrijpende transformaties aangesloten? Uit ervaring weten wij dat Enterprise Architectuur u daarbij kan helpen. Door uw architecten te vragen om inzicht en overzicht en een pragmatische invulling van hun rol, kunt u zelfs extra vaart geven aan de verandering.
Inleiding
‘I often describe the life of a manager as a long and rapid succession of sub-optimal decisions taken partly in the dark’ – Kruchten, 2001.
Organisaties zijn voortdurend in staat van verandering, inspelend op marktomstandigheden en zoekend naar schaalgrootte. Afhankelijk van de sector is de verandering gericht op bijvoorbeeld van product- naar klantgericht werken, naar operational excellence of het realiseren van snelle maar verantwoorde groei. Elke transformatie van de bedrijfsvoering gaat gepaard met veranderingen aan uw IT-systemen en infrastructuur (verder IT-landschap te noemen) en de IT-organisatie.
Alignment is een veelgehoorde en veelgebruikte term. In dit artikel gebruiken we alignment als ‘in of op één lijn brengen’. In de Nederlandse vertaling wordt ook duidelijk dat alignment twee componenten kent: het passend op elkaar aansluiten van verschillende onderdelen, maar ook het beleid, de mensen met elkaar in overeenstemming brengen. Verlang van uw architect dus dat hij of zij een communicator is, die verschillen kan overbruggen, goed kan onderhandelen en mensen kan samenbrengen.
Informatietechnologie is voor de meeste organisaties een kritisch bedrijfsmiddel. Een goede ‘alignment’ (zie kader) tussen primaire bedrijfsvoering en informatietechnologie is noodzakelijk om snel te kunnen reageren op marktontwikkelingen en om profijt te kunnen hebben van de ‘competitive advantage’ van informatietechnologie als onderdeel van diensten en producten. Althans, in theorie.
In de praktijk blijkt IT veelal een beperkende factor voor vernieuwingen. De lappendeken van honderden, soms duizenden applicaties met (tien)duizenden interfaces, lastig te onderhouden legacy applicaties en verouderde datacenters betekent een hoge technische complexiteit van het IT-landschap.
Enterprise Architectuur bevindt zich op het snijvlak tussen primaire bedrijfsvoering en informatietechnologie en brengt deze in één lijn. Daarnaast biedt Enterprise Architectuur middelen om complexiteit van zowel de organisatie als de informatietechnologie te beheersen, door onder meer relaties inzichtelijk te maken tussen primaire bedrijfsprocessen en informatietechnologie en hierdoor de impact van veranderingen op voorhand bloot te leggen. Althans, in theorie.
In dit artikel laten we zien hoe Enterprise Architectuur in de praktijk een goede bijdrage kan leveren aan het begeleiden van complexe veranderingen en illustreren we dit aan de hand van enkele (geanonimiseerde) voorbeelden.
Complexiteit kent meerdere gezichten
Eerst kijken we kort[Geïnteresseerden kunnen zich verdiepen in het boek No Silver Bullet – Essence and Accidents of Software Engineering van F.P. Brooks ([Broo87]).] naar twee kanten van het begrip complexiteit. De eerste vorm van complexiteit komt voort uit de aard van de bedrijfsvoering, zoals de inspanning die nodig is om geld te verdienen. Denk hierbij aan een product dat intrinsiek complex is (een ingewikkelde verzekeringspolis of een hightech device). Deze vorm van complexiteit is misschien wel uw onderscheidend vermogen in de markt en kan alleen door productinnovaties of -wijzigingen veranderen. In de literatuur heet dit essentiële complexiteit. Wij omschrijven dit vaak als ‘het DNA’ van uw bedrijf; dit is wat uw bedrijf uniek maakt.
De tweede vorm van complexiteit is niet strikt noodzakelijk voor de primaire bedrijfsvoering, maar is het gevolg van historische keuzes, of nodig voor instandhouding en beheersing van de bedrijfsvoering. Denk aan de integratieproblematiek tussen legacy applicaties en allerlei raamwerken op het gebied van projectmanagement, risicobeheersing en control frameworks. In de literatuur wordt dit aangeduid met toevallige of bijkomstige complexiteit, de ‘bijvangst’ van bedrijfsvoering.
In onze visie is Enterprise Architectuur hét instrument voor het terugdringen van toevallige complexiteit, juist bij lastige transformaties. Hierdoor komt schaarse tijd en energie vrij die kan worden ingezet voor waaraan de organisatie haar bestaansrecht ontleent, zoals betere voortbrengingsprocessen, producten en/of diensten.
Een organisatie in de financiële sector kampte met onderling moeilijk communicerende IT-systemen. Zo waren klanten dubbel opgevoerd, was het niet duidelijk welk systeem de meest actuele gegevens bevatte en vonden er veel handmatige acties plaats om bijvoorbeeld facturen in te boeken, te accorderen en te betalen.
Enterprise Architecten hebben vervolgens in deze organisatie de informatiestromen gecategoriseerd in primair, secundair en overig. Deze indeling had tot doel tot een goede prioriteitstelling te komen. De vergelijking tussen de gewenste staat (zoveel mogelijk geautomatiseerd) en de huidige staat gaf inzicht in het te volgen migratiepad en een geprioriteerde indeling in een portfolio van projecten.
Bij het uitvoeren van de verschillende projecten waren de architecten verantwoordelijk voor het bewaken van de eindresultaten en adviseerden zij over de (samenhang van) wijzigingsverzoeken die door de projecten afzonderlijk werden gedaan. Ook waren de architecten vraagbaak voor projectmanagers en informatieanalisten; zij hadden immers het overzicht en konden gevolgen van schijnbaar kleine wijzigingen overzien.
Enterprise Architectuur kan, voor het terugdringen van complexiteit, beschikken over veel modellen en concepten. De vrij te gebruiken TOGAF-methodiek voor architectuurontwikkeling en ontwikkeling onder architectuur blijkt veruit het populairst. In opzet is deze vergelijkbaar met bekende projectmanagementmethodieken, dat wil zeggen dat het raamwerk zeer uitgebreid is en op maat gesneden moet worden voor de organisatie waar het wordt toegepast. Voor een meer uitvoerige behandeling van architectuurmodellen en -concepten verwijzen we u graag naar Compact 2011-1 ‘Architectuurvraagstukken’.
Vóór de transformatie: inzicht en overzicht
Alle organisaties hebben dus te maken met een of andere vorm van complexiteit als het gaat om hun IT-landschap. Als het IT-landschap moeilijk te doorgronden is, wordt het lastig de juiste beslissingen te nemen, te onderbouwen en de uitvoering te beheersen.
In deze stap draagt Enterprise Architectuur met name bij door het verschaffen van inzicht en overzicht als het gaat om de samenhang van IT en de bedrijfsvoering. Het is zelfs aan te bevelen de architect mede verantwoordelijk te maken voor de kwaliteit van de IT-ondersteuning van de bedrijfsvoering. In feite wordt de architect daarmee verantwoordelijk voor de vormgeving van de uitwerking van de verandering.
In onze praktijk zien we vaak een afdeling architecten die deze taak (het verschaffen van inzicht en overzicht) interpreteert als het moeten maken van holistische platen; ze proberen de werkelijkheid te fixeren in architectuurbeelden en -paradigma’s. Dit leidt onherroepelijk tot een conservatieve houding, in plaats van één die veranderingen stimuleert en mogelijk maakt (enabling). De kracht van de architect is er naar ons idee in gelegen om het juiste detailniveau te treffen, op het juiste moment en in de juiste bewoordingen voor het publiek. Dat betekent dus dat holistische overzichtsplaten alleen gemaakt worden als daar een directe en aanwijsbare behoefte aan is. In die zin is een architect gebaat bij een wat luie en opportunistische houding.
Enterprise Architectuur kan met een dergelijke houding bijdragen door inzichtelijk te maken hoe het IT-landschap in elkaar zit en welke componenten direct bijdragen aan de bedrijfsvoering, en kan verschillende scenario’s schetsen. Dit alles uiteraard direct gekoppeld aan de voorliggende transformatie.
Maar hoe vergaart een architect dat inzicht? Helaas bestaat hier geen haarlemmerolie voor. Het vereist allereerst een goede kennis van het bedrijf, van de sector waarin het opereert en van het businessmodel dat het hanteert. Al deze contextuele kennis kán een rol spelen bij het adviseren over het IT-landschap. Om deze verschillende aspecten op het juiste moment op een relevante manier te kunnen combineren en daarover helder te communiceren, bestaat het vak van ‘architect’.
Bij een pensioenverzekeraar moest, als gevolg van de komst van het Uniform PensioenOverzicht (UPO), polisinformatie uit verschillende systemen op één overzicht gepresenteerd worden. De hiervoor in te zetten identificatiesleutel bleek fysiek te groot voor het veld ‘sleutel’ van één van de administratiesystemen. Een relatief eenvoudige change, ‘sleutel vergroten van zeven naar twintig posities’ werd ingezet.
Gelukkig werd Enterprise Architectuur geraadpleegd. Uit analyse van de informatiestromen bleek namelijk dat de nieuwe identificatiesleutel in nog vier andere systemen gebruikt zou gaan worden. Drie van deze systemen zouden via een controlemaatregel een sleutelgrootte van zeven posities afdwingen, hoewel zij technisch de nieuwe sleutel wel zouden kunnen accepteren. Eén van deze systemen bleek het printsysteem. Het afdrukken van de jaarlijkse overzichten zou door het doorvoeren van de change onmogelijk geworden zijn!
Een kleine en relevante ingreep van de architect voorkwam dit echter. De change werd iets uitgebreid met het aanpassen van de controlemaatregelen van de drie andere systemen. Een kleine verandering die een noodherstel-procedure vooraf overbodig maakte.
Voorbeeld bij gemeentelijke belastingdienst
Om het bij elkaar brengen van verschillende gezichtspunten te illustreren een praktijkvoorbeeld. Het betreft hier een gemeentelijke belastingdienst die de transitie aan het maken is naar een dienstgerichte organisatie. Een belangrijk kenmerk van het dienstgerichte model is een duidelijke ontkoppeling tussen de verschillende systemen en organisatieonderdelen. Tijdens de implementatie bleek dat het financiële systeem werd gedeeld door twee organisatieonderdelen, te weten de productieafdeling (Aanslagen) en de financiële afdeling. Door deze overlap dreigden de ontkoppelingsdoelstellingen niet gehaald te worden.
In figuur 1 staat deze situatie weergegeven in een swimlane diagram, waarbij de twee banen de afdeling Aanslagen en de financiële afdeling voorstellen. De groene blokken stellen het productiesysteem voor waarin de aanslagen worden vastgesteld. De blauwe blokken stellen het financiële systeem voor waarin de aanslagen worden aangevuld, omgezet naar facturen en geïnd. In het plaatje is duidelijk te zien dat het financiële systeem door twee organisatieonderdelen wordt gebruikt.
Figuur 1. Voorbeeld van verwevenheid in organisatie en functie.
Het eerste plan was om het financiële systeem verder op te delen, om de organisatorische opdeling in het systeem weer te geven. Dit was een kostbare optie aangezien het een standaardpakket betrof, maar de ontkoppelingsdoelstelling zou daarmee wel gehaald worden. Na overleg met de architect stelde hij dat de ontkoppeling ook zonder investering kon worden gerealiseerd. En dit door simpelweg de taakverdeling tussen de afdelingen aan te laten sluiten bij de werkwijze van het financiële pakket. De nieuwe situatie is weergegeven in figuur 2, waarin duidelijk te zien is dat iedere afdeling met haar eigen systeem werkt en zo ook de ontkoppelingsdoelstelling wordt gehaald.
Figuur 2. Voorbeeld van ontvlechting in systeem en organisatie.
In dit geval heeft de architect de complexiteit van het systeem beheerst door het geheel vanuit meerdere gezichtspunten te beschouwen, in dit geval het bedrijfsproces. Het is deze flexibiliteit en creativiteit die u als verandermanager ook mag verwachten van de architecten.
Tijdens de transformatie: beheersen en bijsturen
Als een organisatie eenmaal is begonnen met een transformatie, bestaat er nog de uitdaging om tijdens de transformatie de veelheid aan programma’s en projecten te begeleiden richting het juiste einddoel. Hier begint ook het domein van de programma- en projectmanagementmethoden zoals PMI en Prince2. Enterprise Architectuur-methoden sluiten op twee punten aan op deze methoden. Ten eerste bij de scopeafbakening en ten tweede bij change management.
Eerste aansluiting: de scopeafbakening
Allereerst moet de juiste context gezet worden voor elk project. In onze praktijk komen we vaak een Project-Start-Architectuur (PSA) tegen. Hoewel de term uit het DYA-raamwerk van Sogeti stamt, is de invulling ervan veelkleurig. De bedoeling van de PSA is om de context voor het project in termen van architectuur te beschrijven en bijvoorbeeld de juiste selectie te maken van (mogelijke) pijnpunten voor het project. Het document helpt om de invloed van de architect op het project inzichtelijk te maken. De architect gebruikt het document bij zijn eigen analyse of het voorliggende project werkelijk invulling geeft aan de gewenste end-state en kan actie ondernemen als dat niet het geval blijkt te zijn.
Indien de Enterprise Architectuur verder gevorderd is en ook dieper is uitgewerkt, kan zo’n initieel document als de PSA zeer summier worden of zelfs komen te vervallen; de oplossingsrichtingen zijn immers al bepaald en uitgewerkt.
Ook hier geldt dat het doel de middelen niet heiligt. Vraag uw architecten om hun boerenverstand toe te passen bij het opstellen van de PSA. Als het document niets toevoegt, geen nieuwe inzichten verschaft of niet duidelijk maakt waar het project mogelijk uitdagingen gaat tegenkomen, laat de papierwinkel dan achterwege. Indien het document wordt opgesteld is met name de gebruikte bewoording in deze documenten belangrijk; vraag om duidelijke taal zodat de beslissers uit de business kunnen bepalen of de voorgestelde oplossing hun vraagstelling correct adresseert.
Project-start-architectuur bij een ziekenhuis
Een goed voorbeeld van een startarchitectuur vinden we bij de herinrichting van de backofficeprocessen bij een groot ziekenhuis. Naast de implementatie van een ERP-pakket wordt ook software voor business intelligence, content management, document management en beveiliging uitgerold. Al deze onderdelen moeten in één samenhangend geheel samenwerken. Echter, er bestaat enige overlap tussen de verschillende pakketten. Zo kan bijvoorbeeld het goedkeuringproces van inkomende facturen zowel in de document management-oplossing als in het ERP-pakket plaatsvinden. Tevens is er ruimte voor discussie over locatie van gegevens, zoals de verdeling van de medewerkergegevens tussen het personeelssysteem en de beveiligingssoftware.
Ten behoeve van de inrichting van standaardpakketten worden specialisten ingezet voor de configuratie van het pakket. Deze specialisten kennen veelal de uitdagingen die de klant heeft, de ondersteunde processen en de kenmerken en inrichting van het pakket. In projecten waarbij verschillende standaardpakketten in samenhang worden uitgerold, ontstaat dus een team van specialisten die gezamenlijk de totale oplossing moeten samenstellen. In dit geval bleek het binnen de verschillende specialistenscopes moeilijk te zijn om overeenstemming te bereiken over de pakketoverstijgende processen. Dit had voornamelijk te maken met de verschillende invalshoeken van die specialisten.
Aan het begin van het project is een project-start-architectuur opgesteld waarin met name de aansluiting tussen de pakketten nader is belicht. Volgens de architect was dat namelijk het meest risicovolle gebied. In deze PSA zijn duidelijk de grenzen aangegeven waar de procesondersteuning overgaat van het ene naar het andere pakket. Deze overgangen zijn afgestemd met de betreffende specialisten. Door deze projectspecifieke blauwdruk zijn veel discussies naar voren gehaald en geslecht voordat het project vol op gang was. Hierdoor konden de specialisten zich volledig richten op de inrichting van de pakketten en die focus is de kwaliteit van de totaaloplossing ten goede gekomen.
Tweede aansluiting: de change
Dan is er het tweede punt van aansluiting: change management. De snelheid waarmee uw organisatie kan reageren op changes, vertelt veel over de slagkracht ervan. De snelheid waarmee uw architect kan schakelen, vertelt ook veel over de effectiviteit van de architectuurfunctie. In onze ervaring zijn de architectuurafdelingen die wijzigingen omarmen het meest succesvol. Ook hier geldt dat de architectuur geen starre afbeelding of model moet zijn, maar een weerspiegeling van de wereld van het bedrijf. Omdat die nu eenmaal in beweging is, moeten changes daar ook integraal onderdeel van zijn.
Juist bij een change kan de architect zijn toegevoegde waarde bewijzen: door snel de beslissers bij te schijnen en de complexiteit van het voorliggende in duidelijke bewoordingen toe te lichten, om Kruchten te parafraseren (zie Inleiding), toont de architect zich gesprekspartner op de juiste momenten.
Uiteraard is het achterliggende doel het effect van de change beheerst in te voeren. Een goed begrip van het waarom van de change is daarbij nodig. Pas dan kan het effect voor de doelarchitectuur begrepen worden, en de afweging om de change door te voeren worden gemaakt. Vraag uw architect om de change te belichten vanuit bedrijfsperspectief, en mogelijke effecten op de langetermijndoelstellingen. Ook kunt u hem vragen enkele scenario’s voor te spiegelen. Hij kan u helpen uw besluit steviger te verankeren of te koppelen aan de doelstellingen van de organisatie, waardoor het besluit wellicht eenvoudiger te nemen is.
Ná de transformatie: ondersteunen van planvorming
Indien tijdens een grote transformatie architectuur is ingezet, is aan het einde van het traject een set aan architectuur-deliverables beschikbaar: platen, modellen en beschreven IT-invulling van de bedrijfsstrategie. Het zou zonde zijn deze niet verder te benutten. Ook na een grote transformatie zullen er nog diverse kleinere verandertrajecten worden gestart. Voor deze trajecten geldt ook dat goed inzicht en overzicht kan ondersteunen en de architectuur-deliverables uit de transformatie hebben hier grote waarde. Doordat de architectuur nu goed beschreven is, kan er voor deze trajecten snel geschakeld worden, veel van de principes en overzichten zijn immers onverminderd van kracht.
Onderschat hierbij ook niet het effect dat hopelijk is ontstaan door het werken onder architectuur. Als het goed is, is een cultuur ontstaan waarbij de organisatie gewend is geraakt aan het werken met architectuur. Ook zullen veranderprocessen zijn ingericht met architectuur als component. Als het goed is, zijn de medewerkers van de architectuurafdeling inmiddels de ‘goto-guys’ geworden voor allerlei vraagstukken op het snijvlak van business en IT. Dit niet verder uitnutten zou ook zonde zijn. In feite is na een transformatie een slag gemaakt om de complexiteit structureel beheersbaar te maken.
Om dit hergebruik te faciliteren en te stimuleren is het aan te bevelen om tijdens de transformatie aandacht te besteden aan het gestructureerd opslaan van de architectuur-deliverables. Door de uit vervolgtrajecten voortvloeiende wijzigingen, toevoegingen en uitwerkingen ook te laten opnemen, groeit de architectuur als het ware mee met de organisatie en doet zij wat zij predikt: wijzigingen accepteren als onlosmakelijk onderdeel van het besturen van een organisatie.
Ter illustratie, bij het eerdergenoemde ziekenhuis is na het eerste traject een tweede versie van de architectuur uitgebracht waarin een aantal onderwerpen verder werd uitgewerkt. Deze tweede versie is gebruikt als basis voor een aantal verbetertrajecten die volgden op de grote transformatie. Door de bestaande architectuur te gebruiken in het vervolgtraject is de tijd van die fase aanzienlijk ingekort.
Conclusie / Samenvatting
We hebben in dit artikel gezien dat Enterprise Architectuur bij transformaties kan bijdragen aan het verschaffen van inzicht en overzicht, het helpen controleren en bijsturen van de transformatie en het ondersteunen van de verdere planvorming.
Vraag van uw architecten daarbij een pragmatische aanpak, die zich richt op het halen van resultaat. Verwacht van hen dat zij complexe zaken helder kunnen verwoorden en inzichtelijk maken voor de beslissers. Eis dat zij verandering zien als integraal onderdeel van een (IT-)organisatie en laat hen de architectuur hierop voorbereiden. Verlang geen statische modellen van de werkelijkheid, maar vraag om inzicht, overzicht en sturing op projectbasis. Laat de architecten helpen door u bij een transformatie bij te schijnen bij de beslissingen die u moet nemen, op basis van een solide kennis van uw bedrijf en de bijbehorende IT. Het is niet de Enterprise Architectuur, het zijn uw architecten die haar effectief kunnen inzetten en die uw transformatie kunnen versnellen.
[Broo87] F.P. Brooks, No Silver Bullet – Essence and Accidents of Software Engineering, Computer, 20 (4), p. 10-19, 1987.
[Ross06] J.W. Ross, P. Weill and D.C. Robertson, Enterprise Architecture as Strategy – Creating a Foundation for Business Execution, Harvard Business School Press, Boston, MA, 2006.
[TOGA09] TOGAF Versie 9, 2009.
