Op de afgelopen Dutch Access Developer Day in Aalsmeer bleek dat veel overheden hun Access- en Excel-applicaties versneld uitfaseren omdat deze niet aan de in de Baseline Informatiebeveiliging Rijksdienst (BIR) gestelde eisen voor dataveiligheid kunnen voldoen. Zowel Excel als Access hebben mogelijkheden die je niet in andere ontwikkelomgevingen tegenkomt. Migratie naar een architectuur zonder gebruikmaking van deze applicaties geeft daardoor soms aanzienlijke complicaties.
Niet alleen applicaties met ingebedde gevoelige gegevens maar ook voor het nog zeer wijdverbreide twee-laags client/server-model is het zeer lastig fysieke toegang tot alle gegevens in de database te ontnemen, althans voor die gegevens waartoe de applicatie zelf toegang nodig heeft. De oplossing hiervoor is een webservice-laag tussen de client/server-lagen te plaatsen. Dit vergt echter ‘deployment’ van de webservice.
Klanten die MS-Office afnemen middels Office365 kun je gebruik laten maken van Flow om de applicatie geheel voldoend aan de BIR-familie en eventuele opvolgers te maken. Dat was nog veel simpeler geweest als Microsoft in Flow van Access en Excel ‘first class citizens’ had gemaakt naast PowerApps. Dit kan erop wijzen dat Microsoft niet van plan is Excel en met name Access nog 20, 30 jaar door te laten leven. Erg jammer want het onderscheidend vermogen van het cloud-first mobile-first beleid is over een jaar of tien compleet vervaagd.
Hoewel er bestaande libraries zijn die je in Visual Basic van Access en Excel kunt gebruiken, vindt men het momenteel nog lastig om JSON te produceren en te verwerken. Van Flow naar de ‘on premises’ database kun je gelukkig eenvoudig SQL-scripts ofwel Execution Queries gebruiken. Wat de plannen van Microsoft ook mogen zijn, de lees- en schrijfsnelheden die we met een dergelijke architectuur vanuit PowerApps hebben ondervonden geven alle reden om deze architectuur voor bestaande Excel en Access applicaties aan te bevelen. Een lokaal 1 Gbit/s netwerk met een client/server-applicatie kan er door optredende ‘overhead’ en ‘latency’ van het hele ODBC/ADO/DAO/OLE-DB-gebeuren zelfs niet tegenop.
