Dit is HORA 2.0, de nieuwe release van HORA per 1 november 2018. In deze versie zijn onder meer nieuwe architectuurconcepten opgenomen (zoals de applicatiefunctie) en zijn meer details opgenomen. De legacy-versie HORA 1.0 vindt u op hora1.surf.nl

Het gebruik van HORA


Dit hoofdstuk geeft inzicht in hoe de Hoger Onderwijs Referentie Architectuur (HORA) gebruikt kan worden voor vraagstukken bij hoger onderwijsinstellingen. Het start met een algemene beschrijving van de toepassingsmogelijkheden, waarna op een aantal specifieke toepassingen verder wordt ingegaan.

De toepassing van HORA in het algemeen

De HORA is een referentie-architectuur; een generieke architectuur die nog op maat gemaakt kan worden voor een specifieke situatie. Ze is het best te vergelijken met een sjabloon; deze moet ook nog ingevuld worden voordat deze gebruikt kan worden. Dat betekent dat het primair bedoeld is als basis voor het opstellen van een instellingsspecifieke architectuur. Ze is echter zo rijk (grotendeels gevuld sjabloon) dat het ook direct toegepast kan worden bij een instelling, zonder haar op maat te maken. Er zijn zelfs een aantal belangrijke voordelen in het niet aanpassen van de referentie-architectuur; ze is direct herkenbaar voor mensen buiten de instelling en het wordt ook zelfstandig onderhouden. Nadelen zijn dat ze niet is afgestemd op het instellingsplan en ook niet gerelateerd is aan de huidige situatie, waardoor het gat tussen huidige en gewenste situatie niet is in te schatten.

De algemene toepassingsmogelijkheden van de HORA zijn voor een belangrijk deel die van enterprise-architectuur in algemene zin. Een aantal typische toepassingsgebieden zijn:

  • Het geven van inzicht in verbetermogelijkheden – door de gewenste architectuur zoals beschreven in de referentiemodellen te vergelijken met de huidige inrichting ontstaat ondermeer zicht op witte vlekken en dubbelingen. Witte vlekken kunnen duiden op iets waar nog onvoldoende over na is gedacht. Dubbelingen kunnen een indicatie zijn dat kosten kunnen worden bespaard door te ontdubbelen.
  • Het geven van inzicht in de relevante aspecten en complexiteit van een verandergebied – vanuit het bedrijfsfunctiemodel is inzicht in de betrokken processen, informatie en applicaties. Dit kan relevante inzichten geven, ondermeer in de complexiteit en de wijze waarop deze kan worden teruggebracht.
  • Het geven van inzicht in de scope van projecten en de relaties met andere projecten – de verschillende modellen in de referentie-architectuur kunnen gebruikt worden om de scope van een project af te bakenen in de Project Initiatie Documentatie. Door deze te vergelijken met andere projecten ontstaat snel inzicht in mogelijke overlap en raakvlakken.
  • Het geven van inzicht in koppelvlakken en mogelijke samenwerking binnen een instelling – het bedrijfsfunctiemodel laat zien hoe informatiestromen in het algemeen zouden moeten lopen. Deze kunnen vergeleken worden met de huidige informatie-uitwisseling tussen afdelingen. Het applicatiemodel geeft een soortgelijk inzicht op het niveau van applicaties.
  • Het faciliteren van discussie en besluitvorming over eigenaarschap – in het algemeen is het belangrijk om eigenaren voor processen en gegevens aan te wijzen. De modellen in de referentie- architectuur kunnen worden gebruikt als checklist hiervoor. Zo kan voor elk bedrijfsobject in het informatiemodel de vraag worden gesteld of de eigenaar helder is.

