Wat zijn de kritieke succesfactoren voor het implementeren van een referentiearchitectuur waarmee wordt bijgedragen aan het succesvol werken onder architectuur?

In het kader van een onderzoek naar de implementatie van de Hoger Onderwijs Referentie Architectuur (HORA) is een Delphi-onderzoek uitgevoerd waaraan een aantal experts uit het architectuurvakgebied hebben 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.

 Bij het beantwoorden van de vraag door de verschillende experts is onderscheid gemaakt tussen enerzijds aspecten waaraan een referentiearchitectuur inhoudelijk zou moeten voldoen en anderzijds hoe deze referentiearchitectuur vervolgens binnen een organisatie toegepast zou moeten worden. Bij deze toepassing is vervolgens een tweede onderscheid gemaakt tussen het implementeren van de referentiearchitectuur en het als een gevolg daarvan werken onder architectuur binnen een organisatie.

 Het opstellen van een referentiearchitectuur

 Referentiearchitecturen zijn hulpmiddelen voor het opstellen van specifieke architecturen (architectuur zelf is echter ook een hulpmiddel). Als ze de architect helpen snellere en betere resultaten te behalen dan zijn ze niet alleen belangrijk voor die architect maar ook voor de organisatie. Het toepassen van referentiearchitecturen leidt tot standaardisatie en levert de bijbehorende voordelen op, bijvoorbeeld dat de architect eenvoudig(er) vervangen kan worden door een nieuwe collega als die bekend is met de toegepaste referentiearchitectuur. Referentiearchitecturen geven echter geen (volledig) antwoord op de vraag of en waar ze moeten worden toegepast. Het is nog maar de vraag of ze volgens het ‘just in time, just enough’ principe gebruikt kunnen worden waarbij steeds alleen het architectuurwerk wordt opgesteld wat nodig is. Het maken van een referentiemodel alleen al is daar strijdig mee. De meningen zijn hierover verdeeld. Zo wordt gesteld dat het juist tijd scheelt als je het niet allemaal zelf hoeft te verzinnen maar uit een referentiearchitectuur kunt halen en deze ervoor zorgt dat het opstellen van een specifieke architectuur daardoor juist snel (just in time) kan. Daartegenover wordt echter weer gesteld dat het opstellen van een specifieke architectuur alleen 'werkt' als de referentiearchitectuur door de organisatie geaccepteerd is. Hierbij wordt gerefereerd aan de talloze architecturen en Project Start Architecturen met bijvoorbeeld de tekst 'conform de Gemeentelijke Model Architectuur (GEMMA)' waarvan de principes voor de business en dus ook voor de opdrachtgevers en projectleiders volkomen betekenisloos waren en dus ook niet gevolgd worden. Efficiënt maar dus niet effectief! Te vaak wordt vergeten, dat het tot stand komen van een referentie architectuur talloze compromissen tijdens het proces vereist. Dat maakt het resultaat tot een soort grote gemene deler, waar (om wat voor reden dan ook!) niet-middelmatige organisaties zichzelf en hun specifieke problematiek niet in herkennen. De referentie architectuur wordt dan een soort bench mark en die is zelden inhoudelijk interessant voor de voorlopers. Sterker nog: voor hen kan de referentie architectuur vertragend gaan werken op de eigen ontwikkelingen.

 Een goede referentiearchitectuur biedt een zekere gelaagdheid ofwel gaat uit van het gebruik van een goed gedefinieerd metamodel waarbij de referentiearchitectuur een herkenbare, algemeen gebruikte opzet/structuur moet hebben (denk aan herkenbare architectuurlagen; geen 23-laags architectuur bijvoorbeeld). Het is niet specifiek noodzakelijk om deze gelaagdheid overeen te laten komen met wat standaardframeworks (als TOGAF, Archimate, etc.) voorschrijven maar aangezien referentiearchitecturen vaak worden toepassen in combinatie met andere standaarden biedt dit wel voordelen. Een goede structuur biedt organisaties onder andere de mogelijkheid om onderscheid te maken tussen generieke zaken (waar men de referentiearchitectuur wil volgen) en organisatie specifieke zaken (waar men bewust wil afwijken van de referentiearchitectuur of waar de referentiearchitectuur bewust ruimte laat). Naast de structuur moet de referentiearchitectuur het juiste detailniveau hebben: niet teveel (want dan is er onvoldoende gemeenschappelijkheid) maar ook niet te weinig (alleen een setje algemeen geldige architectuurprincipes voegt weinig waarde toe). Hierbij dient opgemerkt te worden dat detail niet per definitie slecht hoeft te zijn. Als het gedetailleerd kan betekent het dat er ook op een detailniveau gemeenschappelijkheid is. Zo kunnen ook procesdefinities deel uitmaken van een referentiearchitectuur.

 De referentiearchitectuur moet een logische aansluiting tussen de lagen c.q. de concepten in het metamodel borgen. De meest toegevoegde waarde van architectuur zit in de business architectuurlaag (bedrijfsfuncties, processen, business objecten, rollen, stakeholders, etc.) aangezien in deze laag de keuzes met de meeste impact worden gemaakt. De gewenste situatie van het applicatielandschap kan binnen een referentiearchitectuur moeilijk omschreven worden zonder in te gaan op de specifieke huidige situatie in de eigen organisatie en blijft daardoor vaak noodgedwongen vaag (wel kunnen referentiearchitecturen naast het “wat” ingaan op het “hoe”, bijvoorbeeld met patterns ten aanzien van business intelligence of security). Wanneer de referentiearchitectuur echter een specifiek, gezamenlijk probleem in de informatievoorziening oplost, bijvoorbeeld samenwerking in de keten of digitalisering van de dienstverlening draagt deze wel bij aan inzicht in de gewenste situatie op de applicatie en technologie lagen. Dit kan zich vervolgens vertalen in adoptie van de architectuur door software leveranciers. Daar tegenover wordt gesteld dat een referentie-applicatie-architectuur ook los van het bestaan van een gemeenschappelijk probleem beschreven kan worden en waarde kan hebben. Het is in dat geval vooral een spiegel die een organisatie zichzelf voor kan houden.

 Een referentiearchitectuur is idealiter open, kosteloos beschikbaar en leveranciersonafhankelijk (geen afhankelijkheid van een specifieke commerciële aanpak, toolimplementatie, etc.) 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 standaard-notatie. Een referentiearchitectuur die qua modelleerstijl en principes goed aansluit bij de organisatie (cultuur), wordt sneller omarmd dan een die daar juist mee in strijd is. Denk bijvoorbeeld aan een referentiearchitectuur met specifieke principes die goed passen in een hiërarchische organisatie (bijvoorbeeld over escalaties bij afwijkingen van de doelarchitectuur); die zal minder snel geaccepteerd worden in een organisatie die juist bottom-up gericht is op samenwerking en consensus. Daartegenover wordt echter gesteld dat een referentiearchitectuur (meestal) organisatieonafhankelijk is en dus niet kan aansluiten bij een organisatie(cultuur). Wanneer er een referentiearchitectuur wordt opgesteld voor het hoger onderwijs kan de vraag gesteld worden hoe deze dan dient in te spelen op cultuurverschillen tussen verschillende onderwijsorganisaties? Er wordt dan ook geopperd of een referentiearchitectuur niet beter cultuuragnostisch zou moeten zijn? Voor beide type organisaties (top-down en bottom-up) geldt immers dat de in het voorbeeld genoemde principes, mits op de juiste wijze ingezet, heel goed bruikbaar zijn waarbij wel gesteld wordt dat een organisatie beter een kleine set van principes kan formuleren dan een grote verzameling gedetailleerde regels. Als weerwoord wordt hiertegenover gesteld dat hogescholen dan wel verschillende culturen hebben, maar ook heel vergelijkbare uitdagingen en issues. Cultuur stop je dan misschien wel niet in de referentiearchitectuur, maar de uitdagingen en issues juist wel, in de vorm van best practices bijvoorbeeld. In die zin kan een referentiearchitectuur niet cultuur agnostisch zijn: er zitten altijd aannames in over visie, doelen en aanpakken van de organisatie. Het probleem is dat die nooit expliciet gemaakt worden, wat weer tot problemen qua acceptatie door de organisatie leidt.

 Een referentiearchitectuur biedt principes/modellen/patronen voor een bepaald domein (zoals het hoger onderwijs). Dat werkt alleen als er in dat domein ook daadwerkelijk sprake is van overeenkomstigheid zodat die principes/modellen/patronen breed toepasbaar zijn. Bij het opstellen van de Provinciale Referentie Architectuur (PETRA) bijvoorbeeld is er bij alle provincies bekeken wat er al aanwezig was, van twee provincies een volledige architectuur, van de overige provincies wat er lag aan informatieplanning etc. Dit heeft geholpen om de gezamenlijkheid goed in beeld te krijgen en was tevens startpunt voor de eerste versie van de PETRA. Door de referentiearchitectuur vervolgens in een semantische wiki te gieten en aan te bieden was het voor de individuele provincies eenvoudiger om te zoeken en te matchen met hun eigen organisatie specifieke architectuur. Het is dan ook aan te raden om de referentiearchitectuur als model beschikbaar te stellen in diverse software-tools (in elk geval in de tools die gebruikt worden in de beschreven sector). Bij deze aanpak wordt echter wel een kanttekening geplaatst. Gesteld wordt dat door eerst te kijken wat er al is, er nooit een referentiearchitectuur wordt opgeleverd maar wel een grabbelton met assets. Het vertrekpunt zou altijd vanuit de business-vraag moeten zijn: wat doen we eigenlijk en wat zouden we moeten doen? Het opstellen van een referentiearchitectuur dient te geschieden vanuit de gedachte dat er altijd een bijdrage aan de doelstelling van de organisatie geleverd moet worden. Van de andere kant wordt daar tegen in gebracht dat onderkend wordt dat de beschreven aanpak niet volgens de regelen der kunst is maar dat dit alles te maken had met het creëren van draagvlak binnen de verschillende provincies. Eerst de gezamenlijkheid opzoeken en daarna expanderen.

 Een daaruit volgend belangrijk aspect bij het opstellen van een referentiearchitectuur is dat deze 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 om input te leveren, uit het reviewen van het materiaal en uit het formeel goedkeuren van het materiaal. Aangezien elk ‘stakeholder viewpoint’ (uit IEEE 1471/ IEC/ISO 42010) voor elke ‘concern’ van de ‘stakeholder’ een referentiearchitectuur op zich waard is maar niet ieder viewpoint van iedere stakeholder evenveel waarde toevoegt, dient er wel gewaakt te worden voor een overkill aan detail. Omdat referentiearchitecturen generiek van aard zijn is het bovendien erg lastig om specifieke viewpoints, met specifieke concerns voor specifieke stakeholders op te stellen en zullen ze vooral generieke viewpoints bevatten. 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. Het wordt dan aangeraden om bij het opstellen van de referentiearchitectuur gebruik te maken van best practices en bekende problemen/onvolkomenheden te benoemen en aan te geven hoe hiermee om te gaan.

 Ten slotte heeft de referentiearchitectuur bij voorkeur duidelijke doelstellingen (interoperabiliteit, kennisdeling, kostenbesparing, gezamenlijke visievorming, gemeenschappelijke taal, etc.). 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. Rond de referentiearchitectuur moet een goede governancestructuur met alle stakeholders zijn afgesproken, zowel om inhoudelijke kwaliteit als om draagvlak te borgen. Door hierbij niemand uit te sluiten, ook niet “tegenstanders” (juist niet) kan met hen worden nagegaan welke beelden worden gedeeld qua doelen (de uitkomst, het WAT is essentieel), voordat er discussies worden gevoerd over het HOE (die doelen te bereiken).

 Het implementeren van een referentiearchitectuur

 De referentiearchitectuur kan een belangrijke bijdrage leveren aan het bewaken van de kwaliteit van handelen van organisaties. Het is daarom belangrijk dat de enterprise-architectuurfunctie goed wordt ingericht. Dit betekent dat er rollen en verantwoordelijkheden moeten worden gedefinieerd, processen moeten worden ingericht en dat architectuurkennis expliciet wordt beheerd. Hiertoe dienen architecten (of medewerkers met die rol) geworven en/of opgeleid, getraind en gecoacht te worden. De architect maakt het verschil en niet de referentiearchitectuur.

 Het kan individuele organisaties ontbreken aan kennis, kunde en ervaring om vanuit de referentiearchitectuur de vertaalslag te maken naar de eigen situatie. De oplossing hiervoor is ervoor te zorgen dat architectuurcompetenties (niet per definitie in de vorm van een architect) deelnemen in verandertrajecten/projecten. De vertaling van de referentiearchitectuur naar de eigen organisatie dient dan ook door een multifunctioneel team (niet alleen architecten) uitgevoerd te worden. IT is een afgeleide en dient als zodanig te worden behandeld (met uitzondering van organisaties die juist IT tot de kern van hun strategie en bedrijfsvoering maken, zoals de Googles en Facebooks van deze wereld). De architectuur-competenties zijn daarom in eerste instantie vooral business architectuurcompetenties. Het is lastig als deze genoemde competenties/architecten in de IT-afdeling zijn opgehangen; dan worden ze net als de "harde" IT-ers beschouwd als onderdeel van de supply organisatie. Benaderd vanuit de huidige tijd van technologische innovaties wordt echter gesteld dat IT juist niet meer als afgeleide gezien moet worden, maar business en IT hand in hand gaan en elkaar voortdurend beïnvloeden en voeden. Het organisatieonderdeel (IV-organisatie of business) waarbinnen de architectuur-competenties zijn opgehangen wordt dan ook als van minder belang gezien mits de architectuurfunctie maar toegevoegde waarde heeft en aangehaakt is op de verander- en projectmanagementprocessen.

 Architectuur moet een duidelijk doel dienen, anders gaat de organisatie architectuur als doel op zich beschouwen zonder helder voor ogen te hebben wat zij ermee wil bereiken. Bij voorkeur heeft de referentie-architectuur al een duidelijk doel, maar anders dienen in ieder geval de specifieke architecturen die erop zijn gebaseerd een duidelijk doel te hebben Het succes (effect) van de architectuur en de architect is afhankelijk van de waarde die de resultaten toevoegen aan de bedrijfsvoering. Zijn de plaatjes mooi, maar komt de boodschap niet aan dan is het effect nul. 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 aan alle betrokkenen te communiceren. Betere referentiearchitecturen maken duidelijk waarom bepaalde principes of modellen zijn opgenomen, bijvoorbeeld ten behoeve van het bijdragen aan kostenbesparing of het faciliteren van samenwerking met andere organisaties. De architectuurkeuzes zijn zodoende gekoppeld aan de ambities van de eigen organisatie. Een referentiearchitectuur moet problemen adresseren die door mensen echt ervaren worden, zodat toepassen van de referentiearchitectuur als waardevol ervaren wordt.

 Aangezien vrijwel ieder domein dwarsverbanden heeft met andere domeinen, die weer hun eigen referentiearchitecturen hebben, is het belangrijk dat de referentiearchitectuur kan aansluiten bij referentiearchitecturen van aanpalende sectoren, om interoperabiliteit te bevorderen. Daarom is het 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). Wanneer de onderliggende drijfveren kloppen en voor iedereen in de doelgroep en aan de zijlijn aanvaardbaar zijn, pas dan heb je kans op echte interoperabiliteit. Bij de implementatie van de PETRA is er bijvoorbeeld sterk rekening mee gehouden dat principes vanuit de PETRA aangevuld moesten worden (en ook afgestemd) met principes, die niet door de PETRA geraakt werden (organisatiestructuur, over financiën, cultuur, kennis et cetera). De PETRA, en in tweede instantie dus ook de Nederlandse Overheid Referentie Architectuur (NORA), was in die zin een handvat om te komen tot integrale samenhang tussen provincies. Gezamenlijk doen wat kan, daarnaast vanuit de (aanvullende) eigen enterprise architectuur de eigenheid en bestuurlijke keuzes garanderen. Juist door de eigenheid van provincies en het belang van de eigen cultuur en bestuur was het belangrijk dat PETRA als referentie gebruikt kon worden om eigen keuzes te maken. Het was daardoor richtinggevend, meer dan wanneer het als “de enige architectuur” zou zijn geponeerd. Een andere belangrijke succesfactor was het proces rondom het werken in ketens in het kader van de e-Overheid. De hiervoor noodzakelijke interoperabiliteit maakte het hebben van een gezamenlijke referentiearchitectuur (op een minder hoog-over niveau dan de NORA) noodzakelijk.

 Het werken onder architectuur

 In de praktijk blijkt dat er drie volwassenheidsaspecten zijn die het succes van architectuur mede bepalen, de volwassenheid van de organisatie om met architectuur om te (kunnen) gaan, de volwassenheid van de architectuur en de volwassenheid van de communicatie tussen architect en organisatie (alle drie zijn onderdeel van gangbare architectuur capability maturity modellen). Enterprise-architectuur kan alleen een sturende rol vervullen als die geformaliseerd is in de enterprise governance. Dit betekent dat rollen, taken en verantwoordelijkheden (governancestructuur) van een ieder helder dienen te zijn, alsook dat de algemene besturingsfilosofie (governanceprincipes) helder is. In de praktijk blijkt echter dat de invulling van de governancestructuur vaak slechts beperkt is gedefinieerd of geïmplementeerd. In plaats van dat deze (hard) wordt uitgewerkt in een RACI (wie is Responsible, Accountable, Consulting en Informed) wordt dit meer dynamisch opgepakt naar gelang behoefte. Dit hoeft op zich geen probleem op te leveren maar 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.

 Architectuur is vooral belangrijk bij wijzigingen, maar het bedrijfsresultaat wordt verdiend in een stabiele situatie binnen de operatie (business as usual). De kanttekening die hierbij geplaatst kan worden is of dit in de huidige tijd nog wel opgaat en er binnen de instabiele wereld juist sprake is van een continue behoefte / noodzaak tot verandering. Los van of werken onder architectuur dus als een strategische (en herstel) functie of als een operationele functie gezien moet worden, is het succes van werken onder architectuur afhankelijk van de uitkomsten, of die aan de verwachtingen voldoen en of dat zo ook ervaren wordt door senior management, directie en of opdrachtgever. Wanneer dit niet het geval is, wordt werken onder architectuur (terecht) als kostenpost ervaren. Het succes van werken onder architectuur wordt bijna volledig bepaald door de wijze waarop strategievorming en sturing in de eigen organisatie plaatsvindt. Een professionele bureaucratie als het hoger onderwijs wordt niet top-down aangestuurd. Het is hooguit de – in de termen van Mintzberg – fulltime administrateur, die initiatieven tot strategische veranderingen in de informatievoorziening neemt, vooral op het domein van de bedrijfsvoering. Voor het overige zijn het initiatieven vanuit (de beroepsgroep van) de professionals voor hun eigen professionele domein, niet voor de organisatie als geheel. Dit verklaart waarom de toegevoegde waarde van een referentie architectuur en/of het werken onder architectuur door de organisatie alleen herkend wordt en bijdraagt wanneer deze een specifiek, gezamenlijk probleem oplost. Een enterprise architectuur voor een hoger onderwijsinstelling dient zich (in eerste instantie) dan ook vooral te focussen op aspecten die als organisatie breed gezien worden waarbij afstemming met het college van bestuur essentieel is.

 Een bijkomend probleem is echter, dat organisaties voor hoger onderwijs - in de termen van Ross - nog steeds in business silo’s werken en helemaal niet gewend zijn om als organisatie als geheel te sturen op strategische veranderingen. Dit bemoeilijkt het implementeren van werken onder architectuur als zodanig aanzienlijk. Een referentie architectuur kan daar weinig aan veranderen en is op zichzelf niet voldoende om werken onder architectuur geïmplementeerd te krijgen. Zorg er daarom voor dat architecten in een vroegtijdig stadium betrokken zijn bij veranderinitiatieven om daarbij te adviseren over architectuur gerelateerde vraagstukken en leg bij het op orde brengen van de proces-, gegevens-, applicatie- en infrastructuurhuishouding de nadruk op het komen tot een integrale informatievoorziening (vanuit het principe: de juiste informatie op het juiste moment op de juiste plaats) maar stem het implementatieproces wel af op de werkwijze van de organisatie (bijvoorbeeld geen detailblauwdrukken in een agile werkende organisatie).

 Om tot een succesvolle wijze van werken onder architectuur te komen moet het doel van architectuur voor de organisatie helder zijn, de architectuur verbonden met beleidsvorming en projectvoering zijn en moeten betrokken medewerkers (vastgelegd in het communicatieplan) worden opgeleid in het opstellen en toepassen van architectuur (integrale aanpak). Vervolgens stapje voor stapje architectuur gaan opstellen en de referentiearchitectuur daarbij als naslagwerk hanteren. Aangeraden wordt om dit projectmatig en met behulp van het timeboxprincipe te doen. Hierbij wordt een periode vastgesteld waarbinnen bepaalde resultaten worden opgeleverd waarbij de mate van detail en uitgebreidheid ondergeschikt aan inzet en doorlooptijd. Wel moet voor de timebox voldoende tijd worden genomen. Het is belangrijker dat deelnemende organisaties aangehaakt blijven dan dat de referentiearchitectuur er doorheen wordt gejaagd.

 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.

