There are many decisions in life where we come across the question of build or buy. A new house. A business. An application. Monitoring software. Regardless of the object of discussion, answering certain questions can act as gates for helping us along the path to the right solution—for us as individuals or as companies.
Take database monitoring software for example.
- What are the requirements? What are the “must haves” vs. “nice to haves”?
- Does a monitoring solution exist that at least meets minimum requirements?
- Is there a competitive advantage to be realized by building?
- What is the Total Cost of Ownership (TCO) of the build vs. buy options?
Regarding requirements, be sure to get input from all of the stakeholders who will be involved or will benefit from the monitoring solution. This will include DBAs, developers, management, and application owners at a minimum, but may also extend to other IT disciplines (system admins, storage admins, VM admins, etc.). Be as thorough and detailed as possible when defining requirements. Be realistic on the “must haves” and try not to throw in the kitchen sink. Take into account best practices when defining requirements. There is a lot of good content out there on how to define requirements, so no need to be exhaustive here.
Does It Already Exist?
After requirements have been defined, the journey can begin. A quick Google® search will likely yield a number of alternatives for consideration. Some things to look for are:
- Features that match requirements
- Trusted reviews
- 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 talking with sales representatives from the vendors. This is a great opportunity to get additional information you may have missed during your research, or answers to questions that come up during evaluations. Restricting candidates for evaluation to three can save time and effort.
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 databases without a significant install 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.
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), and then maintenance (normally somewhere around 20% of list price due annually).
The TCO for building a solution is a bit more ambiguous. 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, etc. 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.
The decision to build vs. buy is a key one. It’s tempting to go down a path because it’s something that can be done. However, answering the questions listed here should help those making the decision to identify what should be done.