Het Ontwerp van de Architectuurfunctie

De management goeroe Eliyahu Goldratt heeft er zijn levenswerk van gemaakt om de boodschap te verkondigen dat het zinloos is om in alle bedrijfsfuncties tegelijkertijd een beetje te investeren – het eindresultaat dat zo kenmerkend is voor doorgaans enerverende budgetteringsrondes. Goldratt wordt niet moe om erop te wijzen dat deze praktijk vooral verspilling bevordert. Bedrijven zouden volgens zijn «theory of constraints» in plaats daarvan moeten kijken naar de knelpunten in de processen, en er heel gericht in investeren om die knelpunten op te lossen [1].

Het architectuurproces – het geheel van activiteiten die we in het Nederlands zo bloemrijk omschrijven met de term «werken onder architectuur» – staat bij veel organisaties volop in de belangstelling. Als je de belangstelling voor publicaties, congressen en opleidingen op het gebied van enterprise architectuur en IT Governance als maat neemt, dan wordt er ook volop in het architectuurproces geïnvesteerd.

De architectuurfunctie wordt meestal beschouwd als een “inrichtingsfunctie”. Het speelt een rol in de vertaling van de strategie (“richten”) naar de operatie (“verrichten”). Denk aan concrete activiteiten als productontwikkeling, procesverbetering, herstructurering en systeemontwikkeling. De architectuurfunctie wordt uitgevoerd als onderdeel van een concreet ontwikkelings- of verbetertraject en de archITect houdt zich uit hoofde van die functie op allerlei niveaus en terreinen bezig met

1. het analyseren van stakeholders en hun concerns
2. het verkennen van oplossingsalternatieven
3. het faciliteren van de keuze voor een oplossingsalternatief
4. het creëren van draagvlak voor het gekozen oplossingsalternatief
5. de ontwikkeling van het gekozen oplossingsalternatief begeleiden
6. het gebruik van het gekozen oplossingsalternatief evalueren
7. het in kaart brengen van verbeterpotentieel

Misschien valt het u op dat dit taken zijn die ook al uitgevoerd werden toen er nog niemand was die de titel “archITect” droeg. Daar is op zich weinig tegen in te brengen. Het spreekt vanzelf dat in de gevallen waarin geen van de direct bij een vernieuwing of verbetering betrokkenen de functie “architect” bekleedt, vaak een of meerdere personen vanuit een andere rol deze taken uitvoeren. Het gaat bij werken onder architectuur dan ook niet persé om nieuwe taken, maar om het expliciet benoemen van deze specifieke combinatie van verantwoordelijkheden.

Het lastige van het inrichten van een architectuurfunctie is dat deze functie raakt aan het ontwikkelen van de strategie en tegelijkertijd raakt aan het ontwikkelen van concrete oplossingen – zoals producten, systemen en platformen. Maar al te vaak is er in de praktijk sprake van een inpendantie mismatch tussen de processen op deze terreinen. Ze “geleiden” veranderingen met een andere snelheid. Het overbruggen van die mismatch is misschien wel de grootste uitdaging bij het vormgeven van de architectuurfunctie.

Om over te Peinzen

Veel organisaties worstelen ermee dat investeringen in enterprise architectuur lastig in concrete business initiatieven onder te brengen zijn. Het probleem laat zich van verschillende kanten te benaderen. De investeringen in enterprise architectuur renderen als het goed is bij meerdere business initiatieven. Veranderingen en vernieuwingen worden makkelijker, beter of sneller te realiseren. Maar als meerdere stakeholders ervan profiteren, waarom wordt de investering dan afgewenteld op de eerste gebruiker? Waarom moet de eerste die beweegt het risico dragen? Is het wel te verkopen dat dit initiatief door de verbreding van de scope meer (management)tijd gaat kosten?

Als het dan zo onaantrekkelijk is om als eerste een architectuurvernieuwing te adopteren, dan zou het gevolg daarvan kunnen zijn dat dit soort fundamentele verbeteringen maar moeizaam tot stand komen. Dan zou de perceptie kunnen ontstaan dat investeringen in enterprise architectuur vooral afleiden van de hoofdzaak. Als het nemen van zulke risico’s ook nog eens onvoldoende wordt beloond, of als er geen duidelijke verantwoordelijkheid wordt belegd, dan bestaat de kans dat managers zich gaan richten op andere prioriteiten. Maar worden er op die manier dan geen gezonde business kansen gemist? Kunnen zulke investeringen gedurende langere tijd ongestraft achterwege blijven? Zou dat op langere termijn de gezondheid van de organisatie niet kunnen ondermijnen?

