Januari/Februari 2000: L_PASO: het VRI-model opnieuw bekeken - DEMO

De stelling van deze maand komt voort uit een reeks discussies die de laatste maanden gevoerd zijn rond informatie architecturen. Het volgende probleem doet zich voor:

---
'L_PASO, voorheen het VRI-model, is opgezet om het beroepenveld van de informaticus in kaart te brengen. Anno 2000 blijkt dit model verouderd te zijn. Het is voor verbetering vatbaar.
---

Historie
L_PASO is een nieuw acroniem voor wat vroeger het VRI-model heette. Het VRI-model is ontstaan doordat het VRI (Vereniging voor Register Informatici) in het najaar van 1996 haar steun heeft gegeven aan de interne notitie ‘Op weg naar verdere professionalisering’. Deze notitie was gebaseerd op de eindresultaten van eerdere werkgroepen, waaronder de VRI-NGI werkgroep Infocus 2000. Het VRI-model heeft zijn uiteindelijke vorm gekregen door de werkgroep die in de kern bestond uit Prof. Jan Dietz, Klaas van der Poel, Theo Veltman (Infocus’2000) en Steven van ‘t Veld.

Bij de eerste presentatie het VRI-model, medio 1997, was de werkgroep zich er terdege van bewust dat het model nog verder ontwikkeld moest en kon worden. Het model werd echter voldoende rijp geacht om in bredere kring gebruikt en becommentarieerd te worden. De hoop was dat het VRI-model een prominente plaats zou gaan krijgen in de discussie over functies, taken, opleidingen en kwaliteiten van informatici, en zodoende een bijdrage zou leveren aan verdere professionalisering.

Na de presentatie in 1997 is het model geëvalueerd in relatie tot het PAO (Post Academisch Onderwijs). Onder het acroniem L_PASO is er een directe aansluiting gemaakt met de binnen en rond de Technische Universiteit Delft uitgewerkte methode DEMO.
Daarnaast worden pogingen in het werk gesteld om L_PASO de prominente plaats te geven in de discussie rond het beroepenveld die het VRI-model toegedacht werd. Om die reden is het één van de speerpunten van SPITS, het nieuwe samenwerkingsverband van VRI en NGI.

Constateringen
Kijken we, rond de wisseling van het millennium, naar het VRI-model/L_PASO, dan moeten we constateren dat het nooit de prominente plaats gekregen of vervuld heeft in de discussie over functies, taken, opleidingen en kwaliteiten van informatici die verwacht werd. De bijdrage aan de professionalisering van informatici is dan ook minimaal. Reden voor deze geringe bijdrage is dat de discussie over het model in bredere kring en de toepassing ervan niet plaatsgevonden heeft. Buiten initiatieven vanuit PAO en rond DEMO is er weinig gebeurd. Daarbij is de toepassing binnen PAO niet echt gelukt en is/wordt e.e.a. met DEMO uitgebouwd tot een methodologie.

Reeds jaren bestaat een grote behoefte aan een fundamentele discussie over het indelen van het beroepenveld van de informaticus. Dit wordt sterk gevoeld door de beroepsverenigingen die de laatste tijd ontstaan zijn. De vraag is steeds weer hoe beroepen als informatie architect, "kennis"-specialist, functioneel beheerder, functioneel ontwerper enz. zich onderling verhouden. Het VRI-model had vele discussies moeten voorkomen. In de huidige, of desnoods in een aangepaste vorm.

Verder merken we, in lijn met de stelling, in en rond de praktijk dat het VRI-model / L_PASO verouderd is. In de navolgende tekst wordt hier nader op ingegaan. Misschien dat we met deze veranderingen de gewenste discussie alsnog kunnen starten.

VRI-model / L_PASO [Sommige teksten zijn, hier en daar aangepast, overgenomen uit de documentatie van het VRI].

Figuur: VRI-model/L_PASO Figuur

