UWV blijft langer werken met oude systemen

Dienst ziet in 2020 weinig ruimte voor innovatie

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

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

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

@PA VA KE

De operatie die ik voorstel, kost een fractie van wat al uitgegeven is en ook een fractie van wat een groot project kost.

In Nederland willen grote partijen altijd met een voor hun gevoel even grote partij aan tafel. Daarom missen ze kansen. In Duitsland zijn ze slimmer. Daar kom je als kleine partij wel in contact met de directie van een mega grote bank, kom je tot zaken en volgt de aangename verrassing.

Het voorstel is om de rijdende cq op hol geslagen trein, beter bestuurbaar te maken, terwijl die desondanks geen seconde stil hoeft te staan.

Een structureel probleem van velen is, dat je niet kunt weten wat je niet weet.

Onderzoekt het vele en behoudt het goede.

Het ontwerpen van de nieuwe trein moet exacter. Je wilt dat de huidige trein beter functioneert en toegankelijk is voor directe aanpassingen. De vernieuwde onderdelen functioneren ook in het nieuwe systeem.

Ronald heeft daar wel een punt – zo risico minded als veel organisaties zijn blijven ze vaak binnen die o zo bekende, ingesleten olifanten-paadjes wandelen.
Ook vooruitdenken is in veel organisaties nog wel een “dingetje”. Het resultaat binnen een lopend kwartaal/boekjaar weegt vaak zwaarder dan het rendement over 1-2 jaar (of langer); zelfs als dat rendement tegen die tijd een factor 2-3 hoger licht.

Wat dichter bij (mijn) huis:
Een vergelijkbare situatie is ook van toepassing voor de financiële gevolgen bij aanhoudende verstoringen in een hybride, multi-cloud IT/applicatie landschap. In mijn dagelijkse praktijk als TCP-relatie therapeut ervaar ik redelijk wat weerstand rondom geautomatiseerde probleemanalyses. Dit ondanks dat je met zo een aanpak de financiële gevolgen van verstoringen met minstens 50% terugbrengt (tegen een voorinvestering van hooguit 5%).
Vaak kiest men toch voor een meer handmatige, op locatie uitgevoerde procesmatige analyse middels het afnemen van gebruikersinterviews. Of een analyse met (bijvoorbeeld) een Wireshark voor één specifiek probleem binnen een kleine scope.
Beiden met als argument dat een geautomatiseerde aanpak een voorinvestering vereist die “pas” na 1-2 jaar is terugverdient.

Of met een bredere, meer maatschappelijke insteek:
Kijk maar eens naar de aangedragen “oplossingen” voor het klimaat/CO2 vraagstuk: allemaal korte termijn denken met als focus zo min mogelijk impact op de huidige economie/samenleving. Met daarnaast: potentiële oplossingen moeten binnen, pak hem beet, 5 jaar op grote schaal inzetbaar zijn en gekoppeld aan een “harde” terugverdientijd van maximaal 10 jaar.

Terwijl de echte winst (als die er inderdaad gaat zijn!) zich pas laat zien na 20-30 jaar en daarmee generatie overstijgend is. Dit heeft te maken met de "reactietijd" van mensen, samenleving en de natuur. Hoe reageert mens en samenleving op de ingeslagen weg? In hoeverre beïnvloeden de neveneffecten diezelfde natuur (positief of negatief)?

Daarom de volgende suggestie (met het idee dat *niks* doen in ieder geval *geen* optie is):
Geef mensen die er andere, meer revolutionele ideeën op nahouden eens het voordeel van de twijfel door vragen te stellen; de vraag van Jack is daar een mooi voorbeeld van.
In de reacties/beantwoording is het dan wel zaak niet al te veel in statements te blijven hangen. Noem “het conversie-bedrijf” desnoods met naam-en-toenaam. Dat lijkt me nauwelijks een probleem als hun aanpak inderdaad zo goed werkt en universeel toepasbaar is (d.w.z. schaalbaar en reproduceerbaar).

In dat kader heb ik voor Ronald 3 andere vragen die bij mij steeds boven komen drijven:
- Heb je een of twee voorbeelden van de combinatie (1) – “passende repository”, (2) – karakteristieken van de “betreffende organisatie” en (3) – de “vereiste performance”? Hoe zijn elk van deze 3 gedefinieerd?
- Wat zie je als een illustratief voorbeeld van goede, zelfverklarende code en wat maakt dat deze code anders-dan-andere?
- Zijn er artikelen over geschreven? Waar zou ik die terug kunnen vinden?

@Will Moonen

