BLOG – In het artikel van Willem Beelen speelt impliciet een belangrijke vraag mee, die nog explicieter is te stellen: wat zijn de gevolgen van slecht opdrachtgeverschap bij de overheid?
Wanneer de overheid haar eigen digitale basis niet eerst helder definieert, gebeurt bijna automatisch het volgende: leveranciers gaan gaten vullen die door publieke infrastructuur en publieke normering hadden moeten worden ingevuld. Vendors bouwen dan oplossingen rond problemen die in wezen voortkomen uit het ontbreken van een gedeelde architectuur en gedeelde standaarden.
Daarom zou de overheid eerst voor zichzelf twee zaken moeten vastleggen. Ten eerste: welke lagen van de digitale infrastructuur moeten publiek, generiek, open en soeverein zijn? En pas daarna: op welke niet-kritieke of vervangbare lagen kunnen leveranciers meedoen?
- Fase 1: publiek huiswerk
De overheid moet eerst zelf bepalen:
- Architectuurlagen;
- Open standaarden;
- Governance;
- Compliance-kaders;
- Referentie-implementaties;
- Portabiliteits- en exit-eisen.
Als deze basis helder is, kan de markt daarop aansluiten.
- Fase 2: realisatie uitbreiding infrastructuur
Vervolgens organiseert de overheid een aantal generieke voorzieningen:
- Messaging-infrastructuur;
- Trust- en identity-voorzieningen;
- Document- en metadatastandaarden;
- Audit- en loggingvoorzieningen;
- Archief- en duurzaamheidseisen.
De realisatie daarvan hoeft de overheid niet zelf te bouwen, want kan plaatsvinden met platformleveranciers zoals IBM/Red Hat, Microsoft, Cisco, Huawei, Google, Netgear, Sophos, Atos, Capgemini, Exact of anderen die zich daartoe geroepen voelen. Het is cruciaal dat deze lagen ‘commodity’ worden en op termijn nagenoeg gratis zijn.
Daarbij moet dus gelden dat de infrastructuurlaag leverancierneutraal is. Net zoals een serverinfrastructuur van een ministerie of gemeente niet afhankelijk zou moeten zijn van één specifieke applicatieleverancier maar Linux, Unix, Apple e.d. een gezamelijke infrastructuur gebruiken. Daarbij moet wel gekeken worden naar wat de EU (aan tegenstrijdigs) op dat vlak heeft geformuleerd.
Historisch was dat ook het idee achter platforms als Windows Server Enterprise met daarboven oplossingen als SharePoint voor document lifecycle management en compliance. Of vergelijk het met de telecomwereld: een isdn-modem werkte probleemloos met een PBX van Siemens, Avaya, Nortel, NEC, Philips of andere leveranciers.
Tegenwoordig is https-443 feitelijk het universele transport. Alles daarboven wat niet tot een specifieke applicatie behoort maar elke applicatie nodig heeft, zou tot een generieke infrastructuurlaag moeten horen. Verticale toepassingen – van bijvoorbeeld Elastic, mintBlue, Palantir, Splunk of andere leveranciers – moeten zich daar vervolgens aan conformeren om überhaupt werkend te kunnen worden opgeleverd.
Een staatssecretaris van Transport zou bij de aanschaf van een nieuwe trein waarschijnlijk vreemd opkijken als een leverancier vraagt: ‘Waar komt onze rail eigenlijk het station binnen? We gaan er namelijk vanuit dat geen enkel bestaand spoor geschikt is voor deze trein.’ In de digitale wereld gebeurt dat echter regelmatig: leveranciers worden betrokken voordat de rails – de generieke infrastructuur en standaarden – zijn vastgelegd.
Doel
Als digitale soevereiniteit werkelijk het doel is, begint die dus niet bij de keuze voor specifieke technologie of leveranciers, maar bij het vaststellen van een publieke digitale basisinfrastructuur waar iedereen op moet aansluiten.
Anders blijft het moeilijk te begrijpen wat de rol van een staatssecretaris voor Digitale Economie en Soevereiniteit precies zou moeten zijn. Applicaties aanschaffen zoals van Elastic en mintBlue zal op zijn minst moeten wachten tot duidelijk is wat er absoluut niet toe mag behoren en ze dus als een virtuele test-infrastructuur erbuiten moeten meeleveren.
Rob Koelmans, directeur MetaMicro Automatisering
