Infoloog, -noom of -soof?

Op LinkedIn profileer ik mij al jaren trots als Architect. Gedurende mijn loopbaan was ik diverse architecten: Software Architect, Solution Architect, Informatiearchitect, Domeinarchitect, Geo-Informatiearchitect en nu Enterprise Architect. In die hoedanigheid bracht ik vandaag weer eens een bezoek aan het Landelijk Architectuur-Congres (LAC). In zijn keynote drukte Rini van Solingen daar de neuzen van de aanwezige architecten fijntjes op het feit dat hun vak niet bestaat. Er bestaat geen vakopleiding voor. We bestaan evenmin als de eenhoorn. An unconvenient truth.

Zelf ben ik gediplomeerd informaticus. Na 20+ jaren ervaring en wat certificeringen mag ik mezelf architect noemen. Maar het is een officieuse titel. Officieel ben ik informaticus, informatiekundige. Op feestjes zeg ik gemakshalve vaak dat ik “in de ICT” zit. Een aantal jaren geleden bedacht ik daarom dat ik mezelf voortaan misschien beter infoloog kon noemen. Want beroepen die eindigen op loog hebben (in mijn beleving althans) meer befaamde beoefenaars. Denk bijvoorbeld aan Charles Darwin, Sigmund Freud en Mary Anning. Met en beroep dat eindigt op “-loog” kun je op feestjes aankomen.

Zou “infoloog” wellicht een goed aternatief voor “architect” kunnen zijn? Ik heb het zelf verzonnen begrip “infologie” eigenlijk nooit verder uitgediept. Hier doe ik een poging: Infologie bestaat uit “info” en “logie”. Info is (uiteraard) kort voor “informatie”, wat in de Romijnse tijd al “begrip, voorstelling, vorm” betekende. Het deel “-logie” betekent “-wetenschap of -theorie”, wat weer is afgeleid van -lógos (Grieks): ‘die zich met een bepaald onderwerp bezighoudt’. Een infoloog houdt zich dan (kort door de bocht geredeneerd) dus bezig met theorieen over begrip, voorstelling en vorm. Met een beetje fantasie kun je daar wel een architect in herkennen, maar het is mager.

We zouden -logie ook nog kunnen vervangen door -nomie, wat “-onderzoek, -leer of -studie” betekent, en is afgeleid van -nómos (Grieks): ordenen. Misschien zijn architecten wel “gewoon” infonomen: zij die begrip, voorstelling en vorm ordenen. Zou kunnen op zich, maar het dekt maar een deel van de lading.

Laat ik tenslotte ook nog even “-sofie” beschouwen. Ik neem weer even de korte bocht: een filosoof begeert (filo) wijsheid (sofie). Filosofie = wijsbegeerte. Zonder “filo” blijft alleen nog “wijsheid” over. Infosofen zijn erg wijs op het gebied van begrip, vorm en voorstelling. Architecten worden veel wijsheid toegedicht, dus deze past ook redelijk.

Welke van de drie uit mijn fantasie ontsproten termen zou “architect” kunnen vervangen? Die vraag is niet eenvoudig te beantwoorden, want wat is/doet een architect? Een architect houdt zich bezig met architectuur. Okee, maar wat is dan architectuur? Ik hanteer zelf meestal deze sterk vereenvoudigde definitie: architectuur beschrijft de structuur (componenten en onderlinge samenhang) van systemen, en geeft verstandige richting aan de ontwikkeling ervan. Een architect geeft richting aan de vorming van deze systemen, en maakt voorstellingen van (aspecten) van systemen zodat het begrip daarvan toeneemt. Met veel creativiteit heb ik de woorden begrip, vorm en voorstelling hierin verwerkt zodat “info” is afgedekt. Persoonlijk vind ik infosoof dan nog het beste passen. Wat denk jij?

Advertenties

Altijd ter plaatse

Vorige week liep ik nog rond in Sorrento. Een oud Italiaans stadje op het schiereiland Sorrentina in de provincie Napels. Er heerst daar een heerlijk, mild, mediterraan klimaat. Overal waar ik keek zag ik citroenen hangen. Daar wen je snel aan natuurlijk. Just another lemon tree, dacht ik dan als ik er wéér eentje zag.