Weergaven: 696

Reactie van Ad Gerrits op 16 Mei 2015 op 12.36

Goed artikel! Zowel qua inhoud als qua leesbaarheid met veel nuttige aanbevelingen.

De stelling "Een bijkomend probleem is echter, dat organisaties voor hoger onderwijs - in de termen van Ross - nog steeds in business silo’s werken en helemaal niet gewend zijn om als organisatie als geheel te sturen op strategische veranderingen. Dit bemoeilijkt het implementeren van werken onder architectuur als zodanig aanzienlijk." is voer voor verder nadenken over wat voor soort "architectuur" daar bij past. Of je bijv. i.p.v. "integrale informatievoorziening" niet veel meer toe moet naar organisatieonderdelen die autonoom hun zaken op orde brengen met voldoende aandacht voor interoperabiliteit. 

Reactie van Joost Peetoom op 19 Oktober 2015 op 14.02

Berry,

welk punt wil je nu maken in relatie tot de HORA? Als enterprise architect sinds 1 jaar werkzaam binnen de Universiteit Utrecht  merk ik in elk geval, dat de aanwezigheid van de HORA behoorlijk helpt bij het opzetten van de architectuurfunctie binnen de UU en ook een hoop not-invented-here discussies juist weet de kop in te drukken. Daarnaast trof ik, bij de instap in de hoger-onderiwjssector, een aardig levende community rondom het HO architectuurberaad aan, die elkaar ook bij allerlei hoe-doe-jij-dat-nou vragen helpt. E dat is in aldere sectoren wel anders. 

