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!
Wederom een leuk artikel Jeannot,
Als je IT het wilde westen is, is dat vaak een indicatie dat de gehele organisatie dat is. Of dat de business niet in control is en IT niet begrijpt.
Wel vind ik dat je met dit stuk de kloof tussen Dev en Ops weer extra aandacht geeft zodat deze alleen maar groter wordt.
DBA’s of SysOps komen vaak uit het Kingdom of No, omdat hun belang vaak ligt bij het realiseren van uptime, of hebben een sterke mening over wat er allemaal niet goed is aan NoSQL. Overigens ben ik met je eens dat NoSQL uitnodigt tot maatwerk en overigens ook dat Postgres een hele fijne database is. Toch kennen NoSQL oplossingen ook gewoon stored procedures, al zien die er anders uit. Tja ACID. Ook hier zijn wel werkbare mogelijkheden in al lijkt bankverkeer een brug te ver.
Shadow IT is een symptoom, niet het probleem.
die Henri. Kritiek op kloofverbreding maar zelf met aankomen met frasen dat IT niet begrijpt dat business in control is en dat DBAs en SysOps uit Kingdom of no komen, behalve nosql dan. No law vs not structured. De query language. Dump die rommel maar in het datameer. IT als spelletje, slecht voetbal en de scheids is de schuld. Hoe zit het ook alweer met Blatter en Governance ?
@Jeanot
Hoewel ik het belang van een goede DBA vanuit een groot aantal praktijkervaring absoluut onderschrijf betwist ik je voorbeeld van RBS,
@Henri
Wat ben jij langzaam van begrip…..
Enterprise en DevOps zijn een appels en peren vergelijking als we overwegen dat de laatste zich primair richt op business niveau doordat het een extensie op agile is. Nu meen ik me te herinneren dat ik al eens tegen je gezegd had dat we in de jaren 90 (bank) dit dus de pijplijn noemden. En dit was niet de Enterprise Service Bus want die eer kwam MQ Series toe…..
DevOps is een horizontale schoorsteen waar vaak in de vorm van een messagebus nog een horizontale overheen ligt. Natuurlijk kun je ook alles in ‘datalake’ dumpen en dan de rietjes uitdelen maar geheid dat je dan problemen krijgt met de governance. De check & balance van ‘chinese walls’ in de vorm van seperation of powers zijn nogal belangrijk als ik kijk naar de Libor rente jongens.
Ewout, je verwacht wel dat mensen door jouw regels heen lezen en en alle omdenk bruggetjes direct begrijpen, maar zelf doe je dat dus niet.
Ik schrijf : Dev en Ops, geen DevOps
Dev staat voor development *niet* per se software development, en kan dus ook gewoon Business Development zijn. Ops staat over de operatie. De mannen die zorgen dat de operatie functioneert en blijft functioneren.
Waar ik in geloof is dat mensen samen meer bereiken en als je team betert samenwerkt. Door ze dicht bij elkaar te houden en samen te werken maak je de kloof kleiner.
Alles gaat sneller tegenwoordig. Dus als je faalt mee te gaan met de veranderingen (adaptability), dan ga je als bedrijf gewoon de bietenbrug op.
Moeilijk word het niet.
Ik denk ik mogelijkheden jij in beperkingen. Moet je kijken welke skill beter is adaptability 😉
Bruggetjes. maar waarnaar dan ? vroeg de autist. Inderdaad geen ict-business gat meer nodig, die kloof regelen we zelf wel intern. Je hebt trouwens nog meer interpretaties, automatiseren van development met continuous delivery, daily builds en agile en het automatiseren van beheer, met scripting en bijv tools als puppet, cfengine, chef. Maar er is bljkbaar hoop Henri, met je wild wild webservices. Eerst zat je er steeds naast, maar nu ben je slechts langzaam van begrip, althans dat lees ik hier. Ewout heeft nog best veel geduld want hij had het je allemaal nog eens uitgelegd, meent hij zich nog te herinneren 🙂
Wat was het antwoord op de productiviteitsparadox ook alweer. Artikel laast hier. Ik meen meer pauze nemen en dan weer oogkleppen op en ertegenaan.
@Henri
Dev en Ops noemen en dan beginnen over samenwerken……
Als ik me niet vergis gaan bedrijven met teveel ‘adaptability’ op dit moment de bietenbrug op doordat ze zoveel problemen hebben met de skillset integriteit. Ken je het begrip scope creep?
@Felix
Begin ondertussen toch wel mijn geduld te verliezen met Henri ‘rapportgenerator’ Koppen die een klinkende mening heeft over de hybride cloud maar niet eens weet wat het dan precies betekent. Goed hij heeft iets gehoord van zijn vriendje Reza over IAM maar snapt ook hier niet het belang van Check & Balance.
Ongestructureerde bankrekeningen structureren deze jongens wel achteraf, de eventuele kasverschillen die hierbij ontstaan werken ze net als in Rijks ICT-dashboard wel weg met een mooie grafiek. Lang leve de Systems of Engagement die beleving belangrijker vinden dan de feiten.
Artikel lijkt enigzins te zijn afgeleid van : http://www.cio.co.uk/insight/data-management/jim-starkeys-nosql-low-down-it-wont-solve-big-data-3598479/?page=2
Ben trouwens benieuwd of de auteur een mening heeft over SAP HANA. Waar bij NoSQL de applicatielogica naar de client side is verplaatst, gebeurt bij HANA (ook) het tegenovergestelde, applicatielogica op de database middels sqlscript. Check bijvoorbeeld HANA Extended Application Services : https://blogs.saphana.com/2013/04/25/introducing-sap-hana-extended-application-services-xs/
@Ewout: Klopt. Ik weet niet precies wat hybride cloud betekent want er is ook geen consensus over. Dus kun je het niet precies weten. Of wel weten, maar zijn er mensen die er anders over denken, dus maakt weten of niet weten eigenlijk niet uit.
Reza heeft een goed stuk over IAM geschreven en ik doe ook erg veel met IAM, dagelijks.
Ik bouw dingen en breng alles een stukje verder. Scope creep heb ik inderdaad vaak mee te maken en geloof dat het een *goed* iets is, als je de juiste strategie hanteert. Ik maak liever iets wat men nodig heeft dan wat men oorspronkelijk heeft afgesproken.
Jij bent vooral de “advocaat van de Duivel”. Zo iemand heb je ook nodig in het team. Iemand die niet meteen mee gaat, maar meer dan een klankbord ben je niet, want als je alleen maar tegen bent kom je niet verder.
Felix, je vergeet saltstack! 🙂
En JSON REST API’s FTW!