Onder architectuur werken: zes succesfactoren die het verschil maken

Veel organisaties hebben een architectuur. Er is een visie, er zijn principes vastgesteld en er hangt een plaat met het applicatielandschap aan de muur. Toch worden projecten gestart zonder toets, kiest een afdeling zelf een nieuw pakket en groeit het aantal koppelingen elk jaar. De architectuur bestaat, maar de organisatie werkt er niet onder.

In dit artikel beschrijf ik wat onder architectuur werken in de praktijk betekent, waarom het zo vaak blijft steken en welke zes factoren het verschil maken. Ik baseer mij op wetenschappelijk onderzoek naar de waarde van enterprise-architectuur en op ervaring met het invoeren van architectuur bij gemeenten, een waterschap, onderwijsinstellingen en een internationale onderneming.

Wat betekent onder architectuur werken?

Architectuur beschrijft de samenhang tussen de doelen van een organisatie, haar processen, haar informatie en de systemen die dat ondersteunen. Onder architectuur werken gaat een stap verder. Het betekent dat veranderingen in die samenhang niet los van elkaar worden besloten, maar worden getoetst aan principes en kaders die de organisatie zelf heeft vastgesteld.

Ross, Weill en Robertson (2006) omschrijven architectuur als de organiserende logica voor processen en IT, afgeleid van de manier waarop een organisatie wil werken. Die definitie is nuttig, omdat zij laat zien dat architectuur geen IT-document is. Het is een bestuurlijke keuze over hoe de organisatie zichzelf organiseert, vertaald naar principes die bij elk project opnieuw richting geven.

Waarom architectuur vaak een papieren exercitie blijft

De meest gehoorde klacht over architectuur is dat zij te abstract is en te laat komt. Architecten leveren een document op, projecten lopen al, en het document belandt in een map. Dat is geen gebrek aan kwaliteit van het document. Het is een gebrek aan verankering.

Lange, Mendling en Recker (2016) onderzochten bij 133 architectuurprofessionals welke factoren het succes van architectuurmanagement verklaren. Zij vonden vier factoren: de kwaliteit van de architectuurproducten, de kwaliteit van de ondersteunende infrastructuur, de kwaliteit van de dienstverlening door de architectuurfunctie en de verankering in de organisatie. Opvallend is dat die verankering een centrale rol speelt. De invloed van infrastructuur en dienstverlening op het resultaat loopt grotendeels via de mate waarin architectuur in de organisatie is ingebed. Ook vonden zij dat de tevredenheid van gebruikers over de architectuur weinig zegt over het succes ervan.

Met andere woorden: een mooie architectuur die niet is verankerd in besluitvorming en werkprocessen levert weinig op. Dat verklaart waarom investeren in betere documenten zelden de oplossing is.

Zes succesfactoren

1. Bestuurlijk eigenaarschap en draagvlak

Architectuur maakt keuzes zichtbaar die anders impliciet blijven. Dat raakt belangen van afdelingen en leidinggevenden. Zonder een bestuurder die de principes als eigen keuzes draagt, wint bij elk conflict het belang van het lopende project. Kotter (1995) wees er al op dat veranderingen zonder een krachtige coalitie aan de top vroeg of laat stranden. Voor architectuur geldt dat in versterkte mate, omdat het resultaat pas op langere termijn zichtbaar wordt.

Draagvlak is meer dan instemming. Weiner (2009) beschrijft de bereidheid van een organisatie om te veranderen als de combinatie van gedeelde wil (change commitment) en gedeeld vertrouwen dat het lukt (change efficacy). Voor architectuur betekent dit: bestuur en management moeten niet alleen vinden dat onder architectuur werken belangrijk is, zij moeten ook zien welke middelen, rollen en tijd het vraagt. Een architectuurvisie die in het bestuur wordt vastgesteld, met een expliciete keuze voor wie waarover beslist, is daarom de eerste stap. Hoe u dat draagvlak opbouwt, beschreef ik in Draagvlak creëren in projecten.

2. Verankering in besluitvorming en werkprocessen