Doordat de HORA een referentie-architectuur is voor een sector kent ze ook nog een aantal additionele toepassingsmogelijkheden zoals:

  • Het vergelijken van de inrichting van verschillende instellingen – de architecturen van instellingen zijn meer vergelijkbaar als ze zijn gebaseerd op dezelfde referentiemodellen. Hierdoor is ook sneller inzichtelijk hoe de inrichting verschilt, bijvoorbeeld welke applicaties andere instellingen gebruiken voor een bepaalde functie.
  • Het geven van inzicht in mogelijkheden voor samenwerking – doordat de referentiemodellen beschrijven wat hoger onderwijsinstellingen gemeenschappelijk hebben, kan ook eenvoudiger over mogelijke samenwerking worden gesproken. Zo kunnen instellingen zich bijvoorbeeld voor alle functies in het bedrijfsfunctiemodel afvragen of zij zich hier op willen onderscheiden of dat ze hier in kunnen samenwerken met andere instellingen, bijvoorbeeld door het inrichten van een gemeenschappelijk servicecentrum.
  • Het versnellen van het opstellen van een instellingsarchitectuur – doordat hoger onderwijsinstellingen zoveel gemeenschappelijk hebben is veel al beschreven in de HORA. Dit kan direct worden overgenomen, of (licht) op maat worden gemaakt voor een instelling. Hierdoor kan een instelling veel sneller een eigen enterprise-architectuur opstellen.
  • Eenduidiger communicatie naar leveranciers – de HORA biedt een gemeenschappelijke taal om over de processen en informatievoorziening van instellingen te communiceren. Dit maakt het ook eenvoudiger om gezamenlijk op te treden richting leveranciers en meer synergie te creëren in inkoop van IT-diensten.

Best practices

Voor het geven van ideeën voor de inzet van de HORA verzamelt en deelt het HORA beheer best practices welke te vinden zijn op de google drive map: HORA best practices. Materiaal om toe te voegen aan deze map kan gestuurd worden naar horabeheer@gmail.com. In de volgende paragrafen wordt ingegaan op een aantal specifieke toepassingsmogelijkheden.

Het geven van inzicht in verbetermogelijkheden

Zoals in de vorige paragraaf aangegeven kan de HORA worden gebruikt om snel inzicht te geven in verbetermogelijkheden. Er heeft bij een instelling een quick-scan plaatsgevonden met exact dit doel. In deze paragraaf wordt de daarin gehanteerde aanpak op hoofdlijnen beschreven zodat ook andere instellingen deze kunnen hanteren. De quick-scan is uitgevoerd in circa 2 maanden tijd. De quick-scan was gepositioneerd als belangrijke input voor de informatiestrategie, die parallel aan de quick-scan werd opgesteld maar een langere doorlooptijd kende. De verdeling tussen de quick-scan en de informatiestrategie was dat de quick-scan vooral inzicht moest geven in de knelpunten en verbeterpunten, terwijl de informatiestrategie vooral strategisch vanuit ontwikkelingen, het instellingsplan en de brede behoeften moest kijken. De quick-scan diende zowel naar proces-, als naar applicatie- en infrastructuuraspecten te kijken. De nadruk lag echter op een analyse van het applicatielandschap. In het kader van de quick-scan hebben er vooral gesprekken plaatsgevonden met mensen op het raakvlak tussen organisatie en ICT. Om de analyse te ondersteunen is er een spreadsheet opgesteld waarin alle informatie werd verzameld. In deze spreadsheet zaten tabbladen voor respectievelijk de proces-, applicatie- en infrastructuuraspecten. Hierin werd enerzijds feitelijke informatie verzameld, maar ook informatie over gewenste veranderingen. In het tabblad voor processen is het bedrijfsfunctiemodel als uitgangspunt gehanteerd. De namen en definities van de bedrijfsfuncties zijn ingekopieerd in de spreadsheet en er zijn kolommen aan toegevoegd. De belangrijkste kolommen in dit tabblad waren:

  • Beschrijving van de gewenste veranderingen in de processen die invulling geven aan de bedrijfsfunctie
  • Gewenste verandertermijn (binnen een jaar, binnen drie jaar, niet)
  • Mate waarin het proces is beschreven (op globaal niveau, op werkinstructieniveau, niet)
  • Huidige procesinrichting (centraal, decentraal op uniforme wijze, decentraal op pluriforme wijze, uitbesteedt)
  • Applicaties die de bedrijfsfunctie ondersteunen

