Blog

Pleidooi voor grondige architectuurreview mGBA en BZS-K

Het overheidsprogramma modernisering GBA (mGBA / BRP) maakt de Basisregistratie Personen gereed voor de toekomst. Dit programma is ooit rond 2002 opgestart, en gaat zijn tiende verjaardag binnenkort vieren.

Onlangs, medio 2010, is naar aanleiding van een Gateway review door een minister het beeld gegeven aan de tweede kamer dat alle seinen op groen staan voor een succes. Echter als naar gebruikers en betrokken leveranciers wordt geluisterd, als de projectdocumenten op inhoud worden beoordeeld, ontstaat er een heel ander beeld.  Dat beeld doet vermoeden dat een succes van dit programma niet gegarandeerd is. Zeker ook gezien het feit dat er een innovatieve informatiesysteemarchitectuur wordt gebruikt : Een Kernapplicatie die door de overheid wordt ontwikkeld met Aanvullende Modules die door de 'markt' worden ontwikkeld. Dus er is wellicht geen garantie op succes, en dat terwijl het programma mGBA de samenleving waarschijnlijk al enkele tientallen miljoenen euro's heeft gekost.

Deze blog is een pleidooi voor een grondige architectuurreview van het programma mGBA en als onderdeel daarvan het burgerzakensysteem (BZS-K). Deze blog is zeker niet kort en bevat ook specialistische inhoud. Maar voor menig professional zal na het lezen van deze blog duidelijker worden, dat er snel verbetering dient te komen in de mijlpalen van dit programma mGBA.

Waarom deze blog?

Het doel van deze blog is om de betrokkenen (zoals stuurgroep en opdrachtgever) van de modernisering van de GBA (mGBA) en de ontwikkeling van het burgerzakensysteem (BZS-K) er toe te bewegen de mijlpalen PLAN, EISEN, ARCHITECTUUR en ONTWERP in hun samenhang en afhankelijkheid, consistentie en volledigheid grondig te reviewen en deze mijlpalen kwalitatief op een hoger niveau te krijgen aan de hand van verbetervoorstellen en maatregelen nav de nog te houden review.

In het kort wat zou dienen te gebeuren: de inhoud van de mijlpalen PLAN, EISEN, ARCHITECTUUR en ONTWERP van mGBA en BZS-K horen op een hoger kwaliteitsniveau te worden gebracht, zodat ze elkaar meer aan vullen dan nu het geval is: nu zijn ze een 100% overlap en een detailleringslag van elkaar. Een inhoudelijke kwaliteitsverbetering van mijlpalen komt het realiseren van een mGBA en BZS-K, dat voldoet aan de eisen en verwachtingen van belanghebbenden, zoals gemeentelijke gebruikers, zeer ten goede.

Laten we bijvoorbeeld alleen al maar even stil staan bij hoelang het programma mGBA al loopt en wanneer men al sprak over het ontwikkelen van een BZS-K. Uit het technische architectuur op hoofdlijnendocument genaamd ‘De Rapportage’, van 20 nov 2006 voor de stuurgroep mGBA blijkt, dat in 2002 al werd gestudeerd op de architectuur de mGBA en dat in 2004 al is besloten om gemeenten te voorzien van een burgerzakensysteem. Het is inmiddels 2010 (al jaren later) en nog steeds is men bezig met eisen, architectuur en ontwerp van mGBA en BZS-K. Daarnaast staan in dat technisch architectuurdocument van 2006 veel zaken die ook in de documentatie staat uit 2010. Dus de vraag komt dan naar boven: wanneer is de modernisering van de mGBA klaar en wanneer beschikken gemeenten over het in 2004 beloofde burgerzakensysteem?

Alleen al deze lengte van programma’s en projecten maakt dat het legitiem is om zeer kritisch naar de inhoudelijkheid van de eisen-, architectuur- en ontwerpdocumenten te kijken. Immers: de tijd gaat, zoals iedereen weet, snel, en alles verandert continu!

Overigens, hoeveel zou een dergelijk programma dat bijna tien jaar loopt kosten?

Wat is de aanleiding van deze blog?