Lemon field, Fruit, Sorrento, Italy

De reden voor mijn aanwezigheid aldaar werd niet zozeer gevormd door het mooie weer en  de citroenbomen (alhoewel…) als wel het G.E. Grid Solutions Summit. Een conferentie die zich richt op het ondersteunen van de nuts-sector bij het moderniseren van hun distributienetten (grids) door middel van IT-oplossingen die ervoor zorgen dat de levering van elektriciteit, gas en water op veilige, betrouwbare en efficiënte wijze (blijven) gebeuren. Die modernisering is nodig omdat de distributienetten de toenemende vraag naar energie en water moeten blijven aankunnen, maar vooral omdat deze netten steeds slimmer moeten worden in het kader van de verduurzaming van de energie- en waterwinning.

General Electric (G.E.) presenteerde op de conferentie haar visie op het gebied van de in de nutssector benodigde modernisering en de hiervoor ontwikkelde nieuwe oplossingen, tezamen met diverse partnerbedrijven en referenties. De rode draad in deze visie wordt gevormd door de vergaande digitalisering en automatisering van de bedrijfsvoering en het “slimmer maken” van de netten. Door middel van slimme meters, telemetrie en sensoren wordt de dynamiek in deze netten steeds nauwkeuriger gevolgd en wordt op basis daarvan slimmer in deze netten geschakeld. De nutsbedrijven moeten steeds beter in staat worden om grote hoeveelheden data (afkomstig van vele onderdelen in hun distributienetten) real-time te verwerken en te gebruiken voor de sturing van de primaire processen.

Mijn werkgever, Vitens, is het grootste waterbedrijf van Nederland, en beheert daarmee het grootste drinkwaterdistributienetwerk van Nederland. Vitens stelt zichzelf (onder meer) als doel om drinkwater van onberispelijke kwaliteit te leveren. De bedrijfsvoering moet adequaat beschermd zijn tegen verstoringen, en als deze optreden, dan zijn de getroffen klanten op tijd – bij voorkeur voortijdig – en goed geïnformeerd.

Om de betrouwbaarheid van de levering verder te vergroten, en om in staat te zijn om haar klanten beter en proactief te informeren over verstoringen, is het van belang dat Vitens betrouwbare en actuele data heeft over de toestand van haar leidingennetwerk, over de toestand en kwaliteit van de waterbronnen en de bedrijfsmiddelen, over de locatie en status van werkzaamheden van de monteurs in het veld en over de aangesloten klanten. Ook Vitens wil (en moet) steeds beter in staat worden om grote hoeveelheden data (afkomstig van vele onderdelen in het distributienet) real-time te verwerken en te gebruiken voor de sturing van de primaire processen. Vitens past daarmee dus goed in de doelgroep van het congres.

Het congres had uiteraard een sterke commerciële inslag, maar dat lag in de lijn der verwachtingen. Ik heb met name presentaties bijgewoond van andere netbeheerders uit verschillende sectoren (telecom, energie en water) . Het was leerzaam en inspirerend om te horen hoe zij hun bedrijfsvoering moderniseren, en hoe zij de transformatie naar data-gestuurde bedrijfsvoering maken. Dit zijn de lessen die ik eruit heb gehaald:

  • Door gestandaardiseerde, eenduidige (enkelvoudige bron, één waarheid) en hoogwaardige data wordt het eenvoudiger om de bedrijfsvoering te stroomlijnen. Zo wordt het bijvoorbeeld mogelijk om revisies in GIS bijna volledig te automatiseren. Ter plaatse verricht werk leidt automatisch tot registratie van de nieuwe waarheid in de bronsystemen. Het wordt hierdoor ook mogelijk om twee (of meer) veldwerkers over grote afstanden te laten samenwerken. Ter plaatse ziet elk van hen precies wat nodig is om gezamenlijk schakelwerk veilig te kunnen verrichten.
  • Door de nadruk te leggen op de optimale ondersteuning van gebruikers van informatievoorzieningen, vergroot je hun effectiviteit en efficiëntie. Deze voorzieningen moeten eenvoudig zijn in gebruik (prachtige, concrete principes hier zijn bijvoorbeeld: het werkt zo eenvoudig als Google Maps, en alles in één window) . Ook moet precies die informatie worden geleverd die nodig is op het moment, ter plaatse en voor de taak van deze gebruiker. Hier wordt het belang van de toegankelijkheid en betrouwbaarheid van essentiële informatie sterk zichtbaar.
  • Integrale toegankelijkheid van actuele data over de toestand van het distributienet maakt het mogelijk om de bedrijfsvoering te verschuiven van centraal naar decentraal. De controlekamer wordt als het ware mobiel waardoor bedrijfsvoering ter plaatse kan worden gedaan. Daarmee wordt het mogelijk om eigenaarschap en verantwoordelijkheid van delen van het net dynamisch te verdelen als dat nodig is (bijvoorbeeld bij grote verstoringen als gevolg van storm of andere rampen).
  • Applicatie-silo’s met eigen, specifieke datamodellen bemoeilijken de integrale toegankelijkheid van data. Het is lastig om ervoor te zorgen dat ter plaatse kan worden beschikt over betrouwbare, actuele data. Dit zag ik in meerdere presentaties terug komen. Dit vormt doorgaans een grote uitdaging. Een overkoepelend, logisch datamodel dat de silo’s verbindt, is hier de route naar succes. Andere belangrijke succesfactoren hierbij zijn eigenaarschap en ketenbesef (bewust zijn van jouw positie in een procesketen, en jouw effect op die keten).