1) Een repository kan worden gegenereerd aan de hand van de code. Doublures worden onderkend en teruggekoppeld. Met iets meer inspanning wordt e.e.a. zo nodig veralgemeniseerd tot een gemeenschappelijke routine.

2) Sommige organisaties die een goede, eigen manier van werken hebben, hebben een duidelijke karakteristiek. Een 'cultuur' van gestructureerd ontwikkelen, rekening houdend met allerlei randvoorwaarden. Bijvoorbeeld domino-effecten uitsluiten door bepaalde manieren van koppelen tussen systeem-onderdelen. Goede architectuur. Programmeer-standaards. Een programma wordt door collega's beoordeeld.

3) Als je naar een ander platform over wenst te gaan, is het goed om een redelijk vermoeden van de performance te hebben. Doe daarvoor enkele tests.

Op het gebied van performance heb ik enige herinneringen:

- een database verkopende organisatie zou hun systeem 'even' demonstreren aan een marketing-segmentatie bureau dat werkte met postcodes met daaraan gerelateerd het type klant. De normale laadtijd in de betreffende COBOL PC omgeving van ruim 650000 records was 5 minuten. Tijdens de demonstratie lukt het niet op de toenmalige snelste PC op de markt bij de klant om dit binnen 4 uur geladen te krijgen. De verkoper had juist aangekondigd dat zijn systeem geweldig was. Die hoefde niet meer terug te komen. Pure tijdverspilling en onzinnige claims.

- Toen het UWV als nieuwbakken doorgeefluik van werkgevers-info, moest doorleveren aan De Belastingdienst, duurde dit maanden en bleek de doorlooptijd bij hun van één aanlevering, ongeveer een dag te moeten duren. Andere ervaringen uit die tijd: de verwerking van meer dan 130 miljoen transacties en laden in een big-data omgeving, is binnen 20 minuten voltooid. Een interpreter in COBOL verwerkt 20 miljoen records in een complexe selectie middels die interpreter, binnen 1 minuut, zowel op mainframe als op PC.

- Een sukkelige initialisatie op een mainframe in een realtime-transactie omgeving, verstookte voor 200.000 euro per jaar aan CPU. De aanpassing reduceerde dit tot aanzienlijk minder dan 1 euro per jaar.

- Een eerste release van een zwaar encryptie systeem, verbruikte 64 x meer doorlooptijd op een PC dan in de volgende release, na enige tuning.

Je ziet tegenwoordig vaak dat het theoretische gegevensmodel één op één wordt geïmplementeerd. Als de performance te ver achterblijft, worden de instellingen en/of indexen van de database gewijzigd. Maar dat helpt soms onvoldoende. Een aantrekkelijkere aanpak is de uitbreiding met access-paden en de bijbehorende frequenties, om vervolgens tot een geoptimaliseerd technisch gegevensmodel te komen. Hoeft niet veel tijd te kosten en bespaart enorm.

Ook procesmatig zie je vaak dat de achterliggende life-cycles worden opgesplitst in gekunstelde transities / overgangsmomenten met de 'bijbehorende' opslag. Zonde. In de software zie je vaak eindeloos veel uitvragingen hoe het in Godsnaam mogelijk is dat de betreffende transactie hier en nu wordt aangeboden. Als het dan niet anders kan, dan wordt - als ware het de grootste denkbare uitzondering - de transactie in het systeem doorgevoerd. Onhandig. Een herstartbaar proces werkt efficiënter, vereist minder onderhoud, is logischer en laat zich veel gemakkelijker testen, ook op compleetheid.

Methoden & Technieken worden weinig meer beoefend. Maar reken maar dat als je in aanloop naar je nieuwe systeem, vooruit denkt, je heel veel problemen, ontspannen voorkomt. Weinig kosten, veel plezier.

En zo kun je nog uren doorgaan.

Van zelfverklarende code zijn vele voorbeelden, vooral bij de betere bedrijven. Maar als je het Euler project beschouwt waarin oplossingen in moderne programmeertalen worden getoond, dan zie je het veelvuldig gebruik van identifiers als 'i' en 'j', populair bij wiskundigen e.d. Maar je begrijpt wel dat in een omgeving waarbij software veelvuldig moet worden onderhouden, dit een onacceptabele naamgeving is. Mijn vroegere coach zei dat de koffie-juffrouw mijn programma moest kunnen lezen en begrijpen. Hij had gelijk. In de oefen-programma's in het Euler project wordt hier en daar gewerkt met priemgetallen. Dus noem die dan niet 'i' of 'j', maar noem ze wat ze zijn: priemgetal, getal-van-onderzoek, deler, etc. Dat helpt. Weinig moeite, veel plezier. Zelfs als je zo een programma na maanden nog eens ziet. Je kunt het dan sneller en beter doorgronden. Nog beter als je het voorziet van helder commentaar en een schets van de opzet.

