Technology

Deel via:

De public cloud: zowel de pijn als het medicijn

Met de komst van software en diensten uit de public cloud slaakte de IT-wereld een zucht van verlichting. Eindelijk was het gebruikmaken van state-of-the-art oplossingen en technologie niet enkel voorbehouden aan grote corporates met diepe zakken. En eindelijk waren organisaties – deels – verlost van ellenlange implementatietrajecten.

Het succes van de public cloud had echter een keerzijde. Het gevolg van dat gemak van ‘software uit de kraan’ is niet zelden een lappendeken van applicaties. De applicaties werden veelal gekozen door de business managers die verantwoordelijk zijn over het functionele gebied van die oplossing. Zij kijken wat zij nodig hebben, en zijn niet per se geïnteresseerd in hoe die oplossing al dan niet past in het geheel.

Eilandjes met eigen datasets

Het gevolg: eilandjes die vaak niet of nauwelijks met elkaar konden communiceren. En bovendien allemaal afhankelijk waren van een eigen dataset. Overigens was en is dat probleem niet enkel voorbehouden aan software uit de public cloud. Ook private clouds en on-premise-installaties kunnen ontaarden in een gefragmenteerd IT-landschap waarvan van enige cohesie nog nauwelijks sprake is.

Het grootste probleem van die versnippering is de fragmentatie die het teweegbrengt in het datalandschap. Wanneer iedere afdeling zijn eigen applicaties moet managen, ontstaat het gevaar dat er wordt gewerkt met meerdere versies van de werkelijkheid. Data leven versnipperd in spreadsheets, die vaak met de hand worden ingevuld.

Functionele beperkingen

Die situatie biedt ook functionele beperkingen. Stel, je bent een supermarktketen, en je hebt de HR/medewerkersregistratie ondergebracht in een aparte cloudoplossing. Maar je medewerkers zijn ook klant. Alles met betrekking tot klantdata zit echter in een andere database, beheerd door een geheel andere oplossing. Het gevolg: een enkele persoon ‘leeft’ onder meerdere entry’s in de organisatie. Dat is niet handig, want wellicht wil je alle medewerkers standaard korting geven. Dat vereist dus ingewikkelde koppelingen tussen beide databases.

Een aantal organisaties zoekt de oplossing in de aanleg van een enkele data lake waar alle applicaties uit putten. Ze verzamelen alle gegevens uit alle oplossingen op een plek, en hopen die data smart te maken. Maar zo’n data lake is niet zaligmakend. Voor je het weet zit je met een enorme berg gegevens. Het is dan nauwelijks meer helder welke data ‘smart’ is, en waar je dus werkelijk businesswaarde uit haalt, en welke gegevens puur ballast zijn.

Basis voor smart data

Grappig genoeg is precies diezelfde public cloud onderdeel van de oplossing. Zo werkt ons moderne data- en applicatieplatform SAP HANA ook probleemloos op Azure, Google Cloud Platform of Amazon Web Services (AWS). Je kunt in die omgevingen niet alleen je applicaties hosten, maar ook de basis leggen voor een smart data-omgeving.

Die constructie, een SAP HANA-omgeving op een publieke cloud, geeft natuurlijk een geheel nieuwe dimensie aan hoe veel organisaties de publieke cloud zien. Zowel de constructie als het afrekenmodel is afwijkend. Je investeert in je eigen SAP HANA-licentie, maar je draait deze investering op iets dat een ‘pay-per-use’-model kent.

Die ‘mix’ lijkt in eerste instantie verwarrend, maar verrassend sterk als het gaat om businesswaarde. Je krijgt immers de volledige controle over je eigen platform dat geheel van jou is, terwijl de onderliggende capaciteit en verwerkingskracht kan meegroeien (of krimpen) met je organisatie. Op die manier krijg je het beste van beide werelden.

De uitdagingen die big data omgevingen en versnipperde applicatielandschappen met zich meebrengen, vereisen een nieuwe, frisse kijk op de public cloud. Wil je ook af van je data-eilandjes, van big data eindelijk smart data maken en toch blijven profiteren van de voordelen van een public cloud? Ik ga graag eens met je in gesprek.

Leestip: IDC schreef een infobrief over ‘Data Management Platform for Digital Transformation’. Download de infobrief hier. 

Download