Zie je het patroon? Altijd ter plaatse. Met “ter plaatse” bedoel ik hier zowel het moment (de plaats in de tijd) als de locatie (plaats op de kaart). Data ontstaat ter plaatse, stroomt door de bedrijfsprocessen waarin het wordt geïntegreerd met andere data tot informatie. Deze informatie wordt meteen of later elders, maar wederom ter plaatse gebruikt.

Altijd ter plaatse. De bedrijfsvoering van een netbeheerder wordt gestuurd met data die op vele plekken tegelijk ter plaatse ontstaan, en de werkzaamheden die ter plaatse worden gedaan worden ondersteund met integraal toegankelijke, actuele en bruikbare informatie. Althans, dat is het streven. De op het congres gepresenteerde softwaretechnologieën kunnen dit mogelijk maken, maar de benodigde integrale toegankelijkheid van de data ontstaat niet vanzelf door het gebruik ervan. Deze softwaresystemen kunnen de data uit verschillende applicatie-silo’s met eigen, fysieke datamodellen, bij elkaar brengen, maar kan hier geen consistent geheel van maken zonder een overkoepelend datamodel. Het maken van zo’n datamodel vormt doorgaans een grote uitdaging, vernam ik op het congres. Wat in de praktijk dan goed werkt is om klein te beginnen, bijvoorbeeld eerst alleen voor één stuk van een procesketen, en deze iteratief door te ontwikkelen (agile).

Altijd ter plaatse. Benodigde informatie van de juiste kwaliteit komt overal waar het wezen moet. Klaar om te plukken, net als die rijpe citroenen.

Altijd ter plaatse. Als je het mij vraagt een uitstekend basisprincipe om te hanteren bij het ontwerpen en realiseren van ICT-vernieuwingen!

 

De architect is effectief een holistische überbemoeial

Blijkbaar, althans in mijn beleving, moet een architect zichzelf steeds opnieuw uitvinden. In ieder geval moet je in mijn ervaring steeds op zoek blijven naar de rol die je als architect moet vervullen. Dit heeft er misschien mee te maken dat architecten altijd zijn ingezet op complexe problemen (hier mag je ook “uitdagingen” invullen, maar “problemen” dekt de lading meestal beter) die zich afspelen in een zeer dynamische context.

Van een architect mag worden verwacht dat hij/zij veel kennis bezit en deze ook zeer snel kan uitbreiden. De architect moet in staat zijn om problemen vanuit allerlei invalshoeken te benaderen. De architect moet die problemen eigenlijk voor zijn door met de business mee te praten over nieuwe inzichten en ideeën alvorens deze de status van “issue”, “change request” of “project charter” krijgen. Ik noem mezelf dan ook dikwijls een überbemoeial.