Uit verschillende informatie bijeenkomsten over de modernisering van het GBA (mGBA), lees het artikel van Alfred Zebregs over de informatiebijeenkomst op 14 januari 2010 in Utrecht, blijkt dat er de nodige onduidelijkheden zijn en ontevredenheid bestaat over het mGBA. Bijvoorbeeld dat er geen overzichtelijke visualisaties worden gebruikt om samenhang en afhankelijkheid meer helder te maken van het mGBA en BZS-K. Dit terwijl de aanpak onder architectuur juist voor inzicht en overzicht in samenhang en afhankelijkheid moet zorgen. Dit zette mij, als Visual Enterprise Architect, aan tot het grondiger bekijken van de publiek beschikbare projectdocumentatie van mGBA, BRP-Stelsel, RNI, GBA-V en de gepubliceerde PSA van het BZS-K. Dit soort afkortingen overigens, die de overheid gebruikt, maakt het juist allemaal niet eenvoudiger om de materie snel tot je te nemen en te toetsen of alles consistent en juist is.

Een architect dient, als hij een onregelmatigheid waarneemt in een programma of project (waarin onder architectuur gewerkt wordt) daar altijd melding van te maken. Een gedragscode voor architecten zou overigens hier aan kunnen bijdragen in het vakgebied van enterprise architectuur. Het is namelijk de taak van de architect om te waken over en bij te dragen aan hoogwaardige kwalitatieve ontwikkeling en realisatie van systemen. Daar hoort bij om de mijlpalen zoals PLAN, EISEN, ARCHITECTUUR en ONTWERP altijd te toetsen aan bruikbaar, begrijpelijkheid, legitimiteit, volledigheid, consistentie, herleidbaarheid, etc... Zo ook PLAN, EISEN, ARCHITECTUUR en ONTWERP van het mGBA en burgerzakensysteem dat momenteel in ontwikkeling is.

De documentquickscan /  architectuurreview

De website van het programma mGBA (modernisering GBA), http://www.moderniseringgba.nl/, heeft op een overzichtelijke wijze belangrijke documenten gepubliceerd, zoals ook door een gateway review is vastgesteld. Deze documenten geven inzage in het proces en producten van het mGBA en Burgerzakensysteem. (BZS-K)

Een dergelijk burgerzaken systeem, zal voor velen onbetwistbaar, niet zonder architectuur zijn te ontwerpen, te realiseren en succesvol te implementeren.
Uiteindelijk willen Nederlanders dat de overheid voor een goede afhandeling zorgt van burgerzaken. Dat de overheid hier een informatiesysteem voor maakt, voor 100% gemaakt in open source, dat snappen en willen nog steeds een hoop mensen. Hoewel hier al veel mensen zullen denken: bestaat er al niet zo een systeem.

Een scan van de mGBA- en BZS-K-documenten levert een tal van feiten en bevindingen op die een beeld van zorg creëren bij mij, als Visual Enterprise Architect. Deze zorgpunten blijken evenwel niet uit de mij beschikbare informatie over de gateway review die medio 2010 is uitgevoerd en die aan de tweede kamer is overlegd. Het is daarom dat ik de zorgpunten onder de aandacht wil brengen bij de belanghebbenden van mGBA en BZS-K.

Feiten en bevindingen

