6. Van probleem naar eerste architectuurnotitie

Maak voor Aurora een korte notitie met probleem, scope, stakeholders, twee samenhangende perspectieven en eerste onderzoeksvragen. Gebruik alleen de fictieve casusfeiten; verzin geen doorlooptijden of oorzaken.

Een zwakke notitie bevat alleen ‘we hebben betere IT nodig’. Dat kiest een oplossing voordat probleem en oorzaak zijn onderzocht. Een andere zwakke notitie wil alle enterprise-modellen volledig uitwerken voordat één gerichte vraag mag worden onderzocht. Beide missen proportionaliteit.

Feedbackregel. Staat een storing of meting niet in de casus, presenteer haar dan als hypothese of open onderzoeksvraag. Schrijf bijvoorbeeld te onderzoeken: wachttijd tussen besluit en uitleg, niet de backoffice veroorzaakt de vertraging.

Minimale structuur van de notitie

Open met één probleemzin die het ontbrekende resultaat beschrijft. Baken daarna de enterprisecontext af: welke delen van Aurora en welke externe relaties zijn nodig om deze vraag te beantwoorden? Verbind iedere stakeholder aan een concreet concern en kies per concern een view die een benoemd besluit ondersteunt. Sluit af met onderzoeksvragen, aannames en de eerstvolgende bewijsactie.

Kwaliteitscontrole. Laat een collega alleen de probleemzin, scope en onderzoeksvragen lezen. Kan diegene daaruit afleiden waarom de architectuurverkenning nodig is zonder al een oplossing te moeten aannemen? Zo niet, maak de redenering scherper voordat je modellen toevoegt.