Ja, ik vind bemoeizucht (grote betrokkenheid) een niet onbelangrijke eigenschap van een architect. Als je invloed wilt hebben op de ontwikkelingen bij de business en vooral de daaruit voortvloeiende ICT-veranderingen en -vernieuwingen, en daar op strategisch niveau over wil meepraten, dan moet je zorgen dat je een gesprekspartner wordt van de business. En dat wordt je niet alleen door je formele functie in de organisatie, maar vooral door je zichtbaarheid groot te maken. En dat doe ik door me proactief tegen die dingen aan te bemoeien waarvan ik vind dat ik er invloed op zou moeten hebben.

Door die grote bemoeizucht ben je na verloop van tijd bij een veelheid aan ideeën, initiatieven, issues, projecten en programma’s betrokken. Je wordt een spin in een uitermate dicht web. Alles houdt in zekere mate verband met elkaar. Als architect moet je in staat zijn om die verbanden te herkennen. Door je überbemoeizucht krijg je een holistische kijk op de zaken. En dat is mijns inziens de grote meerwaarde van een architect: het holistische perspectief.

Onlangs werd me dit heel duidelijk toen me werd gevraagd of ik ook eens kon nadenken over competentieprofielen. Door de vraag vanuit een holistisch perspectief te benaderen, kon ik de benodigde competentieontwikkeling vrij eenvoudig duiden. In de afgelopen periode heb ik me, naast diverse projecten, intensief bezig gehouden met informatieplannen en een overkoepelende afdelingsvisie en overkoepelend informatiebeleidsplan. Het informatiebeleidsplan beschrijft de wijze waarop de afdeling in de komende 5 jaar haar eigen visie en daarmee de visie van de business wil realiseren. Het is een koersbepaling op de visie. De koers gaat langs een aantal etappes, en bij iedere etappe hoort een aantal concrete resultaten die behaald moeten zijn. Op basis van deze koersbepaling kan dus niet alleen de organisatie en operatie van de afdeling worden ingericht, maar ook de competentieontwikkeling.

Kortom: omdat ik bij veel zaken (vroeg) betrokken ben (lees: mij tegen van alles en nog wat aan bemoei), en omdat ik daardoor in staat ben om verbanden te zien tussen al die zaken, kon ik een ingewikkelde vraag over een onderwerp waar ik me nog niet eerder mee had beziggehouden, heel effectief beantwoorden. En daarmee heb ik mijzelf wederom uitgevonden: als architect ben ik effectief een holistische überbemoeial.

AGNES

Als Geo-Informatiearchitect in de Netbeheersector kom ik graag bij de business thuis. Mijn business (Enexis) vraagt niet direct om Geo-Informatiearchitectuur, maar gewoon om bruikbare en betrouwbare Geo-informatievoorzieningen die snel gerealiseerd kunnen worden. Het Geo Competence Center (Geo-CC) moet maar gewoon zorgen dat die Geo-informatievoorzieningen bruikbaar en robuust zijn.

Bij de buren (andere netbeheerders) gaat het net zo. Los van elkaar realiseren we systemen die veel functionele overlap hebben. De Geo-ICT-leveranciers en -dienstverleners actief in de Netbeheersector zijn hier de lachende derden. We zouden die Geo-ICT-markt en de ontwikkelingen daarin vanuit een gezamenlijke behoefte en referentiearchitectuur  moeten aansturen. En dat is precies waarin AGNES moet gaan voorzien.

AGNES is het “Architectuurmodel voor de Geo-informatievoorziening in de NEtbeheer-Sector”.  Een meisjesnaam in de traditie van referentie-architecturen in de publieke sector (NORA, GEMMA, …).

Onderstaande figuur toont een raamwerk voor een referentiearchitectuur. Vertrekpunt is het beleidskader, het waarom. Voor AGNES bestaat deze uit de wettelijke kaders, maatschappelijke taken en sector-afspraken. Zo zijn netbeheerders WION-plichtig, en daardoor gehouden aan INSPIRE. We moeten in staat zijn om actuele en juiste Geo-informatie te leveren waar dat nodig is.

Raamwerk voor een referentiearchitectuur

Raamwerk voor een referentiearchitectuur

