Newsletters




Should You Build or Buy Database Monitoring?


Bookmark and Share

There are many points in life where you may ask yourself whether it is better to build or buy. Think of a new house, a business, or an application. Regardless of the object of discussion, answering certain upfront questions can act as a guide to help you along the path to the right solution.

Given the increasing importance, complexity, and breadth of database systems, the question of whether to build or to buy database monitoring is an important one to consider. Now, as a software guy, I need to clarify that I am not advocating one approach over the other. Instead, I want to establish that there are good use cases for both and provide a useful framework for determining which direction may be right for you.

It starts with the four key questions you should ask yourself:

  • What are the requirements? What are the “must haves” versus “nice to haves”?
  • Does a commercial solution exist that at least meets minimum requirements?
  • Is there a specific, tangible advantage to be realized by building compared to what is available commercially?
  • What is the total cost of ownership (TCO) of the build-versus-buy options?

Let’s dive a little deeper into each of these areas.

Requirements: The first step is to get input from all of the stakeholders who will consume monitoring data or will need to act on alerts. This includes DBAs, developers, and application owners at a minimum but may also extend to other roles such as systems, storage, or virtualization administrators.

Your goal is to get a good understanding of what data each person needs, how they will act on it, and how monitoring data will allow them to make the right decisions. Be as thorough and detailed as possible when defining these requirements. Be realistic on the “must haves” and try not to throw in the kitchen sink. And, be sure to take into account best practices.

Evaluate What Is Available: After requirements have been defined, the journey can begin. A quick Google search will likely yield a number of options for consideration.

Here are some things to look for:

  • Features that match requirements
  • Testimonials and customer reviews
  • Satisfaction with the product and support
  • Specific strengths and weaknesses of the monitoring solution

In addition to the above research, evaluations are likely in order. All of the key boxes might get checked, but taking the candidate solutions for a test drive can go a long way in determining a good fit. This phase will likely involve deploying the product in your environment, which is a great opportunity to get additional information that you may have missed during your research by observing the product in real-world scenarios. Restricting candidates for evaluation to two to four choices can save time and effort.

Competitive Advantage: Determining if there will be a competitive advantage by building monitoring software is a bit nebulous. Database monitoring tools in general are fairly mature for the major RDBMS vendors. Only database management systems without a significant installed base are likely to not have any commercial off-the-shelf (COTS) monitoring solutions available. Still, if you don’t find a solution that meets your minimum criteria, you may be looking at a build scenario. In fact, many great startups resulted from needs that aren’t met by COTS products.

TOC: Purchasing perpetual COTS licenses is usually straightforward, in my experience. Costs to consider are the list price, the initial purchase/negotiated price (usually some percentage of list), then maintenance (normally somewhere around 20% of list price due annually).

The TOC for building a solution is a bit more ambiguous, but still estimable. Costs to consider include development of the product, potential integration with other technologies, security, administration, opportunity cost (associated with not monitoring) while developing, and maintenance of the product when new versions/drivers are released on the target RDBMSs. Software development being what it is, a contingency factor of at least 20% should be built into the cost for rework, bug fixes, course adjustments, and so on. And hey, if you do succeed in traveling the happy path during development, that’s cost reduction that can flow directly to the bottom line.

Plan for Tomorrow

 The decision to build versus buy is a key one. This framework will help you make a decision that is right for your database environment. Regardless of what that decision is, the most important thing is that you don’t ignore the need to better understand your database and optimize it for not only today’s business needs, but those to come tomorrow, as well.  


Sponsors