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

Advertenties

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 essentie van Open Data

Ik ga maar geen poging doen om een antwoord te vinden op de vraag der vragen: Wat is de zin van ons bestaan? Zo knap ben ik niet. Maar ik doe wel een gooi naar een antwoord op een klein sub-vraagje daarvan: wat is de zin van Open Data?

Mijn gewoonlijke manier om zoiets aan te vliegen is om de vraag laagje voor laagje af te pellen tot ik bij de kern ben aangekomen. Om te beginnen pak ik eerst maar eens het woordje “data” bij de kop. Data is het meervoud van datum, een gegeven, een waargenomen en vastgelegd feit. Ofwel: data zijn geregistreerde feiten.

Maar die definitie voelt ongemakkelijk, en dat zit in het woordje “feit”. Een feit moet eigenlijk verifieerbaar zijn (let op “eigenlijk”). Het moet aantoonbaar zijn. De registratie behelst verder het persisteren op een opslagmedium. In dit tijdperk spring ik meteen maar naar een database. Op basis van de definitie van data zou een database louter aantoonbare feiten mogen bevatten. Waarom moet ik nu denken aan “An inconvenient truth”? Ik zei het al, ongemakkelijk…

Hoe dan ook, een gegeven zou in principe moeten kloppen, en een hele gegevensverzameling zou in principe moeten kloppen. Onjuiste gegevens zou je in principe niet moeten registreren. Dat heeft immers geen nut, toch? O, het gebeurt natuurlijk voortdurend, maar het leidt tot problemen, en problemen vinden we niet nuttig anders zouden we ze niet voortdurend willen oplossen. Dus alleen de registratie van juiste gegevens is nuttig. Ofwel: de zin van data is direct evenredig aan de juistheid van die data.

Tot zover getackeld: Wat is data? Wat is de zin van data? Het gaat lekker. Rest alleen nog: “open”. Zo gepiept. Ik hoef alleen nog maar te analyseren wat de zin is van de openheid van data.

Iets is open als het toegankelijk is. Er lijkt mij ook een mate van openheid. De toegankelijkheid van de inhoud van een kluis is bijvoorbeeld beperkt tot diegenen die de toegangscode kennen, maar de inhoud van een koektrommel is toegankelijk voor iedereen die bij de koektrommel kan en het deksel weet los te krijgen. Twee voorbeelden die eigenlijk over de mate van geslotenheid gaan.

Geslotenheid is het tegenovergestelde van openheid. Zowel openheid als geslotenheid kan zinvol zijn. Ik vind het bijvoorbeeld heel zinnig om de inhoud van de koektrommel tot op zekere hoogte gesloten te houden voor mijn kindertjes. Stel je voor dat ze zich ziek vreten aan een overdosis koekjes. Plaats in dit zelfde perspectief ook de kast met schoonmaakmiddelen, het medicijnenkastje en de kast met sterke drank. Bescherming van de inhoud zelf, maar vooral de consumentjes is hier feitelijk de drijfveer.

Data is inhoud. Dus is de zin van de geslotenheid van data afhankelijk van de mate waarin die data en/of dataconsumenten beschermd moeten worden? Ja, me dunkt dat Jan en Alleman geen toegang zou moeten hebben tot bijvoorbeeld de inloggegevens van de DigID’s van alle Nederlanders. En als iedereen in de wereld het feitelijke recept van Coca Cola zou kennen, is dat natuurlijk niet bevorderlijk voor de concurrentiepositie van Coke. Data kan de eigenaar ervan voordeel (winst, controle, macht)  opleveren. Openheid van die data verdunt en verdeelt dat voordeel. Als dat maatschappelijk wenselijk zou zijn, dan is de openheid van die data maatschappelijk zinvol. De zin van openheid van data is dan dus ook gekoppeld aan maatschappelijk belang. Maar dat geldt ook voor de zin van de geslotenheid van data.

Op de Open Data Estafette (ODE) benaderde Professor Nico Baken (TU Delft) de openheid van data meteen maar vanuit een filosofisch perspectief. Hoogdravend maar inspirerend. Wat bij me is blijven hangen, is het woordje “pneuma“. Het is een oud, Grieks woord dat letterlijk “adem” betekent, maar in religieuze zin “ziel”. De filosofische betekenis komt vooral neer op “essentie”. Kortom: Pneuma gaat over wezenlijk nut: levensbelang. Professor Baken sloeg dat allemaal plat tot “zin”, maar in de wezenlijke betekenis. De boodschap die ik eruit haalde was om na te denken over het wezenlijke belang van open data: Waarom, en voor wie is de te openen data belangrijk?