Hierop volgen de principes: het wat. Deze geven houvast bij het maken van keuzes in de ontwikkeling van Geo-informatievoorzieningen. Een belangrijk AGNES-basisprincipe is: “Altijd ter plaatse met een schat aan informatie”. Toegepaste principes die daaruit volgen zijn “eenduidige vastlegging van data” en “toegankelijke data”.

De standaarden en bouwstenen beschrijven de standaard ingrediënten waarmee een Geo-informatievoorziening kan worden gerealiseerd. Registers voorzien bijvoorbeeld in de eenduidige vastlegging en toegankelijkheid van data.

Dit is nog maar een raamwerk dat we samen verder moeten gaan invullen. AGNES voorziet in een gemeenschappelijke, zuivere taal – Agnes betekent trouwens ook “zuiver” – onder de betrokken. Dan zijn “halve woorden” voldoende en wordt samenwerking eenvoudiger.

Raamwerk voor AGNES

Raamwerk voor AGNES

Registers, en snel een beetje!

In mijn professionele context wordt de laatste tijd veel gesproken over “registers”. De business komt er voor bij de ICT-afdeling: zeg, doe mij eens even een register, graag volgende week klaar. Het lijkt een soort nieuwe silver bullit te zijn (“nieuw” is betrekkelijk hoor, dit speelt al enkele jaren).

De te doden weerwolf is dan de combinatie van slechte kwaliteit (volledigheid, juistheid, actualiteit) en slechte integrale beschikbaarheid van alle data over zaken die centraal staan voor de organisatie, zoals klanten en bedrijfsmiddelen.  Met dat laatste bedoel ik dat data in de diverse systemen “weg gestopt”  zitten, en erg moeilijk met elkaar in verband kunnen worden gebracht. Er is geen integraal informatiebeeld over bijvoorbeeld klanten en bedrijfsmiddelen, waardoor bepaalde analyses onbetrouwbare resultaten opleveren of zelfs onmogelijk zijn.

Het voordeel van een echte weerwolf is trouwens dat je daar alleen bij volle maan last van hebt. Dat is dus hooguit 12 keer per jaar. Het is de vraag of je op zo’n incidenteel “probleempje” een business case voor een zilveren kogel en de hele jacht op de weerwolf rond krijgt. Maar van een gefragmenteerd informatiebeeld heb je elke dag last.  De business case voor een register en de jacht op de data is wel te maken lijkt me.

Maar wat is nou eigenlijk een register? De gewenste eigenschappen (zoals ik dat om me heen hoor) zijn:

  1. Het maakt data over één belangrijk type bedrijfsobject (zoals aansluiting, of  bedrijfsmiddel) integraal toegankelijk;
  2. deze data zijn altijd consistent, volledig, actueel en betrouwbaar (authentiek);
  3. Een register is veilig (goed beveiligd tegen ongeoorloofde toegang);
  4. alle gebeurtenissen op de geregistreerde zaken worden bijgehouden (bij aansluitingen bijvoorbeeld: aanleg, inhuizing, uithuizing, leverancierswissel, …);
  5. Een register kan worden gelinkt aan andere (externe) registers zodat data in verband kunnen worden gebracht met andere, gerelateerde data.

Basisregistraties

De overheid heeft het belang van een voorziening met de bovenstaande eigenschappen al langer ingezien, en noemt zoiets een basisregistratie. Het kabinet heeft een heel stelsel van nationale registraties aangewezen (citaat uit Wikipedia-artikel:) waarvan de Nederlandse overheid meent dat daarin met een gerust hart alle vitale gegevens over burgers, bedrijven en instellingen gecentraliseerd kunnen worden opgeslagen. De verantwoordelijken voor het stelsel gaan ervan uit dat deze zogeheten “authentieke gegevens” een dermate hoge kwaliteit zullen hebben, dat de overheid deze gegevens zonder enig verder onderzoek in haar werk zal kunnen gebruiken.

In het bovenstaande citaat heb ik delen vetgedrukt gemaakt. Ze zeggen iets over de eigenschappen die de overheid toekent aan het stelsel van basisregistraties, en je ziet dat deze eigenschappen overlappen met het lijstje hierboven. Allicht zijn de in mijn omgeving geuite requirements t.a.v. registers geïnspireerd door het overheids-model.

