A recent post on CIO takes on the build versus buy question in enterprise software, framing the issue quite clearly:
A rational build vs. buy decision starts with well-defined requirements. Then potential products are evaluated to measure how well they meet those requirements. If you are considering replacing a homegrown product, include that in the evaluation. It is usually worth starting a new enterprise software project with an evaluation, even if the ultimate result is a development project. So how can the build vs. buy question be answered in a rational way without getting overwhelmed by all the work?
Part of what drives the impulse to build software is the idea that all requirements can be met through the effort. This, the author notes, is a mirage. “Resource constraints mean coding must be prioritized, and some requirements will never be met. Then the team may not fully understand the problem domain, and may not discover unknown requirements.”
A good starting point is using a tool designed for software evaluation and selection. To discover all requirements, reverse engineer features back into requirements: start with the homegrown code to develop a baseline, and then reverse engineer potential replacement products. This effectively builds a list of requirements that includes the unknowns. Importantly, front-loading requirements development drives down project risk.
Once a requirements list is established, requirements must be rated for importance. This not only helps build stakeholder buy in, but also ensures adequate capture of organizational needs.
Doing the math
The requirements should be leveraged to create the RFI/RFP sent to potential vendors. Responses should be scored in software evaluation and selection application, which will automatically do a gap analysis and calculate fit scores. Then the organization can move to the build or buy decision:
Once you have fit scores for the homegrown product and potential replacements, you can rationally answer the build or buy question. Assuming normalized fit scores where 100% means all requirements are fully met, if several cloud or off-the-shelf products have a fit score of 80 percent or more, then buying is the right way to go.
If all commercial products score lower than 60%, there are three other possibilities:
Each of the above increases the fit score. If none of these approaches works well enough, then building the app can be the right way to go.
If an enterprise has an in-house development team, there will always be a push to build. But it is usually cheaper and faster to buy than to build, and as the author notes, “If a problem has been adequately solved in a commercial product, why solve it again?”