For the next 5 weeks we’ll be looking at the 5 key issues that cause application upgrade headaches and some strategies for how you can avoid the pain. This week, we look at application complexity.
Many IT Service Desk and IT Service Management (ITSM) solutions offered by the framework vendors comprise a patchwork of acquired technologies built up over the years to provide comprehensive ITSM functionality. Instead of expanding the native functional footprint to meet customer needs through organic development (which naturally leads to more cohesive solutions) they have acquired smaller technology vendors and integrated these products into their portfolios. As a result, the applications form a complex network of software components with their own platform and hardware requirements.
In many cases, each of these modules must be upgraded individually (in the correct logical order) to achieve a stable system and overall upgrade success. Individual modules may also have their own research and development cycles, product roadmaps and upgrade processes, which together combine to create a very difficult and complex upgrade project—and this is before taking customizations into account.
When one manager of a certain framework vendor’s ITSM solution was asked to map out a project plan for upgrading to the latest version, he came up with this:
Milestone 1: Begin
Milestone 2: False sense of hope
Milestone 3: Unwelcome sense of reality
Milestone 4: Depression
Milestone 5: Desperation
Milestone 6: Quit your job
Milestone 7: Go fishing
The impact of upgrading a framework vendor’s ITSM solution is a long and arduous upgrade project, which can last many months or even years. The effort involved, combined with a lack of internal IT resources and the vendors’ inability to support their own customers, has resulted in third-party consulting organizations entering the market to manage and support clients’ upgrade projects. The complex architecture has created a problem for which a consulting market has sprung up.
Engaging a consulting organization equates to a huge capital cost that further adds to the Total Cost of Ownership (TCO), reduces Return On Investment (ROI) and decreases the business value of the solution by impacting end users over an extended period of time. If the upgrade project disrupts the operation of the service desk and IT support, downtime gets stretched out and the business starts racking up significant losses – for which the IT department will be blamed.
On top of this, the complexity of the solution means there is considerable potential for the upgrade project to fail entirely and force a complete reimplementation, which could last another 12-18 months.
The key to an easy upgrade is to think about how the application architecture will help or hinder you when it comes to upgrade time. As a general rule of thumb, a simple application architecture means a simple upgrade project. Applications with modular architectures are more complex and involve working with a greater number of “moving parts”.
You can read more about the 5 upgrade headaches in this whitepaper: