Het goed documenteren van besluiten is een belangrijk element in voortbrenging van IT binnen de overheid. Keuzes moeten achteraf traceerbaar zijn en verantwoord kunnen worden. Hoe ga je daarmee om in een wereld die enorm aan verandering onderhevig is? Door uitvoerig documenteren overbodig te maken en de applicatie voor zich te laten spreken.
Menno Gülpers ontwikkelt en geeft trainingen aan zowel klanten, partners als eigen mensen van Blueriq
Continuïteit en wendbaarheid zijn sleutelwoorden als het gaat om systemen en applicaties die binnen de overheid worden gebruikt. Op snel en vaak veranderende wet- en regelgeving moet even snel en even vaak ingespeeld kunnen worden. Denk bijvoorbeeld aan alle coronamaatregelen en het effect daarvan op de dienstverlening van overheidsorganisaties.
De entiteit Aanvrager bevat de aanvrager die de aanvraag aanvraagt
Dit zinnetje moest ik twee keer lezen, maar het stond er echt. In het veldje Description bij de entiteit Aanvrager stond bovenstaande omschrijving. Ik vroeg aan de cursist waarom hij dat gedaan had. Zijn antwoord was dat hij geleerd had om altijd goed te documenteren wat hij deed, dat was hij gewend uit zijn programmeertijd. Laten we even een stapje terug doen. Blueriq is een platform waarmee je een bepaald aandachtsgebied modelleert. De applicatie is het resultaat van dat modelleren. In een van mijn eerdere blogs vergeleek ik het met Lego bouwen: je stapelt je blokken en je bent klaar. Je hoeft er geen programmeercode overheen te gooien. Er wordt ook geen code gegenereerd. Blueriq interpreteert het model dat je gemaakt hebt en toont dat als applicatie. Moet je dan nog documenteren? Nee en Ja.
Nee, je hoeft niet te documenteren
Immers, het model is de applicatie. Dus als je (om in de Lego-analogie te blijven) een pagina-blokje hebt gemodelleerd, met daarop een blokje met een groep velden met recht op een subsidie, met bijbehorende bedrag en doorlooptijd, dan hoef je daarnaast natuurlijk niet een of ander document te maken waarin je nog eens vertelt dat dat zo gemodelleerd is. Aangezien de modellen vaak gewijzigd worden, loopt die externe documentatie meteen uit sync, dus op die manier documenteren is dan echt een last. En bovendien compleet overbodig. Omdat er behoorlijk wat onderdelen van Blueriq heel visueel zijn in ons platform, zie je op die plekken in één oogopslag wat het is. Zoals de entiteiten-relatie-diagrammen (ERD) die de structuur van het domein weergeven of de Decision Requirements Graphs (DRG) die heel mooi de samenhang tussen alle beslissingen laten zien. Daarnaast is de structuur van de applicatie (pagina’s services, flows, functies) volledig visueel, net als het proces en de ontkoppeling en samenhang in modules. En natuurlijk de beslissingen zelf. En zo kan ik nog wel even doorgaan. Er geldt in ons platform voor alle onderdelen: het model zelf is ook meteen de documentatie.
Ja, je moet wel documenteren
Maar… soms is een blokje wat ingewikkelder, of wordt het op meerdere plaatsen gebruikt, of wordt het net anders gebruikt dan je denkt, of… etc. In zulke gevallen is het een goed gebruik om in het model te documenteren waarom het blokje zo gemodelleerd is. Met bijvoorbeeld de Description. Maar daar kun je dus in doorslaan, door bij elk blokje de description in te vullen, ook als het volledig duidelijk is wat er bedoeld wordt. Dus – om in dit voorbeeld te blijven – de entiteit Aanvrager zal inderdaad gegevens bevatten van de aanvrager. Categorie NSS. Maar als ik een entiteit ExternPersoon in een model tegenkom, ben ik als startende business engineer op dat project wel blij dat in de description even uitgelegd is dat dat de persoon is, waar het restant-saldo naartoe wordt overgemaakt, indien de bankrekening van de persoon die onder bewind komt te staan, opgeheven wordt.
Maar ik wil toch de volledige documentatie
Die cursist die geleerd had alles te documenteren, heb ik ook de mogelijkheid laten zien dat Blueriq zelf zijn eigen documentatie kan genereren, met een druk op de knop. Het hele model, inclusief alle visualisaties, komt er dan als een lijvig document uitrollen. Dat vond hij wel mooi. Maar zag wel ook meteen dat dat document precies hetzelfde is als de applicatie. En morgen weer achterhaald.
Kortom, het documenteren van modelleerkeuzes is belangrijk. Maar nog belangrijker is het creëren van een wendbare oplossing die de continuïteit van een goede, persoonlijke en efficiënte dienstverlening borgt. Daar draait het allemaal om.
Menno Gülpers is Academy manager en docent bij Blueriq
