Edit: Enkele correcties waarop ik werd gewezen door oud collega en enkele zaken aangepast i.v.m. andere belangen.
Bijna goed, core van BVH draait op een combinatie van
Tru64 en
VMS. Dit is de oude applicatie zoals die gebruikt werd/word in de diverse Politie regio's. Aangezien VMS en Tru64 niet echt meer je van het zijn (hoewel het verdomde stabiel is) zijn er een aantal trajecten gestart om te migreren naar een nieuwe omgeving. Waarbij eerst is gekozen voorhet uniform maken van de
presentatielaag welke onder Windows moet draaien en voldoen aan alle regeltjes rond presentatie.
De tweede stap is de backend systemen migreren naar een nieuw platform waarvan nog niet vaststaat wat het moet worden. Dit scenario is een goede stap zodat gebruikers al kunnen wennen aan het nieuwe systeem zonder dat de backend met alle nodige conversies aangepast hoeft te worden. Hierover is heel goed nagedacht omdat de risico's anders te groot worden op problemen met de consistentie in o.a. de data.
Tijdens het maken van de nieuwe presentatielaag streeft de Politie en de Politiek een uniforme werkwijze na. Dit wil zeggen dat de look, feel, userexperiënce landelijk gelijk moet zijn.
Hierbij loopt het project tegen een groot aantal problemen aan, waaronder het het moeilijk concensis verkrijgen over welke velden, welke menu's, welke workflows en dergelijke er gebruikt moeten worden. Iedere regio heeft hier zo zijn verschillende denkwijzen over en is het moeilijk om overéénstemming te krijgen. Iedereen heeft in de jaren zijn eigen BVH gebouwd (en XPOL op de achtergrond). Hierbij zijn er aanpassingen geweest in de databases welke niet overéénstemmen tussen de diverse regio's. Zelfs over een simpel iets bijvoorbeeld als de opslag en presentatie van een éénvoudig telefoonnummer kan men het tussen de diverse regio's niet eens worden. Ondanks de goede wil van het project zelf.
Nu heeft het project BVH (met inderdaad externen en internen, maar wat is een dure externe???) iets bedacht wat veelvuldig gebruikt wordt binnen vele migratie-trajecten. Ze hebben een screenscraper gebouwd rond de "Terminal" geöriënteerde applicaties met interfaces naar moderne toepassingen zoals Word en dergelijke.
Nu zit o.a. daar het probleem. Binnen BVH zijn er zo veel excepties op presentatie en signaling (status coderingen en menu structuren) dat het bijna ondoenlijk is om uniformiteit te bereiken en. Tevens heeft men door de stringente wens van de diverse korpsleidingen gekozen voor decentrale implementaties. Ieder korps krijgt zijn eigen BVH. Echter wel op een uniforme wijze, dit wil zeggen dat bijvoorbeeld BVH er in Utrecht het zelfde uit ziet voor de gebruiker als BVH in Rotterdam.
Nu zitten er een aantal addertjes onder het gras. Zo eist de software voor het vertalen de terminal output en vertalen naar Windows look and feel dat er een bepaalde minimale Office- en Windows versies gebruikt worden met bepaalde Servicepacks en keuze van inrichting, waardoor het presentatieplatform kan werken onder zowel Citrix en plain Windows en misschien zelfs in de toekomst Linux.
Wat is nu het geval. Het project is uitgegaan van een standaard landelijke infrastructuur (waar ik zelf o.a. aan mee heb ontworpen en gebouwd). Deze infrastructuur is in een groot aantal regio's geïmplementeerd. Echter zijn er een klein aantal grote regio's nog niet zo ver dat ze inpassen in deze standaard infrastructuur. Daar lopen ze met de implementatie achter of hebben "eigen" plannen gemaakt. Echter zijn deze eigen infrastructuren zo danig technisch afwijkend, achterhaald of anders dat BVH daar niet zonder problemen op kan draaien waardoor het project alles moet verzinnen om het toch goed werkend te krijgen. Maar het feit is dat de BVH presentatielaag ontwikkeld is op hedendaagse standaarden (zover je met MS als platform over standaard kan spreken) waar de "probleem"-korpsen nog niet geheel aan voldoen.
Het probleem is daarnaast dat hierdoor de kosten dermate hoog worden en en de implementatietijd van BVH zodanig lang duurd dat het een politiek issue is geworden. Daarnaast is de vraag waarom deze korpsen niet gewoon al aan de beschikbare standaarden voldoen omdat dit ten eerste veel sneller geïmplementeerd kan worden dan hun eigen ideeën en ten tweede een landelijk standaard platform had geboden voor een migratie naar Windows 2008 R2 waar de vtsPN op het moment al mee bezig is. Tevens is de vraag waarom decentraal en niet centraal? Maar dat is een totaal andere discussie en speelt bij veel bedrijven waar ik zit.
Ook zijn er andere projecten welke wel draaien op een standaard infrastructuur. En in de praktijk blijkt dit dan ook snel te implementeren (techinsich).
Just my 2 cents.
[Reactie gewijzigd door Wim-Bart op 22 juli 2024 14:03]