Uit een gesprek tussen Centric en PinkRoccade is gebleken dat de manier waarop beide partijen het Zakenmagazijn geïmplementeerd hebben afwijkt. Wellicht niet erg, maar zeker opvallend. Mijn vraag is eigenlijk wat de visie is vanuit KING, gemeenten en leveranciers.
Hieronder de situatie beschreven via een eenvoudig voorbeeld:
Op het moment dat een zaak ontstaat dan heeft deze zaak bijvoorbeeld een natuurlijk persoon als initiator. Van deze persoon leg je (via een zakLk01) de identificerende gegevens vast in het magazijn, inclusief verblijfsadres gegevens.
Stel nu dat deze persoon gaat verhuizen (deze mutatie komt via een npsLk01-bericht binnen) moet je dan de gegevens in het zakenmagazijn bijwerken, of juist niet?
In de oplossing van PinkRoccade zit het Zakenmagzijn gekoppeld aan het Basisgegevensmagazijn. Dit wil zeggen dat mutaties zoals hierboven beschreven hebben direct gevolgen hebben de antwoordberichten vanuit het Zakenmagazijn.
In de oplossing van Centric is dit niet het geval (tenminste zo geeft Lidwien Meijers aan in een gesprek met mijn collega John Rooijakkers). Het Zakenmagazijn staat geheel los van het Basisgegevensmagazijn. Dit wil zeggen dat wanneer je het adres van een initiator ook in het Zakenmagazijn wilt bijwerken je dit aanvullend moet doen (via de zaakbehandelende applicatie?). Het probleem hierbij is dat je niet alle gegevens die je van een gerelateerde via ZKN-antwoordberichten kan terugkrijgen bijgewerkt kunnen worden met ZKN-kennisgevingen. Je zou in deze situatie dus ook BG-kennisgevingen moeten verwerken in het Zakenmagazijn.
Ik wil hier dus duidelijk geen voorkeur uitspreken over de oplossing van ons (PinkRoccade) of Centric, maar ik wil weten wat volgens de gemeenten in de praktijk de beste oplossing is (rekeninghoudend met dossiervorming in het zaakgericht werken).
Wellicht goed om te vermelden dat volgens de StUF 3.01 standaard:
- van een gerelateerde entiteit altijd de actuele waarde opgenomen moet worden en
- indien van deze gerelateerde een waarde op een ander tijdstip gewenst is dat dan deze entiteit als fundamenteel bevraagd moet worden.
Hier speelt een interessante functionele vraag. De insteek van Centric hierbij is dat het zakenmagazijn een afnemer is van de gegevens uit proces-/zaaksystemen. Afnemers van het zakenmagazijn kunnen deze gegevens opvragen en dan maximaal de gegevens die geleverd zijn door de proces-/zaaksystemen, deze worden niet aangevuld. Laatstgenoemde systemen zijn de bron van de gegevens en zijn dan ook verantwoordelijk voor de bijhouding ervan. De gegevens die een processysteem bij houdt zijn de gegevens die relevant zijn voor de zaak op het moment dat deze wordt afgehandeld. Na het afsluiten van de zaak is het vaak niet meer van belang om de gegevens van bijvoorbeeld gerelateerde personen bij te blijven houden. Je kunt je zelfs afvragen of dat nog wel wenselijk is.
In dat kader levert het zakenmagazijn dus geen andere gegevens dan aangeleverd door het proces-/zaaksysteem. Dit zijn de laatst bekende relevante gegevens in het processysteem. Een afnemer kan op basis daarvan desgewenst bij het gegevensmagazijn of een andere component de actuele gegevens van de gerelateerde personen (en andere objecten) opvragen.
Dit voorkomt ook dat een gebruiker van een proces-/zaaksysteem andere gegevens te zien krijgt dan de afnemer van een zakenmagazijn die dezelfde zaak bevraagt. In onze ogen is dat de correcte weergave. Feitelijk geeft ons systeem dus meer informatie terug: de informatie die geldig was op het tijdstip dat ze relevant was voor de zaak én (impliciet) een relatie naar de personen (en/of objecten) die bij de zaak betrokken waren. Op basis van die laatste kunnen de recente gegevens worden verkregen in een gegevensmagazijn.
Het feit dat StUF stelt dat de meest actuele gegevens moeten worden teruggegeven zullen wij niet betwisten. De vraag is echter wat de meest recente gegevens zouden moeten zijn. In ons geval zijn het de meest actuele gegevens zoals ze bekend zijn binnen de context van de zaak.
In hoge mate bepalend voor het antwoord op de gestelde vraag is m.i. wat het doel is van een zakenmagazijn. In de GEMMA Applicatiearchitectuur is dit een referentiecomponent met als beschrijving: "Systeem voor registratie van zaak- en daaraan gerelateerde klant- en statusgegevens. Dit systeem dient als bron om zowel interne als externe stakeholders inzicht te geven in de status en doorlooptijd van afhandeling van zaken en daarmee ook in de kwaliteit van uitvoer van het proces." M.i. zit de essentie in de tweede zin. Een zakenmagazijn geeft gegevens weer van zaken die elders worden uitgevoerd en onderhouden. Net zoals een gegevensmagazijn gegevens ontvangt en weergeeft. Leidend voor de inhoud van het zakenmagazijn zijn dan de zaakgegevens in andere applicaties. Het zakenmagazijn is volgend. Actualisering van zaakgegevens vindt plaats in andere applicaties, het zakenmagazijn ontvangt een kopie daatvan. Dat geldt m.i. ook voor gegevens van betrokkenen bij een zaak. De desbetreffende zaakapplicatie bepaalt welke waarden die gegevens hebben en verstrekt die aan het zakenmagazijn. Er zijn geen andere bronnen die tevens tot updates van het zakenmagazijn zouden leiden. Dat zou leiden tot verschillen tussen de gegevens van een zaak in een zaakbehandelende applicatie en het zakenmagazijn.
Ik zit hiermee op de lijn van Sid, lijkt mij zo. Bepalend voor deze redenering is de positionering van de referentiecomponent Zakenmagazijn in de GEMMA Applicatiearchitectuur, niet een 'toevallige' StUF-regel.