Blog The 5 upgrade headaches (2 of 5): Migrating customizations and integrations
Continuing the theme of upgrade headaches this week we look at the impact of customization and integrations.
Every organization is different and it is common for organizations to have unique requirements for their Service Desk and ITSM applications.
The business needs the technology to behave in a way that supports the existing culture and processes of the company. Not all ITSM solutions offer the same functionality, so the difference between an individual organization’s requirements and the functionality of the vendor’s offering will dictate the scope of customization that will be required.
Ultimately, there is a choice to be made between commissioning/developing a custom ITSM application and purchasing a commercial off-the-shelf product. In the majority of situations (taking into account the maturity of tools in the Service Desk market) developing an in-house solution is not a viable option; it is more economical to acquire the functionality needed by customizing an off-the-shelf solution.
The way in which functional flexibility is achieved differs from product to product—from the framework vendor solutions which are in some ways more similar to application Integrated Development Environments (IDEs) than applications themselves, to the configurable out-of-the-box solutions that are less technical to use and deliver rapid value to organizations with relatively standardized requirements.
Methods of customization vary from product to product and can be achieved through parameterized configuration, visual design tools, scripting engines or hard-coded changes applied directly to application source code.
It is prudent to consider how the means why which you get value from your software is obtained and how this affects the cost-value relationship. A requirement that is satisfied by out-of-the-box functionality will deliver value efficiently, with few issues experienced at upgrade-time. A requirement that is met through codeless configuration will deliver value, but at a higher cost (as system admins must take time to set this up). Requirements that must be supported by customization of the codebase will be exponentially more expensive. It is important to consider whether code-based customizations are really worth it in the long run, or the technical debt they create is disproportionate to value.
Problems can start to occur as soon as an organization is using custom functionality that creates new or modified source code. As these fall outside the scope of the vendor’s core solution architecture, customizations are not covered by vendor agreements and as such are not supported to the same extent as core off-the-shelf functionality, if at all.
When an organization faces an issue with its customized solution, it is difficult for the vendor to replicate the problem and it takes exponentially longer to identify a resolution—with an obvious potential for unwanted impact on the business. For this reason, some vendors simply will not support customized solutions, leaving customers to rely on independent consulting firms and the user community for assistance.
For some ITSM solutions, the impact of customizations and integrations is so great that it prohibits the organization from upgrading the product. Unless the vendor is mindful of customizations when developing new versions, the migration process can be laborious.
If customizations do not integrate well with the new version, they cannot be directly ported across and this often requires a complete reimplementation of customizations on the new version. In some extreme cases, the effort required to redevelop business-critical customizations in a new version is so great that the business risk of upgrade failure is prohibitive. The impact from loss of custom functionality potentially could be so disastrous and costly that it cannot be considered, and the organization is locked into its current version.
In this way, an organization is prevented from accessing new features and functionality developed by the vendor, and will be forced to develop and support the software itself in order to meet changing needs. It is at this point that the organization should strongly consider going back to the market to identify a toolset that better matches its requirements.
The one thing to remember is – complexity today breeds problems tomorrow. Especially if the people who are making the decisions and doing the work today might not be around to consult with when it comes to upgrade-time.
You can read more about the 5 upgrade headaches in this whitepaper: