Nogal wat leveranciers van softwarepakketten adverteren met hun ondersteuning van meerdere merken databases. En het zijn niet de minsten. Onder hen: SAP, Opentext, en Topdesk, om er maar een paar te noemen. Als enige eis stellen deze applicaties dat er een SQL-compliant database wordt gebruikt. Elke serieuze relationele database spreekt dit protocol.
Oppervlakkig beschouwd klinkt dat aanlokkelijk: welk merk database in je organisatie al aanwezig is, Oracle, IBM DB/2, MS SQLServer of MySQL: het gaat werken. Dat scheelt installeren, het opleiden van je beheerders en het onderhandelen met een databaseleverancier.
Toch is het gewoon een slecht idee en moet je dit niet willen. Waarom niet? Er zijn argumenten van technische en architectonische aard. Daarover graag een volgende keer. Hieronder een simpeler reden: geld. Je betaalt bij zo’n applicatie teveel licentiekosten voor de database en voor de licentiekosten van het pakket zelf.
Licentiekosten database
De afgelopen decennia hebben leveranciers van databases enorm veel functionaliteit toegevoegd aan hun producten. Waar databanken in het (verre) verleden uitsluitend de opslag van gegevens regelden in tabellen, zijn deze in de loop van de tijd geëvolueerd tot geavanceerde platforms met de introductie van autorisatielagen, integriteitscontroles, stored procedures, triggering mechanismen en zelfs embedded fileservers, webservers en jobschedulers. Voor al die mooie functies wordt dan wel stevig betaald door de afnemers. Zelfs de instaplicentie van een database van één van de grote merken kost al snel duizenden euro’s per jaar.
In tegenstelling tot de standaardtaal SQL, (die overigens vele dialecten kent) zijn al die extra opties leverancierspecifiek en daardoor niet (zomaar) uitwisselbaar. Pakketten die meerdere SQL-databases ondersteunen gebruiken daarom alleen die opties van een database die altijd aanwezig en universeel zijn: het verbinden met de database en de opslag van data. Dat is natuurlijk doodzonde: al die mooie opties van jouw database worden niet gebruikt. Maar je betaalt er wel voor.
Licentiekosten pakket
Om meerdere databasemerken te kunnen ondersteunen moet een pakketleverancier flink investeren. Tenslotte moet hij minimaal testen of zijn applicatie ook echt werkt met al die SQL-databases. Dat betekent kosten voor de licenties van al die gegevensbanken, het inhuren of in dienst nemen van personeel met de benodigde kennis, testen, extra infrastructuur, et cetera.
Jij, als afnemer van zo’n pakket kiest echter (meestal) maar één optie: SAP met Oracle of Opentext eDocs met SQLServer. Je betaalt dan echter eveneens voor de ontwikkelkosten van SAP met SQLServer, DB/2 of SAP-DB. De licentiekosten van de applicatie zijn dus (aanmerkelijk) hoger voor functionaliteit waar je als afnemer niets aan heeft.
Niet doen dus, die applicaties die meerdere databases ondersteunen. Dat is het weggooien van (veel) geld. Kun je echt niet om een pakket heen, omdat het de standaard in jouw branche is of de functionaliteit precies aansluit bij jouw behoefte: kies dan voor de goedkoopste database, al is deze nieuw voor je organisatie. Je beheerders zullen er weinig werk aan hebben want van al die geavanceerde functies wordt toch geen gebruik gemaakt. In alle andere gevallen: kies een pakketleverancier die keuzes durft te maken en optimaal gebruik maakt van de opties van jouw dure database.
Jurrie Zaat, managing consultant Orcado
Klinkt als een logisch verhaal, maar het gaat te kort door de bocht.
Vanuit een software leverancier perspectief is het inderdaad duur om je applicatie te laten landen op veel verschillende database systemen. Het kost immers ontwikkelkracht en tijd om te testen en ingewikkelder om te onderhouden. Het is echter een feit dat als je het niet doet, je klanten dus zult mislopen. Als je pakket dus groot is, kun je de keuze voor 1 database niet makkelijk meer maken.
En ja, door geschikt te zijn voor veel databases mis je alle functionaliteit die de verschillende systemen bieden en is de database eigenlijk het sluitstuk van de applicatie geworden. Daarnaast speelt er ook het performance issue. Met generieke code bereik je geen grote performance.
Een mogelijkheid om de propositie naar klanten slimmer te maken is door je software als een dienst aan te bieden met daarnaast API’s om integratie mogelijk te maken. Daarmee kun je als software leverancier WEL profiteren van de voordelen van een specifieke database EN ontzorg je de klant EN los je het probleem van de extra licenties op.
Het argument “Niet doen dus, die applicaties die meerdere databases ondersteunen” vind ik echter slecht onderbouwd. Of je een pakket aan wilt schaffen hangt in mijn ogen niet af van dit database verhaal, maar van andere eigenschappen, namelijk welke waarde het biedt ten opzichte van de investering en operationele kosten.
“kies dan voor de goedkoopste database, al is deze nieuw voor je organisatie” vind ik ronduit een gevaarlijk advies. Je zegt tegen een bedrijf technologie op te nemen waarover het zelf geen kennis en dus controle op heeft. Dan zit je dus vaak aan *nog* een partij vast die dat deel voor je moet beheren. Maar ook qua veiligheid, misschien doe je wel dingen die de veiligheid van je hele infrastructuur op het spel zetten.
Laatst zag ik nog een bedrijf die zelf een Wiki in de lucht takelde op basis van Linux en open source terwijl het bedrijf daar nauwelijks kennis over had. Maarja, het was zo goedkoop… Een levensgevaarlijke keuze.
Slecht verhaal..
Je hoeft vaak niet de meest uitgebreide (dure) versie van een RDBMS aan te schaffen, juist omdat niet alles gebruikt wordt door de applicatie.
Maar de auteur gaat compleet voorbij aan de eisen die een klant stelt aan de complete stack (applicatie + infrastructuur). Bijvoorbeeld beschikbaarheid, performance, backups, monitoring, kwaliteit support, etc.
Dan kan domweg de (qua licentie) goedkoopste database ineens heel erg duur uitpakken.
‘Je beheerders zullen er weinig werk aan hebben want van al die geavanceerde functies wordt toch geen gebruik gemaakt.’
Haha.. Ja, want een compleet onbekend RDBMS, die installeer je even op een vrijdagmiddag. Kan meteen in productie..
Die extra DB features heeft een beheerder vaak sowieso geen werk aan, maar heeft impact op de eigen ontwikkelaars (rapportages bouwen of stukje maatwerk).
Hetzelfde kun je dan zeker generieker doortrekken naar platforms. Kies geen MS Office, want dat draait naast Windows ook op MacOS!
Gebruik geen apps! Want die worden zowel voor iOS als Android ontwikkeld, dus duur..
Enzovoorts..
Juist hierom hebben veel (grote) bedrijven de voorkeur voor zo min mogelijk verschillende platforms. Bijv. alles Linux-Oracle, AIX-DB2 of Windows-SQLServer. Omdat die specialisten zo duur zijn en je niet voor elk pakket weer de “goedkoopste” database wilt kiezen die afwijkt van de standaard.
Grote pakketleveranciers spelen hier op in, vraag-aanbod vanuit de klant dus.
Beste Henri,
Dank voor je uitgebreide reactie.
Mijn stuk(je) was nu juist niet vanuit het perspectief van de leverancier geschreven, maar vanuit de klant. Je merkt terecht op dat er nog veel meer nadelen zijn bij universele applicaties, performance is er daar inderdaad één van.
Mijn punt is dat de ondersteuning van meerdere databases vaak wordt gezien als een voordeel en dus koopargument terwijl ik dat om meerdere redenen juist als een nadeel zie. Je opmerking dat je als leverancier geen keuze zou hebben vind ik onjuist. Er zijn genoeg voorbeelden waarbij die keuze wel is gemaakt en het pakket erg succesvol is. Denk bijvoorbeeld aan Microsoft Dynamics, Oracle Applications of Exact.
Bij het aanbieden van een applicatie als dienst is de keuze voor de onderliggende database inderdaad minder van belang, maar dat lijkt me een andere discussie; namelijk die over de voor- en nadelen van het in huis hebben van systemen of het inkopen van diensten.
En tja, een gevaarlijk advies. Dat valt maar te bezien. Er is, lijkt me, nog wel een verschil tussen ergens totaal geen kennis van hebben en genoeg om het in de lucht te houden zonder specifiek getrainde databasebeheerders te hebben rondlopen. Bovendien zijn de gegevens in de onderliggende database (waarvan ik het belang juist erg groot acht) meestal slecht afgeschermd bij generieke applicaties. De data is te muteren zonder (goede) integriteitscontroles en vaak is er maar 1 gebruiker die “alles mag”. De veiligheid is dus sowieso een issue. Dat je door te kiezen voor een nieuwe database je totale infrastructuur in gevaar brengt waag ik daarom nogal te betwijfelen.
Beste JW,
Jammer dat je het een ‘slecht verhaal’ vindt. Wel leuk dat ook jij uitgebreid reageert.
Dat klanten voor 1 platform kiezen komt, zeker bij grotere organisaties, volgens mij maar weinig voor. Mijn punt is overigens ook niet dat klanten ‘zo maar’ nieuwe besturingssystemen of smaken databases moeten installeren maar wel dat ze applicaties moeten kiezen die zijn geoptimaliseerd voor hun (bestaande) omgeving en niet degenen die pretenderen alles te ondersteunen .
Je voorbeeld van het doortrekken van de gedachte naar officepakketten is onbedoeld een aardige. Zoals je ongetwijfeld weet is de ondersteuning van MS Office op het OSX-platform heel veel slechter dan op Windows. Het is eigenlijk zelfs een ander pakket en niet alle onderdelen (zoals Access of Outlook) worden voor OSX geleverd. In feite heeft Microsoft hier dus wel degelijk een keuze gemaakt. Aan de andere kant gaat die vergelijking wel een beetje mank: er is bij dat pakket geen directe andere relatie met andere software zoals een database. Daar ging het mij nu juist om.
En ja: een standaardinstallatie van een database installeer ik prima in een vrijdagmiddag. Je mag me bellen! 😉
Er is gewoon een markt voor Applicaties voor meerdere rdbms’en.
Veel opensource pakketten werken overigens ook gewoon met mysql/mariadb/postgresql/mssql/oracle. Dan heb je nog frameworks als PearPHP waarmee je nog meer (DB)backend onafhankelijk kan ontwikkelen.
Volgens mij is porten naar meerdere databases eenvoudig als je beetje ervaren bent.
Het argument “Oppervlakkig beschouwd klinkt dat aanlokkelijk” is waar. Maar is net zo goed waar als het gaat om een andere database kiezen dan dat je standaard hebt. Tja. Weinig spectaculaire conclusie maar het ligt dus helemaal aan de omstandigheden wat wijsheid is. Het advies om niet altijd blind te kiezen voor wat je ooit als standaard hebt benoemd vind ik trouwens wel goed. De enige standaard die wat mij betreft altijd gevolgd moet worden is ‘gezond verstand’.
Slecht verhaal.
Mijn perceptie : de auteur werkt waarschijnlijk in de MKB context.
Een pakket als SAP levert ook MaxDB dat 5% van de SAP licentieprjs kost.
Bovendien spelen hele andere redenen mee voor de DB keuze zoals JW al aangaf.
Verder leveren sommige van die “dure” opties zoals Oracle Advanced Db Compression en Automatic Storage Management wel degelijk substantiele voordelen op, waardoor er toch een business case voor zou kunnen bestaan.
Jurrie,
Advies om de goedkoopste database te kiezen is nogal betrekkelijk als non-functionele aspecten zoals beschikbaarheid en prestatie meegenomen worden in de overweging. Dat er bezuinigd kan worden op de licenties zal ik niet ontkennen maar beter in dat geval om vanuit business vereisten te rekenen in plaats van weer als de gebruikelijke ‘supermarkt manager’ op de kleintjes te letten en daardoor het grotere geheel missen.
Betreffende je in reactie gegeven veiligheidsaspecten gelden deze m.i. ook voor de vele oplossingen waar iedere applicatie zijn eigen database heeft, inrichtingsfouten zijn naast SQL injectie nog altijd de meeste voorkomende oorzaak van digitale inbraken. En ja, dit kan impact hebben voor de hele infrastructuur.
Opmerkelijk vaak worden de databases die meekomen met (non-Enterprise) applicaties niet consistent onderhouden, veel legacy hier doordat sommige al lang niet meer ondersteund worden door database leverancier maar nog wel gebruikt worden door de applicatiebouwer.
Hallo Ewout,
Dank voor je reactie.
Punt is dat bij universele applicaties de beschikbaarheid en prestaties van het geheel niet afhankelijk zijn van de zaken die jij noemt. Dat is althans de bewering van de leverancier, anders zou deze wel degelijk een voorkeur voor een database uitspreken. Overigens ben ik dat inmiddels in de meeste gevallen ook wel eens met deze leveranciers. De performanceverschillen van de grote databases zijn inmiddels (als je geen gebruik maakt van onderscheidende kwaliteiten) erg gelijk. (Voor ik hier een nieuwe discussie mee ontlok: hierover graag een andere keer…)
Dat is juist de reden dat ik in voorkomende gevallen inderdaad op de kleintjes (nou ja) adviseer te letten. (Komt misschien ook omdat wij veel werken voor (grote) Food retailers ;-), dus @kj: nee, de auteur werkt (voornamelijk) niet in de “MKB context” maar voor grote ondernemingen en (rijks)overheden.))
Je hebt gelijk dat die veiligheidsaspecten die ik noem (in een eerdere reactie) niet voorbehouden zijn aan dit onderwerp. Daarom vind ik ze als zodanig dus ook geen sterk argument tegen mijn betoog.
Met je laatste opmerking ben ik het volledig eens. Reden te meer om de onderliggende database bij (standaard-) applicaties erg serieus te nemen, lijkt me.
Jurrie,
Ik denk dat ik me bij KJ aan ga sluiten, het advies van leveranciers lijkt me niet de meeste objectieve bron.
Grappig dat je (rijks)overheid noemt want daar zie ik inderdaad nog weleens houtje-touwtje combinaties die niet alleen slecht presteren op de database maar ook op de opslag, opmerkelijk vaak hebben deze trouwens een blinde voorkeur voor Oracle net als bepaalde retailers.
Leuk om wat te besparen op licenties maar als je dan het dubbele kwijt bent aan hardware dan lijkt me dat niet echt slim, veel databases zonder DBA zijn tenslotte verre van optimaal ingericht. Leuk voor de leveranciers maar naar mijn opinie gewoon weer ‘penny wise and pound foolish’ en wat je dan ook nog weleens ziet is dat er voor die afwijkende databases geen back-up of monitoring agents zijn, het blijven vreemde eenden.