De kans bestaat dat de meeste transactionele data in uw organisatie nog in relationele databases als SQL Server, Oracle en DB2 is opgeslagen. Bij het moderniseren van uw applicatielandschap zal dit echter in rap tempo veranderen. Waarom? En wat betekent dat dan?
Moderne softwareoplossingen zijn service-georiënteerd en zeer gedistribueerd, waarbij de systems of record nauwelijks nog van een user interface zijn voorzien maar alleen goede, mediated api’s hebben die de businesslogica ontsluiten. En maatwerk realiseer je door middel van low-code en integratie bovenop deze api’s.
De compositie van deze services ontsloten door api’s vindt dus plaats op een hoger niveau. En dat is waar je onderscheidende vermogen zit. Daar gebruik je kleine apps die precies doen wat jij nodig hebt, volledig geïntegreerd met je applicatielandschap. De achterliggende systems of record zullen ondertussen ook gemoderniseerd gaan worden door de leveranciers, waarbij deze ook weg bewegen van de silo en relationele databasegedachte. Mark my words.
Drie problemen
Er zijn drie enorme problemen met de relationele database:
- Relaties worden hardcoded gelegd, om de referentiële integriteit te waarborgen. Daar is geen plaats meer voor in een op microservices en apps gebaseerde software architectuur;
- Transacties worden uitgevoerd in de context van deze ene database. Dat kan niet werken in een gedistribueerd applicatielandschap. Commit en rollback zijn fenomenen van de jaren tachtig die niet meer houdbaar zijn;
- En niet te vergeten, de kosten van relationele databases zijn veel te hoog omdat ze vaak op eindgebruikerslicenties gebaseerd zijn.
In de praktijk zie je relationele databases misbruikt worden om niet relationele data op te slaan. Gewoon omdat zo’n ding er nu eenmaal al is en beheerd wordt. En omdat het dan makkelijk met de backup mee kan. Dit is een slechte strategie. Daar moet verandering in komen. Nu.
Afscheid
Nu is de tijd om al langzaam afscheid te gaan nemen van de relationele database in je maatwerkoplossingen. Ga voor elke behoefte aan dataopslag na wat precies het doel is en hoe de relatie met andere data is te leggen. Er zijn tegenwoordig talloze opslag methoden, zeker in de cloud.
Om er een paar te noemen:
- NoSQL of Document database: hierin kun je bijvoorbeeld JSON objecten opslaan en makkelijk en flexibel in zoeken. Deze databases kennen geen schema;
- Graph database: hierin sla je uiteenlopende informatie op en kun je dynamisch n-op-m-relaties leggen. Ideaal om profielen samen te stellen en data naar je toe te laten komen die voor jou interessant zijn;
- Data lake: hierin kun je allerlei variëteiten en volumes van data opslaan en vervolgens big-data-analyses op doen. Dit zal ook vaak machine-gegenereerde data zijn, zoals door iot.
In een (micro)service architectuur is het van belang om eventual consistency te regelen. De database regelt dat niet meer voor je, simpelweg omdat dat niet kan over meerdere databases heen. Hoe je je services en api’s organiseert, wordt steeds belangrijker, inclusief de bijbehorende data-architectuur.
Hoe zit het dan met business-intelligence en -analytics? Die oplossingen zullen in rap tempo moeten meebewegen. Meer en meer data die nodig zijn om dashboards te vullen of rapporten te sturen, zullen niet uit relationele databases komen. Traditionele ETL is niet meer toe te passen. Kubussen zijn niet zo makkelijk meer op te bouwen. Artificial intelligence als onderdeel van je analytics-oplossingen, zelfs als het traditioneel terugkijken betreft (wat is er gebeurd?), is onontkoombaar. Laat staan als je voorspellend (wat gaat er gebeuren?) en zelfs voorschrijvend (wat moet ik doen om dit te realiseren?) oplossingen nodig gaat hebben. Over dat soort dingen moet je nu al gaan nadenken en je architectuur er op aanpassen. Stil zitten en wachten tot de hype overwaait is geen optie. De relationele database is al klinisch dood. En de bijbehorende SQL-vaardigheden kunnen naar de afvalberg.
Nadat ik dit gelezen heb kwamen een paar associaties “volgend jaar wordt het jaar van de linuxdesktop” en “a fool with a tool is still a fool”.
Dat ligt natuurlijk aan mij, ik ben te dom te begrijpen dat half internet geen mysql meer nodig heeft of dat Oracle ten dode opgeschreven is.
Gijs,
Ik waardeer je feedback op de reacties hoewel ik de ad hominem over IT-ers misplaatst vind maar dat zal wel mijn overgevoeligheid voor de valse profeten zijn. Over je geconstateerde ‘flawness’ in het service georiënteerde denken schreef ik trouwens 5 jaar geleden al dat SOA het bestaan van data negeert. En voor alle duidelijkheid, Gartner definieert SOA als volgt:
“Service-oriented architecture (SOA) is a design paradigm and discipline that helps IT meet business demands. SOME ORGANIZATIONS REALIZE SIGNIFICANT BENEFITS using SOA including faster time to market, lower costs, better APPLICATION CONSISTENCY and increased agility.”
Ik heb mijn ‘overgevoeligheid’ in definitie even in hoofdletters gezet want hierdoor zijn veel implementaties van SOA proces- en productgeörienteerd. Als de gepatenteerde software van een leverancier de inrichting van je bedrijfprocessen bepaalt dan wordt je in het pak van legacy genaaid. Voor alle duidelijkheid, het gaat niet om het volwassen worden van de data architectuur maar om de wijze waarop de informatie daaruit gehaald kan worden.
Volgens mij heeft Gijs de rapporten die hij heeft gelezen of niet goed begrepen of verkeerd geïnterpreteerd. Dat er naast relationele databases de alternatieve vormen meer in schwung raken is een belangrijke ontwikkeling. Alleen houd dat niet in dat de relationele database gedoemd is om te sterven. De relationele database is een bewezen en relatief eenvoudige manier om gegevens op te slaan. Naar gelang de eisen kan dit dus nog steeds ingezet worden. Er vindt nog steeds innovatie plaats bij relationele databases. Uiteraard niet zo veel meer als vroeger als de alternatieven.
Dat nieuwere manieren van gegevens opslaan beter lijken is ook relatief want net als alles hebben ook deze manieren hun sterke en zwakke punten. De kracht is juist als je in je applicatielandschap een hybride oplossing kiest die alle sterke punten samenvoegt en zoveel mogelijk zwakke punten neutraliseert je een behoorlijk goede fundatie hebt voor wat voor oplossing dan ook. Met name de laatste tien jaar is er qua standaardisatie van database API’s behoorlijk veel veranderd wat het leven van architecten en programmeurs zoveel malen makkelijker maakt dat meer met de echte problemen kunt worstelen.
Het is duidelijk dat Gijs tegen de lamp gelopen is met zijn ‘boeken wijsheid’ want ik krijg niet echt de indruk dat hij nog recentelijk zelf in de code heeft gedoken en met zijn voeten in de modder heeft gestaan. Wat databases betreft heb ik redelijk lang met het hele scala van varianten gewerkt en weet daarom ook dat als je SQL beheerst de overstap naar alternatieven het makkelijker maakt omdat je die abstracte denkwijze kan overnemen en toepassen in een ander context.
De meeste oudgediende ICTers zijn relatief conservatief en hebben zo vaak al de mooie verhalen van oude wijn in nieuwe zakken wel gehoord. ICT is geen speelveld voor al te veel modegrillen en waar vakmanschap, pragmatisme en lange termijn denken de boventoon vieren. Deze kernwaarden staan altijd in het centrum van welk succes in de ICT dan ook.
Beste Gijs, het aantal technologieën dat bij het grofvuil kan is niet meer op de handen van een heel leger IT-ers te tellen. Het aantal technologieën dat in de datacenters van de gemiddelde grote onderneming te vinden is ook niet.
Een organisatie zoals Gartner moet toch zorgen in de belangstelling te blijven, en zoveel anderen, en ook wel eens choqeren .
Er is natuurlijk evolutie, maar ook hypes als Industrie 4 en Internet of things zijn ook mooie verzinsels, die wel de verdienste hebben een gedachtengoed onder de aandacht te brengen, maar ook als business enabler bedoeld, om vooral bij directies ( die er toch niets van begrijpen) angst en onzekerheid aan te praten , dat ze de boot gaan missen.
In 1970 werden door IBM de Copics Black Books gepubliceerd, opgesteld door IBM ers en wetenschappers, met aanbevelingen hoe SW organisaties software konden ontwikkelen om organisaties te ondersteunen. De voorbereidingen zijn dan zeker meer dan een halve eeuw geleden gestart. Wat vond ik schattig daar in: productie machines aansturen met papertapes, aangemaakt door de computer. En data beheer: nog met ponskaarten, en bij wijziging werd geadvizeerd een Journalling kaart te ponsen.
Over die papertapes : die grote orgels die met brede ponsbanden aangestuurd werden is toch ook al automatisatie, geen idee wanneer de eerste tot stand kwam.
Op een sw-event stond ik als standhouder, toen een van de bezoekende studenten de opmerking maakte : ‘IBM heeft fout gemaakt door mainframes te ontwikkelen, ze hadden moeten starten met PC’s.’. Mijn reactie overtuigde de bolleboos toch : zonder mainframes waren er nog geen PC.s.
Dus zo maar iets op de vuilnisbelt zetten om,intressant te doen getuigt ook niet van inzicht.
@Ewout – volgens mij gaat data architectuur ook over hoe data er in gaat (dus niet alleen over hoe het er uit gehaald wordt).
@Johan – ik ben zelf jarenlang systeem ontwikkelaar geweest in een team wat een RDBMS en 4gl ontwikkelde en waarop (nog steeds) honderden klanten draaien met hun bedrijfskritische processen. Daarna jarenlang een R&D team geleid (en mee ontwikkeld) wat een integratie middleware oplossing ontwikkelde wat op Unix, Linux, VMS en Windows en Sybase, DB2, Oracle en SQL Server draaide waar uiteindelijk meer dan 500 klanten hun bedrijfskritische processen op draaiden. En vandaag de dag hebben we een team van 80+ specialisten die dagelijks met Azure PaaS oplossingen en service integratie bezig zijn. Dus praktijkervaring is er zeker.
@Robert – Klopt. Afscheid nemen is lastig. En daardoor stijgt de technical debt nog harder. We hebben alles wat ooit uitgevonden is allemaal nog steeds draaien in onze dc’s.
Gijs, maak het nou niet erger 😉
Gijs,
Mijn reactie ging over een ‘flawness’ in het service geörienteerde denken want daarin is data architectuur – wat een onderdeel is van de Enterprise architectuur – alleen maar de applicatie architectuur. En het is hierdoor dus lang niet altijd duidelijk hoe de data erin gaat en het is ook niet altijd duidelijk hoe – het recht om vergeten te worden? – je de informatie er nu weer uit krijgt.
@Ewout – Next Generation SOA (Thomas Erl) schrijft hier wel wat over. Ik was overigens een van de technical reviewers van dat boek. En AVG / GDPR is inderdaad nog een heel ander vraagstuk.
Gijs, een erg leuk en goed artikel. NIet eens met wat je schrijft, maar dat doet er niet zoveel toe. Gooi de knuppel maar in het hoenderhoek. Het zijn boude beweringen die je daar doet maar het maakt wel de discussie los. Hele goede en leerzame reacties gelezen en het zet aan tot nadenken. Als iemand die altijd op de mariadb uitkomt is het wel eens goed na te denken hoe je een DB kan en wil gebruiken.