Reactie van Berry Pieters op 19 Oktober 2015 op 17.50

Hoi Joost,

Het resultaat van het Delphi-onderzoek is samen met het resultaat van een literatuuronderzoek (tbv methodetriangulatie) gebruikt om tot een onderzoeksoptiek te komen die als meetinstrument is gehanteerd bij de interviews bij een zestal hogeschool waarmee de waarde of kwaliteit van de onderzochte huidige aanpak van het implementeren van de Hoger Onderwijs Referentie Architectuur ten behoeve van het succesvol werken onder architectuur bij deze verschillende Hogescholen in het licht van de gestelde kritieke succesfactoren is onderzocht. Op basis van een vergelijking van de analyseresultaten bij verschillende Hogescholen zijn aanbevelingen betreffende de implementatie van de Hoger Onderwijs Referentie Architectuur opgesteld ten behoeve van het succesvol werken onder architectuur. 

Reactie van Joost Peetoom op 20 Oktober 2015 op 8.18

To the point: welke lessen kan ik dan, als digitaal architect werkzaam bij een hoger onderwijs, trekken uit de ervaringen uit juist die 6 hogescholen? Is op basis van jullie onderzoek de HORA juist succesvol te noemen of niet? 

Reactie van Berry Pieters op 25 Oktober 2015 op 8.35

Hoi Joost,

De aanbevelingen zijn, naar aanleiding van de daar ondervonden problemen betreffende de implementatie van de HORA tbv het succesvol werken onder architectuur, geschreven voor de Haagse Hogeschool als opdrachtgever voor het onderzoek. Bij de interviews met de hogescholen bleek dat deze problemen algemeen van aard zijn. Het resultaat zou zodoende wellicht binnen het architectuurberaad besproken kunnen worden. Indien behoefte kan ik kan je ook de samenvatting van het onderzoeksrapport mailen.

Reactie van Joost Peetoom op 26 Oktober 2015 op 8.48

Berry, 

het lijkt me nuttig om dat in het HO Architectuurberaad te bespreken, maar vooral ook door dat vanuit de hogescholen zelf ook te laten aandragen. Ik zal 19/11 bij het HO arch beraad in de rondvraga er wel even naar vragen of ze dat willen.. Ik zag dat je over dit verhaal ook op het LAC een presentatie gaat geven; veel plezier daarmee!

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Sponsoren

Sessies

24 oktober: GIA/KNVI sessie theorie ontmoet praktijk meer...

Advertenties

Je kunt hier ook zelf adverteren

© 2017   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden