Hoe kies ik voor de juiste dataleverancier?

Welke leverancier is het beste voor de opslag van uw data? MarkLogic, MongoDB, Hadoop of toch een andere? In deze blog heb ik mijn eigen scoringssysteem ontwikkeld om elk van deze leveranciers te waarderen. En om antwoord te geven op deze cruciale vraag: Welke leverancier scoort het beste?

Ik koos verschillende richtlijnen voor hoe je een database/ tool selectie uit kan voeren. Zie hier het resultaat vanuit een ontwikkelaars perspectief.

Voorbereiding

Net als bij de aanschaf van een auto, houd je bij een tool/database selectie ook rekening met een aantal factoren. Dit zijn (af)wegingsfactoren. De wegingsfactoren waarin de partijen allemaal gelijk scoren heb ik uit de lijst gehaald, omdat deze waardes geen verschil gaan opleveren in het resultaat. Dit zijn onder andere: security, Active Directory Suport (LDAP) en Virtualisatie. Alle leveranciers voldoen hieraan, dus worden ze niet opgenomen in de lijst met wegingsfactoren.

Hieronder beschrijf ik de wegingsfactoren die je naar mijn mening mee zou moeten nemen bij het selecteren van een database en tooling:

Wegingsfactoren

Volledigheid

Met volledigheid bedoel ik: wat krijgt de organisatie na de installatie en kun je dan gelijk aan de slag? Ik keek naar de volgende aspecten:

• volledige ontwikkelomgeving;
• monitoring van processen, inkomende en uitgaande data en responstijd;
• ondersteunen van meerdere query(vraag) talen en toepassingen.

Prijs

Voor de score gaat het hier niet alleen om de kosten die je betaalt aan de leverancier (licenties), maar in de weging hou ik ook rekening met indirecte kosten. Zoals implementatie- en applicatiekosten die nodig zijn om te kunnen werken.

Marktbekendheid

Voor de merktbekendheid hanteer ik de kwadrant van Gartner. Is het gemakkelijk om expertise in te huren en naar wat de leverancier doet om zijn product in de
community te laten landen (gratis developer editie, forums etc.)

Integratie

Integratie is niet alleen het gemak waarmee verschillende applicaties aan elkaar gekoppeld kunnen worden, maar ook het aantal tools wat nodig is om je werk te kunnen doen.

Schaalbaarheid

Hoe makkelijk kunt u op- en afschalen om de snelheid te kunnen beïnvloeden, de volgende factoren worden meegenomen in de weging:

1. Support van Scale Out: hiermee wordt bedoeld het koppelen van verschillende apparaten i.p.v het zwaarder maken van 1 server. Deze techniek is vaak minder duur dan de server zwaarder maken.
2. Support van Map Reduce: Als aanvulling van de Scale Out methode is de map reduce een techniek waarmee over een cluster van machines op een snelle wijze data verzameld en getoond kan worden.

Complexiteit

Ik kijk niet alleen naar de investering aan energie, tijd en geld om deze techniek onder de knie te krijgen, maar ook naar het aanbod van documentatie, cursussen en support van de leveranciers.

Performance

Hiermee wordt de responstijd voor het opslaan van de data en de responstijd voor het
ophalen van de data bedoeld.

Flexibiliteit

Dit is de diversiteit van BI, Analytics en Data Science toepassingen die u kunt uitvoeren na het installeren van de database.

Verschillende bestandstypen

In hoeverre kunt u verschillende bestandstypen (json, xml, csv, video, audio en foto’s) met deze tool absorberen en indexeren. Indexeren van de data is belangrijk om de bestanden te kunnen zoeken op basis van kenmerken.

Omgevingsfactoren

Daarnaast is het belangrijk om rekening te houden met de omgevingsfactoren die spelen binnen de organisatie.

Kennis in de organisatie

De tooling en de database moeten aansluiten op de kennis van de organisatie. Organisaties die veel techniek en kennis opbouwen in de organisatie kunnen overweg met een Big Data database die bestaat uit meer lagen (en dus meer configuratie).

Leercurve

De leer curve is de tijd dat de organisatie nodig heeft om de database en tooling eigen te maken. Dit is ook weer afhankelijk van de kennis en kunde van ontwikkelaars en beheerders.

BI/Informatie Architectuur

Afhankelijk van de gekozen architectuur is de integratie van verschillende bronnen ook een must. In dit geval is het belangrijk dat de Big Data database kan communiceren met SQL databases en Message Queing (MQ service bussen) series.

Beheer

Hier gaat het om het gemak en dus de snelheid waarmee software/ processen overgezet kunnen worden naar verschillende omgevingen (OTAP straat) en het beheren van verschillende versies.

Weging

Voor iedere wegingsfactor bepaal ik de maximale score. Dit doe ik omdat ik niet alle wegingsfactoren even belangrijk vind (hierover later meer). Daarom kunnen deze factoren niet niet allemaal een even hoge score behalen.

Voor het scoren/wegen van de hierboven genoemde wegingsfactoren, gebruik ik een schaal verdeling tussen de 1 t/m maximale score. 1 is de slechtste score en maximaal het beste.

Verdeling Max. Score

Als u deze score in een matrix uitzet krijgt u het resultaat zoals in figuur 1. In deze matrix heb ik alleen de score uitgezet op basis van technische (on)mogelijkheden. Het business gedeelte is per situatie en toepassing afhankelijk en en moet u in de tweede kolom invullen.

1.4 Score matrix

Wanneer deze score uitgezet is in een matrix krijg je het het resultaat dat in figuur 1 wordt getoond. In deze matrix heb ik alleen de score uitgezet op basis van technische (on)mogelijkheden. Het business gedeelte is per situatie en toepassing afhankelijk en dient in de tweede kolom ingevuld te worden.

Score van Leveranciers

Om de verschillende leveranciers te scoren op deze factoren gebruik ik de formule: score factor pakket = ((wegingsscore pakket * wegingsscore ) + (wegingsscore pakket * wegingsscore))/10. Deze formule zorgt ervoor dat de score nooit hoger kan zijn dan dat er aangeven is bij de maximale score.

In de matrix kunt u precies zien welke leverancier het beste scoort. Zoals u kunt zien scoort de Azure SQL Server het beste. Maar de keuze is ook nog afhankelijk van het doel waarvoor u de database wilt gebruiken. En dan kan het zomaar dat er een andere uitkomst is. Mijn advies is om te kiezen voor Marklogic als u gaat voor een database gebaseerd op Data Lake. In deze blog leg ik uit waarom.