In mijn nieuwe opdracht ondersteun ik een grote academische instelling bij het inrichten van hun architectuurfunctie en de bijbehorende centrale architectuur repository. Mijn bevindingen deel ik in deze blogreeks.
Het woord is al een aantal keer gevallen: de centrale architectuur repository. De vulling hiervan is een van de deliverables van mijn project. In deze blog ga ik in op wat het is, waarom het nodig is en hoe we bepalen wat we erin vastleggen.
Wat is een repository?
De letterlijke vertaling van het woord repository is bewaar- of opslagplaats. De centrale architectuur repository is dan ook de plek waar alle organisatiebrede architectuurinformatie centraal wordt opgeslagen. De repository bevat alle concepten, relaties, documentatie en links die relevant zijn voor de architecten. Daarnaast bevat de repository ook uitgewerkte views, tabellen en lijsten en zijn er analyses en toekomstige (SOLL) architecturen in opgeslagen. Om het overzicht te bewaren gebruiken we een uitgebreide mappenstructuur. Door concepten op deze manier vast te leggen kunnen ze eenvoudig worden gevonden en hergebruikt. Zo beschikken architecten over een gedeelde set modellen en informatie. Daarmee voorkomen we bijvoorbeeld dat dezelfde applicaties op meerdere manieren worden vastgelegd en onze analyses onvolledig of zelfs onjuist zijn.
Waarom is de repository nodig?
Naarmate een organisatie complexer wordt is het lastig overzicht houden over alle afhankelijkheden tussen systemen, applicaties en processen. In de academische instelling waar ik nu werk hebben we honderden applicaties die rond de duizend processen ondersteunen. Informatie over hoe die systemen samenwerken zit in de hoofden van de beheerders of in informele en inconsistente tekeningen. Doordat de informatie-uitwisseling tussen applicaties via een broker loopt weten zelfs beheerders niet altijd waar hun data vandaan komt of welke bedrijfsprocessen daar gebruik van maken. Bij projecten zoals het implementeren of vervangen van een applicatie wordt informatie uit de repository verzameld, aangevuld en gebruikt om richting te geven aan het project. Om te zorgen dat al deze inspanningen niet verloren gaan vloeien de resultaten van projecten terug in de repository. Zo blijft de informatie bewaard en brengen we de architectuur van de hele organisatie in kaart.
Met een dergelijk totaaloverzicht van systemen, processen en afhankelijkheden kunnen we snel analyses uitvoeren. Door aan het ene blokje te schudden zien we wat er meebeweegt. We weten de mogelijke gevolgen als er een serverruimte vol water loopt en bij veranderende privacywetgeving weten we waar die gegevens worden beheerd, gecached en gebruikt.
Wat leggen we vast in de repository?
Hoewel het idee van het perfecte, allesomvattende model architecten vaak aanspreekt, moeten we beseffen dat het model nooit een doel op zich is. Niet alles wat we vast kunnen leggen moet daadwerkelijk in de repository worden opgenomen. Om hier richting aan te geven zijn er een aantal vragen die we ons steeds opnieuw stellen.
Voor wie ga je dit vastleggen?
We moeten bepalen welke rol architectuur moet gaan spelen, wie de stakeholders zijn en welke producten en diensten we daarvoor moeten leveren om hen het juiste inzicht te verschaffen. Dit hebben we in een reeks workshops vastgesteld. Ook voor individuele projecten moet deze afweging worden gemaakt.
Wordt deze informatie al ergens anders bijgehouden?
Het is zowel zonde van de tijd als foutgevoelig als informatie op meerdere locaties tegelijkertijd wordt bijgehouden. ArchiMate leent zich goed voor het bewaren van het overzicht. Zolang gedetailleerde informatie over bijvoorbeeld de infrastructuur in een CMDB (Configuration Management DataBase) wordt bijgehouden modelleren we alleen het overzicht en maken we verwijzingen naar de locatie waar verdere informatie kan worden gevonden.
Hoe vaak wordt het gebruikt?
Het komt voor dat het heel nuttig is om een bepaald detail te modelleren voor eenmalig inzicht. In dat geval wordt de afweging gemaakt of het de moeite is om dat detailniveau organisatiebreed toe te voegen. Er wordt dan dus een afweging gemaakt tussen de tijd die het kost het om het vooraf op te halen, versus de tijd om het ad-hoc te doen op het moment dat het nodig is.
Hoe veranderlijk is het en zijn we dan op de hoogte?
Alles wat in de repository wordt vastgelegd moet ook worden onderhouden. Als we inzichten genereren waarvan we niet weten of ze kloppen moet het immers alsnog ad-hoc worden uitgezocht. Een voorbeeld: Als applicaties op een virtuele omgeving draaien en regelmatig met een druk op de knop van de ene op de andere locatie gezet worden, is het bijna niet te doen om dit in de repository bij te houden. Daarbij komt dat we iets alleen actueel kunnen houden als we weten wanneer een verandering plaatsvindt. We leggen bijvoorbeeld alleen zaken vast waarvan de veranderingen centraal worden goedgekeurd.
Hoort dit in een rapportage?
Als we hebben besloten wat wordt vastgelegd in de repository stellen we vast hoe we daarover rapporteren. Voor veel details is het goed om te zorgen dat ze zijn vastgelegd, ook al hoeven ze niet altijd te worden weergegeven. In dat geval kunnen stakeholders de vraag stellen aan een architect en wordt op dat moment het juiste inzicht getoond. Dit kan een uitgewerkte view zijn, maar ook een tabel of een lijst. Voor inzichten die veel vaker nodig zijn maken we een rapportage. Omdat deze online beschikbaar komt kunnen mensen daarin zelf de benodigde informatie opzoeken. Ook hier is het bepalend hoe vaak het inzicht nodig is, hoe vaak het verandert en of het werk van het bijhouden opweegt tegen de toegevoegde waarde van de informatievoorziening.
Het feit dat we deze vragen doorlopend blijven stellen betekent dat de repository nooit af is. Nieuwe architectuurvragen, keuzes of veranderende omstandigheden kunnen invloed hebben op de inrichting van de repository. Van architecten vereist dit een flexibele opstelling. Daarbij denken wij graag met u mee!
Overzichtsposter onderwijsinstelling
Om bewustzijn te creëren over het project en wat wij vastleggen in de architectuur repository hebben wij posters opgehangen. Een voorbeeld poster kunt u hier downloaden. Het resultaat is dat mensen nu zelf met hulpvragen komen en ons bij hun projecten betrekken.
Heeft u naar aanleiding van deze blog vragen? Neem dan contact op met Mark Kahmann.
Lees direct de andere blogs uit deze blog-reeks:
Blog 1. Enterprise Architectuur: een schoolvoorbeeld
Blog 2. Een schoolvoorbeeld: bouwen aan de architectuur capability
Blog 3. Een schoolvoorbeeld: ArchiMate
Blog 5. Een schoolvoorbeeld: referentie architecturen en de HORA
Blog 6. Een schoolvoorbeeld: het perfecte architectuurmodel in 5 stappen
Blog 7: Een schoolvoorbeeld: kennisdelen en Enterprise Architectuur best practices