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!
@Henri
In de semantische discussie over consensus en adaptability win jij en on-topic ben ik dus benieuwd wat auteur bedoeld met ‘vinger van de trekker’ aangezien je op dezelfde manier omgaat met servers in de cloud. Ik krijg de indruk dat mijn ‘omdenken’ meer aandacht krijgt nu de Dot.com economie een Bedot.com economie blijkt te zijn;-)
Uiteraard kun je ook doorgaan met je laagjes toe te voegen aan een oplossing waarvan het
fundament rap afbrokkelt, je adaptability versus de OODA-loop blijkt tenslotte steeds vaker de cognitieve dissonantie van marketing te zijn. Nu de DNB ook Sun-Tzun gelezen heeft en middels databewerkingsovereenkomsten met providers een soortgelijke datadrang heeft als Justitie met telefoongegevens moet je nog even kijken naar de definitie van scope creep.
De negatieve connotatie die hieraan hangt kun je uiteraard met een semantische discussie
proberen te bagatelliseren maar als ‘advocaat van de duivel’ wijs ik graag op het wankele vertrouwensmodel van: Mijn vriend is jouw vriend binnen IAM. Zelfs de WRR concludeert in rapport dat de Systems of Engagement niet om de feiten maar belevingen gaan en dat de semantische waarheidsbevinding van het poldermodel (consensus) dus steeds meer moeite heeft met de waarheid voorbij de dijken.
Aangaande IAM is het hoogst twijfelachtig of Reza die opinie geschreven heeft omdat dus de ‘echtheidskenmerken’ van om de drie woorden een uitroepteken en om de vijf woorden een verwijzing naar eerder schrijven mist. En dan zal ik nog maar niet eens ingaan op de cognitieve dissonantie van de consensus ladder middels het scorebord van Computable.
Experts krijg ik opgedrongen, mijn vrienden kies ik wat zorgvuldiger…