23 juni 2021, door Menno Gülpers Blog

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 vorige blog 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 onze 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 - 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.

Meer weten?

Wil je weten wat er nog meer mogelijk is met het Blueriq platform? Neem contact op met Menno Gülpers, Academy Manager bij Blueriq. 

Plan een afspraak Bekijk profiel
Menno
Gülpers
Blueriq Academy Manager