Er zijn enorm veel boeken geschreven over programmeren en technieken. Het ontwerpen staat dan centraal. Data gedreven ontwerp versus functioneel. 'Functioneel' leidt doorgaans tot minder uniformiteit. Helaas krijgt de wijze waarop e.e.a. gecodeerd wordt, veelal aanzienlijk minder aandacht. Volmac besteedde daar vroeger wel goed aandacht aan met performance winst. Een enkele presentatie over dit soort onderwerpen, kan enorm verhelderend werken. Laat een HBO-stage-team e.e.a. tot een handboek verwerken, als jouw organisatie groot genoeg is om hier mee om te gaan. Een aanrader met uitermate plezierig resultaat.

Overigens kan zelfs het gebruik van een editor tot enorme verschillen in prestaties leiden. Wat te denken van een 1000-tal variabelen die stuk voor stuk in een alinea van 20 regels code een aantal keer moeten worden opgenomen. Mensen die de 'power-edit' in een SPF omgeving hebben geleerd, realiseren dit binnen 10 minuten. Je zult ze de kost moeten geven die er een week voor nodig hebben of langer....

In deze tijd ligt het voor de hand om het internet op te gaan voor meer details...

Ronald, je visie heeft wel raakvlakken met een opiniestuk uit 2013 met de toepasselijke titel: Maak legacy klaar voor de toekomst.
https://www.computable.nl/artikel/opinie/security/4775468/1509029/maak-legacy-klaar-voor-de-toekomst.html

Gezien de vele kenmerken van legacy, zoals opgesomd in een reactie bij dit artikel, is het onmogelijk om met een conversieprogramma de verwevenheid in legacysystemen te ontvlechten naar de verschillende lagen binnen een applicatie-architectuur. Hooguit kun je met een conversieprogramma de legacy-spaghetti overzetten naar een andere omgeving.

Toen 'wij' (computer-schaak-geïnteresseerden / CSVN) in zeg +/- 1981 voorspellingen deden over het toekomstige computerschaak en het niveau, zaten we er allemaal naast. We zagen weliswaar steeds beter functionerende programma's maar de wereldkampioen verslaan, was schier onmogelijk. Zelfs toen we na jaren vernamen dat Deep Blue de wereldkampioen verslagen had, konden we bij benadering niet vermoeden dat er een AI systeem zou komen dat in 4 uur tijd op basis van zelf-leren en eigen spel-theorie boven het wereld-niveau zou uitstijgen. Het gaat over AlphaZero. Voor de geïnteresseerden: zoek op AlphaZero op Youtube en laat je een paar bijzondere partijen voorschotelen met Stockfish. Misschien dat dit het ongeloof m.b.t. ontwikkelingen kan wegnemen. Vooral als schaker zul je verrast zijn.

In conversieland zijn er de afgelopen 20 jaar aardig wat ontwikkelingen geweest. Zoals het geautomatiseerd ondersteund interpreteren van allerlei talen, omgevingen en hun eigenschappen. Dat software de mens in behendigheid meer dan de baas is, is kennelijk in sommige kringen nog niet geaccepteerd. Logisch ook, want het inzetten van duizenden handjes - de uurtje-factuurtje fabrieken - is nog altijd heel populair dankzij het succes van de outsource lobby die het hoger management nog immer in hun greep hebben. Niet in het belang van enige opdrachtgever. De nauwkeurigheid van het werk van échte conversie software, gaan de mogelijkheden van de mens te boven. Aan de zijlijn laat je de beste en positief ingestelde mensen meekijken en bijsturen. Dat levert prachtige resultaten op. Dan kun je naast de horizontale herindeling, het verticale aansturen beschouwen: eigenaarschap van bepaalde verzamelingen, business-owners, geautomatiseerd ontvlechten van ongewenste verstrengeling. Prima te doen in interactie met het conversie-bedrijf. In sommige organisaties wordt dit gekscherend het patat-snijden genoemd: de verticale lijnen in de systemen aanbrengen. De contractuele afspraken tussen de verschillende business vastleggen met geautomatiseerde ondersteuning, interface beschrijvingen, etc.

