Application Modernisation

With so many other matters pressing for attention, the argument for Application Modernisation has to commence with timing. One element of timing that has affected applications over the years is the point-in-time functionality that exists with application implementation. Applications are implemented with two constraints. The first of these is available technology. In the broadest sense this will encompass what any given application can achieve. For example, document storage and retrieval has undergone rapid improvements, applications implemented five years ago (state-of-the-art then) will now be seen as slow, ponderous, and unable to match the functionality of more modern applications.

The second constraint is the business need at time of implementation. Technology in general, and applications especially, were introduced to match a business strategy; to aid the business in cost-cutting or revenue generation based upon a strategic plan. A prime example of these would be early ERP or SCM systems. The supply chain model has undergone major change in the past several years, and those organisations that are tied to applications unable to respond to that change will be operating at a disadvantage.

It is worth noting for this last example that we are not talking about changes in technology, but in the way that business is perceived and carried out. External forces demand change within organisations, and the applications in place are not always best-suited in their present form to respond to those demands. The key here is the phrase `in their present form'. No-one would recommend a wholesale change of applications every time a new requirement arose or every time new technology became available. What is required is a method of ensuring that while the incumbent applications might not be considered `state-of-the-art', they can at least answer the majority of the issues raised by new models.

The counter-argument to this has always been that LOB or critical applications must not be touched, they are running the company and should be left strictly alone. Several years ago we were all affected by that attitude. The applications that were 'too important' to touch because of the 'if it isn't broken, don't fix it' attitude, were found to be broken. This breakage was not in the sense of any inability to work within new business models, but fatally broken in terms of Y2K.

Mention of Y2K is important from the aspect of what was discovered alongside the hunt for date-related code. This discovery was that very few people really understood what the code was doing. Very few organisations overcame the Y2K scare by going to documentation that pointed to the relevant sections of code.