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…

Advertenties

Koe melkt Boer en Applicatie gebruikt Bedrijfsproces. Wat klopt hier niet?

Informatiearchitecten zijn soms net monniken. Zelf voel ik me in ieder geval regelmatig monnik, ook al zit ik niet in het klooster, draag ik geen pij, en doe ik niet aan zelfkastijding. Dat ik me soms net een monnik voel komt vooral omdat ik regelmatig monnikenwerk aan het doen ben. In figuurlijke zin, maar desalniettemin monnikenwerk.

Wat ik dan doe is het op nauwgezette wijze vastleggen van de enterprise-architectuur binnen het procesdomein dat mij is toevertrouwd. Een secuur geduldwerkje. Mijn broeders in de organisatie doen dat voor de andere domeinen zodat er een compleet beeld van de organisatie wordt vastgelegd. Iemand moet het toch doen? Bovendien vormt architectuurvastlegging een belangrijk deel van het takenpakket van de informatiearchitect. Gelukkig vind ik het leuk werk, anders zou ik toch van kastijding kunnen spreken.

Dat vastleggen van architectuur doe ik in een architectuurtaal genaamd “Archimate“. Dit is een formele symbolentaal waarmee je op gestandaardiseerde manier de enterprise-architectuur van een organisatie kunt optekenen en vastleggen. Je kunt er imposante platen mee tekenen, waarop symbolen staan die met elkaar zijn verbonden door middel van lijntjes en pijlen. Hoe vollediger en gedetailleerder de vastlegging deste nauwkeurig zijn de analyses die ermee kunnen worden gedaan.

Archimate is een taal zoals Nederlands een taal is, maar dan veel strikter. In het Nederlands mag je bijvoorbeeld schrijven: “De boer wordt gemolken door de koe”. Daar klopt niets van maar grammaticaal gezien mag het. In het Nederlands is het om het even welk zelfstandignaamwoord wat ook maar doet met andere zelfstandige naamwoorden. Je kunt twee znw’s met elkaar in relatie brengen door middel van een werkwoord. Daar ben je heel vrij in. Er zijn alleen regels voor de manier waarop je het werkwoord dat de activiteit uitdrukt, vervoegd dient te worden. Nederlands is eigenlijk heel betekenisblind.

In Archimate gaat het juist om betekenis, maar wel eentje die zich beperkt tot enterprise-architectuur. Er kunnen alleen bepaalde zelfstandige naamwoorden worden gebruikt. Bijvoorbeeld: Bedrijfsproces en Applicatiecomponent. In archimate worden dit “componenten” genoemd. Ook kun je maar een beperkte set werkwoorden gebruiken. “Melken” zit er niet bij.

Werkwoorden leggen ook in Archimate de relaties. Er is precies bepaald welke relaties je mag gebruiken tussen welke componenten. Zo mag een Bedrijfsinformatieobject gerealiseerd worden door en Dataobject, mag een Rol een Business Service gebruiken en mag een Bedrijfsproces – in mooi Nederlands – getriggerd worden door een Business Event. Een Bedrijfsproces dat een Actor gebruikt is niet logisch, dus dat wordt ook niet door Archimate toegestaan. Door deze precieze regels worden de modellen die je in Archimate op stelt logisch en consistent. Hieronder een voorbeeldje.

Dus wie verbaasde mijn schets, eh…maar dan andersom…, toen ik ontdekte dat een Applicatiecomponent een Bedrijfsproces mag gebruiken? Dat slaat als een tang op een varken. Dat is zo onlogisch als een boer die door een koe wordt gemolken. Archimate 1.0 staat dit echter toe en zo ook het op Archimate gestoelde architectengereedschap Bizzdesign ™ Architect (tenminste, in de versie die ik gebruik). Begrijp ik het niet, of ben ik zowaar op een bug in de Archimate specificatie gestuit? Of is die bug op mij gestuit?