Er zijn teveel beslissers die met het air van de wijsheid in pacht en angstig tegelijk, hard remmend, bang als ze zijn achterop de fiets de berg op te gaan. Dat scenario is uit een mop. Niet het gewenste scenario voor mensen die met beperkt budget en met kennis van actuele ontwikkelingen, alles uit de kast willen halen en mooie resultaten in korte tijd willen halen. Want het kan écht, al het negativisme ten spijt. De mogelijkheden van nu zijn zeker niet de onmogelijkheden van vele jaren terug.

Dat computers beter kunnen schaken dan mensen bewijst alleen dat ze beter kunnen rekenen en dat wisten we al.

Een willekeurige 3GL wordt uiteraard niet zelfverklarend door een betekenisvolle naamgeving van de variabelen. Voor zover je met zelfverklarende code echter doelt op declaratieve programmeertalen kom je met een programmeerstijl die tamelijk hardnekkig niet weet door te breken, namelijk functioneel programmeren (zoals eerder al het logisch programmeren niet van de grond is gekomen).

Zie hiervoor mijn reacties op:
https://www.computable.nl/artikel/opinie/development/6330734/1509029/populariteit-functionele-talen-stijgt.html

Uiteraard heb ik niets tegen het gebruik van functies in een object georiënteerde taal als Python; het gaat mij vooral om de academische pogingen zuiver wiskundige en logische programmeertalen te ontwikkelen.

Daarnaast is er een declaratieve programmeertaal die in de praktijk wel werkt, en dat is: SQL. Zoals is aangetoond in de vele reacties op:
https://www.computable.nl/artikel/opinie/digital-transformation/6666832/1509029/sql-vaardigheden-kunnen-bij-grofvuil.html

Op het tegenargument dat SQL toch ook op wiskunde is gebaseerd ga ik nu even niet in :-)

Maar echt declaratief/zelfverklarend wordt het pas met een 5GL waar de gewenste eindresultaten dienen als verklaring voor te realiseren deelresultaten.

Zou het toeval zijn dat ‘explainable AI’ tegenwoordig ook ‘declarative AI’ wordt genoemd? Met een winstwaarschuwing: een academische aanpak zal deze benadering opnieuw met heel veel jaren traineren.
https://2020.declarativeai.net/

In mijn optiek past 5GL geheel binnen het idee van declaratieve AI, en mijn proof of concept is hier terug te vinden:
https://dmcommunity.org/challenge/challenge-march-2019/

Nog altijd kun je een oplossing voor deze challenge insturen in een zelfbeschrijvende, declaratieve taal naar keuze!

… "Dat computers beter kunnen schaken dan mensen bewijst alleen dat ze beter kunnen rekenen en dat wisten we al.... "

Dus niet! Zou je de moeite hebben genomen de commentaren te volgen, dan zie je dat AlphaZero een geheel eigen strategie volgt. De diepte van de berekeningen, is veel minder groot dan verwacht. Zet, tegenzet, iedere zet-stap, noemen we in de schaakprogrammering het aantal ply. Het aantal ply dat AlphaZero benut, blijkt tamelijk gering. Als die vervolgens het lef heeft 3 pionnen te offeren, dan is dat geen onderdeel van het rekenen want dan zou die keus nooit gemaakt zijn. Dus jouw betoog over computers die beter schaken, is slecht onderbouwd. AlphaZero voegt iets toe zonder dat wij mensen, kennis nemen van de door die AI opgebouwde strategie. Helaas. Want er lijkt duidelijk wel iets van te leren.


…. "Een willekeurige 3GL wordt uiteraard niet zelfverklarend door een betekenisvolle naamgeving van de variabelen." ….

Op zichzelf niet, maar zoals het bij de betere bedrijven wordt toegepast, zeker wel. Ook bij conversies wordt een dergelijk commentaar toegevoegd, wordt van subroutines aangegeven wat er in gaat en wat er uit komt, met zinvolle namen, dus iemand die niet kan programmeren maar wel functionele kennis heeft, die begrijpt wat er gebeurt en kan zich er zelfs een gefundeerde mening over vormen.

… "functioneel programmeren " ....