Het VRI-model is een indeling van het gehele werkterrein van de informaticus. Het basismodel kent 24 deelgebieden (cellen). Zij zijn het resultaat van het relateren van vier soorten werkzaamheden met drie soorten systemen en daarbinnen twee soorten modellen. Elke cel is gekenmerkt door een zo algemeen mogelijke aanduiding van de werkzaamheden "in" de cel.

De werkzaamheden (zie de verticale as in de figuur):

1. architectureren is het tot stand brengen van plannen en architecturen (vergelijk met stadsontwikkeling en planologie). Aan architecten worden eigenschappen toegedacht als strategisch en associatief denken, idealisme en sociale vaardigheid.
2. ontwerpen is het tot stand brengen van een concreet systeem binnen het kader van de architectuur (vergelijk het ontwerpen en bouwen van een huis, en het projecteren en aanleggen van een weg). Ontwerpers dienen problemen goed te kunnen onderkennen en begrijpen, en zij dienen in staat te zijn om creatief optimale oplossingen te realiseren.
3. invoeren is het doen functioneren of in werking stellen van een gerealiseerd systeem (vergelijk het in gebruik nemen van een gebouw of het opnemen van nieuwe telefoonverbindingen in een bestaand net). Typische eigenschappen die men van invoerders verwacht zijn snelheid en stressbestendigheid. Op tijd klaar zijn telt zwaarder dan perfectie.
4. beheren is het in gebruik of in werking houden van een systeem (vergelijk het beheren van een kantoorgebouw of van een telefoonnet). Typische eigenschappen die men van beheerders verwacht zijn degelijkheid, betrouwbaarheid en ordelijkheid.

De soorten systemen (zie de horizontale as in de figuur) geven elk een “informatiekundige bril”:

• bedrijfsproces omvat de eigenlijke bedrijfsactiviteiten: het aangaan en nakomen van commitments tussen mensen, die met bevoegdheid en verantwoordelijkheid hun taken uitvoeren en dat uitvoeren onderling coördineren. Een bedrijfsproces wordt gezien als een systeem, bijvoorbeeld het leveren van klantorders, het beheren van een magazijnvoorraad, maar ook het besturen van deze processen.
• informatiesystemen zijn de zuiver informatieverwerkende activiteiten: het inwinnen, verschaffen en onthouden van kennis over de bedrijfsactiviteiten, alsook het afleiden van (nieuwe) kennis daarover. Voorbeelden zijn verkoop en inkoopsystemen en productiebesturingssystemen.
• infrastructuur is de wijze waarop informatiesystemen gestalte krijgen. Deze systemen vormen samen de infrastructuur. Die betreft niet alleen de (lokale en interlokale) transmissienetwerken, maar ook de (centrale en gedistribueerde) opslag en verwerking van gegevens. Voorbeelden zijn e-mail-systemen, tekstverwerkers en DBMS-en.

De soorten modellen (per soort systeem op de horizontale as in de figuur):

• functie/gedrag. Bedoeld wordt de kennis over het gedrag of de functie van een systeem. E.e.a. wordt gelijk gesteld aan een blackbox-model, ofwel het kijken naar wat het systeem dient te doen en welk extern gedrag het dient te vertonen.
• constructie/werking. De kennis over de werking en de constructie van een systeem. E.e.a. wordt gelijk gesteld aan een whitebox-model, ofwel het kijken naar hoe het systeem opgezet is en hoe het intern werkt.

Het basismodel kan men tenslotte beschouwen op verschillende occupatievlakken. Deze zijn niet ingetekend maar dienen als een 3e dimensie gezien te worden, die loodrecht staat op de gehele figuur. Voorbeelden zijn uitvoering, besturing (management), advisering (consultancy), onderzoek en onderwijs.

Rond Bedrijfsprocessen
In de kolom bedrijfsprocessen spreken we dus over de inrichting van organisaties. Taken of activiteiten die samen een bepaald doel (zowel primair, secundair, tertiair enz.) dienen te verwezenlijken. Omdat een organisatie meestal (veel) meer doelen dient te verwezenlijken, kennen we ook meer bedrijfsprocessen. En die kunnen we in beeld brengen (architectureren), we kunnen veranderingen ontwikkelen (ontwerpen), we kunnen de ontworpen veranderingen invoeren (invoeren) en we kunnen de bestaande situatie beheren (beheren).