Op hetzelfde congres sprak Ed Nijpels over de maatschappelijk waarde die je creëert door data van verschillende bronnen (en eigenaars) te verbinden. Door data vrij beschikbaar te maken ontstaat vrijheid voor anderen om die verbindingen te maken en toepassingen te maken die eerst niet mogelijk waren. Toepassingen die belangrijke maatschappelijke vraagstukken kunnen oplossen. Ed Nijpels is voorzitter van de borgingscommissie van het energieakkoord, en beziet het maatschappelijk belang van Open Data vanuit dat akkoord. Hij vestigt grote hoop op Open Data voor het borgen van een duurzaam energiebeleid en het realiseren van duurzame groei. Data die van maatschappelijk belang is, zou vrij toegankelijk moeten zijn voor iedereen die er maatschappelijke waarde mee wil creëren.

Een mooi voorbeeld van een Open Data toepassing dat op de ODE werd gepresenteerd, is de combinatie van open data over zonkracht, kadastrale data en hoogtepunten data om te berekenen of het zinvol zou zijn om op een bepaald oppervlak (bijvoorbeeld je eigen dak) zonnepanelen te plaatsen. Door die drie losse databronnen te verbinden zijn we in staat wezenlijke vragen te beantwoorden. Absoluut zinvol door die verbondenheid. Het nut van het openbaar maken van data moet je dan kunnen bezien vanuit de combinatie met data die door anderen openbaar is gemaakt. Eigenlijk gaat het dus vooral om vrije uitwisseling van gegevens en de vrijheid in het verbinden van die gegevens. Openheid, vrijheid, verbondenheid.

Open, open, open moet het zijn. Thé Lau (The Scene)  zong dat in 1991 al. Dat ging dan wel niet over data, maar hun boodschap is er wel degelijk op van toepassing: Open, open, open je voor mij, en ik open, open, open me voor jou. Openheid leidt tot verbondenheid. En die verbondenheid is misschien wel de belangrijkste voorwaarde voor ons welvaren, en jawel, de zin van ons bestaan.

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.

Ontvlechting en sanering

Ontvlechting en sanering, twee ICT-vaktermen. Het zijn eigenlijk “gewone” Nederlandse woorden die door de ICT-wereld zijn geadopteerd. Blijkbaar was dat nodig. Neem bijvoorbeeld “ontvlechting”. Ontvlechten is alleen nodig als er sprake is van onwenselijke vervlechting. In de ICT raken zaken inderdaad nogal eens teveel met elkaar vervlochten doordat die zaken over de tijd, te haastig en op diverse manieren aan elkaar werden geknoopt. En dat gebeurt dan ook vaak herhaaldelijk en jaren achtereen, zodat de ongezonde situatie ontstaat waarin van delen van het geheel niemand helemaal begrijpt waarom het werkt zoals het werkt.

Het werkwoord “saneren” heeft louter betekenissen die nuttig zijn voor de ICT, zoals: opruimen, weer gezond maken, zuiveren en verbeteren. Maar we denken meestal aan deze betekenis: afbreken en vervangen. Natuurlijk zou je liever willen voorkomen dan saneren, maar dat is moeilijk. De druk vanuit de business is vaak te hoog waardoor toch concessies worden gedaan aan kwaliteit en zonder architectuur wordt gewerkt. En zonder overkoepelend toezicht op en zonder overkoepelende besturing van – ofwel, zonder architectuur governance van – ICT-ontwikkelingen komen de haastig neergezette oplossingen meestal niet weer onder architectuur.

Dus als een ICT-landschap over de jaren door vele uitbouwprojecten is verworden tot een complex, instabiel, onvoorspelbaar, moeilijk beheerbaar en lastig uitbreidbaar geheel, waarvan niemand meer helemaal overziet en begrijpt hoe het werkt en waarom, dan wordt het tijd voor ontvlechting en sanering. Dit zijn doorgaans grote uitdagingen.

Ontvlechten is het proces van het in kaart brengen van de complexiteit en het weer terugwinnen van het overzicht en het inzicht. Door ontvlechting komen we weer “in control” van het beheer en de ontwikkeling, zodat met vertrouwen kan worden besloten tot het opruimen van overtollige constructies en het weer beter maken van ongezonde constructies: ofwel sanering .

En als ontvlechting echt een heilloze zaak is, dan rest eigenlijk nog maar één ding: volledige sanering. Dat houdt dus in dat je een compleet ICT-landschap vervangt. Wanneer is ontvlechting heilloos? Dat is niet eenvoudig te beantwoorden, maar levensvatbaarheid en toekomstvastheid zijn belangrijke factoren.

Uiteindelijk hoop je met ontvlechting en sanering te bereiken dat we weer “in control” geraken over het betroffen ICT-landschap, en dat we deze weer voldoende gevitaliseerd hebben zodat het weer een tijd mee kan. Ook doet uw organisatie er verstandig aan haar ICT-processen te ontvlechten en saneren en te zorgen dat aan- en verbouw in het ICT-landschap voortaan onder architectuur gebeurt.

