Software Build vs. Buy: What's Best for You?

Please note that all DMS news and blog content has been moved to the main website at www.dynms.com for a categorized view.

All utilities and downloads are available at www.dmsiworks.com

I’m currently in the process of buying a new house.  I have two options: buy an older home that has as many of the necessities I’m looking for as possible, or build a new house that is customized to my preferences.  The pros and cons are obvious for both, but making a decision between them is not quite that easy.

Assuming I can find something in my price range, the time until I move into an older house is relatively short.  Once possession is negotiated and my mortgage cheque (hopefully) clears I’m a proud homeowner.  That being said, I may have to renovate the property to achieve the actual aesthetics and functionality I’m looking for.  Still, someone else has done the hard work and I’m happy to sacrifice personalization for predictability and simplicity.

On the other hand, building from the ground up ensures that I’ll have everything I want in a house, right down to the beer taps installed in my man-cave.  Sure, I’ll have to wait over a year (or longer) to see my plans come to fruition, but in the end I’ll pay a little more in terms of time and money to get exactly what I want and need.

If you've had the opportunity to work with, or in, the software development industry you will inevitably be involved in arguments about whether or not to build or buy.  If you're a customer you might not have even been aware there was an option.  Much like buying a house, choosing whether or not to customize the system to your needs is based on a multitude of factors and needs to be made on a situational basis.

All About Building:

Building a custom solution is appealing.  On paper you get functionality closer to what you want, you can limit process changes, and adapt the system to fit you.  For specific problems, or company specific problems, doing a custom build is often the only option.

Custom builds sound great, but what are the gotchas?

• A custom build will take longer to get the solution operational.  Is this an issue?  If it is, how much longer?  If it takes a year to build does that really matter to you?  If you need a solution in place because you're bleeding operationally then this is probably not the approach.
• If you're building with external contractors then make sure effective communications are established before starting.  What needs to get done is like playing a game of telephone: by the time a requirement gets from the person through analysts and requirements spreadsheets, all the way down to the programmer an original feature request could have changed.  (Agile methodologies or shorter project iterations can help with this by enabling more frequent feedback).
• How much of your internal operational people will be affected for requirements gathering, testing, and training?  Remember that it will often be your key people that have the right information about how things are done now in addition to how they should change.
• Who will be supporting it?  If it's internal people building it will you be able to dedicate some of their time afterwards to supporting the system?  If you're hiring external then is the support contract something that is affordable?  Did you remember to include this new support in your budget for the next quarter?  If communications break down between yourself and the contractors that built it, will you be stuck with a re-build or can somebody else take it over?
• Will you own the source code that it was built with?
• Are there any frameworks that can be leveraged?  Will it built from scratch, or can you leverage other existing solutions to extend?  Are there any frameworks that you can use or 3rd party components that can be purchased?  
• If you're building internally does your company have the appropriate skills to build it?  If you apply your employee turnover rate to that department will you still have those skills by the end of the project?  What about a year after it's deployed and it's now broken?

If you're using Dynamics NAV, AX, or CRM many of the risks from custom built solutions can be reduced.  It's often shorter to develop a solution on top of Dynamics, mostly because these systems are frameworks that allow you to focus on the business problems.

External contractors could be changed more easily.  For example with Dynamics NAV the source code is in the system so you need to worry less about IP, and there is a large ecosystem of NAV solution providers to work with.  This should reduce future support concerns and provide options for future maintenance.

All About Buying:

Buying a solution is appealing.  It's a one-time predictable cost, which is often easier to budget and get funds for.  There is often existing support systems in place for products, including documentation and training.  The impact to your operations during deployment is minimal, because you're not taking your key people away running your company.  There will also likely be less issues post-deployment, because as a product it will have been installed many times before and many product issues will have already been worked out.

Buying sounds great, but what are the gotchas?

• It is very unlikely that the add-on will meet 100% of your needs out of the box.  Can your processes change to work with the system?  Or could you extend or customize the product to fit that gap?
• If the product breaks what does support look like?  It is more easy to change your own employees time to fix an issue immediately than it is to call somebody outside your company, escalate the issue as necessary, and find the right guy to balance that time with.    
• If you're not buying an add-on that works in an environment like Dynamics NAV, what upgrades and patches will work?  Has the vendor committed to a specific product roadmap and demonstrated that they are living up to those promises?
• Buying means it's already been done before, which should raise a flag if you're thinking of buying to get a functionally competitive advantage.  Do not be under the illusion that the same product that you're buying that has some features that currently leapfrog your competitor are out of reach of your competitor. 

Like building, by using an environment like Dynamics NAV these risks can also be reduced.  Many add-ons can be further customized be other consultants, and by the open nature of how the code is produced Dynamics NAV even products that have reached end of life can still be supported an further customized. 

You Have Choices:

If you're already in the Dynamics ecosystem then you have choices, and those choices are easier than most.  Many Dynamics project extensions are often hybrids.  Usually a consultant will try and find an add-on that will meet most of the requirements, and then do custom integration work to tie in the rest.

There is a plethora of add-ons for Dynamics NAV, AX, and CRM that enable you to buy off the shelf.  Many of these add-ons also enable you to customize the rest.  Since Dynamics NAV often has many ways of interacting with the system even solutions that aren't "in" Dynamics NAV but around it can more easily be changed.

To make the decision you need to remind yourself how your business operates.  

• Is your technology keeping up with your business now?  
• Does the solution you need provide you with a competitive advantage?
• Do you need the capability now, or can that capability be delayed with more importance on it being more specific and correct?

Tim Dimsdale
Dynamic Manufacturing Solutions CodeProject