test data management tool kopen of zelf bouwen?

5 punten om te overwegen bij het nemen van deze belissing

October 21, 2019 | Maarten Urbach

Je bent je aan het oriënteren op het gebied van test data management, je zoekt informatie online en je ontdekt dat er tegenwoordig meerdere leveranciers zijn die een ‘test data management’ oplossing aanbieden. Dit loopt uiteen van data virtualisatie tot subsetten en maskeren. Het enige wat jij wilt, is betere beschikbaarheid van testdata en een manier van werken met test data management die beter past bij de huidige status van softwareontwikkeling (DevOps, Agile, etc.). Hoogstwaarschijnlijk ben je wat softwareleveranciers tegengekomen, sommige daarvan nogal aan de prijs (Delphix, CA, IBM). Dus je begint na te denken over het zelf bouwen van een applicatie of het gebruik van een open source test data management tool. Dit is altijd een interessant onderwerp en in dit blog wil ik een aantal dingen bespreken die je in je achterhoofd moet houden bij het nemen van deze beslissing.

1. Complexiteit van de database

Wanneer je een beslissing wilt nemen over het kopen of zelf bouwen van een oplossing, is de complexiteit van de database belangrijk. De simpele gedachte in dit geval is: hoe hoger de complexiteit van je database, hoe groter de behoefte aan een gepatenteerde tool. Waarom?

Het bouwen en onderhouden van een tool voor een eenvoudige database (<100 tabellen) is prima te doen. Maar als de database en het datamodel complexer worden, wordt het wat ingewikkelder. De complexiteit van een database kan worden gemeten aan de hand van bijvoorbeeld het aantal tabellen, kolommen en de beschikbaarheid van foreign keys.

Zelf een oplossing bouwen is één ding, het onderhouden ervan is een tweede. Wie gaat de maskering of het subsetten onderhouden? Wat gebeurt er als de Autoriteit Persoonsgegevens jouw maskering onvoldoende vindt? Is het mogelijk om eenvoudig maskeringsregels toe te voegen of te wijzigen? Wat gebeurt er als de persoon die alles heeft gebouwd, vertrekt en alle kennis met zich meeneemt?

2. Aantal features

Stel je voor dat je een kleine database hebt. Dan is het dus waarschijnlijk mogelijk om zelf een maskeerapplicatie te bouwen. Maar kun je ook een virtualisatie- of subsetapplicatie zelf bouwen? Misschien kun je dat, maar is dit nog steeds goedkoper dan het kopen van een kant-en-klaar product. Denk bijvoorbeeld aan het feit dat het 2 tot 3 fulltime banen kost om zoiets zelf te bouwen.

Wij zijn van mening dat je echt moet overwegen om een kant-en-klare oplossing te kopen als je aan meerdere vereisten (maskering, subsetting) wilt kunnen voldoen.

3. Aantal database technologieën

Ook het aantal database technologieën speelt een rol bij het nemen van de juiste beslissing. Als je slechts één type database hebt (bijvoorbeeld Oracle of SQL Server), dan kun je misschien overwegen om er zelf een applicatie voor te bouwen. Als je meerdere database technologieën hebt, dan wordt het meteen al een stuk ingewikkelder.

De tijd die nodig is voor het ontwikkelen van een applicatie om je test data te maskeren en subsetten of voor het maken van een virtuele database, zal aanzienlijk toenemen als het gemaakt moet worden voor meerdere database technologieën. Ik zou je echt niet adviseren om dit zelf te bouwen, vooral als je het vergelijkt met onze prijzen.

4. Ontwikkel snelheid

Als je software ontwikkelingssnelheid hoog is, zul je waarschijnlijk veel features moeten maken. Maar nieuwe features kunnen allerlei wijzigingen veroorzaken op je database. Veranderingen in je database hebben invloed op je test data management; nieuwe data, nieuwe tabellen, nieuwe kolommen. Dit is geweldig, maar het drukt ook op het onderhoud van een mogelijk zelfontwikkelde applicatie. Dit kan veel problemen veroorzaken en het kost je bouwer(s) veel tijd – als hij/zij nog steeds voor je werkt.

5. Nieuwe versies van DB

Laten we kijken naar Microsoft, Oracle, IBM en/of welk database type je hebt. Deze organisaties blijven altijd doorontwikkelen op hun database technologieën. Wij willen allemaal die nieuwste versies, toch? Maar heeft dit invloed op je zelfontwikkelde test data management oplossing? Wat gaat er gebeuren, wie is er verantwoordelijk? Dit kan een grote (en dure) uitdaging worden.

Conclusie

Het belangrijkste om te onthouden is hoeveel moeite, tijd en geld het zal kosten om zelf een applicatie te bouwen vergeleken met wat het kost om een product te kopen. Het bouwen van een applicatie kan kostbaar zijn in termen van tijd en geld. je hebt waarschijnlijk meerdere ontwikkelaars nodig voor de dev-fase en wat kost dat? Meerdere salarissen in ieder geval. En hoe staat dit in verhouding tot het aanschaffen van een kant-en-klaar product? Dit is wat je moet overwegen. De conclusie die wij in de meeste gevallen hebben kunnen trekken: met de aankoop van onze tools is het rendement op je investering gemiddeld één jaar. Daar kan een zelfgebouwde tool meestal niet tegenop.

Wil je weten hoe DATPROF jouw organisatie kan helpen met goed test data management? Neem vrijblijvend contact op. We helpen je graag verder!

Get in touch with our experts

Contactform

  • Dit veld is bedoeld voor validatiedoeleinden en moet niet worden gewijzigd.

Data Masking

DATPROF Privacy

Data Subsetting

DATPROF Subset

Data Automation

DATPROF Runtime

Data Discovery

DATPROF Analyze