Als je daarmee doelt op zogenaamde 'methoden' als functionele decompositie, dan klopt het helemaal dat daar niets van deugt. Vooral omdat de 'methode' geen ingebouwde zelfcontrole heeft en nieuwkomers in hun benadering er weinig in slagen een éénduidige benadering te creëren. Integendeel. Zoveel beoefenaren, zoveel benaderingen. Heel anders als de mensen data georiënteerde Jackson technieken benutten. Allereerst heeft Jackson wel ingebouwde zelfcontroles, waardoor vroegtijdig onderkend kan worden dat er iets aan schort, zowel op systeem-ontwikkelings-niveau als bij het programmeren. Zo zie dat men bij de grotere financiële instellingen, nog altijd enige hang heeft naar 'Volmac Structured Programming' (VSP), terwijl dit maar ongeveer 3,5 hoofdstukken van de 10 hoofdstukken van Jackson Structured Programming tellende (JSP) bevat. Zo heeft Volmac de AMSA weggegooid, dat vooral een zwakke en onvolledige manier was om backtracking problematiek gestalte te geven. Wat de financiële instellingen betreft, heeft VSP echter veel toegevoegde waarde. JSP en JSD dus nog veel meer. Maar aangezien men zich meer en meer op mensen uit India verlaat, die bij benadering geen vermoeden hebben van technieken met ingebouwde zelfcontrole, zie je vooral een forse achteruitgang in kwaliteit. Tegenwoordig zie je vooral de quick&dirty; benadering terugkomen, aangemoedigd door zogenaamde 'sprints'. Vast ook de reden waarom we overstroomd worden met een hoge frequentie aan 'updates' en logischerwijs ook de bijbehorende problemen.


"die in de praktijk wel werkt, en dat is: SQL" . De 'taal' die als gegevensbenaderaar is opgenomen in de verschillende 3Gl's. SQL zie je bij de financiële instellingen ongeveer niet in productie draaien als zelfstandig onderdeel en al helemaal niet met rechten om iets te veranderen. Veel te gevaarlijk. Vraag het eens na.



" object georiënteerde taal" …. Ik raad het niemand aan. Schattige domino effecten van ingebouwde erfenissen zijn het gevolg. Wat ik wel aanraad is het benutten van een life-cycle geörienteerd ontwerp en die op de Jackson manier gestalte geven. Professor Verhelst probeerde met 'Merode' er al eens mee aan de haal te gaan, maar ging voorbij aan de échte ontwikkelingen in JSD. LBMS kocht de Jackson aanpak op, positioneerde het als 'technisch' en probeerde daarmee hun eigen 'methode' voorrang te laten krijgen, maar als je écht kwaliteit wil, dan geniet het moderne JSD nog steeds de voorkeur, juist in een administratieve omgeving en zonder allerlei merkwaardige watertjes bij de wijn te toen. Gewoon de échte regels toepassen, ook bij online (dus vooral niet denken dat het dan anders zou moeten.... ), complexe systemen, etc.
Prettig nauwkeurig. Gemakkelijk testbaar. Goed onderhoudbaar. Geen geknoei. Daar hou ik van.

Ronald

Je wil dat we de moeite nemen de commentaren te volgen.
Dat zijn er nogal wat.

Lastige is dat niet helemaal duidelijk is wat wordt beweerd.

Het begint bij de stelling dat het niet zo moeilijk is spaghetti code te ontwarren.
"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."

"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."

Hoe dat automatisch kan volgt in later posts :
1) AI die mensen niet begrijpen : "De nauwkeurigheid van het werk van échte conversie software, gaan de mogelijkheden van de mens te boven." en "AlphaZero voegt iets toe zonder dat wij mensen, kennis nemen van de door die AI opgebouwde strategie. Helaas. Want er lijkt duidelijk wel iets van te leren." of "Dat software de mens in behendigheid meer dan de baas is, is kennelijk in sommige kringen nog niet geaccepteerd."
2) Toch met met menselijk hulp : "Aan de zijlijn laat je de beste en positief ingestelde mensen meekijken en bijsturen."

Dus we snappen het niet dat het allemaal automatisch kan en het kan eigenlijk ook niet allemaal automatisch :-P

Hozanna over de mogelijkheden van nu en onmogelijkheden van het verleden en dan met schaakprogramma's
en y2k problemen aankomen en priemgetallen, variabele namen en wat function parameters beschrijven ?

Gaat Alphazero die functionele specs uit de code halen en wordt dat tegengehouden door
"de outsource lobby die het hoger management nog immer in hun greep hebben" ?

Over positief ingesteld mensen gesproken ;-)
De enige reden dat we je niet geloven is dat je ongeloofwaardig bent.
Maar we hebben wel genoten :-)

@Dino's veelvuldige 'we' / 'pluralis majestatis'? Voer voor psychologen.

Het UWV werkt met falende partijen.Tijd voor verandering. Besturing toevoegen, meer controle, krachtige inventarisatie, alles beter dan doormodderen.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2019-12-20T11:27:00.000Z Pim van der Beek
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.