Het stelsel van basisregistraties is in detail beschreven in de “Stelselarchitectuur van het Heden“. Het stelsel bevat onder andere de Basisregistratie Personen (BRP), de Basisregistratie Adressen en Gebouwen (BAG) en het Nationaal Handelsregister (NHR). De beoogde doelen van het stelsel  zijn de bestrijding van nationale rampen of fraude, de eenmalige verstrekking van gegevens door burgers en bedrijven en besparing op beheerskosten.

In de Nederlandse Overheid Referentie Architectuur (NORA) vormt de basisregistratie een belangrijke bouwsteen. Er is een lijst met eisen waaraan het moet voldoen, en een lijst met rollen en verantwoordelijkheden. Eigenlijk is het een specificatie van een dienstverlening, en niet van een informatievoorziening.

Register-architectuur

Een register is dus blijkbaar een service die de organisatie (business) verleent. Verder worden in een register in algemene zin gegevens (gebeurtenissen) over de levensloop van objecten  geregistreerd. Dit resulteert in een opzet waarbij alle mutaties aan eigenschappen van een object in de tijd worden bijgehouden.

Als ik het probeer te vatten in een Archimate-schema, kom ik uit op het onderstaande, simplistische plaatje. Ik positioneer het register als een product van de business, dat bestaat uit een cluster van services en kwaliteitsafspraken (contract). Uiteraard draait het register om de registratie van gegevens over een voor de business essentieel business object. Er is een bedrijfsproces dat het beheer van het register realiseert, met daaraan toegewezen de rol van datamanager.

Register-businessarchitectuur
(gemaakt met Archi)

Het blauwe gedeelte van het plaatje gaat over de onderliggende applicatie-architectuur.  Op die laag is de informatievoorziening zichtbaar die in de registerfunctionaliteit voorziet. In bovenstaande plaat wordt die functionaliteit ontsloten via applicatieservices.

Bovenstaande architectuur is heel hoog-over, maar bevat wel de essentie van een Register. Het is vooral declaratief, en zegt dus niets over de manier waarop de Registerfunctionaliteit wordt gerealiseerd. Dat kan op allerlei manieren, maar ik zie vooralsnog maar twee smaken: fysiek register en virtueel register. Die werk ik nog verder uit, dus: wordt vervolgd…

Informatiearchitectuurzorg

De titel doet wellicht vermoeden dat dit artikel gaat over zorgen die ik mij maak om mijn functie, maar nee. Alhoewel ik wel bezorgd ben over de hoeveelheid “architectuurvragen” die ik op de hooivork heb, en de hoeveelheid aandacht die ik effectief aan ieder van die vragen geven kan. Maar daar wil ik het alleen indirect over hebben. In dit artikel wil ik het vooral hebben over “zorg” als in verzorging.

Met “informatiearchitectuurzorg” trek ik dan een directe parallel met “gezondheidszorg”. Op wikipedia vind ik de volgende definitie van gezondheidszorg:

De gezondheidszorg in een bepaald land is het geheel aan activiteiten dat gericht is op de verbetering van de gezondheid van de mensen in dat land. Onder de gezondheidszorg wordt niet alleen het onderzoek en de kennis van gezondheid begrepen, maar ook de toepassing van deze kennis om de gezondheid van mensen te verhogen, ziekten te voorkomen (preventieve gezondheidszorg) of te genezen, en het lichamelijk en psychisch functioneren te verbeteren.

Het leuke is dat die definitie nagenoeg 1-op-1 kan worden overgenomen voor de definitie van informatiearchitectuurzorg:

De informatiearchitectuurzorg in een bepaalde organisatie is het geheel aan activiteiten dat gericht is op de verbetering van de gezondheid van de architectuur van de bedrijfsinformatie, en -informatievoorzieningen. Onder de informatiearchitectuurzorg wordt niet alleen het onderzoek en de kennis van informatiearchitectuurgezondheid begrepen, maar ook de toepassing van deze kennis om de gezondheid (duurzaamheid, toekomstvastheid) van de informatiearchitectuur te verhogen, verzwakkingen te voorkomen (preventieve architectuurzorg) of te herstellen, en het functioneren van bedrijfsinformatievoorzieningen te verbeteren.

