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!

Cloudificatie en Cloudisme

Zijn uw processen al gecloudificeerd? Of doet u niet aan cloudisme?

Twee woorden die ik uit mijn dikke duim heb gezogen, maar die op zich levensvatbaar zijn. Misschien worden ze zelfs al gebezigd, maar dat heb ik niet gecontroleerd.

Cloudificatie is dan “het geschikt maken voor de cloud”. Dat stoelt wel op de verwachting dat er iets voor nodig is om een proces (of een deel ervan) “in de cloud” te kunnen stoppen. Ik denk dat die verwachting heel rëeel is, want niet elk proces leent zich zonder meer voor de cloud. Ik heb geen diepgaand onderzoek gedaan natuurlijk. Ik baseer me op pure GBV (Gezond Boeren Verstand).

Mijn GBV zegt me bijvoorbeeld dat processen die in hoge mate bedrijfs-specifiek zijn moeilijker te cloudificeren zijn dan processen die generiek zijn of nauwelijks afwijken van de “marktstandaarden”. Dat zou dan betekenen dat cloudificatie ondermeer inhoudt dat je je processen meer moet standaardiseren om ze te kunnen verclouden.

Ook de strategische waarde van de informatie in een proces bepaalt of en de mate waarin het proces kan worden gecloudificeerd. Hoe hoger de strategische waarde, des te hoger de mate waarin de informatie beveiligd moet zijn. En laat beveiliging nou net een gevoelig onderwerp zijn in cloudificatiediscussies. Cloudificeren zou dan dus voor een belangrijk deel ook kunnen betekenen dat je het procesdeel dat je in de cloud zet ontdoet van strategische informatie en de benodigde koppeling met het oncloudificeerbare procesdeel (de toegang tot strategische informatie) goed beveiligt. Weer mijn GBV hier aan het werk hè, hier ligt geen fundamenteel onderzoek aan ten grondslag.

Cloudisme kan diverse betekenissen hebben. Ik ben daar nog een beetje zoekende. Misschien moet ik het zoeken in de sensatie. Een soort toerisme. Dan wordt de cloud een soort avontuurtje waarvan je terugkomt met foto’s. Leuk joh, clouds! Moet jij ook eens doen!

Of misschien moet ik het zoeken ik blootstelling en risico. Exhibitionisme en fanatisme dus eigenlijk. Ik durf mij bloot te stellen aan de cloud. Oeoeoe. Dat is het andere uiterste van het spectrum. Roekeloosheid is niet iets wat past bij cloudificatie.

Te denken valt ook aan een aandoening of een afwijking, maar die kant wil ik zeker niet op. Voor mijn gevoel is er niets mis met cloudisme. In tegendeel. Cloudisme is gezond.

Nee, ik voel meer voor een betekenis in de richting van een stroming: Realisme. Clouds zijn handig maar niet altijd verstandig en vice versa. Het is mooi om met je kop in de wolken te zitten, maar hou de voeten op de grond. En omgekeerd: nuchterheid is mooi, maar er stel je ook open (toch een beetje blootstelling dus) voor de mogelijkheden en voordelen van de cloud. Dát is cloudisme.

Stof tot nadenken

Bij ons in de keuken staat een kast. Het is zo’n handig Zweeds meubel dat we ooit als bouwpakket kochten. Het is met het ons gezin meegegroeid door er steeds uitbreidingen bij te kopen. Het begon met 3 staanders en wat planken. Met de functie van stereo-en-TV-meubel. Heel overzichtelijk en het wekelijkse afstoffen (onderhoud) kostte nauwelijks moeite.

Nu is het een uitgebreid wandmeubel met vele functies. Hieronder volgt een kleine selectie van de huidige manieren van gebruik:

  • Entertainment (stereo, spellen, legpuzzels, knutselmaterialen)
  • Financiën (archief voor betaalde facturen, spaarvarkens, beker met kleingeld voor de wekelijkse uitbetaling van zakgelden en voor giften aan collectanten)
  • Bar (buiten bereik van kinderen houden van sterke dranken en stoffige wijn-, bier- en borrelglazen)
  • Kantoor (uitpuilend postvakje, printer, oplaad-station voor gadgets)
  • Bibliotheek (kookboeken, tijdschriften)
  • Expositie (fotolijsten, kinderkunstwerken)

Je begrijpt dat dat afstoffen nu veel meer moeite kost. Sterker nog, zelfs de externe partij waaraan wij de schoonmaak van ons huishouden hebben geoutsourced waagt zich hier niet aan. Veel te veel werk. Bovendien is er een veel te groot risico dat de processen die zich in en rond de kast afspelen, door het afstoffen in de problemen komen. Kortom: dat afstoffen gebeurt niet. Het is veel te specifiek en dus te lastig. Daarentegen weet onze ZPZP-er (zelfstandige poetser zonder personeel) wel raad met de vloeren, de badkamer en de toiletten, want dat is gewoon standaard-poetswerk.

Moeten we op basis daarvan dan concluderen dat outsourcing alleen goed werkt voor gestandaardiseerde processen? Het is in ieder geval wel veel eenvoudiger en minder risicovol. En je kunt altijd heel gemakkelijk van je outsourcingspartner af, want er zijn genoeg anderen die het hetzelfde kunstje kennen. Toch?

