BUY OR BUILD A TEST DATA MANAGEMENT TOOL?

You’re thinking about test data management and you’ve searched the internet. Today there are multiple vendors offering a ‘test data management’ solution. This may differ from data virtualisation to subsetting and masking. All you want is a better test data availability and a way of working with test data management that suits the current state of software development (DevOps, Agile etc.) better. So should you consider buying a test data tool or should you built one yourself?

In all probability you came across some proprietary software vendors, some of them really expensive (Delphix, CA and IBM). So you’re starting to think about building an application on your own or using an open source test data management tool. This is always an interesting topic and in this blog I want to share with you some things to consider while making such a decision about buying a test data tool or building one.

1. COMPLEXITY OF DATABASE

If you want to make a decision about buying or building a solution, the complexity of your database is an important one. The simple thought in this case is: the higher the complexity of your database, the higher the need for a proprietary tool. Why?

Building and maintaining a solution for a simple database (<100 tables) is doable. But if the database and the data model is getting more complex it gets a bit more complicated. The complexity of a database can be measured by for example the number of tables, columns and the availability of foreign keys.

Building a solution yourself is one part of the story, maintaining it is another. Who is going to maintain the masking or subsetting? What happens if privacy authorities find your masking insufficient? Is it possible to easily add or change your masking? What happens if the person who built the solution leaves and takes all the knowledge with him/her?

2. NUMBER OF FEATURES

Imagine that you have a small database. Then it is probably feasible to build a masking application yourself. But can you also create a data virtualization or subsetting application? Maybe you can, but is this still cheaper than buying an off the shell product, taking in to account that it might cost 2 to 3 fulltime jobs to build something yourself?

We believe you should really start considering buying a ready-made tool if you’ve got multiple requirements to meet.

3. NUMBER OF DATABASE TECHNOLOGIES

The number of technologies is also a factor. If you only got one database type (e.g. Oracle or SQL Server) then maybe you could consider building an application for it yourself. If you’ve got multiple database technologies it gets more difficult straight away.

The time it takes to develop an application for masking and subsetting test data or create virtual test data will increase significantly if you have more than one database technology. I really wouldn’t advise you to start building it yourself, especially compared to our pricing.

4. DEVELOPMENT RATE

If your software development rate is high you’ll probably create a lot of features. But new features can cause multiple changes is your database. Changes in your database have an impact on your test data management; new data, new tables, new columns. This is great, but it also pressures the maintenance of your (possible) self-developed application. This can cause a lot of trouble and will take up a lot of time for your (one-man) team (if he is still working for you).

5. NEW VERSIONS OF DB

Then we’ve got Microsoft, Oracle, IBM and/or whatever kind of database vendor you might have. These organisations won’t stop developing on their database technologies. We all want that Oracle and others keeps developing new versions! So new versions of your databases will be released. But does this have any impact on your self-developed test data solution? What will happen, who’s responsible? This may be challenging and thus expensive.

CONCLUSION

The main thing to keep in mind is how much effort it will cost to build vs to buying a test data tool or a product in itself. Building a product can be costly in terms of time and money. You’ll probably need multiple developers for the dev-phase and what are the costs? Multiple salaries? Compared to buying a product? This is what you should consider. The conclusions we’ve made in multiple cases is: with the purchase of our tools, the return on investment is on average one year.

Do you want to know how Accoled Technology Consulting can turn things around at your organization? Contact us without obligation. We’re happy to help!