Omdat het VRI-model / L_PASO bedrijfsprocessen als systemen ziet wordt het erg makkelijk om alleen in structuren te denken waar een model van gemaakt kan worden. De praktijk leert echter anders. Naast het uitwerken van structuren zal ook de inzet van mensen en middelen een grote rol spelen. De praktijk leert dat het beeld van bedrijfsprocessen, wat bedrijfsproces architectuur heet, dan ook meer is dan een model. En daarmee wordt het architectureren meer dan puur modelleren. En dient bij de onderliggende activiteiten van het ontwerpen, invoeren en beheren veel meer in acht genomen te worden dan alleen de structuur.

Spreken we over de occupatievlakken, dan zien we rond bedrijfsprocessen alleen een haast indirecte invloed van informatiekunde en ICT. Natuurlijk is de invloed van ICT en de mogelijkheden van inzet daarvan van belang bij het neerzetten van de bedrijfsproces architectuur. Maar zeker zo belangrijk zijn bijvoorbeeld de personele, culturele, juridische en logistieke aspecten. In de praktijk blijkt het daarom steeds weer de vraag of het inrichten van bedrijfsprocessen wel het werk is van informatiekundigen of zelfs ICT-ers. Daarbij dient aangetekend te worden dat specialisten op dit gebied veel voordeel en synergie kunnen realiseren als ze goed (kunnen) samenwerken met informatici.

Rond infrastructuren
In deze kolom wordt het moeilijker. Als we naar de zgn. technische infrastructuur kijken, dan klopt e.e.a. goed. We spreken dan over systeemsoftware en hardware/netwerken. Die kunnen we in beeld brengen (architectureren), we kunnen veranderingen ontwikkelen (ontwerpen), we kunnen de ontworpen veranderingen invoeren (invoeren) en we kunnen de bestaande situatie beheren (beheren). Hier natuurlijk wel weer de opmerking dat een architectuur breder is dan een model.

Het wordt moeilijker als we naar applicaties en gegevens kijken. Deze geven informatiesystemen mede gestalte, zoals in de definitie van infrastructuur staat. En dat klopt ook met de genoemde voorbeelden E-mail systemen en tekstverwerkers. Applicaties en gegevens zouden daarmee onderdeel zijn van de infrastructuur. Hier ontstaat echter een discrepantie met de kolom informatiesystemen.

Rond informatiesystemen
In deze kolom zijn problemen ontstaan. In 1997 werd hier feitelijk nog een verkapt systeemontwikkelingstraject neergezet, waarbij onder architectureren een veel bredere manier van specificeren werd gedacht. Ontwerpen was het ontwikkelen van veranderingen in de vorm van nieuwe informatiesystemen of applicaties. Deze werden daarna ingevoerd en beheerd.

We hebben de volgende vraagpunten ontdekt:

1. in de context van het VRI-model spreken we over het ontwerpen, realiseren en beheren van informatiesystemen en/of applicaties. En dat terwijl we net geconstateerd hebben dat applicaties en gegevens informatiesystemen mede gestalte geven, en daarmee onderdeel zouden zijn van de infrastructuur.
2. We beheren ingevoerde applicaties. Wat we beheren is in feite een huidige invulling van wat bij architectureren in beeld is gebracht. Beheren is daarmee een activiteit die te maken heeft met de huidige manier van implementeren. Maar met een functioneel beheer dienen we in termen van de (informatie) architectuur te spreken en niet in termen van het geïmplementeerde. Architectureren zou daarmee een ander soort beheren inhouden. Aan de andere kant spreken we ook over het beschikbaar stellen van ingevoerde oplossingen die eerder als onderdeel van de kolom infrastructuur gezien konden worden. En daarmee zouden die oplossingen natuurlijk ook in die kolom beheerd dienen te worden.