Architectuur werkt pas als zij een vaste plek heeft op de momenten waarop echt wordt besloten. Denk aan de start van een project, de keuze voor een nieuw pakket, een investeringsvoorstel of een wijziging in een werkproces. Leg vast dat op die momenten een architectuurtoets plaatsvindt, wie die uitvoert en wat er gebeurt als een voorstel afwijkt.

Boh en Yellin (2007) lieten zien dat architectuurstandaarden vooral effect hebben als zij worden ondersteund door governancemechanismen, zoals toetsing van projecten en afspraken over investeringsbeslissingen. Zonder die mechanismen blijven standaarden vrijblijvend. In de praktijk werkt het goed om de architectuurtoets op te nemen in de bestaande portfolio- of projectstart, in plaats van een apart architectuurproces te bouwen dat naast de lijn staat.

Verankering in werkprocessen gaat nog een stap verder. Wie de eigenaar is van een proces, is ook eigenaar van de informatie en de systemen die dat proces ondersteunen. Door eigenaarschap bij proceseigenaren te beleggen en hen te ondersteunen met eenvoudige rapportages, wordt architectuur onderdeel van het dagelijkse werk in plaats van een taak van een paar specialisten.

3. Kaders die richting geven, niet alleen beschrijven

Een architectuur die alleen beschrijft hoe het landschap eruitziet, helpt weinig bij een keuze. Wat helpt zijn principes met een duidelijke rationale en duidelijke implicaties, bijvoorbeeld: gegevens worden eenmalig vastgelegd en meervoudig gebruikt. Zo’n principe maakt direct duidelijk waarom een nieuw pakket met een eigen klantenbestand een probleem is. Houd het aantal principes beperkt en maak ze toetsbaar. Tien principes die iedereen kent, zijn meer waard dan veertig die niemand kan opnoemen.

4. Een architectuurfunctie die dienstverlenend werkt

Architecten die vooral controleren, worden omzeild. Architecten die helpen, worden opgezocht. Lange en collega’s (2016) vonden dat de kwaliteit van de dienstverlening door de architectuurfunctie via de verankering bijdraagt aan het resultaat. Praktisch betekent dit: architecten schuiven vroeg aan bij projecten, denken mee over oplossingen en leveren snel een advies. Een architectuurtoets die drie weken duurt, nodigt uit tot omzeilen.

Van den Berg en Van Steenbergen (2006) benadrukken in hun werk over het opbouwen van een architectuurpraktijk dat architectuur moet aansluiten bij de concrete vragen van de organisatie. Het uitgangspunt is niet een compleet model, maar de vraag waar de organisatie nu mee worstelt.

5. Aansluiten bij een referentiearchitectuur

Voor publieke organisaties hoeft architectuur niet vanaf nul te beginnen. De Nederlandse Overheid Referentie Architectuur (NORA) biedt een gemeenschappelijke basis met principes voor de hele overheid. Daarop bouwen sectorale referentiearchitecturen voort, zoals GEMMA voor gemeenten, WILMA voor waterschappen en ROSA voor het onderwijs.

Aansluiten bij zo’n referentiearchitectuur versnelt en maakt samenwerking met ketenpartners eenvoudiger. De valkuil is dat een organisatie de referentiearchitectuur overneemt zonder eigen keuzes te maken. Een referentiearchitectuur is een vertrekpunt, geen vervanging van bestuurlijke afwegingen.

6. Groeien in stappen en meten wat het oplevert

Ross en collega’s (2006) beschrijven dat organisaties in stappen groeien in hun architectuurvolwassenheid: van losse, afdelingsgebonden oplossingen, via gestandaardiseerde technologie en een geoptimaliseerde kern, naar een modulaire organisatie. Elke stap vraagt andere vaardigheden en levert andere voordelen op. Wie te snel wil, overvraagt de organisatie.

