During a recent discussion I was asked if I was a supporter of “buy” or “build” philosophy for software solutions. Whilst I think this is an unusual question as I feel you should evaluate each software component on its merits, it is still a valid question and is getting more relevant as technology progresses. I actually think there are at four main options with nuances of within the “buy” option that need to be considered.
- Re-use / Refactor existing solutions
- Rent (SaaS)
Every organisation should have a set of “Architecture Principles/Guidelines” that describe both the landscape into which the solution components must fit and the decision making process behind what to consider when replacing (or adding) software components..
It is also important to note that the buy option can have three distinct flavours;
- Configuration only (no code changes allowed, pretty much the same as rent)
- Minimal Code changes allowed, Generally less than 20% of code base and mostly additions rather than modifications
- Product is a base that you will heavily modify to be your own after purchase
Note – Option 3 actually fits more into the Build category as you will be going your own route and not taking any upgrades from the vendor as your version will be significantly different within a short timeframe.
Option 2 is interesting in that unless you work with the vendor to make your enhancements in a controlled and valid manner you can also make upgradability very difficult and expensive.
So when should you build? There are many reasons put forward for building your own software but in reality only one should be used as the catalyst for embarking on this route.
If the software component is a Business Differentiator then a Build approach MAY be a valid option. A “business differentiator” means that the software solution(s) gives you a competitive edge in you marketplace, in essence the solution is you IP and an accountable asset to the organisation.
If you decide to “build” then you should treat the software component as a real software “product” and make sure there is a PLM (product lifecycle management) process in place for it. Owning a piece of software that is critical to your business can turn out to be very costly if not approached in the right manner. It needs to have a multi-year budget, roadmap, comprehensive support & management program and most of all a “product owner” whose responsibility is to make sure it is not “over engineered” and does not become a black box or bottleneck that people are afraid to touch. Also be pragmatic and initiate regular reviews of the product’s technologies and viable commercial alternatives that may come to market.
If you do decide to build then the technology choice is key to ensuring your Internal Product is built in a manner that best meets your organisations needs. Do not immediately decide to build on a particular technology base just because you have the skills currently in-house. Conversely do not build on the latest and greatest new fad because your techies want to try something new. Build on a technology base that makes architectural sense to the needs of the organisation, future growth / expansion / usage & models. By all means be cutting edge if necessary, but beware of being “bleeding edge”.
It is also a good exercise to sit down and review your organisations software applications/components on a regular basis and look at the lifecycle management of each piece. As part of this process you should also engage in a theoretical exercise how would you would run the business just using the “rent” option, i.e. “cloud”. As you discount cloud options for components, work back through the buy, re-use and build options until you get to a sensible architecture that meets the needs of the business and justifies the costs/benefits from all perspectives. This will give you a realistic roadmap for a pragmatic approach as to what parts of your architecture landscape fit into which category for software ownership.