Het klopt als een bus, en mijn hierboven genoemde zorgen over de aandacht die ik effectief kan besteden aan de veelheid aan architectuurwerk die ik op mijn hooivork heb, kan ik met behulp van deze parallelle definitie heel mooi oplossen. In de gezondheidszorg zijn (in Nederland althans) namelijk niveau’s aangebracht: een eerste, tweede en derde lijn. Op de eerste lijn bevindt zich de rechtstreeks toegankelijke hulp zoals huisartsen, apothekers, psychologen, fysiotherapeuten, et cetera. Op de tweede lijn bevinden zich de specialistische zorgverleners die alleen na doorverwijzing geconsulteerd kunnen worden. En op de derde lijn bevinden zich tenslotte expertisecentra waarop tweedelijns-specialisten een beroep kunnen doen.

Een mooi systeem. De verlichting van mijn persoonlijke architectuurzorgen ligt mijns inziens dan ook in het aanbrengen van vergelijkbare niveaus in de informatiearchitectuurzorg (en waarschijnlijk gebeurt dat vaak al heel vanzelfsprekend, maar noemen we het niet zo).

De eerstelijns informatiearchitectuurzorg bestaat dan uit informatieanalisten. Zij vormen het eerste contact met de business rondom ICT-gerelateerde vragen en zorgen (issues), of issues met een ICT-component. Hoewel de diversiteit kleiner is dan in de gezondheidszorg hebben de informatie-analisten evengoed ook verschillende specialiteiten. Zo zijn er bijvoorbeeld ERP-informatieanalisten, GIS-informatieanalisten en BI-informatieanalisten. Allemaal proberen ze hun “patienten” eerst te bedienen vanuit hun specialisme en binnen afgesproken beleidskaders en conform architectuurprincipes die op hun specialisme van toepassing zijn.

Op de tweede lijn van de informatiearchitectuurzorg plaats ik de solutions architecten en informatiearchitecten. Zij komen in beeld wanneer de issues en de impact daarvan op de gezondheid van de informatiearchitectuur de kaders van de informatieanalist ontstijgen. Soms is de ingeschatte overschrijding van een zekere budgetgrens daarin bepalend, maar vaak ook de complexiteit van de benodigde oplossing (meerdere systemen vanuit verschillende disciplines worden geraakt).

Tenslotte bevinden zich op de derde lijn, in mijn beleving, de architectuurbeleidsmakers, domeinarchitecten, security-architecten en enterprise-architecten. Maar ik ervaar zelf de scheidslijn tussen lijn 2 en 3 als onscherp. Met name het terrein van de domeinarchitect vind ik onscherp. Eigenlijk staat deze met één been in de tweede lijn en met één been in de derde lijn. Vanuit zijn domeinexpertise wordt hij/zij regelmatig geconsulteerd door informatiearchitecten, maar binnen zijn/haar domein opereert de domeinarchitect op de tweede lijn.

Zoals ik al aangaf, helpt het aanbrengen van deze zorgniveau’s mij bij het vergroten van mijn eigen effectiviteit (als GEO-informatiearchitect). Ik moet er daarbij goed voor zorgen dat de informatie-analisten met wie ik nauw samenwerk, goed op de hoogte zijn van de toepasselijke beleidskaders en architectuurprincipes. Tegelijkertijd voeden zij mij weer met de toepasbaarheid van dat beleid en die principes in de dagelijkse praktijk, en met informatie over voorgenomen verbeteringen (TO-BE Architectuur).

Op die manier kan ik mijn aandacht beter verdelen over de diverse projecten en complexere business-vragen, en hou ik tijd over voor architectuurbeschrijving en -vastlegging (mijn monnikentaak) en het maken van architectuurvisie.

Eigenlijk komt het erop neer dat informatiearchitectuur een capaciteit is van de organisatie. Die capaciteit zit niet op competenties van enkele individuen, maar op samengestelde competenties verspreid over verschillende mensen. Een goede indicatie voor volwassenheid van iedere organisatie-capaciteit is de (snelle) reproduceerbaarheid ervan door “nog-niet-ingewijden” (nieuwe teamleden of teamleden met nieuwe taken).