Hierna volgt een hele korte opsomming van enkele opmerkelijke feiten en bevindingen naar aanleiding van een quickscan van deze documenten. Daarbij dient te worden rekening gehouden met het feit dat de documenten op de website van het mGBA de enige bron van informatie waren hiervoor.

  1. In de verschillende documenten die opeenvolgend zijn in het systeemontwikkelingsproces, zoals definitiestudie, architectuur en ontwerp, staan dezelfde zaken vermeld over en weer.
       a. In het eisen document staan vele architectuur- en ontwerpaspecten
       b. In het architectuurdocument staan vele eisen- en ontwerpaspecten
       c. In een ontwerpdocument staan vele eisen- en architectuuraspecten
    Als alle gegevens in alle documenten staan, is het lastig om de bron te herkennen van een gegeven en de impact van het ene document (als input) voor het andere document. Een wijziging in gegevens over eisen, ontwerpbeslissingen en architectuurprincipes is dan ook lastig consistent door te voeren qua impact in ontwerp en architectuur. En vice versa.
    Wat is dan wel het verschil tussen de bestaande eisen, architectuur en ontwerp documenten? In de documenten zien we, hoe verder we in de tijd komen, een steeds hogere mate van detail van de onderwerpen die aan bod komen. Overigens staan in het eisen document generieke digitale overheidsproducten genoemd, die inmiddels andere namen hebben gekregen.
    In het architectuurdocument staat bijvoorbeeld ook letterlijk dat het een levende aanvulling is op het eisen document. Uit welke praktijk of studie blijkt dat dit een correcte of succesvolle aanpak is?
     
  2. In het definitiestudie-mGBA document staan eisen in de vorm van wensen, maar ook in de vorm van standaarden en principes geformuleerd. De eisen zijn niet opgedeeld in uitgangspunten, doelen, randvoorwaarden en eisen. Ook zijn eisen niet opgedeeld in kwaliteitseisen en prestatie-eisen. Ook zijn eisen niet hard gekoppeld aan belanghebbenden of prioriteit. De principes uit een referentie architectuur zijn overgenomen als eisen. Maar principes zijn volgens mij heel iets anders dan eisen! De context, omgeving en grens van de systeemoplossing die er dient te, komen is niet scherp gedefinieerd. Begrippen als GBA-stelsel, GBA, GBA-systemen, GBA-v, BRP, RNI, BRP-stelsel en BZS-K staan onduidelijk ten opzichte van elkaar geformuleerd en gedefinieerd. Er wordt een innovatieve kernsysteem-en-aanvullende-modulen-ontwikkelwijze geïntroduceerd, die niet van veel nadere toelichting wordt voorzien (waaronder bewezen aanpak en best practices). Een visualisatie van deze ontwikkelaanpak zou op zijn plaats zijn. De wijze waarop de eisen zijn gedocumenteerd en worden gepresenteerd maakt het lastig om gecontroleerd en gefaseerd een ontwerp te maken van het geheel en idem dito voor het realiseren van een oplossing die voldoet aan de gestelde eisen. De eisen geven vervolgens ook veel ruimte voor interpretatie. Ze zijn niet SMART geformuleerd en niet op een schaal weergegeven van wens naar eis. De eisen in het eisen document gaan veel over technisch ontwerp en technisch realisatie van een moderner GBA en te weinig over de kwaliteit en functies van een moderner GBA. Het eisen document is in feite overwegend een warrig logisch ontwerp en technisch specificatie document van de oplossing. Uit welke praktijk of studie blijkt dat deze aanpak omtrent eisen een correcte of succesvolle aanpak is?
     
  3. Het programma start architectuurdocument mGBA is, zoals wordt gesteld in het document, een aanvulling op het eisen document. In het architectuurdocument ontbreekt echter een heldere scheiding tussen het conceptuele, logische en fysieke beschouwingsniveau van de oplossing. Er is geen inzichtelijk en helder onderscheid te maken tussen een gestelde functionele prestatie-eis danwel kwaliteitseisen en de daarbij gekozen (vorm)technische oplossing. In het architectuurdocument staan weinig tot geen verkenningen van scenario’s op verschillende oplossingsrichtingen. Er wordt niet of nauwelijks verwezen naar voorbeeld praktijken waarin voorgestelde oplossingen al naar behoren werken, ter onderbouwing van de realiseerbaarheid van de voorgestelde oplossingen. De wijze waarop teksten in het Programma Start Architectuur document staan geformuleerd is verwarrend. Uit de zinnen blijkt niet of iets moet, mag, kan of gaat gebeuren. Voor gebruikers van dit document is het lastig daarmee om te zien wat nu echt moet, mag, kan of gaat gebeuren. De aannames in het document zijn niet expliciet gedocumenteerd. Het document toont vele fragmenten en aspect uitwerkingen, maar toont niet voldoende de aspecten in een geheel in samenhang en afhankelijkheid. Het programma start architectuur document kan vele malen korter dan bijna 100 pagina’s die het nu is, als de eisen in het eisen document komen te staan, de functioneel ontwerpaspecten in het functioneel ontwerp document en de technische ontwerpaspecten in het technische ontwerp document komen te staan. De totaaloverzichtsvisualisatie in het architectuurdocument toont een kennelijk geheel waarbij niet te toetsen is of GBA, RNI, BRP en BZS-K conform definities hier staan weergegeven. De architectuur van BZS-K en GBA-V staan in deze visualisatie niet aangezet of uitgewerkt. Deze visualisatie toont conceptueel, logisch, fysiek en productniveau door elkaar heen. Het nadeel hiervan is onder andere dat bij ontwerp en realisatie van een systeem bepaalde keuzes en afhankelijkheid naar leveranciers en technologie toe te vroeg wordt genomen. Ook de onderbouwing van de keuze voor een technologie, productoplossingen en leveranciers in het licht van gestelde eisen is door het ontbreken van de scheiding in abstractieniveaus lastig te maken. Het bevreemd mij dat er geen solution architectuur wordt gemaakt van het gehele mGBA, maar wel een Programma Start Architectuur, iets dat niet een best practice in de huidige ICT-branche. Een Project start architectuur, waar de programma start architectuur naar alle waarschijnlijkheid op is gestoeld, is volgens de literatuur geen solution architectuur.
     
  4. Er is geen totaal overkoepelend detail functioneel ontwerp of detail technisch ontwerp gemaakt of in de maak van de gehele mGBA en BZS. Het logisch ontwerp gaat over slecht een deel van en te realiseren oplossing. Er ontbreekt een A0-formaat bouwplaat / overzichtsplaat met detailinvullingen in de domeinen van het geheel, zeg maar de keten of enterprise blueprint van het mGBA en burgerzakensysteem. Die zou dan vervolgens te projecteren zijn op een pure conceptuele overzichtsplaat, maar ook die komt niet voor in het architectuurdocument.
     
  5. De Project Start Architectuur van het BZS-K systeem is nog niet gepubliceerd dd 25 okt 2010. De presentaties over de het BZS-K systeem maken mij nieuwsgierig naar de architectuurvisualisaties die in het document zouden horen te staan. Op de Dragon1 WIKI (wiki.dragon1.com) staat een overzicht van de noodzakelijke modellen in een PXA (de presentatie die een PSA voorziet van beelden). Waar ik benieuwd naar ben is welke impact modellen er al zijn gemaakt in het project, om ver genoeg van te voren eventuele showstoppers te identificeren en weg te nemen. Het programma start architectuur document van mGBA doet mij vermoeden dat vele impact-visualisaties er niet in zullen staan. Het bevreemd mij dat er geen solution architectuur wordt gemaakt van het BZS-K, maar wel een Project Start Architectuur. Een PSA is  volgens de literatuur geen solution architectuur.
     
  6. In de documentatie van het mGBA staan uitspraken gelabeld als principes, terwijl de uitspraken in feite ontwerpregels zijn, highlevel requirement (eisen) of strategische uitgangspunten. Deze foutief gelabelde principes zijn overgenomen uit NORA en staan ook in beleidsnotities of strategiedocumenten, maar dan onder een ander label. De echte principes (van het mGBA en BZS-K) die aanduiden op welke wijze de concepten in de architectuur werken en resultaten produceren, staan echter niet of nauwelijks in de documentatie. Zo is moeilijk vast te stellen welke problemen er nu zijn met het huidige GBA complex van systemen, en hoe en waarom de problemen er straks niet meer zijn, vanwege de inzet van bepaalde oplossingen.
     
  7. Het valt mij op dat er, in deze tijd van vele beveiligingsincidenten, geen security architectuur is gemaakt voor de mGBA of BZS-K oplossing. Ook vormen specifieke security-architectuurprincipes geen integraal onderdeel van de opstelde architectuur voor het mGBA en BZS-K.
     
  8. Welke systeemontwikkelingsaanpak is en wordt gehanteerd bij mGBA en BZS-K? Als ik kijk naar de fasering en mijlpalen in de documentatie lijkt het veel op een SDM-achtige systeemontwikkelingsaanpak hier en daar hedendaags gemaakt met agile en architectuur accenten. Velen zijn het erover eens dat de personen die een systeem dienen te ontwikkelen niet en passent ook een systeemontwikkelingsaanpak moeten ontwikkelen. Tijdens een spel pas je niet de spelregels aan. Voor de beheersbaarheid van de systeemontwikkeling van dergelijke belangrijke systemen voor de Nederlandse samenleving is in mijn ogen een strak regime qua ontwikkelaanpak op zijn plaats, anders dan dat ik nu qua gevoel krijg bij de huidige aanpak van mGBA en BZS-K.
     
  9. Het wordt mij onvoldoende helder na het doornemen van de documentatie op de mGBA website, wie de opdrachtgever, gedelegeerde opdrachtgevers en primaire belanghebbenden precies zijn, wat het probleem is dat met de oplossing (mGBA en BZS-K) dient te worden opgelost, hoe deze oplossing qua werking (principes) het probleem wegneemt, en hoe straks door de opdrachtgever is vast te stellen dat de oplossing heeft geleidt tot het voldoende wegnemen van problemen. Omdat het mGBA programma zo groot is en lang duurt, zijn veel uitvoerenden bezig met het ontwikkelen en realiseren van deeloplossingen, waarbij hun deel-oplossing-opdrachtgever ver weg staat van de opdrachtgever van het programma. Dit kan, en ik benadruk KAN, tot gevolg hebben dat bepaalde middelen en doel op zich worden. Daarom is veel meer helderheid zeer gewenst.

 

