Een onderzoeksrapport uit 2008 dat in handen kwam van actualiteitenprogramma EenVandaag geeft een heldere inkijk in het politiesysteem BVH vanuit de optiek van de softwarebroncode en documentatie. Op basis van een objectieve methodiek wordt een uitdrukkelijk kritisch oordeel geveld, dat op z'n minst tot heroverwegingen van de architectuur en implementatie van het systeem hadden moeten leiden. De opvolgende alsnog voortgezette invoering en beproeving van een als 'wankel en kwetsbaar' beoordeeld systeem in de praktijk is feitelijk vragen om problemen.
Actualiteitenprogramma EenVandaag vroeg mij om inhoudelijk commentaar op het onderzoeksrapport 'Software Risk Assessment ' uit 2008, dat ik daartoe mocht inzien. Zonder enige achtergrond of andere bekendheid met het politiesysteem BVH, vielen mij na bestudering van het rapport, dat zich toespitst op beoordeling van de kwaliteit van de softwarebroncode, documentatie en het ontwikkelproces, onmiddellijk enkele zaken op. Ik zal middels de welbekende denotatie van 'Do's & Don'ts' met name de don'ts kort toelichten.
Voorafgaand dient opgemerkt te worden dat het hierbij gaat om een nieuw politiesysteem dat het primaire proces van de politie ondersteunt.
Geen architectuur voor een complex systeem
De architectuur van het systeem is niet helder beschreven. Om toch een kapstok te hebben voor het onderzoek is in feite de samenstelling en samenhang van het systeem door de opstellers van het rapport high-level in kaart gebracht. Het ontbreken van een goede architectuur wordt ook meermaals als manco gesignaleerd. Gegeven de complexiteit van het BVH systeem, dat bestaat uit een samenhangend geheel van meer dan tien onderliggende onderdelen met meer dan zestien externe koppelingen, is dit gewoon vragen om moeilijkheden.
Samengesteld systeem op basis van matige subsystemen
Het rapport detailleert de kwaliteit van de verschillende onderdelen ofwel subsystemen. Deze worden overwegend als matig beoordeeld. Het bouwen van een samengesteld systeem op basis van individuele onderdelen met een matige kwaliteit leidt onverwijld tot een minder dan matig totaalproduct. Het bouwen van een kwalitatief goed systeem op basis van vele autonome onderdelen noopt tot het hebben van onderdelen met het op z'n minst hebben van een meer dan goede kwaliteit.
Legacy integratie voor de lange termijn
Het nieuwe BVH systeem wordt gebouwd rondom de bestaande legacy handhavingsapplicatie Xpol. Xpol is een karaktergeoriënteerde applicatie die gebouwd is in de verouderde 4GL taal Accell, waaraan jarenlang geleidelijk is doorgebouwd. Het hergebruiken van deze applicatie door toepassing van legacy integratie door screen-scraping technologieën is op zich een prima mechanisme voor interim situaties, zoals een op handen zijnde migratie naar een volledig nieuw systeem, waarbij het bestaande systeem nog even mee moet. Echter lange termijn gebruik van een omvangrijke legacy applicatie op basis van integratie technologieën met karakteristieken die welbekend staan als niet heel solide, is gewoon in de basis geen goed idee.
Veelvoud van technologieën voor hetzelfde zonder consolidatie
Het rapport detailleert het gebruik van vele verschillende technologieën. Op zich helemaal niet vreemd bij dergelijk complexe systemen. Over het algemeen bestaat nu eenmaal de noodzaak tot het ondersteunen of gebruik van meerdere technologieën, zeker bij hergebruik van bestaande elementen of bij integratie met externe partijen. Wat daarentegen niet heel handig is, is dat men gekozen heeft om intern in het systeem meerdere verschillende technologieën voor basiszaken toe te staan. Dit had op z'n minst geconsolideerd moeten worden. Een goed voorbeeld hiervan is het gebruik van zowel Sybase als MySQL als RDBMS voor het huishouden van dezelfde datasets.
Gedistribueerde integriteitcontrole op datahuishouding
De datahuishouding binnen het systeem is gecentraliseerd in één database, te weten de centrale database van het legacy Xpol systeem. Andere onderdelen maken ook gebruik van dezelfde database door rechtstreeks hierop te lezen en te schrijven. Integriteit wordt op diverse manieren bewaakt, onder andere in de Xpol applicatie zelf, maar ook door decentrale validatie regels in de verschillende softwareonderdelen. Een dergelijk gedistribueerde integriteitcontrole, waarbij de validiteit en integriteit van de data afhankelijk is van het functioneren van allerlei satelliet componenten, is geen good practise en leidt veelal tot enorme onduidelijkheid, complexiteit, of erger… gegevensverlies of corruptie.
Onvoldoend testen
De rapport spreekt over het onvoldoende testen op allerlei punten in het ontwikkeltraject waar je normaliter testmomenten zou verwachten. Het spreekt voor zicht dat het niet tijdig en goed testen van complexe, samengestelde systemen leidt tot problemen, alsook geen beeld ontstaat over de kwaliteit van het systeem.
Uitrollen zonder precies te weten hoe
Het rapport spreekt over een zeer complexe en onvoldoende herhaalbare uitrol. Systemen uitrollen welke inhaken op het primaire bedrijfsproces vergen een gedocumenteerde, minutieus geplande, doorgeteste en beproefde uitrol. Normaliter voer je geen nieuwe software in zonder aan deze voorwaarde te voldoen.
Deze zaken waren het meest treffend. Er zijn natuurlijk nog vele andere aspecten die maken dat een computersysteem juist en goed functioneert, zoals de functionele, infrastructurele en beheer aspecten. Het rapport gaat echter niet in op deze zaken (buiten scope), maar tipt wel voorzichtig aan dat het beoogde hardwarepark op z'n minst enige zorg behoeft. Het mag voor zich spreken dat er een duidelijke relatie bestaat tussen software en de benodigde infrastructuur; ook deze dienen goed op elkaar te zijn afgestemd, te meer wanneer het gaat om complexe software bestaande uit meerdere onderdelen.
Op basis van enkel de in het rapport benoemde aspecten kan concluderend worden gesteld dat basale zaken niet in orde waren. Een dergelijk negatieve conclusie is echter niet heel ongebruikelijk na een risk assessment. Veelal wordt een dergelijk onderzoek namelijk niet zomaar ingezet, en als resultaat krijgt je een keurige set van aanbevelingen met verbeterpunten. Hiermee kan een organisatie vervolgens aan de slag en gericht verbeteringen aanbrengen om zo tot de gewenste kwaliteit te komen. Opmerkelijk is echter dat dit rapport aan de vooravond van de landelijke uitrol beschikbaar was, maar dit niet heeft geleid tot de significant benodigde herziening of verbetering.
Op basis van het rapport met zeer heldere indicatoren en de kennelijke context dat invoering is doorgegaan kun je stellen dat dit systeem bottem-line gedoemd was te mislukken.
