Four Levers – One Goal: Options for IT Modernization

Four Levers – One Goal: Options for IT Modernization

Migration, new product development, standard software, outsourcing – or perhaps a mix? My decision guidance for your IT modernization.

In my last blog post, I illustrated the central challenges to IT modernization and concluded that due to growing lifespans, legacy systems can increasingly become liabilities. Have you also come to the conclusion that your applications and development technology need to be modernized, and have you worked past all concerns that stood in the way of reorganization? Then it is now time to consider the “how”.

I have already presented four strategies of IT modernization to you in the form of an infographic, and would now like to delve deeper into the matter.

Blog posts on the topic of IT modernization

  1. 4 Ways of IT Modernization
  2. IT Modernization – Yes or No? A Checklist
  3. IT Modernization between Necessity and Skepticism
  4. Four Levers – One Goal: Options for IT Modernization

Would you agree?

How modernization is executed depends on many different factors – from strategic orientation through the importance of IT for value generation or products and the degree of digitalization in the company all the way to the parameters vertical integration and resources. Each alternative for modernization presented in the following has its pros and cons, and the provided sample statements are intended to help you determine the option best suited to your needs.

1. Migration

  • I’m generally satisfied with my application (processes, data set, functionalities etc.).
  • The technology is too expensive and inflexible and/or the expertise of the employees is insufficient.
  • The software illustrates processes that are among the core processes for my company.
  • The relevant company-specific processes cannot or should not be mapped in a standard scheme.
  • Due to requirements specific to the market or the company, freeze times must be kept to a minimum.
  • The software documentation is incomplete or not up to date, which means a reengineering would be necessary to ascertain the complete functionality of the software.
  • The project duration must be short in order to avoid having to implement two systems for a longer period of time or delaying requirements for extensions/changes.
  • In order to be able to easily exchange the technology stack in the future, independence from platforms (e.g. application server, database) is desirable.

2. New product development

  • The legacy system can no longer be supported.
  • The legacy system does not meet the needs of the company, neither with regard to functionality nor to processes and data.
  • The application is supposed to provide competitive advantages in the market through opportunities for differentiation.
  • In order to facilitate value generation, differentiating market requirements need to be able to be implemented in a quick and agile manner.
  • The new product development will not bind up the company’s entire innovative potential.

3. Standard software

  • The business process is not part of the company’s core competencies and using it as a means of differentiation in the market is not desired.
  • The provider of the standard software has a standard model regarding customization/adjustment (e.g. customizing modules, process automation, generation etc.), which also enables flexibility and agility.
  • The pricing model (procurement, customization and maintenance) is more attractive than that of migration or new product development; the provider furthermore occupies a stable position in the market and is suitable for the own company regarding its structure.
  • New requirements can be met by an existing solution (with a minimum of customization efforts).

4. Outsourcing

  • The partner does not just offer outsourcing, but also IT modernization and the option of re-insourcing.
  • The IT-technical implementation of (specialist) business processes shall no longer be realized within the company.
  • The business process is standardized to a degree that makes a relocation of the business area profitable under consideration of the transition costs.
  • In the foreseeable future, the relocated business areas or processes will not be among the company’s core processes.

Avoiding rash actions

Different arguments usually support one option or another– which is why you will often find a mix in practice: for instance, within automated migration, it is possible that certain application components are realized through a new product development. I would like to refer you to my colleague Anne-Kathrin Hanisch’s blog post “Software development: Buy or mAKE? Just BAKE!” in this context, as it takes a closer look at this approach.

In general, the growing market requirements, which are intensified by digitalization, lead to an increased demand for modernization and updating and in consequence to shorter release cycles. This favors approaches which only require short periods for modernization and which do not or hardly impede the further specialist development. Unfortunately, instead of examining alternatives in detail, rash decisions based on the wrong reasons are still often made in reality and lead to increased efforts in the best case and a complete failure of the modernization project in the worst case. So make sure you set sail successfully!

 

Picture credit: Shutterstock

Leave a reply

Your mail address will not be published. Required fields are marked with *.