Nieuwe inzichten lijken het VRI-model / L_PASO dus toch ingehaald te hebben.

Een nieuw VRI-model / L_PASO?
Met het bovenstaande lezen blijkt de stelling juist te zijn. Wat moet nu gedaan worden om de VRI-model / L_PASO bruikbaar te maken voor het in kaart brengen van het beroepenveld? Het volgende:

1. Zorg ervoor dat wat in de kolom bedrijfsprocessen staat breder uitgelegd wordt dan wat in modellen en structuren gevangen kan worden. Dit doet recht aan wat onder een bedrijfsproces architectuur wordt verstaan.
2. Ga in discussie met andere, meestal lang gevestigde beroepsgroepen over wat bedrijfsprocessen zijn. Het is aannemelijk dat deze kolom hoogstens naast het werk van de informaticus dient te komen. Maar dan wel als een uiterst belangrijk punt van uitwisseling van ideeën en gedachten met organisaties (denk aan wat onder business alignment of strategic alignment verstaan wordt).
3. Geef applicaties en gegevens de juiste plaats in het model. Het zou logisch zijn om deze elementen uit de kolom informatiesystemen te halen en toe te voegen aan de kolom infrastructuur. Daarmee zou dan niet alleen de technische infrastructuur gestalte geven aan systemen, maar ook aan de applicaties en gegevens. En dat lijkt een logische keuze.
   Een andere mogelijkheid zou zijn om een extra kolom tussen informatiesystemen en infrastructuren te introduceren voor applicaties en gegevens. De gedachtenwereld van wie zich hier mee bezig houdt, vooral systeemontwikkelaars en applicatie- en gegevens-beheerders, is een andere dan die van de technische infrastructuur specialisten. Toch is het de vraag of in het model zo zwaar ingegrepen moet worden. Alles houdt immers verband met wat werkelijk aan organisaties ter beschikking gesteld is en wordt. En daarmee krijgt de term (informatie) infrastructuur ook gelijk een heldere betekenis.
4. De kolom informatiesystemen dient anders uitgelegd te worden. In de praktijk blijkt steeds weer dat een informatie architectuur nu eenmaal op een heel ander niveau naar informatie kijkt dan in één van de andere kolommen nodig en gewenst is. Ook daar kan je heel goed spreken over architectureren, ontwerpen, realiseren en beheren van de informatie architectuur. Beheer zal echter niet iets als applicatiebeheer (zie onder infrastructuur) zijn, maar eerder het beheer dat een informatie architect voert over een informatie architectuur (de vergelijking met functioneel beheer dringt zich terecht op). Misschien dat de naam van de kolom zelfs beter veranderd kan worden in informatie architectuur.

Er zullen meer vraagstukken zijn, maar deze duiken iedere keer weer op. Het kan voor stevige veranderingen zorgen in het VRI-model (of L_PASO). Het nodige krijgt daarmee wel een veel logischer en inzichtelijker plaats. En dat niet in de laatste plaats als de dimensie occupatievlakken toegevoegd wordt.

Ter afronding
Zoals gesteld is een discussie over het indelen van het beroepenveld van de informaticus nog steeds hard nodig. Sterker, de behoefte lijst door het ontstaan van nieuwe beroepsverenigingen steeds groter te worden. De huidige opzet en inrichting van het VRI-model / L_PASO blijkt verouderd te zijn. Het wordt dus tijd voor het aanpassen van dat model. Of voor het ontstaan van een ander model waarmee het beroepenveld wel goed en duidelijk in beeld gebracht wordt. Omdat er op dit moment geen andere modellen kandidaat zijn is het tijd om deze het VRI-model om te zetten naar bijvoorbeeld een SPITS-model. Misschien dat we daarmee die brede discussie op gang kunnen krijgen en de nodige afspraken met elkaar kunnen maken. Het zou een start kunnen zijn om beroepen te maken van wat nu vaak nog door cowboys en indianen uitgevoerd lijkt te worden.