Voor het applicatietabblad in de spreadsheet zijn de applicaties van de instelling als rij in de spreadsheet opgenomen. In het kader van de quick-scan is dan ook vooral een beter zicht opgebouwd van het applicatielandschap van de instelling. Daarbij lag de nadruk op het inventariseren van applicaties met een instellingsbreed karakter (die breder dan één faculteit ingezet kunnen worden). Voor de applicatie-inventarisatie is een veel groter aantal kolommen opgenomen in de spreadsheet omdat de intentie ook was om de informatie na de quick-scan ook te gaan beheren ten behoeve van enterprise-architectuur en applicatieportfoliomanagement. De belangrijkste kolommen in het applicatietabblad waren:

  • Naam van de applicatie
  • Applicatie(s) in de HORA waar deze applicatie invulling aan geeft
  • Functionaliteit die wordt geleverd door de applicatie
  • Beschrijving van de gewenste veranderingen in de applicatie.
  • Gewenste verandertermijn (binnen een jaar, binnen drie jaar, niet) Belang voor de organisatie (hoog, middel, laag)
  • Aanpasbaarheid (hoog, middel, laag)
  • Aanwezigheid van kennis (hoog, middel, laag)
  • Actualiteit van de technologie (hoog, middel, laag)
  • Gebruikte technologie
  • Functioneel beheerder
  • Technisch beheerder

Het infrastructuurtabblad volgde dezelfde structuur als het applicatietabblad. Doordat er in de quick- scan echter focus lag op het applicatielandschap is dat tabblad heel beperkt gevuld. De spreadsheet is ook gedurende het proces van tevoren gedeeld met de gesprekspartners. Zij hebben deze voorafgaand, tijdens en soms ook nog na het gesprek aangevuld met hun kennis. Ook zijn er gespreksverslagen opgesteld. Op basis van de spreadsheets zijn visualisaties gemaakt die inzichten geven in de informatie in de spreadsheets. Zo is het bedrijfsfunctiemodel (de gedetailleerde versie ervan) ingekleurd met een oordeel over de waarde van de verschillende velden in de spreadsheet. Het applicatiemodel in HORA is gebruikt als achtergrond waarop de specifieke applicaties van de instelling zijn geplot. Hierdoor was snel inzichtelijk waar dubbelingen en witte vlekken aanwezig waren. Daarnaast is er een rapport opgesteld waarin de bevindingen, conclusies en aanbevelingen uit de spreadsheets en de gespreksverslagen in zijn samengevat. Op basis van dit alles is een workshop georganiseerd met de betrokkenen waarin de resultaten van de quick-scan en de tussentijdse versie van de informatiestrategie zijn besproken.

Het geven van inzicht in de scope van projecten

Architectuur is vooral een instrument om richting te geven aan veranderingen en ervoor te zorgen dat zij in samenhang plaats vinden. Verandering vindt vooral plaats in programma’s en projecten. Het is daarom belangrijk dat het helder is welke verandering een project aanbrengt, dat deze verandering in lijn is met de architectuur en niet conflicteert met andere projecten. Een duidelijke scope zorgt ervoor dat het voor iedereen helder is wat wel en niet tot het project behoort en voorkomt oneigenlijke wijzigingen (“scope screep”). De referentiemodellen in de HORA kunnen gebruikt worden om de scope van projecten inzichtelijk te maken zodat duidelijk wordt welke veranderingen projecten aanbrengen en hoe deze veranderingen samenhangen met veranderingen in andere projecten. Deze samenhang volgt als het goed is ook uit de architectuur; een afhankelijkheid tussen elementen in de architectuur leidt al snel ook tot een afhankelijkheid tussen projecten die veranderingen in deze elementen aanbrengen. Zo is het bijvoorbeeld logisch dat een verandering van web content management systeem niet los kan worden gezien van de implementatie van een portaal.

