Many companies still cling to the ‘wisdom’ that they should always buy off-the-shelf packaged software if it is available, because "building custom applications is too risky, costly and time consuming."
By purchasing an off-the-shelf solution a company seeks to:
- Mitigate risk by choosing a proven commodity – assuming that an existing product has been well tested and is bug free
- Reduce overall costs by purchasing a ready-made product – assuming that funding a custom development project would cost much more
- Reduce the time-to-market - assuming that because the product is done, you can hit the road running
The answer isn’t strictly a lack of due diligence, as one would expect, but more often a failure to recognize the hidden pitfalls of an off-the-shelf solution.
Hidden pitfalls
Differentiation
Although this is somewhat obvious, it is still overlooked. If you use the same software as the other 17 firms in your sector you can only ever be ‘as good’ as them, and cannot achieve a competitive advantage differentiating you from the pack.
The fit
The most common mistake you can make, when choosing an off-the-shelf solution, is to over-estimate the amount of value a solution will offer in terms of matching functionality to need.
Relate these common estimation statements to their hidden meaning and they don’t sound as appealing as they did before:
- The solution fits most of our requirements…our employees will be mostly productive
- The solution fits some of our needs, but we can make do…our employees will be somewhat productive
- The solution has way more than we will ever require…our employees will take way longer to understand and use what they require
Part two of the fit is the realization (after the fact) that the fit isn’t good enough but because you have already invested a large amount of time and money you decide that you must invest more to customize the off-the-shelf solution in order to get what you need. You either pay the vendor outrageous rates to do the customization for you, or to save money you try to integrate it yourself (in-house) and spend a huge amount of time and effort to do so. Flexibility is a concern as off-the-shelf products can only accommodate so much in terms of customization as they must still service the masses. Some choices that are good for your business are cross-purpose to the main product offering and other client’s needs, and simply can’t be done.
Bundling
The most misunderstood danger of off-the-shelf solutions is the purported ‘integrated suite’, or product bundle. These are a number of disparate products ‘glued’ together to offer one suite of tools. Products that are not designed to work together are always inefficient, require the most amount of work to customize (since it requires knowledge of several disparate technologies to perform any customization), and are by far the most expensive to customize. Be weary of solutions that were not designed to work together but have been ‘adjusted’ to do so. Just like used car salesmen apply a new coat of paint to a junker to increase its value, old software is often recycled as suites or bundles. Did the vendor create the products or did they just purchase them from different companies and then brand them as one package?
Desupport
While the goal of any firm is to amortize software purchases over a number of years to maximize your return on investment, software vendors have opposite goals. It is seldom in a vendors’ best interest to continue to support older versions of their software. Number one, the costs are too high for a firm to maintain in-house knowledge and expertise on multiple versions – especially versions with few customers. Number two, as licensing is only a supplemental revenue used to fund support, they can only generate new revenue by enticing you to purchase or ‘upgrade’ to the newest version. One such tactic is called ‘desupport’ where a vendor will threaten to no longer support your version forcing you to move to a newer solution making it difficult to achieve a full return on your investment before the next investment.
How to choose
Should all solutions be built instead of bought then? No, certainly not.
Use these guidelines when deciding whether to build or buy:
- Will we gain a competitive advantage by getting a solution tailored to our way of doing business?
- Does the software perform the functionality the way we do it, or will we have to adjust our business to match the software?
- Does the solution meet close to 100% of our requirements without customization?
- Are there one or more vendors completely committed to supporting this product?
How does it measure up to our guideline?
- There is no real competitive advantage of having an accounting package tailored to your business since accounting practices are virtually the same regardless of business type.
- The software is designed around actual accounting practices that have been in use over hundreds of years, so it is doubtful you practice accounting differently.
- The software should offer 90-100% of the required functionality without customization (be careful not choose a package that offers 'way more than you need' though).
- There are many reliable vendors that have been around for a long time.
A good rule of thumb is the more something is specific to your business or industry, i.e. specialized, the more customization will be needed. Specialization = Customization.
Strategies
The line between build and buy isn’t black and white though, and there are many shades of gray in between. We have identified 5 key strategies that encompass a range of solutions and help you to decide when each strategy is appropriate in order to obtain the robust solutions you require, while still reducing your time-to-market, and seeing more of a return on your investment.
Application Simulation
Turnkey Solutions
Kick-Start Applications
Custom Development
Application Integration
Sometimes you don’t know what kind of solution you require. You need to explore possibilities, find out where your biggest return will come from, and firm up your requirements before you even start looking to build or buy.
Application Simulators can help in this area. You can model your existing business processes in a simulation, and then ‘play’ with the model to find out which processes could be improved, what happens to your overall productivity as you make changes to the different areas of your business, which areas will offer quick wins, etc. Best of all you can afford to make mistakes - ideas that don't work out are simply discarded.
Similar to a prototype, application simulations are a fast and cost-effective way to figure out what you need before you build or buy.
Strategy One is to use application simulations to fully envision needs requirements, preferably using a tool that can be used by analysts and architects (no programming ability required).
When time to market is THE most critical factor, and all other considerations are secondary, an off-the-shelf (turnkey) solution is the fastest option.
If your company is already behind most of your competitors, then it’s a matter of survival and purchasing a turnkey solution may be your only option.
Evaluate each potential solution, attempting to find the best fit, but you may have to compromise somewhat on functionality.
If that is the case, try to choose a product or solution that can easily be extended or customized. Products that are designed to be extensible will offer you the quick win now, and the flexibility to grow in the future.
Strategy Two is to purchase turnkey solutions when time to market is the primary concern, but choosing solutions that are designed to be extended.
Many times a solution will provide 'most' of the functionality you require, but you know you will require custom additions, changes or enhancements from day one.
Off-the-shelf solutions do not offer the best choice in this scenario since customization will be very expensive and time consuming (often negating the benefit sought from purchasing an off-the-shelf solution in the first place).
Application Blueprints, or templates, are a functionality road map designed to provide a starting point allowing a customized application to be built more quickly.
Much like the blueprints for a house, or a document template in Word, these are not finished applications but application road maps that outline the base functionality allowing you to concentrate on only the additional requirements.
It is important to note that most existing applications do not serve as good blueprints or starting points. Only applications that are designed to be extended are easily extended. Adapting existing applications that were not designed to be extensible often requires more work than building it from scratch.
Strategy Three is to use application blueprints or templates when similar applications provide some of the functionality required, but not all. Customization will be required but you will get a head start reducing the time to market considerably.
When you have used the guideline to evaluate existing solutions, and come to the conclusion that they don't match enough of your needs without customization, or they don't offer any competitive advantage because they aren't specific enough to your business, or you will have to retrain your personnel in order to use the available software then it makes sense to develop a custom solution that completely suites your needs.
Does that mean you have to compromise on your original goals of reduced risk, reduced cost, and reduced time to market? Not if you make use of an application framework.
Application frameworks are tools and techniques used to develop custom applications in a fraction of the time it normally requires by leveraging a comprehensive set of existing functionality. With common application functionality already complete, the development efforts can be concentrated on just the business-specific functionality you require. Since a large portion of the code is already done and tested, your risk is much less and the cost of a custom application that meets all your requirements will still be cheaper than modifying an off-the-shelf product.
Furthermore, by using the same framework for each subsequent solution, you will reduce your overall cost and guarantee that all your applications will interoperate.
Strategy Four is to develop a custom application using an application framework when specialized requirements are needed.
Some companies have a very large amount of legacy technology and replacing it with either an off-the-shelf solution or custom development will take too long or cost too much.
In this case Enterprise Application Integration (EAI), the process of integrating legacy applications together to form one integrated suite, is the only feasible option. Didn't we say to be weary of bundles? Yes, they are more inefficient, but in this case an EAI initiative is the only way to integrate the disparate applications into one cohesive unit in a timely, cost effective manner. The advantage of interoperability and shared data outweighs the disadvantage of the lack of integration by design.
EAI is made up of two fundamental concepts: unified process management, the ability to manage all processes across all systems in a similar manner, and data synchronization, the ability to synchronize data across all systems.
Common EAI design patterns address those two concerns with the Publish/Subscribe design metaphor, and suggest a process bus (facility to manage processes uniformly) and a data bus (facility to synchronize data).
Useful tools that implement the publish/subscribe metaphor are workflow/business process engines to manage the processes, and publish/subscribe data systems to handle data synchronization. Another key technology in EAI is the use of XML transformations to replace the expensive and outdated EDI transformations.
Strategy Five is to use business process engines, the publish/subscribe metaphor, and xml technologies to implement EAI solutions when legacy components must be integrated together. A system that also supports web services is also desirable, offering further flexibility with regards to legacy integration/abstraction.
info@sabertooth-interactive.com