If you made a list of the “Top Five All Time Favourite” principles, then I’m sure “Buy Before Build” would be on the list. It just seems like one of those obvious statements. Why wouldn’t you buy of the shelf – proven – software to reduce delivery risk, outsource (non-core) software development, and gain incremental improvements through upgrades.
That’s all very good in theory, but it only works well if the off-the-shelf software provides a good functional fit in terms of business processes, data and organisation, as well as a good technical fit in terms of non-functional requirements and existing technology environment.
The Buy-Before-Build Anti-pattern
This anti-pattern exists when an organisation deploys off-the-shelf software with a poor fit. The result is a pile of custom developed code to change the off-the-shelf software (as illustrated below).
Why would this happen? A poor fit exists when:
- The (assumed) business processes built into the off-the-shelf software requires significant business process re-engineering. A system implementation project can accommodate smaller changes, but larger changes are unlikely without a dedicated effort. And that’s of course assuming it is in the organisation’s interest to align business processes. Off-the-shelf implies commoditisation, and no one would like to commodities their business advantage.
- Integration with existing IT systems will be difficult and expensive, where the off-the-shelf software implicitly assumes itself to be the data and/or process master. Even if the new system has a perfect functional fit, the custom code required to ensure good synchronisation between two masters is the perfect recipe for cost blow out.
- Operation management of an off-the-shelf software system designed for business hours only operation may prove impossible to do within an 24 by 7 environment. Gaps are likely to occur due to long-ish maintenance windows, lack of true redundancy and insufficient configuration management.
Buy-Before-Build is the answer, if the off-the-shelf software provides a “good enough” functional, operational and technical fit – and if future upgrades remain feasible and without too much complexity. If it isn’t then the organisation might have bigger problems to tackle (technical debt?) or it’s trying to standardise its competitive advantage – In those cases, build-before-buy might be the better option (at least in the short-term).