Langer doorwerken met oude systemen, hogere ict-kosten en minder modernisering van de dienstverlening dan de burger verwacht. UWV ziet het komend jaar weinig ruimte voor vernieuwing en verbetering door innovatie. De basis van de ict is volgens de dienst inmiddels op orde, maar doordat de dienst extra taken moet gaan uitvoeren, een grote datacentermigratie en meer nadruk op securitty, schiet innovatie er bij in.
Dat blijkt uit het Jaarplan 2020 dat UWV dat naar de Tweede Kamer heeft gestuurd. Wie tussen de regels doorleest ziet een uitvoeringsorganisatie die in ambtelijk jargon een juichverhaal houdt over allerlei verbeteringen, maar ook moet toegeven dat het voorlopig behoorlijk blijft hangen in ict-ellende en weinig kan innoveren.
‘Vanwege het beslag wet- en regelgeving op onze verandercapaciteit is er maar beperkte ruimte om initiatieven te starten voor de vernieuwing van het ict-landschap en het verbeteren van de ict-dienstverlening aan onze klanten en medewerkers. We blijven langer werken met oude systemen en maken hogere kosten, zijn minder goed in staat om mee te bewegen met wensen vanuit de maatschappij en kunnen minder moderne dienstverlening bieden dan we zouden willen’, staat in het Jaarplan. Er wordt niet specifiek toegelicht om welke nieuwe taken het gaat.
De dienst stelt dat de afgelopen jaren de basis van het ict-landschap op orde is gebracht. Preventief onderhoud zou zijn geborgd in een reguliere cyclus voor groot onderhoud. Ook zou de aandacht voor continuïteit, stabiliteit, informatiebeveiliging en privacy zijn vergroot en UWV wijst op verbetering van de beveiliging van portalen.
Stapsgewijs
‘We veranderen stapsgewijs en niet alles kan tegelijkertijd. In 2020 legt nieuwe en veranderde wet- en regelgeving een groter beslag op de verandercapaciteit van UWV dan in voorgaande jaren.’ Daarbij ziet de dienst steeds meer impact van zij-instromende opdrachten; wet- en regelgeving buiten het SZW domein. ‘In 2020 gaat het om meer dan een kwart van alle wet- en regelgevingstrajecten.‘
Afscheid van IBM
Het gaat om de overstap naar een nieuwe hostingconsortium waarbij een contract met IBM wordt ontbonden. René Veldwijk, ict-kenner bij de overheid, licht desgevraagd aan Computable toe dat bij UWV-onderdeel Werkbedrijf ‘alles op slot gaat om de ict-omgeving klaar te maken voor die migratie.’
UWV in het Jaarplan 2020: ‘Alle applicaties en voorzieningen die bij de huidige leverancier draaien moeten nu in een periode van tussen de drie en vier jaar worden overgezet naar de nieuwe leverancier. Daarbij zetten we in op het vernieuwen en vervangen van verouderde ict-componenten.’
‘De migratie is complex en zal de komende jaren veel van onze aandacht vragen. Kleine fouten kunnen al leiden tot grote verstoringen van de dienstverlening aan onze klanten. Een goede planning is nodig om een goed verloop te garanderen en onze verandercapaciteit zo gericht mogelijk in te zetten.’
UWV zegt tijdens de migratie dienstverlening te blijven bieden aan klanten. ‘Ook zullen we blijven werken aan vernieuwingen en verandering van wet- en regelgeving.’ Daartoe wordt een traject gestart voor verbetering van de informatievoorziening, schrijft UWV. Ook privacy en het verbeteren van veilig communiceren worden genoemd.
AVG
De dienst deelt verder dat In 2020 de aandacht uitgaat naar ‘het verder inbedden van de AVG in de organisatie.’ Kennelijk was dat nog niet overal het geval.
UWV: ‘Dit betekent dat onze medewerkers zich in toenemende mate bewust moeten zijn hoe zij kunnen bijdragen aan een veilige omgang met informatie. Onvermijdelijk is dat in de uitvoering tot op zekere hoogte ook ongestructureerde gegevens buiten de systemen worden opgeslagen. Voor deze omgevingen richten wij stapsgewijs het schonen en beheer in.’
UWV zegt ook te investeren in maatregelen die bijdragen aan het verder terugdringen van datalekken, zoals het minimaliseren van de exportfunctie in applicaties met veel persoonsgegevens. Ook worden en preventieve oplossingen geïmplementeerd die tijdig moeten signaleren wanneer gevoelige gegevens onnodig of onterecht de organisatie verlaten, bijvoorbeeld via e-mail. Een tijdspad of planning wanneer die systemen actief zijn wordt niet genoemd
Zo moeilijk is het niet om systemen geschikt te maken voor een andere omgeving. Totaal niet zelfs. En veel hoeft het ook niet te kosten! Je moet dan natuurlijk wel de intelligentie hebben om voor een geautomatiseerde oplossing te kiezen. Sterker nog, bij een conversie kun je enkele belangrijke voordelen inbouwen.
1) Bij de conversie wordt normaliter de omgevings-afhankelijkheden afgesplitst in een aparte omgeving-laag.
2) Bij de conversie wordt normaliter de gegevensbenadering afgesplitst in een aparte gegevens-laag.
3) Als stap 1 en 2 goed worden uitgevoerd, dan wordt de business-logica afgesplitst in een aparte business-laag.
4) Laat de nieuwe interactie tussen de aldus gevormde lagen, voorzien van een uitgebreide SOA interface en een SOA-scheduler. Dat betekent dat de verbindingen tussen de verschillende programma’s flexibel worden gestuurd. Er zijn legio voordelen:
– een nieuwe koppeling kan per een bepaalde datum ingaan
– de nieuwe koppeling kan voor test-ranges eerder getest worden en worden vergeleken
– controle posten kunnen parallel uitgevoerd worden
– big data laat zich gemakkelijk sturen
– nieuwe communicaties tussen een externe applicatie en het ‘oude’ systeem, kunnen eenvoudig worden geparameteriseerd: het zogenaamde wrappen.
– loggen van aanroepen laat zich eenvoudig implementeren. Daardoor dus ook herstartbaarheid of opnieuw draaien vanaf een bepaald moment met verbeterde routines.
Bij een geautomatiseerde conversie weet je exact welke nieuwe source-regels in welk beperkt aantal te selecteren routines te testen zijn. Vaak maar 20% van het geheel. Een gigantische besparing als je daar slim mee om gaat. Bij handmatige conversie heb je dit voordeel per definitie niet.
Je kan er nog uren over schrijven. Helaas zijn velen onbekend met het plezier van het hernieuwen van software. Men mauwt vaak over legacy, zeer tot mijn ergernis kan ik wel zeggen. Denk eens aan Return On Investement. ROI. Als die good-old-software het prima doet, waarom zou je het dan niet middels proofen technology / conversie tools flexibiliseren? Dan kun je vervolgens in een gewenst ontspannen tempo de nieuwe functionaliteit introduceren.
Denk dat hier sprake is van:
Garbage in is garbage out.
Als je er nog steeds mee draait, dan is het kennelijk niet zo slecht als sommigen blijven roepen.
Als je dan van de spaghetti door de omzetting een beter toegankelijke lasagne maakt, dan win je heel veel.
Als er als klap op de vuurpijl bij de conversie een perfect fraaie repository wordt opgeleverd waarmee functioneel beheerders cq product-owners functionele specificaties in een flits kunnen achterhalen, dan ga je er flink op vooruit. Je krijgt het systeem beter onder controle en dat verdient zichzelf snel terug, nog los van de voordeligere uitvoerings-omgeving.
Ronald, welke programmeertaal of ontwikkelomgeving zou je willen aanbevelen voor het beschrijven van “de business-logica afgesplitst in een aparte business-laag”?
in een repository is dat niet relevant. Bij conversie wordt het in de gewenste vorm gebracht, dus naar keuze, passend bij de betreffende organisatie, vereiste performance, etc. Het is aan te raden zelfverklarende code na te streven. In overleg met het conversie-bedrijf kunnen bijvoorbeeld de database-variabelen centraal gesteld worden, zo nodig te verbeteren en als uitgangspunt nemen in de variabelen die in het systeem gebruikt worden.
Voorbeeld: als je in de Y2k periode naar de moeilijkere conversies kijkt, dan kom je variabelen tegen die als register voor alles en nog wat werden gebruikt. Door het conversie-bedrijf is van ieder statement geautomatiseerd terug te vinden om welke context het gaat, zodat het register-karakter kan worden gewijzigd in een aanzienlijk betere definitie. Het juiste commentaar laat zich ook toevoegen. Met moderne conversie software kun je heel ver komen. De prijs-prestatie verhouding van een écht conversie-bedrijf overtreft alle outsourcing bedrijven.
@Ronald,
“De prijs-prestatie verhouding van een écht conversie-bedrijf overtreft alle outsourcing bedrijven.”
vreemde vergelijking. Is het doel om zelf te blijven beheren/ontwikkelen maar dan eenvoudiger, of om dit uit te besteden ?
In ontwikkelomgevingen bedoelen we meestal met repository een versiebeheersysteem.
Doel jij een automatisch gegenereerde bewaarplaats “waarmee functioneel beheerders cq product-owners functionele specificaties in een flits kunnen achterhalen” ?
Wie bepaalt wat er getest, progressie en regressie, moet worden en hoe ? Hoe kom je op 20% als je uitgaat van spaghetti ?
Wie bepaalt dat de conversies methode en uitvoering “proofen” is ?
Van spaghetti naar lasagna dus, maar heb je dan niet nog steeds een zwaar verteerbare monoliet. Heb je geen ravioli nodig voor SOA ?
Ik denk dat ik niet de enige ben die zo’n conversie eerst zou willen zien en dan geloven.
Je voorbeelden gaan steeds over low level code inspectie, niet over het automatisch reverse engineeren van code naar high level specificaties.
Doe svp nog eens een poging om Jacks vraag te beantwoorden, nu iets concreter.
@Ronald … ik vrees dat de praktijk vaak wat weerbarstiger is (gebaseerd op de ervaringen die ik zelf heb)
De spaghetti die je naar lasagne wil transformeren is vaak een organisch gegroeide, dynamische kluwen. Tijdens de conversie groeit deze spaghetti gewoon verder; immers er blijven nieuwe functionaliteiten of implementaties nodig om verder te groeien als organisatie/onderneming.
En vaak is het niet alleen de IT spaghetti die geconverteerd moet worden, maar hangt er nog heel veel meer aan vast, zoals werkprocessen en eigen tools die gebruik maken van de spaghetti en (on-)mogelijkheden van de oude tooling.
@Ronald
Jouw pleidooi is een utopie, die werkt alleen in het paradijs, niet in de echte wereld. Daar zit de business logica deels in de datalaag en voor een ander deel in de presentatielaag. Legacy van leverancier A is houtje touwtje gekoppeld aan legacy van leverancier B. Broncode is niet beschikbaar. Ben je misschien een consultant die klanten helpt met migreren? En heb je nog nooit “nee” hoeven verkopen?
Johan en Pascal hebben beide gelijk. En ik ben benieuwd naar het echte antwoord op de vraag van Jack.
De werkelijkheid is een stuk gunstiger dan de sombere ervaringen van sommigen hier.
Ik doe geen sales en bezit weinig conversie software. Wel heb ik zeer plezierige ervaringen met een bekwame conversie partner.
Conversies, gestructureerd ontwerp en onder architectuur werken, zijn wonderwel zeer plezierig en verleggen de mogelijkheden aanzienlijk. Zo zijn er weinig applicatie-ontwikkelaars die interpreters maken. Ik maakte er verscheidene die jarenlang in financiële omgevingen succesvol zijn ingezet. COBOL/Mainframe en PC. Niet erg voor de hand liggend, wie je er ook naar vraagt. Altijd sombere verhalen over dat soort onderwerpen. Onbekend maakt onbemind. Er zijn vaak verrassende oplossingen mogelijk. Een kwestie van vooral heel goed nadenken. Vooraf! Anderen huren liever niet-herhaalbare, totaal niet flexibele, handmatige inzet in. Inzet die massaal het land permanent binnenkomt in weerwil van de Europese regelgeving en zonder het gewenste creatieve niveau. Uurtje factuurtje idee. Niet listig.
De sombere reacties hier verrassen mij totaal niet. Het is helaas een bekende uiting van mensen die ongeveer niets gewend zijn of zelfs bang zijn voor enige innovatie. Die praten over utopieën en dergelijke. Ten onrechte. Fraaie, flexibele en snelle oplossingen zijn goed realiseerbaar, zo is gebleken. Je moet er wel voor openstaan. Nee zeggen, is veel te makkelijk.
Grote overheids-organisaties zeggen graag ja tegen hele grote partijen die miljoenen projecten willen doen, meestal in een klassieke benadering. Dat soort projecten blijken keer op keer over de kop te gaan, om zeer voor de hand liggende redenen die onvoldoende bekend blijken te zijn.
Het kan anders.
Niks utopie.
Proven technology.
Als je maar hard genoeg ‘nee’ roept, creëer je die self fulfilling prophecy waar sommigen naar op zoek blijven. Dan blijven die projecten mislukken. Per definitie.
Het kan beter!
Probeer eens een andere benadering.
Cheers!
@Ronald … achteraf is het makkelijk te roepen dat met vooraf had moeten nadenken over bepaalde aspecten.
De architectuur die je vandaag bedenkt zou over 10 jaar best wel eens een verkeerde keuze of achterhaald kunnen zijn.
Niet iedere organisatie heeft de middelen om tussentijds bij te sturen en/of redesigns te implementeren. Je kunt je geld immers maar één keer uitgeven, en ik heb meerdere malen meegemaakt dat er dan toch gekozen wordt voor nieuwe features in plaats van conversies, redesign of wat dan ook. Immers, een nieuw feature kun je aan je klant verkopen, eenzelfde product op basis van andere architectuur is voor een klant veelal niet interessant.
Dat het beter kan ben ik helemaal met je eens, maar sleutelen aan een rijdende trein is toch net even iets anders dan een nieuwe trein ontwerpen