Begrippenkader: van concern naar afgebakend besluit

Een infrastructuurarchitect begint niet bij een product, maar bij een concern: een belang of zorgpunt van een stakeholder. De arts wil een dossierhandeling tijdig kunnen afronden, de directie wil de kelder verlaten, de CISO wil ongeoorloofde toegang voorkomen en beheer wil een omgeving die aantoonbaar bedienbaar is. Deze concerns kunnen hetzelfde systeem raken, maar vragen niet automatisch hetzelfde besluit.

Het systeem van interesse is het geheel dat u voor één besluit onderzoekt. De systeemgrens bepaalt wat u daarin meeneemt en wat als externe afhankelijkheid wordt behandeld. Een grens is geen natuurgegeven. Zij is bruikbaar wanneer zij past bij de beslisvraag, verantwoordelijkheden zichtbaar maakt en voorkomt dat een oorzaak buiten beeld valt. Voor de EPD-beschikbaarheid kan het systeem van interesse het volledige artsenpad omvatten; voor de kelderverhuizing kan de fysieke huisvesting centraal staan. Beide views zijn geldig, mits scope, grens en doel expliciet zijn.

Houd zes begrippen uit elkaar. Een requirement beschrijft een benodigde en toetsbare uitkomst. Een constraint begrenst de oplossingsruimte, bijvoorbeeld een bevestigde einddatum of bindend beleid. Een aanname is tijdelijk als waar behandeld en moet worden gevalideerd. Een feit is herleidbaar tot casus, meting of bron. Een Onbekende is informatie die nog ontbreekt. Een oplossing is pas een kandidaat nadat deze vijf zichtbaar zijn. Een wens als ‘altijd beschikbaar’ is dus nog geen requirement: meetpunt, conditie, grens en eigenaar ontbreken.

In deze cursus gebruikt u voor ieder materieel besluit dezelfde acht velden: (1) context en concern; (2) systeem van interesse, scope en grens; (3) feiten en Onbekenden; (4) requirements, constraints en aannames; (5) serieuze alternatieven, inclusief niets-doen waar dat werkelijk mogelijk is; (6) criteria en bewijs; (7) voorkeur, besliseigenaar en voorwaarden; (8) consequenties en herijkmoment. Het model is een werkmethode van deze cursus, geen garantie dat het besluit vanzelf juist wordt.

Uitgewerkt voorbeeld — twee vragen scheiden. De ambitie van Brandaris bevat ‘één dossier, overal beschikbaar’ én ‘het rekencentrum uit de kelder binnen drie jaar’. De eerste vraag gaat over een gebruikersdienst en haar keten; de tweede over huisvesting en migratie. Dezelfde oplossing kan beide raken, maar samenvoegen zou verschillen in stakeholder, bewijs en acceptatie verbergen.

Voor de dossierdienst is het concern dat een arts een noodzakelijke dossierhandeling kan afronden. Feiten zijn onder meer de drie locaties en de geregistreerde incidenttypen. Onbekend zijn de bevestigde uitvalgrens, de gemeten gebruikersprestatie en de impact per verstoring. Mogelijke alternatieven zijn oorzaken verminderen, herstel versnellen, afhankelijkheden scheiden of locatieredundantie toevoegen. De directie of aangewezen risico-eigenaar bevestigt de risicogrens; de architect maakt gevolgen en bewijs zichtbaar.

Voor de kelderverhuizing is de bevestigde termijn een constraint wanneer de bevoegde eigenaar die als harde grens vastlegt. De inhoud van de brandbevindingen, beschikbare investering en gewenste sourcingvorm zijn Onbekenden. De consequentie van deze afbakening is dat twee samenhangende besluitrecords ontstaan, met een expliciete afhankelijkheid tussen beide. Zo voorkomt u dat één technisch project stilzwijgend twee bestuurlijke besluiten neemt.

Werk voor de Brandaris-ambitie één concern, systeemgrens, requirement, constraint, aanname en Onbekende uit. Leg daarna uit waarom dit nog geen technische oplossing kiest.