Samenvatting en conclusie

De modernisering van het mGBA en de ontwikkeling van het BZS-K lijkt ingewikkelder dan nodig te worden opgepakt en op een kwalitatief lager niveau dan nodig is.

Het stellen van eisen, het maken van een architectuur, ontwerp en het doen van realisatie dienen voldoende te zijn gescheiden van elkaar (qua mensen, proces en inhoud). Bij de quickscan van de mGBA en BZS-K documentatie blijkt dat dit alles onvoldoende helder het geval is.

De belangrijkste mijlpalen zoals PLAN, EISEN, ARCHITECTUUR en ONTWERP van het mGBA-programma en van het BZS-K-project horen elkaar veel meer dan nu het geval is aan te vullen, in plaats van een 100% overlap en een detailleringslag van elkaar te zijn. Dit komt het realiseren van een mGBA en BZS-K dat voldoet aan de eisen en verwachtingen van belanghebbenden, zoals gemeentelijke gebruikers, zeer ten goede.

Project start architecturen zijn nog geen wondermiddel gebleken, en zouden dan ook beter niet gebruikt dienen te worden om gebrek aan eisen en ontwerp goed te maken. Een project start architectuur mag al helemaal niet worden ingezet, zoals nu wel gebeurt, in plaats van een ontwerp of in plaats van een solution architectuur.