Met het aanbrengen van zorgniveau’s zou de volwassenheid van de informatiearchitectuur-capaciteit dus groter moeten worden. Ik heb het  niet gemeten, en ik ga dat ook niet doen, maar ik zie dat het werkt.

De GIS-Architect

Het gezicht dat me aankijkt als ik in de spiegel kijk, zou van een GIS-Architect kunnen zijn. Ik weet in ieder geval vrij zeker dat de beste man een IS-Architect is. De ‘G’ is een recente toevoeging. Formeel ben ik een informatie-architect. Ik hou me blijkbaar bezig met het beschrijven van inhoudelijke relaties en samenhang tussen toepassingen en gegevensverzamelingen onderling.

TOGAF levert de volgende definities van Architectuur:
1. Een formele beschrijving van een systeem, of een gedetaileerde blauwdruk van het systeem op componentniveau ter begeleiding van de implementatie van dat systeem (ISO/IEC 42010:2007).
2. De structuur van componenten, hun onderlinge afhankelijkheden en de principes en richtlijnen die hun ontwerp en ontwikkeling sturen.

Ik ben dus zo vrij om informatie-architect gelijk te stellen aan informatiesysteem-architect, afgekort: IS-Architect. In de afgelopen jaren werd ik geleidelijk het aanspreekpunt voor alle GIS-Architectuur binnen de organisatie waar ik werkzaam ben, dus mag ik er een ‘G’ voor zetten. Ook maak ik sinds kort deel uit van de Afdeling GEO ICT. De teamleden noemen mij “onze GIS-Architect”, wat me een warm gevoel geeft. Zo werd ik dus GIS-Architect.

Maar wat is een GIS-Architect? Dat is een vraag die me de laatste tijd veel bezig houdt. Ik zie het vooral als een focus van de generieke definities van Architectuur op een specifiek soort systemen, namelijk Geografische Informatiesystemen. En dat geeft me ook de houvast die ik zoek. Een GIS-Architect:
– beschrijft de inhoudelijke relaties en samenhang tussen GIS-toepassingen en GIS-gegevensverzamelingen onderling;
– beschrijft de structuur van componenten van een GIS-Architectuur en hun onderlinge afhankelijkheden;
– en beschrijft de principes en richtlijnen voor de sturing van het ontwerp en ontwikkeling van die componenten.

En in die hoedanigheid hou ik mij momenteel bezig met de architectuur van een complex geografisch informatiesysteem (GIS) dat een zeer groot aantal gebruikers in staat stelt om spatiale data te creëren, beheren, delen en gebruiken binnen een breed scala aan toepassingen. Dit GIS is bovendien geïntegreerd met andere grote bedrijfssystemen (ERP, DMS, …). Ook is er een groeiende trend om de spatiale data uit het GIS in andere bedrijfssystemen in te passen, of omgekeerd, om spatiale kenmerken toe te voegen aan data in andere systemen. Een GIS van dat kaliber wordt ook Enterprise GIS genoemd.

Mezelf dan maar Enterprise GIS-Architect te noemen gaat me nu te ver. Alhoewel ik me ook ooit eerst Architect ben gaan noemen om het te worden. Ik volgde toen namelijk letterlijk het advies op dat ik ooit kreeg toen ik aan een Architect vroeg hoe je Architect wordt. Het antwoord was toen: Door “Architect” op je visitekaartje te zetten. En dan natuurlijk ook zorgen dat je vooral veel ervaring als Architect op doet. Ik ben me dus sterk gaan profileren als architect, en rolde daardoor in de door mij begeerde architectuurfuncties. En nu ben ik in de Enterprise GIS-Architectuur-functie gerold. Het profiel ijlt nog wat na, maar dat zie ik als prachtige ruimte voor persoonlijke groei.

Toevoeging:

Informatie-architectuur, en dan dus ook GIS-architectuur is uiteindelijk ook een team-competentie. Ik spreek zelf vaak van eerste- en tweede-lijns architecten. M.i. zijn informatie-analisten 1e-lijns informatie-architecten. Zij kunnen voor de minder complexe changes een impact analyse doen en een eerste toets op architectuur compliancy op basis van de principes en het beleid aangereikt vanuit de tweede lijn.