Informatie relevant voor scoping en afhankelijkheden kan worden opgenomen in projectmanagementdocumentatie zoals een project brief en de project initiatie documentatie. Daarnaast is het ook mogelijk dit soort informatie centraal inzichtelijk te maken in een programma en projectportfoliomanagementsysteem. Hierdoor wordt de portfoliomanagementfunctie beter ondersteund en kan er centraal beter worden gestuurd op veranderingen. De HORA bevat verschillende modellen waarmee de scope van een project kan worden uitgedrukt. Zo is het mogelijk om aan te geven welke bedrijfsfuncties, bedrijfsprocessen, bedrijfsobjecten, applicaties en applicatie-infrastructuur worden geraakt.

De volgende tabel geeft aan hoe de referentiemodellen kunnen worden gebruikt voor het afbakenen van projecten. Het voorbeeld laat zien wat de impact is van het implementeren van instellingsbreed relatiebeheer. Een dergelijke tabel kan worden opgenomen in projectdocumentatie.

Naam Impact
Bedrijfsfuncties Relatiebeheer
Contactbeheer
Relatiebeheer centraal inrichten
Contactbeheer gebruik laten maken van centrale relatiegevevens
Bedrijfsobjecten Individu
Organisatie
Prospect
Stagebedrijf
Instellingsbrede gegevens van individuen, organisaties, prospects en stagebedrijven centraal beheren
Applicaties CRM systeem Centraal CRM systeem inrichten, decentrale systemen uitfaseren

Tabel 1 Voorbeeld projectscope: implementatie instellingsbreed relatiebeheer

Het geven van inzicht in koppelvlakken

De HORA geeft handvatten bij het bepalen van de gewenste koppelvlakken tussen afdelingen en applicaties. In het bijzonder geven het bedrijfsfunctiemodel en het applicatiemodel ook een beschrijving van de gewenste informatiestromen tussen bedrijfsfuncties en applicaties. Daarnaast hebben koppelvlakken een belangrijke relatie met de bedrijfsobjecten zoals beschreven in het bedrijfsfunctiemodel. Zo zullen er in een koppelvlak (of specifieke service daarbinnen) gegevens behorende bij één of meer bedrijfsobjecten worden uitgewisseld. Het is zelfs aan te bevelen om services dusdanig te ontwerpen dat zij primair in termen van gehele bedrijfsobjecten gegevens uitwisselen [36]. Dit verhoogt de herbruikbaarheid van services. Daarnaast is het belangrijk om de gegevens die worden uitgewisseld te standaardiseren in een zogenaamd canonical datamodel (zie ook het Integratie hoofdstuk in de architectuurvisie). Het bedrijfsobjectmodel biedt hiervoor een goed startpunt.

Er is binnen de Hogeschool Utrecht (HU) een aanpak ontwikkeld voor het identificeren en ontwerpen van koppelvlakken tussen applicaties op basis van de HORA. Het realiseren van koppelingen tussen applicaties is geen doel op zich, maar een middel om andere doelen te realiseren. In het strategisch ICT Beleid van de HU zijn onderstaande wensen t.a.v. de informatievoorziening vanuit de organisatie geformuleerd die vanuit een goed werkend koppelingenlandschap gefaciliteerd kunnen worden. De informatievoorziening is:

  • betrouwbaar en gepersonaliseerd
  • via één portaal toegangelijk
  • optimaal gedeeld over de processen
  • anytime, anywhere en any device beschikbaar.

Om dit te kunnen realiseren zijn de integratie van systemen (koppelingen dus) en harmonisatie van data belangrijke enablers. De HU heeft hiervoor een integratievisie opgesteld met daarin een aantal richtinggevende architectuurprincipes. Een kleine maar belangrijke selectie uit deze set principes zijn:

  • De HU werkt met een eenduidige set van master data. Dit leidt onder andere tot de invulling dat ieder gegeven één bronsysteem heeft en dat ieder gegeven een eigenaar heeft.
  • Applicaties zijn loosely coupled. Dit leidt bij de HU tot een technische invulling m.b.v. een Enterprise Service Bus.
  • HU werkt met een canoniek datamodel. Dit wordt eveneens met de technische invulling van een Enterprise Service Bus gefaciliteerd.

