Frequently Changed Parameters

Ach, wij it-ers houden wel van afkortingen, vooral die van de drieletterige soort, dus hier een nieuwe: FCP. Hoe kwam ik erop?

Reflecterend met een organisatie over de zin en onzin van flexibele informatiesystemen, moest ik de band een paar decennia terugspoelen en opnieuw afspelen om het een en ander in het juiste perspectief te zien. Vroeger, als je een wijziging in een applicatie wilde aanbrengen, moest je een programmeur inschakelen. Je kent de stereotype programmeur wel: sterk analytisch karakter, slordig uiterlijk, sociaal onbeholpen, smalle en intense interesses en een eigenaardig letterlijke manier van het interpreteren van woord en geschrift. Kunnen verdomd goed programmeren. Maar goed, zo’n programmeringstraject is relatief duur en duurt lang. Zeker nu ervaar je het als lang want de wereld draait steeds sneller rond en wijzigingen op wijzigingen stapelen zich op. Wijzigingen in de markt waarin je opereert. Wijzigingen in de diensten die je biedt. Wijzigingen in de bedrijfsprocessen. En uiteindelijk wijzigingen in de ondersteunende informatievoorziening en informatiesystemen.

Maar gelukkig komen er steeds meer applicaties op de markt waarin het als gebruiker mogelijk is, dus zonder tussenkomst van zo’n dure en onhandige programmeur, om de functionaliteit te veranderen. Business rule driven, heet dat vaak. De belastingwetgeving verandert en je hoeft maar een paar regels te veranderen en klaar is Jan Kees. Klinkt simpel maar een adder schuilt onder de regels. Overziet de regelveranderaar wel de gevolgen van een ogenschijnlijk onschuldige wijziging? Heeft-ie voldoende overzicht over de vaak complexe samenhang der regels? Het is te vergelijken met een complexe spreadsheet: een formule aanpassen is zo gebeurd maar werkt de spreadsheet nog naar behoren? In feite moet de regelveranderaar net zo analytisch zijn als de programmeur. Misschien wel meer, omdat hij op een hogere abstractieniveau acteert. Ga dus voorzichtig om met deze mooie moderne mogelijkheden.

Zoals er vaker gebeurt, is er een gulden middenweg tussen geprogrammeerde wijzigingen en wijzigingen met business rules. Sta stil bij de wijzigingen die op je afkomen en identificeer de soorten die zich lenen voor wijzigingen door gebruikers. Zodoende ontstaat een lijst van frequently changed parameters met een aanvaardbaar risicoprofiel. Maak daarvan een gebruiksvriendelijke scherm en spreek voor de andere soorten wijzigingen een strakker gecontroleerde procedure af.

Naar mate wij steeds meer applicaties uit kleinere applicaties samenstellen, bijvoorbeeld op basis van Software as a Service, zal het belangrijker worden dat iemand het hele landschap overziet en dat er afspraken zijn over wie wat wijzigt. Het lijkt wellicht overdreven, deze wijze van IT Governance, maar anders wordt het gauw een janboel.