At a time when IT is being driven to deliver business benefits at an ever increasing pace, justifying a costly modernization programme, with relatively small tangible benefits, can be a daunting task. Opposition can come not only from within the business, but also from within IT itself.
Most large organizations have stringent financial controls around large projects, with demands around a three or five year payback. In cash terms, a modernization project can rarely deliver to these targets, however, a creative programme manager can put together a compelling case based on hard facts and future projections.
The following list is a “Top Ten” of areas to look at, but it is by no means exhaustive, and many organizations will have their own unique circumstances to justify the cost of modernization.
- Vendor costs. In some cases, for instance database migration, this can be the biggest single benefit, particularly if an organization already has an instance of the database being migrated to. Other areas to consider here are ISV licensing costs. For instance, can annual costs be reduced by changing platform and/or tooling?
- Skills. The reasons for modernization are numerous, and one of the most prominent is the ageing technology. With this comes a diminishing pool of skilled resources, both internally and in the marketplace. Training in older technologies can be hard to obtain, and can also be varying in quality, with, for instance, ex programmers turning their hand to training as other opportunities dry up. Internally, staff can be very protective of the systems and technology that they have nurtured over many years, however this should be seen as part of the problem rather than a reason not to do it, with training in newer technologies being a motivating factor for the employees. The danger of retaining the technology and the staff is that eventually the people will move on or retire, whilst the technology will remain, eventually becoming unsupportable.
- Staff. Cross training staff to the latest technologies can be expensive, with the added danger that the newly trained staff will suddenly become much more marketable. This can be seen as a major risk, however, on the positive side of this argument, an organization that embraces newer technologies and keeps its staff well trained is far more likely to attract good quality candidates from the marketplace.
- Strategy. In a world where complexity seems to increase almost daily, how agile (with a small ‘a’) are your systems? Compare the cost of building function points in newer technologies against existing, particularly around the areas of integration. Can the current database be easily accessed by the newer applications? How difficult was the first integration exercise? As newer technologies become more widespread, this integration is likely to get harder and more costly.
- Local knowledge. This can be one of the biggest blockers to modernization, as “only Johnny knows the application”, but Johnny has a vested interest in keeping his knowledge to himself and is very much against the modernization approach. This can be especially true where a third party is involved in the modernization project, as the “we can do this ourselves” mentality kicks in. In these cases the modernization should be seen as a learning exercise, with the local knowledge being spread across the project team as part of the testing effort.
- Vendor Support. When was the last time you saw your sales representative or got invited to a user conference? Is the vendor still in business and are they still actively enhancing and marketing the product? Is there still an active user community? Lack of product development can often be dismissed as “it works so we don’t need it enhancing”, but this can be a very short-sighted approach. For instance, does it take advantage of 64 bit architecture or is it still languishing in 24 bit mode? At some point, as operating systems get upgraded to faster and more functionally rich versions, legacy applications or databases may simply not be compatible and will stop working, effectively halting the upgrade of the remainder of the estate.
- Product stability. Where modernization is required, the product is often very stable and this is not really an issue. However, if thereis a problem an organization can be exposed if the only support can be obtained from the local knowledge (see above). If a problem is encountered in a product that is being actively developed and marketed, it is almost certainly going to attract the full attention of the vendor, as well as having recent knowledge of the application or product within internal project teams.
- Tooling. Major tools vendors will ensure that their tools will work with all of the latest developments in platforms and technologies. The productivity gains provided by, for instance, automation tools can be significant, but that is another discussion. The point here is that with older technologies and platforms there is not even the option to purchase tooling as, in many cases, it is quite simply not available.
- Training. The case for training is very similar to that for tools. Most vendors will provide training as part of an implementation and rollout strategy. In the case of your older technologies, this training is quite likely to be non existent, or is provided by an ex technician who has decided to turn their hand to training. Sometimes this can be beneficial as the trainer passes on a wealth of knowledge, but do they really have the training skills?
- Cost of doing nothing. Add all of these points together and a robust case can be made for modernization. The most compelling is probably the implication of putting off the exercise. In five years time the people who can help in the modernization effort, both internally and externally, may not be around. The platform or technology could well have become so outdated that it inhibits business growth, and whilst there is still the capability to make enhancements, these are becoming increasingly difficult and more expensive in terms of system knowledge and complexity of integration.
