Project teams have been debating the build-versus-buy question for decades. Some people believe that it’s always better … purer, more worthy of praise … to build your own application, others will insist that the drawbacks always outweigh the benefits in coding your own app. But I think most of us agree that there are benefits in both building and buying, the real question is which choice best meets an organization’s project goals and capabilities.

In general I find that the axiom “Buy to standardize, build to compete” is a good rule of thumb. If a solution is going to address a company’s core business differentiators, then building a custom solution may provide real benefits. But if the solution is going to automate standard processes, why waste time and money reinventing the wheel?

Beyond strategic value, you also have to factor in costs, time to deploy/time to market and skill sets. I suggest that enterprises use a Build or Buy risk analysis to determine whether it is more appropriate to custom build or purchase a product.

Here are some questions to consider in your analysis:

• Is there enough money available to analyze, design, and develop a custom system? Do we have a proven way of determining the ultimate cost of this process?
• Does the source code have to be owned or controlled?
• Does the system have to be installed as quickly as possible?
• Is there a qualified internal team available to analyze, design, and develop a custom system?
• Is there a qualified internal team available to provide support and maintenance for a custom developed system?
• Is there a qualified internal team available to provide training on a custom developed system?
• Is there a qualified internal team available to produce documentation for a custom developed system?
• Would it be acceptable to change current procedures and processes to fit with the packaged software?
• Will the software need to be adapted to address advances in technology or new threat vectors? If so, do we have the needed skill set to monitor and adapt the software quickly, and can we safely assume we will retain that same set of skills in the future?

And while there may be room for debate in Build vs Buy, most people agree that best practice dictates that if you buy, don’t modify.

InfoWorld did a great job of explaining this in their article on Build vs Buy:

Build vs Buy has been under debate for decades, and we’ll no doubt keep discussing it. But I’ve noticed an odd thing lately, solutions providers are offering what appear to be off-the-shelf software packages which actually turn out to be a build project, something that isn’t explicitly spelled out in the feature lists.

For example, in our Protegrity Data Protection System (DPS) 5.1, which will be released shortly (a free upgrade from DPS 5.0 for our customers who are on the maintenance plan), we offer ‘DB integrated tokenization’ which eliminates application changes because it is engineered to provide easy deployment by database plug-ins (we will release plug-ins for Oracle and SQL Server with DPS 5.1, with plug-ins for other databases to follow very shortly after). We provide a ‘Single administration interface’. No programming is needed.

But another available ‘solution’ is in reality only an API/toolkit with a framework and routines that developers/programmers must program to when integrating with existing applications. The vendor refers to it is a ‘Single developer interface.” — a nice-sounding way to say that programming is needed and applications must be changed.

Buyer beware — make sure to ask questions about deployment times as well as feature sets. Protegrity’s transparent approach allows us to deploy in typical environments in weeks instead of the months needed with other solutions.