Is it Out-of-The-Box or Customized Application? Think Upgrade!
Pravin Kothari
Another way to determine if an application is OOTB or Pre-Assembled is to look into the upgrade history of the application. The biggest issue with Pre-Assembled applications is that they quickly turn into custom applications. As business requirements evolve, the customization usually gets more extensive. Why is this not necessarily a good thing? Customization is almost never supported by the vendors. At best, vendors will provide “best-effort” support for area of the application that has been customized. Ultimately, there is the inevitable upgrade challenge. Attempt to upgrade a customized application more often than not turns into a complete redeployment. Redeployment is obviously time consuming and expensive. As I have said many times now, as long as that is a trade-off that is understood upfront and is a desired trade-off, then there is nothing wrong with selecting a RDP based application. Too often, we see companies unknowingly go down the customization path and be surprised with the effort and cost associated with such a strategy.
A customized application is expensive to the customer, and can be equally expensive to the vendor. Patching, new feature design, platform certification all become exponentially more difficult as the engineering team now has to account for more variations and unknowns in the install base. The fact that customers cannot upgrade easily, usually results in the vendor supporting many different versions of the product. Even very old versions still need to be maintained because it is required by important customers. There are numerous stories in the software industry about vendors struggling to support legacy products because all the engineers that worked on the legacy code had left the company. New engineers support the product by reverse engineering the legacy code. The solution to this problem is usually to ask the customer to buy more consulting services or premium support.
Upgrading a customized application can involve dealing with any of the following, ranked in increasing order of difficulty:
- Manual apply the upgrade and migrate your data because vendor’s upgrade tool is not compatible with the customization.
- Re-apply all customizations after automated or manual upgrade
- Update customization due to changes in data schema
- Update customization due to changes to API
- Update customization due to changes in product behavior
- Update customization for past workarounds when new features are introduced
- Update customization that uses undocumented API
- Difference between new vendor code and custom code to figure out what has changed and merge customization into new vendor code
If you are looking for a OOTB product, then you should ask deeper questions about upgradability during the product selection process. The answers will help you calculate the total cost of ownership over the long run. Ask the vendors and check with customers who have been using the product for at least 2 years and have done at least one major version upgrade. Some questions to ask:
- How many different versions of the product are in use? A true OOTB application should have no more than 2 major releases, each with a couple of minor releases still in production.
- How long does a typical upgrade project last? Is it a few days or weeks, or is it more like 3 to 6 months or even longer?
- What percentage of customers use the latest major release? It should be over 50% six months after a major release.
- What percentage of customers has successfully upgraded without using paid services?
One lame response you will often hear from vendors when justifying why their upgrade statistics are less than stellar is that while their software is easy to upgrade, some customers just do not want to upgrade. Every customer I have ever met, especially for emerging market such as GRC, wanted to upgrade to the latest version in a timely manner. Customers who put off upgrading for a long time do it for a simple reason: the pain of upgrading outweighs the pain of living with old software. It’s as simple as that.
Hi there
Iam not sure about OOTB in agiliance, i like your article, however in a OOTB approach should not be more Wizards and templates for more industries? as many customer is asking about it?
sometimes you get very frustrated trying to implement Agiliance and no template or wizard is available.
regards
OOTB is an architectural approach. Content and template obviously will make deployments even more easy. Quality content and template need to be vertical specific or domain specific. Unless a software vendor has the size of Oracle or SAP, it cannot bring vertical expertise from every vertical, or even most major verticals. This is where partners play a key role. Partner bring vertical and domain expertise to an deployment. Agiliance has some very key partners, both large and boutique partners.
Nice article Pravin – this is an excellent read for anyone looking to purchase an enterprise application.
In my experience, I have seen two classes of enterprise applications. The first involve those built on an application platform (like SAP, Oracle Apps, etc) – and the second that are fully-custom developed each time around.
For the first class of applications – there are about two or three ‘levels’. First, there is the application platform or infrastructure itself. This can include web servers, workflow engines, portal infrastructure, presentation & reporting engines, etc. Then come the pre-assembled applications based on this infrastructure. And finally, there is ‘content’ which can be loaded into the applications.
I tend to see platform & infrastucture upgrades as critical to ‘stay in touch with the times’.
Modifications to the applications themselves tends to fall along the lines of what you have written about. Basically – if you REALLY want to do it – then do so with your eyes open. There are rarely ‘magic bullets’ that will let you customize the application logic AND upgrade easily too.
Upgrades to the content make sense only you have not directly modified & repurposed the content to your own specific purposes. In cases where content is reference material, pre-built data connectors, etc – then the need for an upgrade path is clear too.
Regards.