Het belang van Requirements Management en samenwerking met de Business

Begin dit jaar verhuisde ik met mijn gezin naar een nieuw huis. Verhuizingen zijn altijd hectisch, zo ook die van ons. Uiteindelijk ben je over met al je spullen en staat alles min of meer op de plek waar je denkt dat het moet staan. Alle essentiële klusjes zijn gedaan en alles is redelijk aan kant. Natuurlijk blijven er altijd klusjes die nog heel lang in je achterhoofd geregistreerd staan onder “moet ik nog doen, maar kan later wel”. Één zo’n klusje was het op de juiste hoogte hangen van een fotolijst. Klinkt simpel, zou je denken, en dat was het ook. Kwestie van meten, boren, schroefje d’r in, lijstje eraan ophangen en klaar. 

Het ging om een foto van één van de kinderen. De foto’s van z’n broer en zus hingen ernaast. Drie vierkante lijsten van 50 bij 50 cm. Het zijn schitterende afdrukken van mijn prachtige kinderen op canvas dat op een houten frame gespannen zit. Bij de verhuizing waren ze tijdelijk aan de reeds aanwezige schroeven in de muur gehangen. Twee van de drie foto’s hingen keurig met de bovenkantjes gelijk, maar de derde hing 5 cm lager (zie bovenstaand plaatje). Dat heeft mijn vrouw (de business) een tijd lang zonder klachten geaccepteerd. Een onuitgesproken issue dus. Ik (ICT-er) besloot om dit potentiële issue pro-actief op te pakken, en vol goeie moed ging ik ermee aan de slag. Een kwartiertje later bekeek ik tevreden mijn resultaat. De foto’s hangen keurig op de zelfde hoogte, met gelijke onderlinge afstand van elkaar (zie onderstaand plaatje).

Even resumerend: ik had zonder samenspraak met de business een oplossing voor een potentiële issue geïmplementeerd. Ik had geen idee van de verwachtingen van de business, nog van de exacte wensen t.a.v. de implementatie van de verwachte oplossing. A recipe for disaster?

Later op de dag presenteerde ik de oplossing aan de business (mijn vrouw). De reactie was als volgt: “waarom hangt de jongste nog steeds helemaal rechts?”. Ai! Maar ik sprong meteen in aktie. In een handomdraai verwisselde ik de meest linker en de meest rechter foto van plekje aan de muur. Resultaat: 

Shit! Dit was niet in de lijn der verwachtingen. Noch die van mijzelf, noch die van de business. Ik had het issue alleen maar vergroot in plaats van opgelost. Ik had de scope van mijn project ook veel te smal gehouden (verhang foto 3), en impliciet aannames gedaan over de de verwachtingen en wensen van de business én over de flexibiliteit van mijn oplossing. Mijn oplossing ging namelijk uit van een aangenomen uniformiteit in de constructie van de fotolijsten. Echter, die bleek toch niet zo uniform als ik dacht. Fotolijst 3 was namelijk 2 jaar later geproduceerd dan fotolijsten 1 en 2. En jawel, er is een “architectuurafwijking” tussen de twee. Zie onderstaande plaat. Ik kon de haren wel uit mijn kop trekken. Destijds had ik bij het bestellen van lijst 3 de gewenste lijst-dikte moeten opgeven. Fotolijsten 1 en 2 waren mijn referentie-architectuur. Kortom: de oorzaak van het onverwachte resultaat ligt bij de uitvoering van een eerder project. Was ik toen maar uitgegaan van de reeds aanwezige standaard-maten!

Mijn project had dus een diepgaander onderzoek moeten doen naar de exacte requirements van de business en naar de mogelijke oplossingen. Dit had ik in samenspraak met de business moeten doen, en dan was iedereen tevreden geweest. Ik had mijn snelle oplossing naast enkele andere oplossingen moeten zetten en die bespreken met mijn vrouw. Ik zie nu (achteraf) ook de volgende oplossingsrichtingen:

1. eerst de dikte van het houten frame van foto 3 gelijk maken aan die van lijst 1 en 2, en dan pas verhangen

2. een generiek, verstelbaar fotolijst-ophangsysteem (een BAVO voor de ophanging van lijsten) selecteren en implementeren welke kan omgaan met de afwijkende afmetingen van de frames

3. de diktes van de frames van fotolijsten 1 en 2 verkleinen (even de schaaf erover…) en gelijk maken aan die van lijst 3

Je ziet het, ik heb mijn les hier wel uit gehaald. Doe er zelf ook maar je voordeel mee!