Moeten we wellicht ook concluderen dat een uitbreidbaar, multifunctioneel systeem uiteindelijk slecht onderhoudbaar wordt? Volgens mij hangt dat heel sterk af van de mate van regie. Mijn gezin bestaat nu uit 6 personen. Ieder gezinslid geeft zijn eigen invulling aan het gebruik van onze keukenkast. Er is feitelijk onvoldoende regie over het gewenste gebruik ervan. We laten de boel een beetje de boel omdat we onze energie al opmaken aan de primaire gezinsprocessen. Daardoor waagt niemand zich aan het wegwerken van de stoflagen in onze keukenkast.

Gebrek aan standaardisatie en regie kan dus leiden tot een stoffige bedoening, vooral in de hoekjes waar de dynamiek laag is, zoals bij mijn verzameling borrelglaasjes, want ik drink maar heel af en toe (geen primair proces…). En omdat er zoveel stof op ligt, laat ik die mooie borrelglazen maar gewoon stoffig en drink mijn slaapmuts uit een espressokopje (koffie drinken is voor mij wél een primair proces). En zo zie je dat er door achterstallig onderhoud ook nog eens oneigenlijk gebruik van middelen ontstaat. Wat een zooitje. Ach, het geeft in ieder geval stof tot nadenken.

Wat als storingsinformatie openbaar zou zijn

Natuurlijk twitteren de netbeheerders er al lustig op los over stroom- en gasstoringen. In dat opzicht wordt er over storingen niet geheimzinnig gedaan. Ze treden op en ze worden zo snel mogeljk weer opgelost. De tweets vermelden doorgaans de begintijd en locatie van de storingen, beperkte informatie over de voortgang van het verhelpen ervan en de uiteindelijke eindtijd van de storing. Wettelijk gezien zijn netbeheerders verplicht om actuele storingen openbaar te maken. Daarom wordt alle actuele storingsinformatie online gepubliceerd.  

Via GasEnStroomstoringen.nl kun je doorklikken naar de de gepubliceerde storingen van de diverse netbeheerders. Je komt dan uit bij de storingenzoekmachines van de geselecteerde netbeheerder. De “ruwe data” die ten grondslag liggen aan de gepubliceerde storingsinformatie zitten in de informatiesystemen die de netbeheerder daarvoor gebruikt. De publicatie is een eindproduct. En hoewel ze handig via een centrale URL kunnen worden gevonden (http://www.gasenstroomstoringen.nl), moet je als mogelijke storingsgedupeerde nog teveel zoeken naar de informatie waar je wat aan hebt.

In een wereld waarin mensen altijd online zijn via hun mobiele apparaten zou die storingsinformatie die voor hen relevant is vanzelf onder hun aandacht moeten komen. De mensen bepalen zelf welke locaties voor hen belangrijk zijn: eigen woonplaats, woonplaatsen van familie & vrienden, vestigingsslocaties van ondernemingen, et cetera. Hier zitten veelal sociale motieven achter. Mensen staan via sociale media steeds in contact met vrienden, familie en collega’s. Het gegeven dat je zelf of iemand die je kent door een storing getroffen wordt is sociaal relevante informatie. Net als het weer, file-informatie, OV-informatie en financiële informatie willen mensen ook storingsinformatie in hun dagelijkse informatieconsumptie en de anticipatie daarop kunnen verweven.

In de huidige vorm kan dit niet. De gegevens zijn verspreid over verschillende websites en worden op verschillende manieren aan de gebruiker gepresenteerd. Als alle storingsdata centraal opvraagbaar zou zijn in een gestandaardiseerde, onopgemaakte vorm (geen presentatie) via een SOAP/REST Web Service en eventueel een Web API (Application Programming Interface), dan creëer je een voedingsbodem voor allerlei leuke en nuttige mashups, apps en zelfs games, geproduceerd door derden, die de verweving van de storingsinformatie met alle andere sociaal relevante informatie mogelijk maken.

Het is niet de vraag of dit gaat gebeuren, maar wanneer. Ik voorzie dat binnen afzienbare tijd alle storingsinformatie van alle gezamenlijke netbeheerders via een centrale databank beschikbaar zullen zijn. Openbare storingsgegevens. Ofwel: Open Data, een hot topic bij de nederlandse (semi)overheden. 

Hier wordt helder uitgelegd wat Open Data is. Onderstaande is een citaat:

Open Data is data waar geen restricties i.v.m. privacy, veiligheid of anderszins op rusten. In Nederland wordt steeds meer gesproken over ontsluiting van data die beschikbaar is bij overheid en bedrijfsleven. Denk bijvoorbeeld aan milieu- en demografische data, data over incidenten, mobiliteit, educatie, connectiviteit, infrastructuur en de planning en het gebruik van (publieke) ruimte. Die data is vaak niet publiek toegankelijk vanwege praktische, politieke, commerciële of andere redenen. Er ligt een kans en een noodzaak om daar iets aan te doen.

Data over incidenten, connectiviteit en infrastructuur. Daar heb je het. 

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 😉