Het inrichten van een aparte functie voor “enterprise architectuur” beoogt een uitweg uit dit dilemma te bieden. Het is een mechanisme om een verantwoordelijkheid te creëren voor de functies en voorzieningen die het belang van één bedrijfsdomein overstijgen. Dat betekent dat de opdrachtgevers van business innovaties de functies die hun eigen verantwoordelijkheidsgebied overstijgen voortaan over kunnen laten aan een afdeling die daarvoor speciaal geëquipeerd is. Natuurlijk roept zo’n centrale functie tal van nieuwe besturing­vragen op, maar het is tenminste een nobele poging om een begin te maken met het oplossen van de geschetste problematiek.

Het valt te bezien of het inrichten van enterprise architectuur een modegril van voorbijgaande aard is, of dat er anno 2008 dieperliggende redenen zijn waarom het organiseren van een architectuurfunctie op enterprise niveau noodzakelijk is geworden. Persoonlijk ben ik van mening dat de noodzaak voor het organiseren van een architectuurfunctie alles te maken heeft met het definitief afscheid nemen van het silo denken. Of het nou Service Oriented Architecture heet, of Business Process Reengineering, of misschien Complex Event Processing, het zijn allemaal varianten op het thema “slimmer structureren van de informatiefunctie”. Met meer synergie, meer consistentie en meer slagkracht als resultaat.

Het onderscheiden van de bedrijfslaag, de applicatielaag en de technologielaag als aparte aandachtsgebieden in de architectuur is een beproefde manier om zo’n slimmere structuur vorm te geven. Maar deze drie lagen hebben van nature elk een eigen dynamiek c.q. een aparte impedantie; denk bijvoorbeeld maar aan de verschillende discussies die rondom het thema ‘outsourcing’ op de verschillende lagen worden gevoerd – vaak met elk hun eigen uitkomst. Het voorkomen van een mismatch tussen deze lagen rechtvaardigt niet alleen, maar vereist zelfs een andere aanpak, een andere manier van samenwerken. "Werken onder architectuur" is hiervoor juist geknipt. Dat blijkt keer op keer uit de ervaringen van structurele verander- en verbeterinitiatieven.

Is het feit dat veel organisaties vandaag de dag worstelen met een nijpend legacy-probleem trouwens geen voldoende indicatie dat zij hun architectuurfunctie in het verleden misschien onvoldoende hebben belicht?

Effectief en efficiënt innoveren is tegenwoordig voor veel bedrijven van cruciaal belang. Investeringen in de architectuurfunctie zijn dus indachtig het gedachtegoed van Eliyahu Goldratt vooral van belang als de architectuur een bottleneck vormt in het innovatieproces – het proces van ontwikkeling van nieuwe functies en verbetering van bestaande functies. Als de bestaande architectuur vernieuwingen en verbeteringen in uw organisatie beperkt in plaats van stimuleert. Dat plaatst investeringen in architectuur meteen in de relevante business context. Innovatievermogen. Hoe beter het is gesteld met uw architectuur, hoe groter uw innovatievermogen is. En hoe slechter uw architectuur in elkaar zit, hoe slechter u in staat bent om te vernieuwen en te verbeteren.

Dus mocht u ooit de vraag krijgen wat u als archITect nou eigenlijk doet, dan weet u nu het antwoord. Als architect werkt u aan het verbeteren van het innovatievermogen van uw organisatie. Een «mission statement» om trots op te zijn, vindt u niet?

Deze overpeinzing is bedoeld om tot nadenken te stemmen. Het is de 7^de in een reeks bespiegelingen die op dit weblog gepubliceerd zal worden.

[1] Eliyahu M. Goldratt, Jeff Cox: “The Goal: A Process of Ongoing Improvement”; North River Press, 1984.

Be the first to write a comment

Only registered users can write comments.
Please login or register.

Share / deel