In de huidige tijd van beschikbare en werkende open source oplossingen en verregaande instelbaarheid van standaard applicaties en pakketten, doet de vraag zich voor: welke alternatieven zijn er en hoe goed zijn deze onderzocht, om veel minder dan nu het geval is, alles in het kader van mGBA opnieuw te gaan en te laten ontwikkelen? En waarom is er niet voor een twee-sporen of drie sporen beleid gekozen: Zodat de eerste en de beste gaat winnen?

Alles wat ik met deze blog beoog is niet meer dan te pleiten voor een grondige architectuurreview voor het mGBA en BZS-K. In de brief aan de tweede kamer, betreffende de gateway review van mGBA, wordt overigens ook een review voorgesteld. Daar sluit ik mij dus bij aan, alleen stel ik wel voor om niet het proces te reviewen, maar de inhoud!

PS: Ik ontvang graag reacties op naam in de vorm van opmerkingen die mij helpen de feiten, bevindingen en conclusies in dit pleidooi sterker te maken.

Deze blog is geschreven door Mark Paauwe. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

 
Reacties
Ad Gerrits op maandag 1 november 2010 1:06

Als niet-project-modernisering-gba-kenner kan ik niet al je opmerkingen op hun waarde beoordelen. Net als veel anderen verbaast het me natuurlijk ook dat het hele traject al zo lang heeft geduurd (dit terwijl de GBA al vanaf de jaren 90 in veel opzichten een voorbeeldsysteem is). Het geeft de indruk dat er (zoals zo vaak) teveel hooi op de vork ligt waardoor het alsmaar voortgaat en er geen tussentijdse bruikbare producten worden opleverd. Zonder waardeoordeel bekruipt me bij jouw voorstellen toch ook het gevoel dat er weer extra tijd gestoken gaat worden in nog beter gaan bedenken en voorbereiden. Dit, terwijl gemeenten en marktpartijen vooral willen dat er zsm concreet bruikbare producten komen, zelfs als die niet van uberkwaliteit zijn. Dus: minder ambitieus, eenvoudiger en inzetbare producten. Kreeg ik als opdrachtgever die garanties niet dan ging bij mij de stekker er uit.

