Schiet de DBA sneller dan zijn shadow-IT?

Ooit waren databaseadministrators (dba’s) de onbetwiste sheriffs van de it-infrastructuur van een organisatie. Door de groei van de zogeheten ‘shadow it’ krijgen ze echter steeds minder controle over hun werkterrein. De opkomst van agile ontwikkelen en webapplicaties wordt door sommigen wel vergeleken met het Wilde Westen: data stores gevuld met gestructureerde en ongestructureerde data, die als bandieten opduiken door de gehele organisatie.

Hoe voorkomt de DBA een open vuurgevecht met de applicatieontwikkelaars? Veel enterprise-organisaties hebben complexe legacy systemen. Het gevaar van agile ontwikkelen is dat er buiten deze systemen om nieuwe datasilo’s ontstaan waar de DBA geen controle over heeft. Onderzoeksbureau Gartner schat dat in 2017 de helft van de data die is opgeslagen in NoSQL DBMA’s schadelijk zal zijn voor een organisatie. Dit komt men name door het ontbreken van goed beleid over het beheren van databases.

De DBA die voorzichtigheid suggereert of probeert processen in te voeren om de risico’s te verminderen, wordt echter gezien als een vervelende vertragende factor bij het bouwen van applicaties. Om de cowboy-analogie nog wat verder te trekken: de DBA is een sheriff die een saloon binnenloopt en door zijn prangende blik stoppen de bandieten met wat ze aan het doen zijn en verbergen ze hun verboden zaken onder de tafel. Hoewel de relatie tussen een DBA en applicatieontwikkelaar nog niet zo slecht hoeft te zijn, ik overdrijf graag een beetje, is het herstellen van de orde in de schaduw-ict van een organisatie wel een fikse uitdaging voor een DBA.

DBA’s zijn altijd verantwoordelijk geweest voor het onderhouden van de dataflow, stabiliteit en integriteit van een organisatie. Nu de hype rond Hadoop en NoSQL het hoogtepunt bereikt, lijkt het soms wel alsof it-afdelingen hun workflowprocessen opofferen om aan de organisatie te kunnen laten zien hoe responsive en agile ze kunnen zijn. En dat is geen goede zaak, want hoewel NoSQL-oplossingen ideaal zijn voor sommige workloads, vereist hun inzet goede planning en beheer.

Uitdaging bij NoSQL

Het gebruik van NoSQL-databases binnen een organisatie heeft een aantal consequenties. Ten eerste zijn NoSQL-databases niet ACID-compliant. Dit betekent dat de transacties in de database niet voldoen aan de vier regels (atomic, consistent, isolated, durable), die voorkomen dat meerdere gebruikers data lezen of schrijven in de database waardoor er inconsistente situaties kunnen ontstaan. Sommigen NoSQL-oplossingen claimen ACID-compliance in een single document, maar de robuuste data-integriteit die enterprises tegenwoordig vereisen, hebben doorgaans complexe applicaties nodig voor het ‘zware werk’ dat relationele databases al verrichten.

Ten tweede kunnen NoSQL-oplossingen alleen data opslaan en het niet verwerken. Data moet naar de applicatie gebracht worden voor analyse. De applicatie, en dus elke afzonderlijke applicatieontwikkelaar, is hierdoor verantwoordelijk voor efficiënte toegang tot data, de implementatie van beleidsregels en dataconsistentie.

Dit zorgt niet zelden voor problemen, omdat elke NoSQL-oplossing een andere dataweergave heeft en er verschillende toegangs- en bewerkingstalen worden gebruikt. Bovendien kunnen NoSQL-only oplossingen geen stored procedures ondersteunen en is er geen mogelijkheid om code te hergebruiken, standaarden op te stellen of talented resources te vinden. Al bovenstaande zaken en het eerder genoemde ontstaan van ongestructureerde datasilo’s voor elke nieuwe applicatie, zorgen ervoor dat er voor een DBA moeilijk beleid te voeren is.

Consequenties

Dat dit tot grote problemen kan leiden, weet elke zichzelf respecterende enterprise organisatie. Zeker downstream heeft serieuze consequenties, daar kan de Royal Bank of Schotland (RBS) sinds afgelopen zomer over meepraten. Door it-problemen faalden honderdduizenden betalingen, waardoor een groot deel van de uitkeringen niet tijdig bij de ontvangers terecht kwam. Met alle gevolgen van dien.

Bij het lezen van deze ellende, dacht ik direct aan de technische oplossingen die Postgres hiervoor kan leveren. Zo kan ongestructureerde data gecombineerd worden in relationele tabellen, zonder dat dit ten koste gaat van de ACID-compliance. Daarnaast ondersteunt Postgres ongestructureerde data stores, maar wel zo dat ontwikkelaars schema rules op geselecteerde data kunnen toepassen om aan het bedrijfsbeleid te voldoen. En zo kan ik nog wel doorgaan, maar ik wil hier ook niet te veel uitweiden over de positieve kanten van Postgres.

Samenwerking

Eén belangrijk punt wil ik nog wel maken: controle houden over schaduw-ict lukt niet door alleen naar de techniek te kijken. We moeten voorkomen dat de volgende fase in de ontwikkeling van it-architectuur een soort ‘gunfight at the OK Corral’ wordt. Voor diegenen die niet zo bekend zijn met de historie van het Amerikaanse Wilde Westen; dit vuurgevecht voor een bar aan de Mexicaanse grens in Arizona, waarbij drie beruchte cowboys werden gedood, is één van de bekendste aller tijden. Zowel applicatieontwikkelaars als DBA’s moeten een manier vinden om samen te werken. Alleen in een team kunnen ze laten zien dat it voor vrijwel elke organisatie concurrentievoordeel oplevert en de bedrijfsstrategie ondersteunt. Dus handen van de trekker!