Maak daarom zichtbaar wat architectuur oplevert. Tamm, Seddon, Shanks en Reynolds (2011) laten zien dat architectuur waarde creëert via vier mechanismen: betere afstemming tussen organisatie en IT, betere beschikbaarheid van informatie, een optimaler gebruik van middelen en een betere samenhang tussen die middelen. Kies bij elk van die vier een of twee eenvoudige indicatoren, zoals het aantal applicaties, het aantal dubbele gegevensbronnen of het aandeel projecten dat de architectuurtoets doorliep. Dat maakt het gesprek met het bestuur concreet.

Uit de praktijk: architectuur bij een waterschap

Bij een waterschap was er een architectuurvisie, maar werden informatie en systemen per afdeling georganiseerd. De aanpak begon bij het bestuur: een visie op informatiehuishouding en architectuur, gebaseerd op WILMA, werd bestuurlijk vastgesteld. Vervolgens is het eigenaarschap bij proceseigenaren gelegd en is de informatie procesmatig geordend. Governance is ingericht op strategisch, tactisch en operationeel niveau, met één centrale catalogus waarin processen, informatieobjecten en systemen aan elkaar zijn gekoppeld.

Het verschil zat niet in een beter document, maar in de plek waar architectuur meewoog: bij de directie, bij de start van projecten en in het dagelijkse werk van proceseigenaren.

Checklist: staat uw organisatie klaar om onder architectuur te werken?

Succesfactor	Toetsvraag
Bestuurlijk eigenaarschap	Is er een bestuurder die de architectuurprincipes uitdraagt en knopen doorhakt bij conflicten?
Verankering in besluitvorming	Is vastgelegd bij welke besluiten een architectuurtoets verplicht is, en wie die uitvoert?
Verankering in werkprocessen	Weten proceseigenaren dat zij eigenaar zijn van de informatie en systemen in hun proces?
Richtinggevende kaders	Kunnen projectleiders de belangrijkste principes noemen en uitleggen?
Dienstverlenende architectuurfunctie	Krijgt een project binnen een week een bruikbaar architectuuradvies?
Referentiearchitectuur	Is duidelijk welke referentiearchitectuur u volgt en waar u bewust afwijkt?
Groei en resultaat	Rapporteert u minstens jaarlijks wat architectuur heeft opgeleverd?

Veelgestelde vragen

Hoe lang duurt het voordat een organisatie echt onder architectuur werkt?

Reken op een doorlooptijd van één tot drie jaar voordat architectuur vanzelfsprekend meeweegt in besluiten. De eerste resultaten, zoals een werkende architectuurtoets bij projecten, zijn vaak binnen een halfjaar zichtbaar.

Heeft een kleine organisatie een eigen architect nodig?

Niet per se. Een kleine organisatie kan de architectuurfunctie beleggen bij een informatiemanager of inhuren voor een beperkt aantal dagen per maand. Belangrijker dan de omvang is dat de rol een vaste plek heeft in de besluitvorming.

Wat is het verschil tussen architectuur en informatiebeleid?

Informatiebeleid beschrijft wat de organisatie met informatie wil bereiken. Architectuur vertaalt dat naar principes, kaders en een samenhangend beeld van processen, informatie en systemen, zodat keuzes in projecten consistent worden.

Bronnen

• Boh, W. F., & Yellin, D. (2007). Using enterprise architecture standards in managing information technology. Journal of Management Information Systems, 23(3), 163–207.
• Kotter, J. P. (1995). Leading change: Why transformation efforts fail. Harvard Business Review, 73(2), 59–67.
• Lange, M., Mendling, J., & Recker, J. (2016). An empirical analysis of the factors and measures of Enterprise Architecture Management success. European Journal of Information Systems, 25(5), 411–431.
• Ross, J. W., Weill, P., & Robertson, D. C. (2006). Enterprise architecture as strategy: Creating a foundation for business execution. Harvard Business School Press.
• Tamm, T., Seddon, P. B., Shanks, G., & Reynolds, P. (2011). How does enterprise architecture add value to organisations? Communications of the Association for Information Systems, 28, artikel 10.
• Van den Berg, M., & Van Steenbergen, M. (2006). Building an enterprise architecture practice. Springer.
• Weiner, B. J. (2009). A theory of organizational readiness for change. Implementation Science, 4, 67.