Mark Paauwe op maandag 1 november 2010 12:43

Precies Ad: Sense en simplicity - dat heeft de modernisering GBA nodig!
Op 1 punt na, kan ik kan me echt helemaal vinden in je aanvullende opmerkingen.

Ik vind het echt onbegrijpelijk dat de modernisering van GBA doorgang mag vinden terwijl de eisen verward zijn met het ontwerp. Die verwarring alleen al is voor mij de druppel...

In de planning gaan ze overigens nog gewoon jaren door met ontwikkelen. Dan is het toch niet teveel gevraagd om parallel daaraan de eisen scherper op papier te zetten. Als was het maar om te kunnen testen of wat opgeleverd wordt voldoet aan de eisen. En daar zijn de geformuleerde eisen nu volgens mij niet goed genoeg geschikt voor.

Het punt waar ik niet helemaal in mee ga is je opmerking over mijn voorstellen. Dit GBA programma dient hele goede en strakke mijlpalen te hebben voor PLAN, EISEN, ARCHITECTUUR en ONTWERP. Volledig ontward en professioneel hoog niveau. Ik wil helemaal NIET dat er iets nieuws wordt bedacht. Maar ik wil WEL dat wat men al heeft bedacht succesvol kan worden gerealiseerd en in gebruik worden genomen. Conform verdere planning en budget.

Elke dag dat het programma verder doorsukkelt zonder dat de mijlpalen strak en professioneel zijn, is iets dat jij toch ook niet zou moeten willen accepteren!

Bart Claassen op dinsdag 2 november 2010 12:06

Ondertussen heb ik de gelegenheid genomen om zelf ook eens rond te snuffelen in de documentatie van mGBA en BZS-K. Het is mij persoonlijk niet duidelijk geworden wat er nu gebouwd moet worden en volgens welke eisen, principes of waren het nu richtlijnen? Er is veel geschreven, veel van het zelfde, net iets anders geformuleerd, niet eenduidig, verschillende terminologien welke ook door elkaar worden gebruikt, in verschillende type documenten.

Ben ik dan verbaasd nee en ja! Nee, want ik herken bepaalde valkuilen ook bij andere organisaties. Ja, want men geeft de indruk dat de tijdsduur van dit project geen reden tot zorg is.

Organisaties kunnen het zichzelf enorm moeilijk maken, zonder dat dit nodig is. Ik ben het in die zin eens dat er niet iets nieuws moet komen. Wel moet er veel meer duidelijkheid komen over het WAT! Het kan niet zo zijn dat dit het resultaat na bijna 10 jaar!

Mark Paauwe op woensdag 3 november 2010 9:51

'Dit geloof je toch niet. Dat de modernisering van de GBA zo tijd- en geldverslindend wordt opgepakt', is één van de e-mails die ik heb gekregen naar aanleiding van deze blog-pleidooi.

Oke. Stellen we dan nu met elkaar vast dat de modernisering GBA een tijd en geldverslindend project is? Maar hoe nu verder? Hoe krijgen we het voor elkaar dat de mijlpalen professioneel worden gemaakt, zodat er meer garantie op succes is?