Om tot een goed ontwerp van een koppeling te komen, met inachtneming van de architectuurprincipes, heeft de HU een stappenplan ontwikkeld. Deze is in onderstaande tabel weergegeven.

Stap Aandachtspunten
Stap 1: Breng het ketenproces in kaart
  • Bepaal de koppelmomenten
  • Bepaal welke informatieoverdracht daar plaats vindt
  • Bepaal tenminste use cases voor opvoeren, wijzigen en verwijderen van gegevens in de keten
Stap 2: Bepaal de bedrijfsobjecten en hun onderlinge relatie
  • Bepaal 1-1; 1-n; n-1 relaties tussen de objecten
  • Abstractieniveau Bron: HORA
Stap 3: Bepaal welk systeem welk(e) proces(stap) ondersteunt
  • Bron: HU applicatiearchitectuur
  • Specifieke of generieke applicatie?
Stap 4: Bepaal uitwisseling van dataobjecten tussen de systemen
  • Vertaling van bedrijfsobject naar dataobject
  • Bestaat er al een bronsysteem voor het dataobject?
  • Bij vervanging systemen volledige omschrijving van de bestaande canonieke dataformaten
  • Bij nieuw proces en nieuwe applicaties zijn essentiële vragen:
    • moet het zelfstandige entiteit zijn? opotentiële attribuutuitbreiding?
    • Verplichte velden?
Stap 5:Vertaal dataobject naar het logische datamodel van bron - en doel applicatie
  • Indien er al een canoniek datamodel is, dan hoeft dat voor de bron niet meer gedaan te worden
  • Randvoorwaarde aan de applicaties: data kan geïmporteerd en geëxporteerd worden.
  • Fieldmapping bepalen
Stap 6: Canoniek dataformaat bepalen
  • Zijn er meer (potentiële) gebruikers van het dataobject?
  • Bepaal tevens attributen die in nabije toekomst nodig zijn
  • Global business identifier in het canoniek dataformaat (geen GUID)
  • Als het masterdata betreft, dan ook beheerproces inregelen

Het ondersteunen van de inrichting van gegevensbeheer

Een belangrijk toepassingsgebied van de HORA is de ondersteuning van gegevensbeheer (ook wel: “Data Governance” [1]). We hebben het hier met name over beheer van administratieve gegevens; het beheer van onderzoeksgegevens is een meer specifiek vakgebied die een andere inrichting vraagt. In het algemeen is het erg belangrijk dat de gegevenshuishouding op orde is. Hierdoor zal de kwaliteit van de (ondersteunende) processen [32] en daarmee de studenttevredenheid stijgen. In het kader van gegevensbeheer is het vooral belangrijk dat duidelijke afspraken worden gemaakt over taken en verantwoordelijkheden, over definities en over de bron van gegevens. Het informatiemodel is daarbij het belangrijkste instrument; het geeft een lijst van gegevensverzamelingen in de vorm van bedrijfsobjecten waarover afspraken gemaakt moeten worden.

Voor het toekennen van verantwoordelijkheden is het overzicht met daarin de relatie tussen bedrijfsfuncties en bedrijfsobjecten waardevol. Voor bedrijfsfuncties is het meestal relatief eenvoudig aan te wijzen wie de verantwoordelijkheid heeft. Deze kan overigens zowel centraal (instellingsbreed) als decentraal (bij faculteiten) liggen. Het identificeren van de verantwoordelijkheid voor de gegevens kan hierdoor worden ondersteund. Er wordt vaak gesproken over “eigenaarschap” van gegevens, maar dat is vanuit juridisch perspectief genuanceerder.

