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.
