Although the venn diagram shows the buy v/s build concerns in reality software has many interfaces and sides that a buy v/s build is never easy to arrive at. But echoed below are some common rants where the decisions turn this way or that way and choose either and do not get lost in the quagmire of decision making.
Buy
- We do not have the capability.
- That is not our core competency.
- We need it as an add on piece and is not our core function
- The cost of buy is much less than the one of losing the customer prospect.
- We do not have the time and the resources/skill set.
- We need to scale up fast to newer technology and not lose customers
- Packaged software which is time proven has already gone through the twist and turns.
- What is the shelf life of this product will it change hands or get
Build
- We need to develop something unique which will be our core strength going ahead.
- We can wait and build it ourselves.
- It will be our IP moving ahead.
- We will build components whose life-cycle is in our control.
- We could outsource this as well which means it is a kind of a buy with a different connotation.
- We like what the buy guys have to offer but it does not meet our requirements.
- What will happen to our legacy code ? Is there a reuse or can it be repackaged with a new interface for some more time.
- What new skills do we need on board? How much will be the wait time before we can roll it out using agile/RAD processes?
Both
- Will build some will buy some
- Will buy and still build some interface , connectors , glue code to interface the solutions.
- What about the internal organisation buy in are all the stakeholders in synch.
- Do we have people lined up and having loyalties of one v/s the other.
- How do we decide which way to go ? How much of either to choose and replace the other ?
- Look unemotionally on where you want to go as there would be a lot of forces for either debate. Stick to one approach and ensure the approach is agreed upon by all before the roll-out.
Post this debate once you have arrived at say three solutions A, B and C. Now using a weighted average method you can rule out any competing concerns. It is another thing if you have arrived at your architecture by white boarding and have done your due diligence. Also you can use some sort of cost benefit analysis to narrow down your choices. Use what works you to turn your enterprise around.