Daarnaast is het belangrijk om te constateren dat er verschillende rollen relevant zijn om gegevensbeheer goed in te richten. In de Data Management Body of Knowledge [1] wordt onderscheid gemaakt tussen de volgende rollen:

  • Executive data stewards – mensen uit de directie die eindverantwoordelijkheid nemen. Dit is wat vaak de “eigenaar” wordt genoemd.
  • Coordinating data stewards – leiden en vertegenwoordigen een team van business data stewards. Deze zijn vooral belangrijk in grote organisaties.
  • Business data stewards – zijn erkende domeinexperts die dagelijks bezig zijn met het definiëren en controleren van gegevens.

In veel gevallen zijn dit soort rollen reeds impliciet aanwezig in de organisatie en hoeven ze alleen expliciet te worden gemaakt. Dat is vooral ook een erkenning van het werk dat ze al doen in de dagelijkse praktijk en maakt hun verantwoordelijkheid formeel.

Een belangrijk deel van gegevensbeheer is het komen tot gemeenschappelijke definities voor gegevens. De definities zoals deze aanwezig zijn in het informatiemodel zijn hiervoor een goed startpunt. Deze blijven echter op het niveau van bedrijfsobjecten; er zijn geen attributen gedefinieerd in het informatiemodel. Hiervoor kan wel geput worden uit andere bronnen zoals het DUO gegevenswoordenboek [33] of uitwisselingsstandaarden zoals IMS.

Een ander belangrijke afspaak rondom gegevensbeheer is het bepalen wat de bronapplicaties zijn voor gegevens. Ook hier biedt de referentie-architectuur belangrijke ondersteuning. Zo is er voor alle gegevens bepaald wat de meest logische bronapplicatie zou zijn. Het overzicht met daarin de relatie tussen applicatiecomponenten en bedrijfsobjecten geeft deze informatie weer. Instellingen kunnen deze informatie als basis gebruiken om te bepalen wat bronapplicaties zouden moeten zijn.

Overigens heeft een dergelijke rolverdeling van applicaties ook direct invloed op de koppelvlakken. Als een applicatie de bron is voor een bepaald bedrijfsobject dan zullen andere applicaties die dit bedrijfsobject gebruiken de bijbehorende gegevens moeten ophalen uit de bronapplicatie. Idealiter is dit een geautomatiseerd koppelvlak, maar als het om een hele beperkte set van gegevens gaat of als de gegevens erg stabiel zijn dan kan het acceptabel zijn deze handmatig bij te houden.

Het versnellen van het opstellen van een instellingsarchitectuur

De HORA beschrijft de bedrijfsfuncties, bedrijfsprocessen, bedrijfsobjecten en logische applicaties die instellingen voor hoger onderwijs gemeenschappelijk hebben. Hierdoor is een kernonderdeel van de instellingsarchitectuur al voorgedefinieerd en kunnen instellingen zich richten op de zaken die specifiek zijn voor de eigen situatie. In deze paragraaf wordt aangegeven welke stappen een instelling herbij zou kunnen zetten. Het gaat ondermeer om het aanpassen en verdiepen van de referentiemodellen en het relateren ervan aan de instellingsspecifieke inrichting.

De referentiemodellen beschrijven wat instellingen gemeenschappelijk hebben. Een aantal instellingen voert echter afwijkende taken uit. Denk hierbij bijvoorbeeld aan universitaire medische centra die ook zorgtaken uitvoeren, instellingen die ook andere vormen van onderwijs uitvoeren (voortgezet onderwijs, MBO) en de open universiteit die meer dan andere instellingen te maken heeft met logistiek rondom onderwijsmaterialen. Dit soort afwijkende taakstellingen leiden ertoe dat er uitbreidingen noodzakelijk zijn in de verschillende modellen. Voor een deel zijn hiervoor ook al andere referentiemodellen beschikbaar. Denk bijvoorbeeld aan het referentiemodel ziekenhuizen zoals ontwikkeld door Nictiz [38].

