Met alle as-a-Service begrippen als Iaas, PaaS en SaaS lijken informatiefuncties en diensten steeds makkelijker als een service te kunnen worden geleverd. Of het nu infrastructuur zelf, het platform waarop ontwikkeling en operatie plaatsvindt of de toepassing zelf is, we kunnen steeds makkelijker deze diensten extern betrekken. De spiraal van standaardisatie en groei, dan verdere standaardisatie en verdere groei, heeft ertoe geleid dat afgelopen twintig jaar informatievoorziening een algemeen goed is geworden. Met serieuze consequenties wat betreft externe afhankelijkheid voor organisaties van die globale standaardisatie en platformen.

In de oude tijd van cliënt/server toepassingen waren het vaak afdelingsgerichte applicaties die op de server via cliënts werden aangeboden aan de afdelingsmedewerkers. Dat maakte het nodig om afspraken ‘slechts’ afdelingsbreed te maken over processen, procedures, gebruikte data en informatiestromen. Overzichtelijke functionele gebieden waar de afdelingsleiding de ‘macht’ had voor zijn afdeling processen en informatiestromen in te richten en de te gebruiken data te definiëren. Het verlaten van de oude mainframe-platformen ten gunste van deze lokale applicaties leidde tot nieuw flexibiliteit in functionaliteit maar tot verlies van centrale data-afspraken. Centrale mainframes konden slechts functioneren als datamodellen en onderliggende entiteiten en attributen nauwkeurig in datastructuren waren vastgesteld en vastgelegd.

Datastructuren
Deze afspraken over datastructuren maakten het mogelijk dat verschillende toepassingen via de data makkelijk konden worden gekoppeld en konden samenwerken in integrale processen. Maar dat maakte nieuwe applicatie-ontwikkeling minder makkelijk omdat die nieuwe applicaties òf volledig aan bestaande datastructuren moesten voldoen òf over het gehele applicatiegebied datastructuren moesten worden aangepast. Toen in het cliënt/server tijdperk deze door velen toegejuichte verruiming ontstond, gaf dat een explosie in nieuwe lokale applicatie-ontwikkeling maar de voorheen strikte en logische data-koppeling tussen applicaties verdween.

De ene applicatie in afdeling X kon een heel ander datamodel hebben als andere applicatie in afdeling Y. Vrijheid blijheid op het gebied van toepassing, maar groeiende gefractioneerdheid op het gebied van integraal datamanagement. De opkomst van applicatie centrische architecturen. Elke afdeling werd een zelfstandig subsysteem. De komst van ondernemingsbrede applicaties als ERP en PDM bracht dan ook veel inspanningen met zich mee om bestaande afdelingsprocessen en deze generieke ondernemingsprocessen met elkaar te koppelen. Immers als de datastructuren verschilden, moesten datastructuur-koppelingen worden toegepast. De opkomst van ETL-applicaties – extract, transform, load – die datesets vertaalden van de ene applicatie naar de andere applicatie. Het koppelen van subsystemen in een groter bedrijfssysteem.

Van enterprise applicatie naar multicloud
Maar omdat enterprise applicaties nog steeds binnen de grenzen van de onderneming bleven, kon de leiding van die organisatie nog steeds bepalen welke applicaties met welke datastructuren op welke technische platformen moesten draaien. En daar nette lange termijn ROI-berekeningen op los laten. Om de processen te laten passen binnen deze nieuwe enterprise en afdelingsapplicaties waren langdurige en vooral dure Business Process Redesign projecten aan de orde van de dag. Vaak was het herontwerp inclusief de implementatie van de nieuwe processen vele malen duurder dan de nieuwe enterprise software zelf. En het bewaken en garanderen van de Quality of Services maar zeker over de Quality of Data over al die via ETL gekoppelde data-omgevingen was een fikse uitdaging.

