Bundeling van architectuurkennis in de vorm referentiearchitecturen is een duidelijke trend. Een referentiearchitectuur is een soort sjabloon voor een specifieke architectuur. De vraag is wat succesfactoren zijn bij de ontwikkeling en implementatie van referentie-architecturen. In het kader van een onderzoek naar de implementatie van de Hoger Onderwijs Referentie Architectuur (HORA) binnen hogescholen is een Delphi-onderzoek uitgevoerd met deze vraagstelling (zie ook kader). In dit artikel zijn de belangrijkste inzichten uit het onderzoek samengevat. Deze hebben zowel betrekking op de ontwikkeling als de implementatie van de referentie-architectuur.
Succesfactoren voor ontwikkeling
Bijdragen aan doelstellingen
Architectuur is geen doel op zich maar moet bijdragen aan de doelstellingen van de organisatie. Referentie-architecturen geven echter geen (volledig) antwoord op de vraag of en waar ze moeten worden toegepast. Het is niet evident dat ze ‘just in time, just enough’ architectuur borgen. Ze zouden wel altijd vanuit de business-vraag moeten vertrekken. Bij voorkeur adresseert de referentiearchitectuur een gemeenschappelijk probleem. Vooraf tijd investeren in het begrijpen van elkaars werelden, zodat onderling begrip en respect ontstaat, maakt het gemakkelijker om het eens te worden over doelstellingen en inhoud van de referentiearchitectuur. Eerst de gezamenlijkheid opzoeken en daarna expanderen. Het gevaar is dat compromissen tijdens de totstandkoming ervoor zorgen dat er een soort grote gemene deler ontstaat, waar organisaties zichzelf en hun specifieke problematiek niet in herkennen. Aan de andere kant moet ook voorkomen worden dat een referentie-architectuur onvoldoende rekening houdt met cultuurverschillen in organisaties zoals bijvoorbeeld de wijze waarop besluitvorming plaatsvindt (top down of bottom up).
Gezamenlijk opgesteld
Een referentiearchitectuur moet zijn opgesteld door of in nauwe samenwerking met de inhoudelijk betrokkenen in de sector zelf. Het betrekken van de verschillende stakeholders is wellicht zelfs een van de meest cruciale aspecten. Deze betrokkenheid van alle deelnemende organisaties kunnen bestaan uit actieve deelnames in workshops, uit het reviewen van het materiaal en uit het formeel goedkeuren van het materiaal. Er moet voldoende tijd worden genomen voor het opstellen van de referentie-architectuur; om ervoor te zorgen dat deelnemende organisaties aangehaakt blijven. Indien deelnemende organisaties deel uitmaken van een belangenorganisatie is het verstandig om ook die organisatie een rol te geven in het opstellen van een referentiearchitectuur. Zo’n belangenorganisatie is het natuurlijke landingspunt van een referentiearchitectuur en bovendien is daar veel kennis aanwezig over wat wel en wat niet werkt in de samenwerking tussen organisaties.
Goede structuur en juiste detailniveau
Een goede referentiearchitectuur biedt een herkenbare, algemeen gebruikte opzet/structuur. Dit is in eerste instantie vooral een goed gedefinieerd meta-model. Daarnaast moet een goede structuur ook helder maken waar keuzevrijheid voor organisaties zit. Ook het juiste detailniveau is belangrijk: niet teveel (want dan is er onvoldoende gemeenschappelijkheid) maar ook niet te weinig (alleen een setje algemeen geldige architectuurprincipes voegt weinig waarde toe). Detail is niet per definitie slecht; als het gedetailleerd kan betekent het dat er ook op een detailniveau gemeenschappelijkheid is. Informatie die alleen voor specifieke doelgroepen interessant is, zou moeten worden voorkomen, omdat het andere lezers afleidt. Omdat referentiearchitecturen generiek van aard zijn, is het bovendien erg lastig om gezichtspunten te definiëren die specifieke communicatiedoelstellingen ondersteunen.
Toegangelijk
Een referentiearchitectuur is idealiter open, kosteloos beschikbaar en leveranciersonafhankelijk (geen afhankelijkheid van een specifieke commerciële aanpak, toolimplementatie, et cetera) en zodanig gepubliceerd dat deze gemakkelijk te vinden, te lezen en te begrijpen is om geen barrières voor het gebruik op te werpen. Van belang zijn daarbij vooral een goede inleiding en toelichting per onderwerp, gericht op hoe en waarom toe te passen. Zonder dat kan een referentiearchitectuur lastiger toegepast worden, worden fouten gemaakt en/of wordt de referentiearchitectuur teleurgesteld terzijde geschoven als ‘te moeilijk’. De referentiearchitectuur moet dan ook begrijpelijk zijn voor de doelgroep, beschreven in termen van algemene, breed gebruikte architectuurconcepten en opgesteld in een standaardnotatie.
Aansluiten bij andere referentie-architecturen
Aangezien vrijwel ieder domein dwarsverbanden heeft met andere domeinen, die weer hun eigen referentiearchitecturen hebben, is het belangrijk dat referentiearchitecturen van aanpalende sectoren onderling aansluiten. Dit bevordert ook de interoperabiliteit. Zo is de Gemma (voor gemeenten) een verdieping van de Nora (voor de overheid als geheel) en is bij het opstellen van de Gemma-principes expliciet gekeken naar de impact van de Nora-principes op gemeenten. De relatie tussen de Gemma-principes en de Nora-principes waarvan ze zijn afgeleid is ook expliciet opgenomen in Gemma. Het is ook belangrijk om onderscheid te maken tussen wat van de referentiearchitectuur voor de eigen organisatie aangepast kan worden (bijvoorbeeld om de eigen specifieke ambities te ondersteunen) en wat niet (bijvoorbeeld om samenwerking met andere organisaties mogelijk te maken).
Successfactoren voor implementatie
Governance ingericht
Om een referentie-architectuur te laten werken bij organisaties zullen deze een architectuurfunctie moeten inrichten. Dit betekent vooral dat architectuur is geformaliseerd in de governance. Rollen, taken en verantwoordelijkheden (governancestructuur) van een ieder dienen helder te zijn. Wanneer architecten (of medewerkers met die rol) bij individuele organisaties geen klankbord hebben, kunnen zij geïsoleerd raken met als gevolg dat stakeholders vervolgens het nut van architectuur (en daarmee de referentiearchitectuur als hulpmiddel van de architect) niet inzien en over zullen gaan tot de orde van de dag. Het succes wordt ook sterk bepaald door de wijze waarop strategievorming en sturing in de eigen organisatie plaatsvindt. Als centrale sturing nauwelijks is ingericht zal het ook lastig zijn om van enterprise-architectuur een succes te maken. Daarnaast moeten architecten zelf ook de juiste competenties hebben. De architect maakt het verschil en niet de referentiearchitectuur. Het is wel lastiger als architectuur in de it-afdeling is opgehangen; dan wordt het mogelijk beschouwd als onderdeel van de supply organisatie.
Onderdeel van de veranderprocessen
Een organisatie dient een aansprekende visie te hebben over datgene waar de implementatie van de referentiearchitectuur toe zal leiden (‘het bevlogen verhaal’) en dient deze breed te communiceren. Door een referentie-architectuur binnen een organisatie door een multifunctioneel team te vertalen naar een organisatie-specifieke architectuur ontstaat draagvlak. Belangrijk is dat de referentie-architectuur (of de organisatie-specifieke architectuur die ervan is afgeleid) aangehaakt is op de verander- en projectmanagementprocessen en expliciet wordt ingebracht in projecten. Architecten moeten in een vroegtijdig stadium betrokken zijn bij veranderinitiatieven om daarbij te adviseren over architectuurgerelateerde vraagstukken. Het succes van werken onder architectuur is verder afhankelijk van of de uitkomsten van architectuur voldoen aan de verwachtingen en of dat zo ook ervaren wordt door senior management. Wanneer dit niet het geval is, wordt werken onder architectuur (terecht) als kostenpost ervaren.
Community
Ten behoeve van de continuïteit is het raadzaam dat er een architectencommunity voor het collectief wordt gecreëerd waarbij ervaringen en best practices met het toepassen van de referentiearchitectuur worden gedeeld. De referentiearchitectuur kan zodoende aangevuld worden met toepassingsrichtlijnen en praktijkvoorbeelden die laten zien hoe een organisatie deze zelf kan gebruiken. Het inrichten van een architectuurreviewproces waarbinnen een goed onderhoudsproces gedefinieerd is, zorgt er ten slotte voor dat de referentiearchitectuur toekomstbestendig is. Een architectuur, en met name een referentiearchitectuur, is namelijk nooit af.
Samenvatting
In dit artikel zijn een aantal kritieke succesfactoren voor het ontwikkelen en implementeren van referentiearchitecturen benoemd. We hopen dat dit artikel daarmee bijdraagt aan meer effectieve referentie-architecturen en daarmee aan meer succesvol werken onder architectuur. Duidelijk is dat ontwikkeling van referentie-architecturen zonder expliciete aandacht voor implementatie in de sector weinig kans van slagen heeft. De effectiviteit van de architectuurfunctie van individuele organisaties is daarbij ook een belangrijke factor.
Deze bijdrage is geschreven in samenwerking met Berry Pieters, docent en onderzoeker op de Haagse Hogeschool.
Delphi-onderzoek
In het Delphi-onderzoek hebben een aantal experts uit het architectuurvakgebied deelgenomen. Martin van den Berg, Eric Brouwer, Marijn Driel, Bas van Gils, Danny Greefhorst, Marc Lankhorst, Arianne de Man, Erwin Oord, Ria van Rijn en Marlies van Steenbergen bogen zich allen individueel over de vraag: Wat zijn de kritieke succesfactoren voor het implementeren van een referentiearchitectuur waarmee wordt bijgedragen aan het succesvol werken onder architectuur? Hun bijdragen zijn verwerkt in een samenvatting waarna een ieder is verzocht hierop te reageren door aan te geven of zij zich in de tekst konden vinden of dat er passages waren die zij ter discussie wilden stellen door er commentaar en/of aantekeningen bij te plaatsen. De reacties zijn vervolgens weer verwerkt in de samenvatting. Na dit proces drie keer doorlopen te hebben is in gezamenlijk overleg besloten om het tot stand gekomen resultaat met andere vakgenoten te delen.
Ik zou er nog één aspect aan toe willen voegen: wanneer je eenmaal een referentiearchitectuur hebt, borg ook dat er regelmatig getoetst wordt of er nog aan voldaan wordt.
Met name bij langlopende projecten, of projecten met een langdurig onderhoudstraject komt het voor dat er initieel heel erg volgens deze referentiearchitectuur ontworpen wordt, maar op het moment dat de “dragers” van deze architectuur uit het project verdwijnen verslapt de aandacht en ontstaan er steeds meer afwijkingen, waardoor onderhoud op termijn onnodig complex kan worden.
Een referentiearchitectuur is niet alleen iets voor aan het begin van je project, maar voor de hele levenscyclus van je product.
Voordat je begint met het opstellen van een referentie architectuur moet je eerst de vraag stellen over de gebruiksduur ervan, heb ondertussen teveel M.C. Escher referenties gezien die probeerden de werkelijkheid te abstraheren omdat opstellers in een kantoor zaten waar de ramen met kranten dichtgeplakt waren. Alle organisaties die zeggen onder architectuur te werken hebben gemiddeld genomen dan ook het hoogste percentage ‘shadow IT’ door de wegwerp architectuur van SCRUM.
Referentie architecturen zijn nuttig en noodzakelijk. Het moet alleen geen doel op zich worden. Een referentie architectuur is generiek en open genoeg om zelf specifieker te maken. Ook zou de referentie architectuur een bijdrage moeten leveren in de communicatie over alle lagen van de organisatie en daar ontbreekt het nog wel eens aan.
Verder zou de referentie architectuur veel meer ingericht meoetn worden op agile development, dus flexibel en wendbaar, zonder de noodzakelijk structuur te verliezen.