Naast het uitbreiden van de referentiemodellen met afwijkende taakstellingen kan het wenselijk zijn de referentiemodellen ook aan te passen aan de taal, modellen en definities die reeds worden gehanteerd binnen de instelling. Hierdoor zullen de modellen meer herkenbaar worden voor medewerkers van de instelling. Het nadeel is echter dat communicatie over de grens van de instelling juist lastiger wordt. Daarnaast komt er een beheerlast bij de instelling te liggen voor het onderhouden van deze instellingsspecifieke versie van de referentiemodellen. Er wordt dan ook geadviseerd om hier voorzichtig mee om te gaan.

De referentiemodellen zijn relatief abstract van aard. Dit geldt met name voor het informatiemodel en het bedrijfsprocesmodel. Het informatiemodel is inherent abstract doordat het een conceptueel model is. Het creëren van een meer gedetailleerd model leidt dan ook snel tot het creëren van een ander (logisch) model, dat kan worden gerelateerd aan het conceptuele model. Dit meer gedetailleerde model is ondermeer relevant om te komen tot een gemeenschappelijk gegevensmodel voor het managementinformatiesysteem en voor de uitwisseling van gegevens tussen applicaties (canonical datamodel).

Het bedrijfsprocesmodel is met opzet abstract gehouden omdat verdere detaillering al snel leidt tot instellingsspecifieke inrichtingskeuzes. Voor instellingen is dit meer gedetailleerde abstractieniveau wel belangrijk, bijvoorbeeld voor procesverbeterinitiatieven. Het is dan ook verstandig dit bedrijfsprocesmodel (gericht) te detailleren om zo de instellingsspecifieke procesinrichting inzichtelijk te maken. Overigens gaat dit verder dan enterprise-architectuur; dit is eigenlijk onderdeel van de procesmanagement functie.

In het applicatiemodel is alleen het logische niveau gedefinieerd. Een applicatie is daarbij alleen logische clustering van functionaliteit en gegevens. Instellingen hebben zelf specifieke applicaties gemaakt en gekocht die kunnen worden gezien als de fysieke invulling van deze logische applicaties. Het inventariseren van deze fysieke applicaties en het relateren ervan aan de logische applicaties geeft allerlei inzichten (zoals eerder in dit hoofdstuk beschreven). Het is tevens de basis voor applicatieportfoliomanagement. Dit is onderdeel van applicatiebeheer en zorgt ervoor dat het applicatielandschap kwalitatief hoogwaardig en in lijn met de organisatiedoelstellingen en behoeften blijft.

Het verdient de aanbeveling om zowel de referentiemodellen als de instellingsspecifieke modellen te beheren in een architectuurbeheersysteem (repository). Hierdoor wordt de consistentie bewaakt en is de informatie optimaal toegankelijk. Om die reden zijn de referentiemodellen ook in de vorm van een ArchiMate bestand beschikbaar en is het ook mogelijk een instellingsspecifieke wiki in te richten die rechtstreeks gekoppeld is aan de HORA wiki. Door het aanbrengen van een relatie tussen de referentiemodellen en specifieke modellen ontstaat ook extra inzicht. Zo kunnen er eenvoudig zoekvragen worden gesteld die dubbelingen en witte vlekken in het applicatielandschap of in de beschikbare procesbeschrijvingen zichtbaar kunnen maken. Ook meer gedetailleerde informatie zoals de procesbeschrijvingen zelf, configuratie-items in het configuratiemanagementsysteem en gedetailleerde gegevensdefinities kunnen in een dergelijk beheersysteem bij elkaar worden gebracht waardoor een integraal kennisportaal ontstaat met kennis over de inrichting van de organisatie.

Naast de referentiemodellen is de architectuurvisie ook een belangrijke versneller voor een instellingsarchitectuur. Een mogelijke manier om de visie te vertalen is door deze te lezen en voor alles wat er staat de vraag te stellen welke specifieke keuzes de instelling heeft gemaakt en in welke mate de beschreven situatie ook zo aanwezig is bij de instelling. Zowel deze keuzes als de verschillen met de beschreven situatie zijn interessant en zouden expliciet moeten worden gemaakt in de instellingsarchitectuur. Voor een deel kunnen teksten ook één-op-één worden overgenomen als ze ook relevant zijn voor de instelling.