Met de komst van de cloud werden in eerste instantie ‘equivalenten’ van de enterprise applicatie services buiten de deur als dienst ingekocht. Vaak waren enterprise applicaties natuurlijk al geoutsourcet en was de stap van outsourcer naar cloud-leverancier een niet al te grote stap. En als de datastructuren van deze enterprise toepassingen grotendeels gelijk bleven, was de overgang naar nieuwe cloudtoepassingen goed te managen. Totdat het aantal cloudleveranciers ging groeien. En de ‘afdelingsbehoefte’ aan nieuwe functionaliteit en diensten toenam. En totdat de IT-afdeling het overzicht van ingekochte informatiediensten ging verliezen. En totdat de overheid strengere compliance eisen aan data en processen ging stellen. Opeens werd de organisatie zelf een ‘afhankelijk subsysteem’in een wereldomvattend informatiesysteem.

De verdwenen grenzen van de organisatie
Al deze vanzelfsprekende ontwikkelingen hebben één vervelende bijkomstigheid: het houdt niet op bij de grens van de organisatie en de impact van ontwikkelingen buiten de organisatie op de organisatie zelfs worden groter. Elke organisatie is nu een subsysteem dat onderdeel is van een wereldomvattend systeem dat wordt beïnvloed door alle systemen er omheen. Daar is geen simpele ROI-berekening meer op los te laten, omdat je niet weet wat volgend jaar nodig is cq noodzakelijkerwijs veranderd zal moeten zijn. Moet ik belastingdata anders inleveren, heb ik nieuwe partners die andere data-uitwisseling willen, zijn er nieuwe competitieve clouddiensten waar de organisatie gebruik van wil maken?

Omdat organisaties geen informatie-grenzen meer hebben en nu zelf elk als een afhankelijk subsysteem in een overkoepelend systeem moeten kunnen blijven functioneren, is de noodzaak om van Capex naar Opex te gaan een sine qua non. Waarop is nog serieus af te schrijven wat betreft platform, werkplek en productie-omgeving? Ouderwetse ROI-berekeningen voor de lange termijn informatieproces-inrichting is bijna onmogelijk geworden. Daarnaast is het voldoen aan de groeiende compliance wetgeving, investeren in nieuwe IoT-toepassingen, bijblijven met cybersecurity en de voldoen aan de toenemende groei in generieke data-standaarden kostentechnisch een enorme uitdaging. Naast het aannemen of inhuren van schaars beschikbare deskundigheid zowel op strategisch, tactisch als operationeel niveau.

Informatiekwaliteit als een dienst
Het als transformerende organisatie afnemen van informatiediensten in een veranderende wereld levert te veel variabelen op om lange termijn robuuste investeringsprojecten op dit gebied te initiëren. Een ‘big bang’is onmogelijk en dus is noodzakelijkerwijs ‘klein fijn’geworden. In een eerdere blog ‘Zwarte zwanen, witte zwanen’ over strategiekeuzes in onzekere situaties schreef ik dat het accepteren van onzekerheid de enige optie is. In onzekere tijden moet je een gezond eigen beleid hebben dat op korte termijn voldoende stabiliteit geeft maar tevens genoeg instabiliteit toelaat om snel van koers te kunnen wijzigen.

We zien bedrijven die 5 jaar geleden volledig voor de cloud kozen, nu op hun schreden terugkeren. De uitdaging is vaak serieuze data-integratie, -protectie en compliance als subsysteem in een groter systeem. Hoe garandeer ik in de cloud een ‘data-centrische architectuur’? De belangrijkste stabiliteit is ‘eigen’workforce, productieproces en onderliggende (bedrijfs-)data. Vanuit dat gegeven kan het invullen, inhuren en gebruiken van de gewenste (beperkte) toepassing, functie, taak of dienst relatief eenvoudig plaatsvinden. Richten op een lange termijn doel, daar eigen kennis en kunde voor ontwikkelen en flexibel diensten inhuren. En zodra dat einddoel tenslotte helderder, concreter en stabieler wordt wat betreft de noodzakelijke informatie-huishouding, kunnen de lange termijn investeringen en contracten  (weer) concreter worden.