Customization… and beyond

In the last post we described Customization and Configuration, two different approaches that change the behavior of a standard application to addresses customers’ unique needs.

In this post we take a closer look at the ramifications of modifying and maintaining custom software.

Maybe you heard that customization is complex and expensive, but worth the effort – they say that tailor-made software is the best solution to all your business needs.

Upfront expenses are expected by organizations asking for customization of any kind.  There might be some room for negotiating discounts here, but usually vendors can present hard evidence of what drives the cost up.

Programs are sets of instructions, written as many lines – thousands, millions –  of code.  The format and structure of these instructions follow very strict rules.  One part of code can call another, so the interdependence and resulting flowcharts can resemble convoluted spider webs.

Tampering with just one line can bring the whole application to its knees.  Software providers release new versions to the public after arduous and thorough testing cycles are completed.

Customization involves additions and modifications to the standard program.  It introduces a greater opportunity of defects.   Not to say that the customization itself is a dangerous undertaking and will result in a disaster.  The software provider will perform necessary testing and fix any bugs.  This is what the customer paid for.

However, unlike standard releases, the customized application may include a few undiscovered hiccups, special cases and undocumented features that are not caught by the manufacturer.   You should involve your own experts to perform additional testing to catch all the nuances.  Your expert resources add up to the cost of the project and are not included in the customization quote.

This can also be the case with configured software as well.  You need your internal experts to test it.   However, in customization there is no magic “undo” button.  Reverting to the older version may wipe out some good custom features.  In configuration, testing is more straightforward. There is no risk that the third party – the manufacturer – misunderstood your requirements and coded features that shouldn’t end up in the application.

Eventually, after the customized product is tested, it is put into the production.  Your team is finally using it.

You will have to wait for a custom patch or a confirmation that a standard patch can be applied to your version.  Perhaps other customizations need to be disabled and re-implemented later.   You may be slapped with a customization price again.  Check your contract with the software manufacturer.

To avoid all these headaches, you may decide that the customization is not crucial and you want to proceed with a few standard patches going forward, overwriting the custom code.  Even this – seemingly cost-cutting – decision requires either more development research and testing.  Again, you will need a team of experts on your side to test any updates, because your software is now unique.

Maintaining a customized application is even more complex and costly if that software is a SaaS (Software as A Service) product.  Customization is not common in the SaaS world.

What is SaaS and why should you care before entertaining customization?  In SaaS world, multiple customer organizations, also called subscribers or tenants, use the same application that is stored somewhere “in the cloud”, using the most sophisticated and secure infrastructure.   When these customers use the application, they are given access only to their data – usually residing in a central database – and run the same code, i.e. written for all subscribers.  There are slight variations in the SaaS landscape out there, but all SaaS “share some resources.  Even if the databases are split, they must have the same structure, so the program always “knows” where to look for data.

SaaS has many benefits.   One of them is no IT overheads and smooth upgrades of standard versions, performed by the provider without disrupting daily operations of the customers.  Standard patches are applied to standard versions transparently.

You have a customized product, so it won’t be that easy.

A customized version of SaaS software will be maintained separately, probably on a separate server or by introducing an insane number of switches (if/then). The ongoing cost might cover not only patches and upgrades, but also the additional server resources and maintenance.

The more customization you have done, the more work it is to maintain such product version.

Some customers decide to opt out from any upgrades to their customized software.  If a single custom patch is problematic, imagine the scenario of having a major upgrade.  The reason for avoiding any upgrades is not only the cost, but also a risk of potential interruptions to daily business.   There is a chance that something goes wrong.  However, deciding against upgrades will end up with an outdated, or worse, an unsupported version of the product.

Before asking for customization, identify what functionalities are crucial.  Don’t try to design the new software to resemble the old one.  Ask for free trials, take them for a spin, and talk to the vendors to find out how your needs can be addressed by configuring their standard product.

Make sure that the customization delivers realistic and vital value to your business, estimate the full cost and assess all future risks. In the next post we will look at using configuration as an alternative.