IS modernization: kinds of move

IS modernization means replacing IS components by other components which, while delivering the same functionalities to end users, bring business advantages or costs kills, or reduce business risks. IS evolution that brings new functionalities or an adaptation to an enterprise organisational move is not called IS modernization but… IS evolution!

• Business advantages: reducing time to market by improving response time, enabling the IS to support new sales channels, opening the IS connectivity toward business partners…
• Cost kills: getting rid of expensive software/hardware maintenance contracts, moving to IT areas where specialist people costs less, improving maintenance tooling efficiency and so reducing maintenance costs…
• Reducing business risks means moving away from a technology that has reached an end of life point: no more support from software providers, no more resources available in the market (human and material)…

Several kinds of IS modernization moves co-exist: rewrite, migrate, re-architecture, replace. They usually don’t apply to the whole system but to a set of applications.

• Rewriting an application usually means that the existing source code will be considered as a documentation source for the target application. The rewrite can be total or partial, will use a different technical architecture for the rewritten part, and will need new specifications (quite often the original ones are out of date). The key point is that it will be very hard to stay into the iso-functionality track as part of low-level functional comportments have a good chance to stay and remain between existing source code lines and nowhere else. On another hand, rewrite allows to combine IS evolution with IS modernization.
• Migrate means translate the existing source code into target source code. While algorithms will remain the same, software architecture usually don’t. That’s why migration is almost never just a matter of translating a programming language or dialect into another. The idea is: deduct the target architectural structure that match both the source application functional organization and the target IS architecture constraints, then put in it the algorithms extracted from the source code (in this step the programming language translation may be used). The gap between source and target architectures may be small or very huge, and there is a lot of transformation techniques which may apply. These techniques can often be partly automated: although one can imagine to migrate “manually” the ROI will be far better will the help of dedicated migration tools. The key point is  that a migration move has to be iso-functional, iso-bug and iso-GUI to keep costs at the right level.  If IS evolution may apply, it has to be in a second move.
• Re-architecture means adopting a new way to organize application layers and components while keeping the same IT environment and programming language, and delivering the same functional services. A typical use case is moving into a service oriented architecture. Re-architecture may be considered as a migration move without the algorithm/programming language translation step.
• The replace move intend to use an existing component in place of the replaced one. The replacing component may be found on the market shelf, or somewhere else on the enterprise IS shelf. The existing source code may eventually be used as a specification for customization of the new component, but it is highly expectable that the modernization iso-functional requirement will not be respected. So, apart for enterprise functional commodities available into ERP modules, the replace move is an IS evolution move, not an IS modernization move.

If existing in real life, a pure modernization move has to be able to support an automated process. These modernization automated processes almost never reach a 100% automation level but provide enough cost gains to enable the modernization move in terms of ROI.