There are essentially two approaches for software development, build a solution yourself, or create it by using other software packages and perhaps integrating with other services. Both have merits and drawbacks and in this article we’d like to share how ‘being conscious of these’ can better help you to decide on and keep to the approach used. So what are each of these approaches and their underlying motivations?
Building a software solution from scratch essentially gives you complete control over the code. You get to decide exactly how you want to design the flow of business processes within the solution, how you want it to look and feel and how the data is stored and operated on. Essentially you have complete ownership of the solution, but the cost you pay is to invest time and money to build the solution from the ground up and be completely responsible for resolving support issues that arise.
Conversely, creating a solution by buying software gives the opportunity to ‘have a solution sooner’, which in a competitive market place can be an advantage. Add to that, the responsibility for maintenance of the solution is delegated to the provider of the packages that you use. But from a design standpoint, the drawback is that you do not have complete control of the code. So the emphasis is on getting the product that is the best fit to your desired processes, within a budget and considering ongoing support costs.
A variation of Buy, is to either create a solution based on building blocks of other products, or to use open source code which has a licence that enables you to use this in the way desired. Depending on the product(s), you may be able to obtain paid support, and having visibility of the code means that you have some freedom to be able to customise this if needbe.
Upfront, the key differentiator between build or buy is who designed the business processes. If you buy, someone else has already done this. It saves you that time and money developing it yourself, but you have to be prepared to potentially compromise your processes to fit with how the product implements them. And the devil can often be in the detail. It may not be until after an evaluation of a product has been performed and everything checks out ok, that you find something deeper down which needs to be changed.
If you unconsciously take the Buy approach and then (assuming the product vendor supports this) try to customise the product to fit your desired solution, you need to be conscious of mitigating the following risks:
- You’ll take longer to make the changes you need because you’ll have to learn a product that someone else has designed.
- You can no longer completely delegate support, because the end supplier is not fully aware of all the code.
- Upgrading to a later version of the product becomes more challenging because you’ll have to re-integrate your customisations. They may not be supported in the same way or at all, requiring rework.
Sound scary? Well, the above is worst case. But it is something that we have seen organisations get into because they have not approached each new feature with this overall approach in mind. Even products that support customisation well, can require man months of effort to re-integrate and test customisations if there are significant customisations present. While this time and money has little or no business value to your organisation, its something you may need to do on a periodic basis in order to keep to a product version that remains supported by the vendor.
Being conscious of the downsides of each approach is something that can help you make informed decisions throughout the lifecycle of your product. If you head down the buy route, we would suggest that you:
- Establish the most critical business processes in terms of importance to your underlying business vision, and then evaluate these down to each step and page within any candidate product.
- Perform some detailed due diligence to identify what customisations you might have to make.
- Restrict customisations that you are willing to perform to a small percentage of your overall functionality and identify and document any that you do to help with maintenance and support.
- If possible, share these with the vendor and ask if they could be included in a later version, to remove the potential headache of re-integration work.
Above all, be conscious of why you have taken the route you take and apply this to each subsequent design decision to understand the ramifications for later.
To learn more about what strategy might work best for your team and project, Contact Us. And sign up for our newsletter to stay informed of new articles, news and events occurring for Inviting Futures.