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.

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!

 

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?

Canonieke modellen

De laatste tijd hou ik me bezig met de ontwikkeling van een Canoniek Datamodel. Ik weet wat daarmee bedoeld wordt, maar de theorie blijkt toch wat te zijn weggezakt. Dus ik fris mijn geheugen maar eens wat op en snuffel in boeken en op het internet. Bijzonder woord ook, dat “canoniek”. En omdat ik me ineens realiseerde dat ik met mijn mond vol tanden zou staan als ik gevraagd zou worden wat “canoniek” betekent, zocht ik eens op wat dat woord nou eigenlijk betekent. 

Ik kom onder andere de volgende betekenissen tegen:

• typisch
• normaal, genormaliseerd
• uniek, eenduidig
• gestandaardiseerde manier van weergeven
• volgens erkende, geaccepteerde regels

Het is ook een bijvoegelijk naamwoord met de betekenis dat het onderwerp in overeenstemming is met de canon, de kerkelijke wetten. Canonieke zaken zijn dus geloofwaardig, en zo ook een canoniek model. Ik weet verder niet zo veel (lees: nul comma nul) over kerkelijke wetten, en wellicht zou ik me er eens wat meer in moeten verdiepen. Wie weet wordt ik dan een geloofwaardiger informatiearchitect. 

Geloofwaardig of niet, informatiearchitecten hebben het vaak over canonieke modellen. Met model wordt hier conceptueel model bedoeld, wat een vereenvoudigde voorstelling is van een stukje werkelijkheid. Een conceptueel model deelt een stukje werkelijkheid op in concepten en legt verbanden daartussen. We maken conceptuele modellen om een stukje werkelijkheid inzichtelijk te maken, om problemen uit die werkelijkheid te begrijpen en uiteindelijk te kunnen oplossen.  

Met een canoniek model wordt een eenduidig conceptueel model bedoeld dat is gebaseerd op een gestandaardiseerde en gemeenschappelijke kijk op iets binnen een bepaalde context (een stukje werkelijkheid). Dat is mijn vertaling van de Engelse omschrijving op wikipedia. Er zit al een stukje interpretatie in, maar ik moet die zin eens verder ontleden voor ik hem helemaal snap. Ik zie de volgende aspecten:

1. eenduidigheid
2. standaardisatie
3. gemeenschappelijk
4. kijk
5. context

Dus een canoniek model is ondubbelzinnig en maar op één manier uit te leggen. De betekenissen van de concepten in het model zijn gebaseerd op een gemeenschappelijk afgesproken standaard. Daardoor geeft het model een uniforme kijk op het stukje werkelijkheid dat het model moet vereenvoudigen. Canonieke modellen voorzien in een typische, standaard voorstelling van iets. Denk bijvoorbeeld aan een typische beschrijving van een auto. Een auto is een heel complex ding, maar het onderstaande model van “auto”  is heel universeel.

Het model brengt de complexe auto terug tot enkele essentiële concepten die met elkaar in verband staan. Een typische auto heeft een carrosserie, een motor, een stuur, een vooras met twee wielen en een achteras met twee wielen. Het stuur staat in verband met de vooras, en de motor drijft één van de assen of beide tegelijk aan. Dit model typeert een auto. Iedere auto voldoet aan dit model. Inderdaad, driewielers niet, dus het model is niet universeel, maar wel binnen de context van een autofabrikant die alleen vierwielers produceert. 

Een canoniek model vereenvoudigt de communicatie over dingen in een bepaalde context (bijvoorbeeld een bedrijf). Iedereen binnen die context die het model kent weet wat er wordt bedoeld wanneer de concepten uit dit model worden besproken. Het voorkomt, heel simpel gezegd, misverstanden. Het model is immers ondubbelzinnig.

Dat is natuurlijk prachtig, maar hoe ontwikkel je een model waar iedereen binnen een bedrijf het mee eens is? Dat is niet eenvoudig. In grote organisaties hebben verschillende mensen een verschillende kijk op de dingen waar de organisatie zich mee bezig houdt. Vaak conflicteren de “kijken”, en vereist de ene kijk veel detail, en de andere juist weinig. Toepassen van het poldermodel maakt het proces om tot zo’n gemeenschappelijk en breed geaccepteerd model te komen, te tijdrovend.  

Dan is het misschien beter om met een kleine groep deskundigen, die de voor het model relevante onderdelen van de organisatie goed vertegenwoordigen, zo goed als mogelijk een eerste versie van het beoogde canonieke model op te stellen en deze tot dé standaard te bombarderen. Er volgen dan verfijningen over de tijd. Het opstellen van een canoniek model is dan een iteratief (jawel!) proces. Kortom: in een ivoren torentje de wet opstellen en bijwerken en dan aan de wereld daarbuiten opleggen. Autoritair als ik ben, kan ik daar wel wat mee 😉