Often times the evaluation of whether to build or buy software is undertaken without complete information. Additionally, items that are taken as givens often end up not coming to fruition leading to increased cost and an undesirable effect.
Given the complexity of the IT landscape, technical purchase decisions are made daily. Once of the most common conundrums is the battle between opting for commercially available, shrink-wrapped products or developing custom solutions.
The software industry has not done much to help customers as there is a clear focus on development tools, environments and platforms over the development of a viable and healthy partner ecosystem.
When confronted with a business problem that will require a technical resolution, after clearly defining the problem space the quandary of solving the resultant problem will come to the forefront. Quite naturally, the first question should be that of, “Build versus Buy.”
Many a company has watched IT spending skyrocket and be paired with poorly performing internally developed applications. This problem was so rampant that it has caused a seismic shift in the behavior of company management.
I want to address the main challenges and questions faced as a firm embarks on this strategic and potentially expensive decision.
This decision process is far clearer than most realize.
For the purpose of this article, we will assume the following:
1. The company is not a software development company by trade.
There is rigor and discipline that comes along with developing software professionally that is absent in most other organizations. From specification, test and check-in processes to documentation, scheduling and release management discipline the world of a software development firm is very specialized. Add to that the reality that software development does not stop with the release of the software, but rather continues through the updates of the application(s), improvements, support and roadmap and you have a project of indeterminate length and perpetual cost.
Even for a firm that is in software development, the best solution is sometimes to buy rather than build.
2. The problem (to be solved) is one that has viable buy options on the market.
There will be occasions where the problem to be solved is either not common enough or simply too unique to have a mass market solution available.
This is the space where custom development becomes a viable option (note the word was “custom” not “customer”).
It could be that at one time in a company’s history, there were options to purchase ‘turn-key’ solutions. As time goes by, the reason for purchasing them may become forgotten.
Build
Once it is determined that a custom solution must be built, the following areas should be evaluated:
1. What parts can be purchased entirely?
a. Are there similar sized reference customers? b. Are they using the software in the same way we plan to? c. What is the support model for the company that we are buying from? d. Does the software allow interfaces to other systems through a documented set of APIs? (and does support extend to this avenue) 2. Will e have to create any custom code?
a. Will core components need to be architected (proprietary processes or interfaces in the company that would not be addressed via a shrink wrapped solution) It could be that the belief was no and it turned out to be yes. b. Will any interface/presentation layer need to be created for our users? c. Will there be a need to integrate the solution into the help desk/issue tracking system? d. Will there be a need for any ‘Glue Code’ or interface middleware to connect systems or push/pull date to/from data stores? 3. Are we equipped to handle this project?
a. Do we have the requisite
- Staff
- Expertise
- Time
- Resource
- Procedures
b. Can the project bear the risk of development?
c. Does this project and its constituent architectural components support and enhance our internal technical roadmap?