Wellicht zijn er nog meer voorbeelden nodig die laten zien wat er allemaal (is) gebeurt: Omdat mensen dus blijkbaar niet geloven hoe miljoenen euro’s zijn uitgegeven om een programma in de ‘startfase’ te krijgen, met ‘alle opties voor iedereen nog open’.

Een voorbeeld dan: Uit een artikel met Cees Meesters (voorzitter NVVB) blijkt dat het programma volgens kenners (Gateway Review) zich pas in de startfase bevind. Het project heeft al vele, vele miljoenen euro's gekost, gezien de opgave van businesas case kosten in het artikel. En dat nog steeds belangrijke ontwerpbeslissingen (aangaande de systematiek van het ontwikkelen van aanvullende modulen) niet zijn genomen. En wat in dit artikel staat, is nog niet eens integraal in de officiële documenten doorgevoerd. Ook zijn eisen aangaande het burgerzakensysteem nog steeds niet definitief zijn. En ga zo maar door als je het artikel leest.

Download hier het artikel met Cees Meesters: http://www.nvvb.nl/websites/common/download.asp?PropId=1206

Heel markant is deze opmerking in het artikel: 'In het denkproces over een moderne GBA werd al snel duidelijk dat een compleet standaardpakket, waar zowel de grootste als de kleinste gemeente mee uit de voeten kan, onhaalbaar is; niet te realiseren.'. Dan zeg ik: welke eisen hebben hier ten grondslag gelegen en waar tref ik in de architectuur aan dat deze afweging is gemaakt. Ik ken genoeg schaalbare (clouded) open source software applicaties.

En het zijn precies de opmerkingen in het artikel die laten zien hoe erg het is dat de mijlpalen zoals EISEN, ARCHITECTUUR en ONTWERP met elkaar verward zijn.

De onrust bij gemeenten is denk ik ook daarop terug te voeren: Als de gemeenten als grote belanghebbenden van het burgerzaken systeem zoveel onduidelijkheid constateren, dan vinden zij in onvoldoende mate hun eisen, uitgangspunten, randvoorwaarden en doelen terug in het programma van eisen, en ze vinden in het ontwerp in onvoldoende mate het beantwoorden van hun eisen terug.

Als mensen het niet snappen of zich kunnen vinden in een bepaalde opdeling in een oplossing, leg dit dan uit aan de hand van gestelde eisen door een groep belanghebbenden, zou ik zeggen.

Wat ik echter proef, bijvoorbeeld in het artikel Met Cees Meesters, is dat de architecten en ontwerpers van het mGBA niet opnieuw naar de EISEN en het ONTWERP kijken samen met de belanghebbenden, maar dat ze opnieuw proberen uit te leggen dat wat er ligt goed is. En waar kennen we deze houding ook alweer van?

Bezoeken van mij van deze week bij overheidsorganisatie leveren geluiden op dat er een rommeltje van wordt gemaakt in het mGBA, maar nog steeds lijkt het alsof niemand er iets aan doet.

Dus ik blijf het zeggen: maak de mijlpalen EISEN, ARCHITECTUUR, ONTWERP professioneler en ontvlecht ze, omdat ze nu met elkaar verward zijn. Dat is inhoudelijk gezien altijd een begaanbaar pad in een lopend project.

Henri Koppen op vrijdag 8 november 2013 10:09

Toeval? Deze link is dood : https://www.nvvb.nl/websites/common/download.asp?PropId=1206

Wat ik ook overigens al plaatste bij dit artikel van rene veldwijk : http://www.computable.nl/artikel/opinie/overheid/4920613/1277202/de-over...

Ik heb geen idee wat de mGBA is, iets met persoonsgevens vastleggen en wat processen mbt nieuwe wereldburgers en hun relaties. Maar heel moeilijk kan dat niet zijn, en in de basis gelden die regels landelijk, dus laten we allen hetzelfde systeem gebruiken.

Er is maar één wet die geldt en die is van John Gall : "A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system."

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.